第 0 章 · 开场：从 Chatbot 到 Agent
本章观点
这门课不把 Agent 理解成“更聪明的聊天机器人”，也不把它理解成“完全自动化的封闭系统”。我们采用一个更工程化的理解：
Agent 是一种受控委托系统：你把目标交给模型，但必须同时设计工具边界、状态记录、停止条件和人工确认点。
这句话比“Agent = LLM + 工具 + 循环”更重要。因为后者只是结构，前者才是工程判断。一个能循环调用工具的系统，如果没有权限边界、成本控制和失败回退，就不是可靠的 Agent，只是风险更高的自动化脚本。
0.1 一句话定义
先扔结论：
Agent = LLM + 工具 + 能跑的循环
这一句话贯穿本教程。
用一个类比感受一下：
- Chatbot（聊天机器人） 更接近一次性问答系统：用户输入一句，它返回一句，通常不持续推进任务，也不直接执行外部操作。
- Agent（智能体） 像一个真实有思考和动手能力的伙伴——你交给他一个任务（"帮我查一下本周 arxiv 上 visual tracking 的新论文，整理成摘要发我邮箱"），他会自己拆步骤：去 arxiv 搜索 → 下载 PDF → 读摘要 → 翻译成中文 → 写邮件 → 发出去。中间遇到问题（比如 PDF 下不下来）会自己想办法。
差别在哪？Agent 有外部行动能力（工具）和持续推进能力（循环）。Chatbot 主要停留在一次性回复。
但这里要立刻补一句：有行动能力和自主性，不等于可以不受约束地行动。
一个真实可用的 Agent 至少要有四个边界：
| 边界 | 要回答的问题 | 没有边界会怎样 |
|---|---|---|
| 工具边界 | 它能调用哪些工具？能读还是能写？ | 误删文件、误发邮件、越权操作 |
| 状态边界 | 它怎么记录已经做过什么？ | 重复搜索、忘记约束、上下文混乱 |
| 预算边界 | 它最多跑几轮、花多少钱？ | 无限循环、成本失控 |
| 审批边界 | 哪些动作必须人确认？ | 高风险操作自动执行 |
所以本教程里说“自主”，不是无限自主，而是在边界内自主。
0.1.1 从 ReAct 和 Reflexion 得到的启发
Agentic AI 不是凭空出现的概念。很多关键思想已经在早期论文里被反复验证过。
ReAct 提出的核心不是“让模型多调用工具”，而是把推理和行动交替起来：模型先形成一个短推理，再执行动作，再读取观察结果，然后继续修正下一步。它指出了两种单薄做法的问题：只推理容易脱离外部事实，只行动又缺少高层计划。
Reflexion 则进一步说明，Agent 失败以后不应该只是机械重试，而应该把失败原因总结成语言形式的经验，写入记忆，并在下一次尝试时使用。也就是说，Agent 不只需要“当前工作记忆”，还需要“经验记忆”。
因此，本教程把 Agent 看成一个反馈系统：
思考 Thought -> 行动 Action -> 观察 Observation -> 反思 Reflection -> 记忆 Memory这个循环比“LLM + 工具”更完整。工具让 Agent 接触外部世界，观察让 Agent 校验现实，反思让 Agent 从失败中提炼经验，记忆让经验影响下一次决策。
0.2 为什么是现在
Agent 这个概念不是新东西，2023 年 AutoGPT 就火过一波。但那时候做出来的 agent 大多是"玩具"——能跑两步就崩，或者陷入无意义的循环。
2024-2025 这两年发生了三件事，让 agent 真正可用了：
- 模型能力够强了。Claude 3.5 Sonnet、GPT-4o、Gemini 2.0 这一代模型在工具调用、长上下文、复杂推理上的能力，比 2023 年提升了一个数量级。agent 能跑通的门槛大幅降低。
- 工具生态标准化了。2024 年 11 月 Anthropic 开源 MCP（Model Context Protocol），把"模型 ↔ 工具"的集成从 N×M 降成 N+M。一个 MCP server 写一次，所有支持 MCP 的 host（Claude Code / Cursor / VS Code）都能用。
- 官方 SDK 出齐了。Anthropic、OpenAI、Google 都推出了自己的 Agent SDK，把 agent loop、工具调用、权限管理等基础能力封装起来。你不需要从零实现所有运行时细节。
三件事齐了，agent 从"研究玩具"变成"工程产品"。这本教程就是教你做这个工程产品。
不过，工程产品和演示原型的差别不在于用了多少框架，而在于能不能解释清楚这些取舍：
- 为什么这里用 Workflow，而不是 Agent？
- 为什么这个工具只允许读，不允许写？
- 为什么这里需要人工确认？
- 如果工具失败，Agent 是重试、换工具，还是向用户报告？
- 如果跑了 10 轮还没结果，系统怎么停？
教程如果只停留在概念罗列，就会缺少判断力。后面每章都会围绕“权力交给模型以后，工程边界怎么设计”展开。
0.3 全教程路径图
[入门]
第 0 章 开场 ──────────── What：什么是 Agent
第 1 章 Anthropic 定义 ── Why：为什么这么定义
第 2 章 心智模型 ──────── How：反馈循环 + 工程边界
第 3 章 Agent Loop ────── 看懂循环怎么转
第 4 章 Tool Use ──────── 学会让 agent 用工具
[进阶]
第 5 章 MCP ───────────── 学会标准化的工具协议
第 6 章 Agent SDK ─────── 学会用官方 SDK 造 agent
第 7 章 Skills ────────── 学会让 agent 长本事
第 8 章 评估与安全 ────── 学会控制 agent 风险
[实战]
第 9 章 开源生态地图 ─── 知道用什么轮子
第 10 章 7 个递进实战 ── 从 30 行代码到生产级 agent
第 11 章 学习路径 ────── 知道接下来怎么走入门部分回答"Agent 是什么"，进阶部分回答"怎么造一个"，实战部分回答"怎么用 agent 解决真实问题"。
0.4 你将做出什么
第 10 章有 7 个递进实战，难度从 ★ 到 ★★★★★：
- ★ 30 行代码跑通第一个 agent（查天气）—— 感受 agent loop
- ★★ 让 agent 会用工具（读文件 + 搜索）—— 理解 tool use
- ★★★ 写一个 MCP server—— 给 agent 加自定义能力
- ★★★ 用 LangGraph 写带反思的多步研究 agent—— 理解框架
- ★★★★★ 自动追踪目标算法论文的科研 agent—— arxiv 搜 → PDF 解析 → 中文摘要 → 邮件推送
- ★★★★★ 自动找候选人并发邮件的招聘 agent—— GitHub 搜 → README 解析 → 评分 → 邮件草稿 → 人工审核
- ★★★★★ 拆解 OpenClaw / Hermes-agent 架构—— 看生产级 agent 怎么设计
做完前 4 个，你能掌握 Agent 的基础运行机制。做完后 3 个，你能把 Agent 放进更接近真实业务的约束里分析和实现。
0.5 谁适合读本教程
- 你能看懂基础 Python（函数、类、异步
async/await大概知道） - 你调用过 LLM API（哪怕只跑通过一次
client.messages.create） - 你想搞清楚 Claude Code / Cursor 这类工具底层怎么工作
- 你想自己造一个能干活的 agent，而不只是调 API 聊天
不需要你有机器学习相关背景、不需要你懂模型训练、不需要你读过论文。
0.6 本教程的判断框架：四权模型
为了避免把 Agentic AI 学成名词堆砌，本教程使用两个贯穿始终的判断框架。
第一个是反馈循环模型：
Thought -> Action -> Observation -> Reflection -> Memory这个模型来自 ReAct 和 Reflexion 的共同启发：Agent 的能力不只来自单次推理，而来自每一步行动之后的观察、修正和经验沉淀。
第二个是四权模型：
- 控制权：下一步由代码决定，还是由 LLM 根据反馈决定？
- 工具权：LLM 能调用什么工具，哪些工具有副作用？
- 状态权：系统如何保存事实、计划、错误、历史和预算？
- 停止权：谁决定任务完成、继续、失败或升级给人？
这个框架可以解释很多概念：
| 概念 | 主要解决哪种权力问题 |
|---|---|
| Tool Use | 工具权：让模型能调用外部能力 |
| MCP | 工具权：用标准协议连接更多工具 |
| Agent Loop | 控制权：让模型根据反馈决定下一步 |
| ReAct | 控制权 + 状态权：让推理、行动和观察交替发生 |
| Reflexion | 状态权 + 停止权：让失败轨迹转化为经验记忆 |
| Memory / Context | 状态权：让系统知道已经发生了什么 |
| Guardrails | 工具权 + 停止权：限制危险行为 |
| Skills | 控制权 + 状态权：复用专家流程和经验 |
| Agent SDK | 控制权 + 状态权：管理运行时、工具和权限 |
如果你能用四权模型分析一个 Agent 产品，就说明你已经不是在背概念，而是在做工程判断。
0.7 阅读建议
- 理论部分（0-9 章）：按顺序读，每章 1500-2500 字，配代码和图。读不懂的可以跳过，回头再来。
- 实战部分（第 10 章）：挑感兴趣的做。建议至少做完实战 1 和实战 5，前者让你"跑通"，后者让你"做出有用的东西"。
- 遇到不懂的词：查附录 A 术语表。
0.8 常见误区
误区 1：会调用工具就是 Agent。 不一定。如果调用路径完全由代码写死，那更像 Workflow。Agent 的关键是 LLM 能根据中间结果决定下一步。
误区 2：Agent 越自主越好。 错。越自主，越要控制权限、预算和停止条件。生产级 Agent 往往是“局部自主”：低风险步骤自动跑，高风险步骤让人确认。
误区 3：Multi-Agent 一定比 Single Agent 强。 不一定。多 Agent 会带来通信成本、上下文污染和调试难度。单 Agent 能解决的问题，不要急着拆成多 Agent。
误区 4：写一个复杂 prompt 就是在做 Agent。 Prompt 很重要，但 Agent 的核心还包括工具、状态、循环、错误处理和评估。只有 prompt 的系统很难稳定完成多步任务。
前人智慧 / Prior Art
本教程把 Agent 看成"受控委托系统"，并主张用反馈循环和四权模型来设计边界。这两条主线不是凭空造的，它们来自三组经典研究的共同启发。
提示词样本分类：Zero/One/Few-shot 07-09
在讲 CoT 之前，先补一个更基础的提示词分类。吴恩达 Agentic AI 课程（Bilibili BV1DfrdByE2H，Module 4 反射工作流）把提示词按"给几个示例"分成三类：
| 类型 | 给几个示例 | 适用场景 | 例子 |
|---|---|---|---|
| Zero-shot（零样本） | 0 个 | 任务简单，模型已能理解 | "翻译这句话：Hello" |
| One-shot（单样本） | 1 个 | 任务需要看一个例子才懂格式 | "翻译：Apple -> 苹果。翻译：Banana" |
| Few-shot（多样本） | 2-5+ 个 | 任务复杂，需要多个例子展示模式 | 给 3 个翻译对，再让它翻译新词 |
为什么这个分类重要：
- 它是 Agent prompt 设计的基础：工具的
description字段（第 4 章讲）本质上就是 zero-shot 说明；如果描述不够，可以加 few-shot 示例 - 它解释了为什么需要反射：当 few-shot 提示词优化到边际收益骤降（平台期），下一步不是加更多示例，而是加反射或外部反馈--这是本章 0.1.1 节 Reflexion 的工程动机
- 它和 Spec Engineering 衔接：SPEC.md（第 4 章 Spec Engineering）可以看作"给 Agent 的 zero-shot 上下文"--通过描述而非示例来定义任务
对 Agent 工程的启示：不要一上来就写超长 few-shot prompt。先用 zero-shot 看模型能不能做对，做不对再加 one-shot，还不够再加 few-shot。示例越多 context 越长，Context Rot（第 5 章）的代价也越大。最小有效示例集比"多多益善"更工程化。
Chain of Thought：推理过程要显式化
Wei et al. 2022 的 CoT 论文是 Agentic AI 的思想原点。论文最关键的实验：在 GSM8K 数学题上，标准 prompt 准确率 17.7%，加一句 "Let's think step by step" 跳到 58.3%。
这个跳变定义了后续所有 Agent 的一个共同特征：模型不应该只输出答案，应该输出推理过程。ReAct 的 "Thought" 字段、Reflexion 的反思轨迹、Claude 的 extended thinking，本质都是 CoT 的延伸。
对本章"四权模型"的支撑：CoT 解决的是控制权——把"一步出答案"变成"多步显式推理"，让任务的推进方式从模型黑箱变成可检查的轨迹。
ReAct：推理和行动必须交替
Yao et al. 2022 在 HotpotQA 和 ALFWorld 上做了三组对照：只推理 / 只行动 / 推理+行动。结论影响深远：
| 方法 | 准确率 | 主要失败模式 |
|---|---|---|
| 只推理（CoT） | 中等 | 幻觉，编造事实 |
| 只行动（Act） | 较低 | 不知道为什么调工具，参数乱 |
| ReAct | 最高 | 失败模式最少 |
论文 Fig. 2 展示了关键曲线：随任务步数增加，纯推理的幻觉率上升，纯行动的工具错误率上升，只有 ReAct 把两条曲线都压住。
对本章的支撑：ReAct 验证了反馈循环模型（Thought → Action → Observation）不是审美选择，是实证最优。也支撑了控制权 + 工具权的分离——推理管决策，行动管执行，两者交替才能稳定。
Reflexion：失败要沉淀成经验
Shinn et al. 2023 的 Reflexion 论文补了 ReAct 没解决的问题：一次完整轨迹失败以后怎么办？
Reflexion 的核心设计：把失败轨迹送给一个"反思者" LLM，让它生成一段语言形式的经验（"这次失败是因为搜索结果包含大量 survey，下次先排除 title 含 survey/review 的论文"），写入 episodic memory，下一次尝试时加载。
在 AlfWorld 上，Reflexion 把 ReAct 的成功率从 70% 提到 97%。关键是这个提升不是来自更强的模型，而是来自经验记忆。
对本章的支撑：Reflexion 验证了状态权——Agent 不只需要当前 working memory，还需要跨次尝试的经验记忆。本教程"四权模型"里的"状态权"正是把 Memory 和 State 都纳入边界设计。
Lilian Weng 的 Agent 四块拆解
Lilian Weng 2023（OpenAI 前研究员）的博客至今仍是 Agent 概念拆解最被引用的文章。她把 Agent 拆成四块：
- Planning：任务拆解 + 反思
- Memory：短期（context）+ 长期（向量库 / 文件）
- Tool Use：Function Calling
- Action：执行环境
本教程的"四权模型"（控制 / 工具 / 状态 / 停止）和 Lilian 的四块是同一问题的不同切面：
- Lilian 偏概念（Agent 有什么能力）
- 本教程偏工程（这些权力怎么收边界）
读 Lilian 的博客理解"Agent 是什么"，读本教程理解"Agent 怎么不闯祸"。两者互补。
这条主线的工程意义
把 CoT + ReAct + Reflexion + Lilian 四块合起来，能得到一个重要判断：
Agent 的价值不在于一次回答多聪明，而在于能不能通过外部反馈持续修正自己的行为。
这正是本章"反馈循环模型"的来源。后续每一章都会回到这条主线——MCP 扩展工具权，Skills 沉淀过程知识，Agent SDK 管理控制权和状态权，评估与安全约束停止权和工具权。
- 选一个你每天重复做的任务，写出它的目标、输入、输出、工具、人工确认点。
- 判断这个任务更适合 Chatbot、Workflow 还是 Agent，并写出理由。
- 画出一个最小 Agent Loop：最多 5 个节点，不需要代码，只要说明每一步在做什么。
- 找一个你用过的 AI 产品，用“四权模型”分析它：控制权、工具权、状态权、停止权分别在哪里？
下一章我们从 Anthropic 官方定义开始——为什么 Agent 这个词被定义为"LLM dynamically direct their own processes"，而不是更宽泛的东西。