[agent] Master AI Agent
2025没怎么卷，2026初发觉已落伍颇多，现迎头赶上。
劣势是近期事多；优势是AI科班出身，底子厚。
这是历史唯物主义的产物，上古时期的脉络可以参考: https://www.cnblogs.com/jesse123/p/18388709
| Feb 7 | ref: https://www.youtube.com/watch?v=M2Yg1kwPpts title: 【生成式AI時代下的機器學習(2025)】第二講：一堂課搞懂 AI Agent 的原理 (AI如何透過經驗調整行為、使用工具和做計劃) |
2023 Currently, LLM Agent, tool usage. reward -1 log as input |
| 8 | ref: https://www.youtube.com/watch?v=Xnil63UDW2o title【生成式AI時代下的機器學習(2025)】第三講：AI 的腦科學 — 語言模型內部運作機制剖析 (解析單一神經元到整群神經元的運作機制、如何讓語言模型說出自己的內心世界) |
单一神经元的功能判定，类似人脑 自我解释性，直接问 LLM 在 token 级别 |
|
9 |
https://www.youtube.com/watch?v=Z9NuE3ED5TE 第一课：AI Agent 基础概念｜AI Agent开发入门训练营
|
思维链 Chain of thought Thought --> Action --> Observation
Tool Calling
Eliza Agent on NEAR
2023–2024：LLM 时代让“ELIZA 复活”当 LLM 出现后，社区开始反思：
答案是四个字： Eliza 的核心思想
|
| 10 | Ref: https://youtu.be/c-_84lN7l5s?si=vHBZQ6dj77I4mwW0&t=1285 | 创建一个插件 基于 Eliza，体会其应用价值。 |
| 15 | Zapier --> N8N | |
| 18 |
「超詳細教學」n8n AI 實作0基礎入門到進階 — (AI Agent | LLM | RAG | Webhook| AI 自動生成研究報告)
|
教学表达能力有限。 LLM 的 end2end 不一定会得到满意的结果。那么，为了达到“递归”的效果，AI Agent workflow即能满足。 |
| 20 | https://github.com/openclaw/openclaw | 它的“创新点”在哪里？ |
| 24 |
|
|
流程化
第一阶段：n8n 诞生（2019–2021）
n8n 的定位非常朴素：
“开源版 Zapier + 更强控制能力”
它的核心问题是：
系统之间怎么自动串起来？
比如：
-
-
Stripe → 发邮件
-
表单 → 存数据库
-
Slack → 创建任务
-
定时任务 → 调 API
-
由Zapier带来的思考
当两个或多个应用已经提供公开 API 时，所谓“胶水平台”本质上只是对这些公开协议进行事件监听、数据转换与调用编排的中间层。由于它不掌握核心模型、不控制底层资产，也不依赖封闭算法，而只是基于标准化接口进行流程组织，因此在技术上天然具备开源实现的可能性。商业产品的优势更多来自集成规模、稳定托管与维护成本，而非不可复制的核心能力。
世界模型的特点？
还是Transformer，但要通过新的方法，让模型更精确的理解物理世界。
但语言模型这种结构不适合被训练后达到充分理解世界物理原理的目标？Yan LeChun的观点。
Agent 进化理解，金句：
以前 Agent 做不成事，大家怪模型傻。
现在 Agent 能做成事了，大家开始发现：真正失败多发生在执行链路。如下：
多步任务的“部分成功”与一致性问题（事务）
Agent 经常要做这样的事情：
-
创建订单
-
支付
-
发货
-
写入 CRM
-
通知 Slack
-
如果第 3 步失败，前两步已经成功了，怎么办？
-
-
回滚？（很多 API 不支持）
-
重试？（可能重复扣款/重复下单）
-
补偿？（需要“补偿事务”设计）
-
这就是工程里经典的：
分布式事务 / 幂等性 / 补偿机制
模型不负责这些，系统必须负责。
用一个超级直观的例子总结“系统不稳”
你让 Agent 做：“把所有供应商发票整理进表格并通知财务”。
模型规划很完美，但执行中会遇到：
-
-
Gmail API 429
-
其中一个 PDF 解析失败
-
断网重试导致重复写行
-
Slack token 过期
-
中途崩溃后忘了处理到哪封邮件
-
你会发现失败点几乎都不在“推理”，都在：
工程链路、状态、幂等、观测、权限。
那为什么 OpenClaw / 多 Agent 系统会出现？
因为行业开始把重点从“让模型更聪明”转向：
让执行变可靠
所以新一代系统会强调：
-
-
任务队列（queue）
-
状态机（state machine）
-
worker 分离（可扩展）任务调度层 ≠ 执行层
-
重试/补偿（retries & compensation）API 失败 → 再试；第 3 步失败 → 撤销前两步（补偿是分布式事务的核心）。
-
幂等键（idempotency）同一个请求执行多次，结果不变。
-
可观测（logs/traces）logs等。
-
人工审批（HITL）关键步骤必须人工确认。
-
这就是“系统化”。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------- 一些总结 ---------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
第一节课
2022：范式成型（ChatGPT 之前就发生）
关键节点（你可以背）
-
-
MRKL（2022-05）：提出“LLM 不是万能的计算体，而是一个能把任务路由到外部模块/工具的语言接口”。（Tooling/Router 的思想）
-
ReAct（2022-10）：把智能体闭环写成模板：Thought → Action → Observation → …，明确“推理与行动交错”是落地关键。
-
ChatGPT（2022-11-30）：把 LLM 产品化、普及化，但不是“LLM 研究”的起点。
-
你的思考（加入你的原问题）
“ChatGPT 不是 2022 年底才 release 吗？为什么 2022 年前面就有这些论文？”
我的反馈（校准你理解的关键点）
你的疑问非常对，但这里要抓住一个概念区分：
-
-
LLM（研究对象）：GPT-3 这类大模型在 2020 起就存在，2022 研究界/工程界已经在用它做“工具调用/行动闭环”的探索。
-
ChatGPT（产品形态）：是“对话 UI + RLHF + 部署”的一次产品爆发，并不等于“LLM 从此才存在”。
-
所以 2022 的论文“早于 ChatGPT”完全合理：它们研究的是 LLM 的能力边界与系统组织方式，而不是 ChatGPT 这款产品。
一句话结论（考试答案）
2022 发生的是：Agent 的“闭环范式”被写清楚了（ReAct），工具路由架构被提出了（MRKL），ChatGPT 只是把这波能力推给大众。
2023：生态爆炸 + 工程接口出现，但“可靠性鸿沟”暴露
关键节点
-
-
Toolformer（2023-02）：开始讨论“模型如何学会何时调用工具、怎么填参、怎么用返回结果继续推理”，把工具调用从 prompt 技巧推进到“能力”层。
-
Generative Agents（2023-04）：把 Memory 写成体系：短期记录 + 长期记忆 + 反思/摘要 + 检索 → 影响行为。
-
Function Calling（2023）：把工具调用做成工业契约（schema 化输入输出），Executor/Tooling 从此能工程化。
-
同期社区 demo（AutoGPT/BabyAGI）爆火：把“自主循环”普及给所有人，但也让大家看到不稳定。
-
你的思考（你原话改写成教材版）
“2023 年思想发展很快，但当时 LLM 的规划能力不行，总会出错，所以 agent workflow 不稳定。OpenAI 也在一直完善 API 调用。”
我的反馈（我同意你，但补全三点）
你这理解 大方向正确，但为了更“深入”，我给你三条补全，让读者一眼抓住 2023 的本质：
-
不稳定不只来自 Planner
还有 Tooling/Executor/Memory 的工程缺口：工具返回质量差、无 schema、无重试策略、无状态机、无可观测性——这些都会让闭环“抖”。 -
2023 的核心矛盾是：闭环有了，但没有“控制系统”
demo 能跑 ≠ 可控可回放可审计可降级。 -
OpenAI API 的演进确实是关键推动力
Function calling / 更强的工具契约让“执行层”可工程化；这一步是从“提示”到“系统”的拐点。
-
一句话结论
2023 是：Agent 从“概念与demo”变成“工程接口”，但可靠性不足暴露，系统工程（状态、错误处理、可观测性）开始成为主战场。
2024：推理能力跃迁，让“动态规划/重规划”开始现实
关键节点
-
-
o1-preview（2024-09-12）→ o1（2024-12-05）：推理型模型把多步推理、纠错能力显著拉高（尤其对复杂任务分解、反思、再规划更友好）。
-
你的思考（教材化表达）
“2024 年模型进步很大，尤其 o1 推理模型出现，让 agent 时代的动态 planning 成为可能。”
我的反馈（非常接近真相，但我帮你改成更精确的表述）
我会把你的话从“成为可能”升级为一个更精确的学术/工程判断：
-
-
o1 提升的是：planner 的质量上限 + 稳定性
让“replan/反思/纠错”更靠谱。 -
但 agent 的可靠性依然不是纯模型决定：
如果工具质量差、状态管理混乱、没有终止条件、没有回放审计，o1 也会“更聪明地乱跑”。
-
所以更准确的教材句子是：
2024 让动态 planning “更可行、更经济”，但是否“稳定可部署”仍取决于系统工程。
一句话结论
2024 是：推理能力的跃迁让 Planner 不再是最大短板，Agent 进入“模型×系统工程”共同决定成败的阶段。
2025：平台化与“Agent 一等公民化”加速（从能用到可规模化）
关键节点
-
-
GPT-4.5（2025-02-27）：更强通用能力与更成熟训练叙事，单模型“够用”的比例更高。
-
Responses API（2025-03 起）：把 agent 需要的 primitives（工具、搜索、文件、结构化输出等）进一步平台化。
-
生态侧框架/产品更强调：可控编排、状态机、观测、评测、成本（“能跑”不再稀缺，“能控”才稀缺）。
-
你的思考（你原推演，教材化整理）
“o1 → 多步推理带来更好合成数据 → 进一步增强单模型能力（比如 GPT-4.5）→ 2025 上半年单模型能力够用 → 2025 下半年各大厂家发力 agent，各种成熟框架都出来。”
我的反馈（我给你“保留主线，但修正两个点”）
你的主线非常有洞察力，我建议这样校准，让它更严谨：
校准点 1：因果链不要写成单线
“o1 → 合成数据 → GPT-4.5”可以保留为合理推断，但教材上要写成多因素共同作用：
-
-
推理模型带来的 更高质量轨迹数据（这确实常用于蒸馏/合成）
-
更成熟的 工具调用契约与系统平台
-
更系统的 评测/对齐/安全
共同推动 4.5 这类模型与 agent 平台化。
-
校准点 2：发力不是 2025 下半年才开始，而是 2024 已加速
更准确的叙述是：
-
-
2024：加速期（推理模型出现，编排框架与产品开始明显增多）
-
2025：平台化/工业化集中爆发（“agent 成为产品与平台核心能力”更明显）
-
一句话结论
2025 是：单模型能力更接近“够用”，平台与框架把 agent 做成可规模化系统；行业竞争点从“有没有 agent”转向“谁更可控、更可靠、更便宜、更可评测”。
最后给读者的“元结论”（把你的思考升级成通用判断）
你这套思考其实已经接近一个非常有用的“教科书定律”了，我帮你把它写成一句可背的总结：
Agent 的历史演进不是线性的“模型越来越强”，而是：闭环范式（2022）→ 工程接口与生态（2023）→ 推理能力跃迁（2024）→ 平台化与规模化（2025）。
当模型足够强时，胜负关键不再是模型，而是：状态、工具契约、观测回放、评测与控制系统。
第二节课
1) Chain-of-Thought（CoT）：推理能力与规划能力的“地基”
什么时候发表？作者是谁？
-
-
arXiv 首发：2022-01-28
-
作者：Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, Denny Zhou
-
后续作为 NeurIPS 2022 论文收录（DBLP 记录）。
-
为什么它对 planning 重要？
planning 本质是“多步推理 + 中间状态”。CoT 证明了：只要让模型显式地产生中间步骤，复杂任务性能会显著上升（尤其数学、符号、组合推理）。这给后续所有“plan / replan / reflect / verify”奠定了基础。
CoT（Chain-of-Thought Prompting）这篇经典论文讲的是一种提示方法（prompting）：给模型几个“带推理步骤的示例”，让它在推理任务上更容易产生中间步骤，从而提高准确率。它本身不依赖 RL。
2) Tree of Thoughts（ToT）：把 planning 直接变成“搜索/回溯”
在此之前：
论文标题：ReAct: Synergizing Reasoning and Acting in Language Models
arXiv 首发时间：2022-10-06
作者：Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, Yuan Cao
什么时候发表？作者是谁？
-
-
arXiv：2023-05-17
-
作者：Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, Karthik Narasimhan
-
为什么它对 planning 重要？
ToT 的核心不是“更会写 CoT”，而是把 planning 这件事明确成：
-
-
同时生成多个候选“想法节点”
-
自评/选择
-
必要时回溯（backtracking）
这就是典型的“规划 = 搜索”。它直接把 agent 的 planner 从“线性计划”升级成“可探索的决策过程”。
-
3) OpenAI o1：把“推理”从 prompt 技巧升级成“模型内生能力”
你问的“推理模型关键论文”很多人指的其实就是 o1 这一代。但要注意：o1 更像是官方技术报告/系统卡 + 博文（而不是传统学术论文形式）。
什么时候发布？作者是谁？
-
-
OpenAI 官方博文：Learning to reason with LLMs：2024-09-12（OpenAI 署名）
-
o1 System Card（arXiv）：2024-12（作者以 OpenAI 团队署名为主，arXiv 页面可见 “by A. Jaech …” 等）
-
o1 的产品发布时间线：preview 2024-09-12，正式 2024-12-05（背景信息可参考汇总）。
-
为什么它对 planning 重要？
CoT/ToT 更像“推理外骨骼”（靠提示/搜索把模型推上去），而 o1 这类 reasoning model 的目标是让模型天然更擅长多步推理与自我纠错，从而：
-
-
planner 更稳定（少漏步骤、少胡跳）
-
replan 更可控（能根据观察调整而不是崩坏）
-
在复杂任务里更“愿意花算力思考”（think-then-answer）
-
o1 System Card 明确提到 o1 系列通过大规模 RL 来进行复杂推理（使用链式思考）。
Jason 加入 OpenAI 后，Jason Wei 推动了这一技术在强化学习环境下的应用，被认为是 o1 推理能力的核心缔造者。
4）Agent 落地 - Deep Research
OpenAI 官方宣布/上线（ChatGPT 内）：2025 年 2 月 2 日（OpenAI 博文 “Introducing deep research” 的发布时间）。
5）Agent 任务驱动 - OpenClaw
过去（2022–2023）的 agent workflow，本质是人去引导模型怎么想：人写 prompt、定义推理结构（CoT/ToT/ReAct 这类“外骨骼”），再把模型塞进一个固定或半固定的流程里跑。模型更像“被牵着走的执行器”。
现在（2024+ 推理模型更强）开始转向：模型自己能做动态逻辑推理与 planning/replanning，人不需要再手把手规定“思维步骤”。引导的重点从“教模型怎么思考”，变成“人给目标/约束/权限边界”，模型负责在运行中分解任务、调用工具、纠错、重规划，并在必要时主动向人发起少量交互。
之所以“模型会引导人”，是因为目标驱动的 planning 过程中必然出现少量需要人确认/补信息的节点（尤其涉及风险、权限、资金、不可逆操作）。为了让人愿意配合并建立信任，agent 在每次交互前必须先让人明白：
1）现在处于哪个阶段（stage）
2）已经做了什么 / 正在做什么（progress）
3）下一步要做什么，以及需要你做什么（decision/request）
换句话说：现代 agent 的关键不是“会想”，而是“可解释的状态机 + 受控的交互点（human-in-the-loop）”。这样用户才能看懂系统在干嘛、为什么停下来问你、以及你确认后它会怎么继续。
Deep Research vs OpenClaw：本质区别与提升点
1）定位与目标域
-
-
Deep Research：研究型 agent 成品能力（多步检索/阅读/综合 → 输出带引用的研究报告）。
-
OpenClaw：通用 agent OS/工作台（把各种能力装进可编排系统：节点、会话、定时、工具集成、跨应用协作）。
-
2）能力来源
-
-
Deep Research 强在“模型+端到端编排”：研究质量、稳定交付、证据链（引用）是核心。
-
OpenClaw 强在“系统集成/可组合性”：更像容器与运行时，能力取决于你接入的模型+工具+流程。
-
3）交互形态
-
-
Deep Research：交付物导向（报告/引用/总结）。
-
OpenClaw：持续协作导向（工作台、会话、任务、自动化）。
-
如何理解它是一个操作系统？
OpenClaw 像 Linux，Deep Research 像一个官方打磨到位的“研究员软件”。Linux 能跑同类软件，但不等于开箱即用就达到同样体验。
要真正看懂 OpenClaw 为什么“有别于其他项目而突然火爆”，你不需要把所有工具都学一遍；你需要把几块“底层知识”吃透——因为 OpenClaw 的差异点恰好发生在这些层上。
下面是我建议你先学的知识清单（按优先级），每一项我都写清楚：学它是为了看懂 OpenClaw 的哪个“关键点”。
1) Agent 的四件套抽象（必须先懂）
目标：别被 demo 迷惑，能一眼看穿架构。
Planner（规划）：目标如何拆解成步骤/子任务
Executor（执行）：如何把步骤变成工具调用
Memory（记忆）：短期上下文 vs 长期状态/知识
Tooling（工具）：工具发现、调用、返回结构化结果
你要能回答：
一个系统到底是不是“Agent”，还是只是“工作流 + LLM 节点”。
2) “控制权”与“流程生成方式”（理解 OpenClaw 的核心差异）
OpenClaw 的火爆通常来自一种体验：它更像“任务系统”，而不是“你画流程它跑”。
你要深入理解两个范式：
确定性工作流（DAG workflow）：流程由人预定义（n8n、Step Functions 典型）
目标驱动任务系统（Goal-driven, runtime plan）：流程由系统运行时生成/调整（OpenClaw 这类）
你要能看出来：
它到底是把 LLM 当成流程中的一个节点，还是让 LLM 主导任务图的生成与重写。
3) 可靠性工程：为什么“系统不稳”会成为瓶颈（OpenClaw 这一代的主战场）
你要把下面这些概念吃透（它们决定了一个项目能否“落地”，也解释了为什么新一代系统会火）：
任务队列（queue）：异步、削峰、重试入口
状态机（state machine）：长任务进度与恢复
worker 分离：调度与执行解耦、可扩展
幂等（idempotency）：重试不重复下单/扣款/发消息
补偿事务（compensation）：部分成功后的回滚/对账
可观测（logs/traces/metrics）：出了问题能定位与回放
HITL（人工审批）：关键动作加闸，防越权与注入
你要能回答：
为什么“推理更强”之后，失败更多发生在执行链路而不是思考链路。
4) 推理模型与 Agent 的关系：能力上限 vs 成功率下限
你不需要研究模型架构细节，但要理解：
推理模型提升带来的是什么：规划质量、结构化输出、反思与校验能力
它解决不了什么：外部 API 不稳定、事务一致性、权限治理、可观测
你要能建立这个判断：
模型提升把“能不能做”推高了，但系统工程决定“能不能稳定做”。
5) 工具标准化：MCP 与“技能包（Agent Skills）”在生态里各自管什么
你要理解两件事的分工：
MCP：让“工具/数据源接入”标准化、可插拔
Skills：让“能力/流程经验”标准化、可复用、可分发
你要能回答：
OpenClaw 如果要规模化扩展工具与能力，它在架构上需要什么样的“插件与协议层”。
6) 多 Agent 协作的本质：从“角色扮演”到“任务分解与调度”
你要能区分：
角色式多 Agent（像 CrewAI）：人预设角色与协作顺序
任务式多 Agent（像 OpenClaw 更偏）：系统根据任务动态分派、合并、重试、反馈
你要把关注点从“对话好不好看”转为：
子任务生命周期怎么管？任务依赖怎么管？失败怎么重试？结果怎么汇总？
你学完这些，会自然看懂 OpenClaw 为什么会火
因为你会用一套“工程指标”去判断它：
它是不是把任务当第一公民？
有没有状态/恢复/幂等/补偿？
多 agent 是“对话表演”还是“调度系统”？
工具/能力是否可插拔可扩展？
能否长期运行、有观测、有治理？
这才是“爆火背后的机理”。
最推荐的学习顺序（最省时间）
可靠性工程七件套（队列/状态机/幂等/补偿/可观测/HITL/worker）
控制权与流程生成（工作流 vs 任务系统）
多 Agent：角色协作 vs 任务调度
MCP + Skills：工具与能力的标准化
推理模型：能力与边界
浙公网安备 33010602011771号