中文译本。原文见同目录 README.md
第 4 课：Agentic 设计模式
你将学到什么
- 什么是 agentic 设计模式，以及为何重要
- 四个核心模式：ReAct、Reflection、Tool Use 与 Planning
- 何时使用每种模式，以及涉及的权衡
- 如何在真实世界 Agent 中组合模式
先修
ELI5：设计模式就像菜谱
想象你要做晚饭。你可以随便抓食材碰运气。或者你可以按菜谱——别人已经验证过行之有效的一套步骤。
设计模式就是构建 AI Agent 的菜谱。它们是组织 Agent 如何思考、行动与学习的经过验证的方式。就像菜谱书有不同菜式的不同菜谱，我们也有针对不同类型 Agent 行为的不同模式。
就像优秀厨师可能组合多道菜谱的技法，最好的 Agent 通常也会组合多种模式。
为何设计模式重要
如果你写软件有一段时间，大概熟悉 Observer、Strategy 或 Factory 等设计模式。这些模式给工程师共享词汇，以及解决常见问题的成熟蓝图。
Agentic 设计模式服务于同样目的，但面向 AI Agent。它们描述 Agent 如何：
- 推理问题
- 在世界中采取行动
- 从结果中学习
- 改进自身输出
没有这些模式，构建 Agent 就像写意大利面条代码——一切缠在一起、难以调试。有了它们，你得到更清晰的架构，更容易构建、测试与维护。
从简单到 Agentic
并非每次 LLM 交互都需要设计模式。下面是粗略光谱：
| 层级 | 描述 | 例子 | 需要的模式 |
|---|---|---|---|
| 简单提示 | 一问一答 | 「法国首都是哪里？」 | 无 |
| 结构化输出 | LLM 格式化其回复 | 「以 JSON 返回」 | 无 |
| 链式 | 多个 LLM 调用按序进行 | 先摘要，再翻译 | 极少 |
| Agent | LLM 决定下一步做什么 | 研究一个主题并写报告 | ReAct、Tool Use、Planning |
| 多智能体 | 多个 Agent 协作 | Agent 团队一起构建软件 | 以上全部 + 协调 |
一旦你越过简单链式，进入真正的 agentic 行为——LLM 在决定下一步做什么——设计模式就变得重要。
Agentic 设计模式可视化
探索每种模式的流程图，或并排比较全部四种。
模式 1：ReAct（Reason + Act）
ReAct 是最基础的 agentic 设计模式。如果你只学一种模式，就学这个。
核心想法
ReAct 把推理（思考做什么）与行动（真正去做）交错在一个循环中。Agent：
- 思考当前情况
- 行动，调用工具或迈出一步
- 观察结果
- 重复直到任务完成
餐厅类比
想想餐厅服务员：
- 思考：「5 号桌点了意面。我需要检查厨房是否做好了。」
- **行动：**走到厨房询问。
- **观察：**厨师说还要 5 分钟。
- 思考：「好，等的时候我去看看 3 号桌的饮料。」
- **行动：**去 3 号桌续杯。
- **观察：**3 号桌很满意。
- 思考：「时间差不多了。再去看 5 号桌的意面。」
- **行动：**回到厨房。
- **观察：**意面好了。
- **行动：**把意面送到 5 号桌。
服务员不会提前规划整个班次。他们思考、行动、观察并适应——持续进行。
ReAct 长什么样
一般流程如下：
User: "What is the weather in Tokyo and should I pack an umbrella?"
Agent Thought: I need to find the current weather in Tokyo. I will use the weather tool.
Agent Action: call weather_api(location="Tokyo")
Observation: {"temp": 18, "condition": "rain", "forecast": "rain continuing through tomorrow"}
Agent Thought: It is currently raining in Tokyo and rain is expected to continue.
The user should pack an umbrella.
Agent Action: Respond to user.
Agent Response: "It is currently 18C and raining in Tokyo, with rain expected to
continue through tomorrow. Definitely pack an umbrella!"
ReAct 的关键特征
- 推理与行动交错。 Agent 不是盲目行动——它思考每一步。
- 锚定于观察。 每个想法都受 Agent 实际看到的内容影响，而不只是想象。
- 灵活。 Agent 可根据发现改变路线。
- 透明。 推理轨迹让调试 Agent 在想什么更容易。
何时用 ReAct
| 适合 | 不太适合 |
|---|---|
| 需要外部信息的任务 | 纯文本生成任务 |
| 路径不确定的多步问题 | 简单问答 |
| 需要审计轨迹的情况 | 延迟敏感应用 |
| 需要根据新信息适应的任务 | 序列固定、已知的任务 |
常见坑
- 推理循环。 Agent 反复想同样的想法却不推进。加最大迭代次数。
- 幻觉行动。 Agent「调用」不存在的工具。执行前校验工具名。
- 观察盲视。 Agent 忽略工具返回的内容，继续用先前假设。确保观察被清晰注入上下文。
模式 2：Reflection（反思）
核心想法
在 Reflection 模式中，Agent 审查自己的输出并改进。不是产出单次回复就结束，Agent 生成草稿、批评它，然后修订。
作者类比
想想写文章的作者：
- 草稿： 写第一版。
- 审阅： 回读。「嗯，引言弱，第 3 段与第 1 段矛盾。」
- 修订： 重写引言并修矛盾。
- 再审阅：「好多了。但结论需要更强的行动号召。」
- 再修订： 改进结论。
- 完成： 终稿比初稿强得多。
没有经验丰富的作者会寄出初稿。同样，会反思自身输出的 Agent 产出显著更好的结果。
Reflection 长什么样
Step 1 - Generate:
Agent produces initial response to user's request.
Step 2 - Critique:
Agent (or a separate critic) reviews the response:
"This code has a bug on line 12 - the loop index is off by one.
Also, the function lacks error handling for empty input."
Step 3 - Revise:
Agent fixes the identified issues and produces an improved version.
Step 4 - Evaluate:
"The bug is fixed and error handling is added. The code now handles
edge cases. This meets the requirements."
Reflection 的变体
| 变体 | 如何工作 | 例子 |
|---|---|---|
| 自我反思 | 同一 LLM 审查自己的输出 | 「审查你的代码找 bug」 |
| 批评者 Agent | 单独的 LLM 实例审查 | 专用代码审查 Agent |
| 基于评分标准 | 由具体标准引导反思 | 「检查：准确性、完整性、语气」 |
| 测试驱动 | 输出对照具体检查测试 | 跑单元测试、检查格式 |
何时用 Reflection
| 适合 | 不太适合 |
|---|---|
| 代码生成（上线前抓 bug） | 实时对话回复 |
| 写作任务（改进清晰度与结构） | 简单事实查询 |
| 复杂推理（抓逻辑错误） | 速度比质量更重要的任务 |
| 任何质量比速度更重要的任务 | 有客观可验证答案的任务 |
实用技巧
- 设置最大反思轮数。 两到三轮通常够用。更多往往收益递减。
- 使用具体标准。 「让它更好」太模糊。「检查 SQL 注入漏洞、缺失的错误处理与性能问题」给反思焦点。
- 考虑对批评者用不同模型或提示。 新鲜视角比用同一透镜重读能抓住更多问题。
- 跟踪改了什么。 记录每次修订之间的差异，以便验证反思真的改进了结果。
模式 3：Tool Use（工具使用）
核心想法
在 Tool Use 模式中，Agent 决定调用哪些工具、用什么参数、按什么顺序。LLM 作为编排外部能力的推理引擎，而不是试图自己做一切。
我们在 第 3 课 深入讲过工具。本节聚焦 Agent 如何决定使用工具这一模式。
工匠类比
想想经验丰富的木匠做项目。车间里有满满的工具——锯、钻、砂光机、夹具。项目每一步，他们：
- 评估下一步需要做什么
- 为这一步选对工具
- 使用工具
- 检查结果
- 决定接下来做什么
他们不会凡事都用锤子。他们选适合工作的工具。有时项目做到一半才意识到需要原先没打算用的工具。
Tool Use 长什么样
User: "Find the top 3 trending repositories on GitHub about AI agents
and summarize what each one does."
Agent Thought: I need to search GitHub for trending AI agent repositories.
Agent Action: github_search(query="AI agents", sort="stars", limit=3)
Observation: [repo1: "autogen", repo2: "crewai", repo3: "langchain-agents"]
Agent Thought: Now I need to get details about each repository.
Agent Action: github_get_repo(name="autogen")
Observation: {description: "...", readme: "...", stars: 42000}
Agent Action: github_get_repo(name="crewai")
Observation: {description: "...", readme: "...", stars: 28000}
Agent Action: github_get_repo(name="langchain-agents")
Observation: {description: "...", readme: "...", stars: 19000}
Agent Thought: I now have enough information to summarize all three.
Agent Response: "Here are the top 3 trending AI agent repositories..."
工具选择策略
Agent 用多种策略决定用哪个工具：
| 策略 | 描述 | 权衡 |
|---|---|---|
| 直接匹配 | 工具名/描述匹配需求 | 快，但工具命名差时脆弱 |
| 能力推理 | Agent 推理每个工具能做什么 | 更灵活，但用更多 token |
| Few-shot 例子 | 提示中的例子展示何时用每个工具 | 可靠，但占上下文空间 |
| 工具推荐 | 系统按查询建议相关工具 | 减轻 LLM 的决策负担 |
并行 vs 顺序工具调用
有些任务允许同时调用多个工具：
- 顺序： 先搜索用户，再查其订单历史（需要先有用户 ID）
- 并行： 查三个不同城市的天气（彼此独立）
并行工具调用显著降低延迟。设计 Agent 时，识别哪些工具调用独立且可同时运行。
何时用 Tool Use
此模式适用于几乎任何与外部系统交互的 Agent。关键设计决策是：
- 多少工具？ 从小开始。有 3-5 个设计良好工具的 Agent，通常胜过有 50 个设计糟糕工具的 Agent。
- 工具 schema 描述得如何？ 更好的描述带来更好的工具选择。
- 工具失败时怎么办？ 好的 Agent 优雅处理错误——重试、试替代工具，或向用户求助。
模式 4：Planning（规划）
核心想法
在 Planning 模式中，Agent 在执行前创建计划。不是像 ReAct 那样边走边想每一步，Agent 先向前想，并铺出结构化方法。
项目经理类比
想象项目经理接到构建新功能的请求：
- 拆解：「我们需要更新数据库 schema、写 API 端点、做 UI，并加测试。」
- 排序工作：「先 schema，再 API，再 UI，再测试——每步依赖上一步。」
- 分配资源：「数据库工作给后端团队，UI 给前端团队。」
- 执行与跟踪： 按计划推进，完成一项勾一项。
- 必要时调整：「schema 变更比预期复杂——我重新规划时间线。」
Planning 长什么样
User: "Write a comprehensive blog post about Kubernetes security best practices."
Agent Plan:
1. Research current Kubernetes security threats and CVEs
2. Identify the top 5-7 security best practices
3. For each practice, find concrete examples and commands
4. Write an outline with introduction, main sections, and conclusion
5. Draft each section
6. Review the full post for accuracy and flow
7. Add code examples and formatting
Agent Execution:
[Executes steps 1-7 in order, adjusting as needed]
规划策略
| 策略 | 如何工作 | 最适合 |
|---|---|---|
| 顺序规划 | 创建线性步骤列表 | 简单、理解充分的任务 |
| 分层规划 | 拆成高层目标，再拆子任务 | 复杂、多阶段项目 |
| 条件规划 | 计划中包含 if/then 分支 | 结果不确定的任务 |
| 迭代规划 | 规划几步、执行、再规划 | 后续步骤依赖早期结果的任务 |
Plan-then-execute vs. ReAct
这两种模式代表不同哲学：
| 方面 | Planning | ReAct |
|---|---|---|
| 何时做决策 | 大多提前 | 逐步 |
| 适应性 | 需要显式重规划 | 天然自适应 |
| 效率 | 可并行独立步骤 | 通常顺序 |
| 透明度 | 完整计划提前可见 | 每步推理可见 |
| 浪费工作的风险 | 计划错误时更高 | 更低，边走边适应 |
| 最适合 | 结构良好的任务 | 探索性任务 |
实践中，多数 Agent 混合两种做法：先做粗略计划，执行时再用 ReAct 式推理。
何时用 Planning
| 适合 | 不太适合 |
|---|---|
| 结构清晰的多步任务 | 简单单步任务 |
| 顺序重要的任务 | 纯反应式/对话型 Agent |
| 可并行化的工作 | 路径完全未知的任务 |
| 需要进度跟踪的项目 | 快速、临时请求 |
模式对比
并排比较，帮你选择：
| 模式 | 核心想法 | 优势 | 弱点 | 成本 |
|---|---|---|---|---|
| ReAct | 思考-行动-观察循环 | 灵活、透明 | 可能慢、可能循环 | 中等（多次 LLM 调用） |
| Reflection | 自我审查与改进 | 更高质量输出 | 增加延迟 | 高（多遍） |
| Tool Use | 编排外部工具 | 扩展 Agent 能力 | 依赖工具质量 | 不定（取决于工具） |
| Planning | 先规划再执行 | 结构化、高效 | 计划错误时脆弱 | 中高（规划 + 执行） |
决策流程图
问自己这些问题：
- Agent 需要外部信息或行动吗？ 是 -> Tool Use
- 任务是路径不确定的多步吗？ 是 -> ReAct
- 质量关键且任务有清晰标准吗？ 是 -> Reflection
- 任务复杂但结构良好吗？ 是 -> Planning
- 多数问题的答案都是「是」？ -> 组合模式
组合模式
真实世界 Agent 几乎从不单独使用一种模式。最有效的 Agent 把模式叠在一起。
常见组合
ReAct + Tool Use（最常见组合）
Agent 推理做什么，用工具采取行动，观察结果，再推理。这是多数实用 Agent 的主干。
Think -> Use Tool -> Observe -> Think -> Use Tool -> Observe -> Respond
Planning + ReAct + Tool Use
Agent 创建计划，再用带工具的 ReAct 式推理执行每一步。
Plan -> [Think -> Act -> Observe] -> [Think -> Act -> Observe] -> ... -> Done
Planning + Reflection
Agent 创建计划、执行，再在交付前审查整体输出。
Plan -> Execute -> Reflect -> Revise -> Deliver
全栈：Planning + ReAct + Tool Use + Reflection
对复杂、高风险任务，你可能用全部四种：
Plan the approach
-> Execute each step with ReAct + Tools
-> Reflect on the overall result
-> Revise if needed
-> Deliver
例子：代码生成 Agent
代码生成 Agent 可能这样组合模式：
- Planning：「我需要写 REST API。步骤：定义数据模型、创建端点、加校验、写测试。」
- ReAct + Tool Use： 每一步，Agent 推理该做什么，用工具（文件读取、代码搜索、linter）收集信息并写代码。
- Reflection： 写完代码后，Agent 对照最佳实践审查。「这处理错误了吗？输入校验了吗？有安全问题吗？」
- Revision： Agent 修复反思中发现的问题。
何时不要组合
更多模式并不总是更好。每种模式都会增加：
- 延迟： 更多 LLM 调用意味着更多时间
- 成本： 更多 token 意味着更多钱
- 复杂度： 更多活动部件意味着更多调试
对简单问答 Agent，ReAct + Tool Use 大概就够。把全栈留给质量值得成本的复杂、高价值任务。
Google Cloud 中的模式
Google Cloud 的 Vertex AI Agent Engine 为使用这些模式构建 Agent 提供基础设施。Agent Development Kit (ADK) 给你实现它们的构建块。
Google Cloud 生态中的关键概念：
- Agent Engine 管理 Agent 生命周期——部署、扩缩容与监控
- ADK 提供定义 Agent 行为、工具与编排的框架
- Gemini 模型 作为驱动每种模式中推理的 LLM 骨干
关键要点
Agentic 设计模式是成熟蓝图，用于组织 Agent 如何思考与行动。它们给你共享词汇与架构起点。
ReAct 是基础。 思考-行动-观察循环是最基本的模式，也是多数 Agent 的起点。
Reflection 显著提升质量，但花费时间与 token。质量比速度更重要时使用。
Tool Use 扩展 Agent 能做的事，超越 LLM 内置知识。好的工具设计与好的提示设计同样重要。
Planning 给复杂任务带来结构。 任务理解充分、步骤可提前铺开时效果最好。
有意识地组合模式。 更多模式意味着更多能力，也意味着更多复杂度与成本。从简单开始，按需添加模式。
没有单一最佳模式。 正确选择取决于你的任务、质量要求，以及延迟与成本预算。
延伸阅读
下一课： 记忆与上下文 - Agent 如何记住
评论