【学习笔记】Agentic 设计模式(二):Reflection / Tool Use / Planning / Multi-Agent 四大智能体模式

19 min

整理日期:2026-07-01 涵盖范围:Reflection、Tool Use / Function Calling、Planning、Multi-Agent Collaboration(本书 Part One Ch 4–7,即 Andrew Ng 四模式) 说明:这是 Agentic 设计模式系列总览 的第二篇分篇,也是全系列最重要的一篇——因为这四个模式正是 Andrew Ng 那套被引用最广的「四大智能体设计模式」,也是让系统从「工作流」升级到「智能体」的核心。内容基于本书英文原书(经 xindoo 中文版核实)、Andrew Ng 的 DeepLearning.AI 四部分系列、Anthropic《Building Effective Agents》。标注「(未确认)」处以英文原书为准。

一、核心结论(太长不看)

  1. 这四个模式 = Andrew Ng 的「四大智能体设计模式」,也正是 Antonio Gulli 本书的第 4–7 章。Ng 在 2024 年 3 月那句「Agent 工作流带来的进步,今年可能比下一代基础模型还大」和「GPT-3.5 套循环达 95.1% 打败 GPT-4 零样本的 67%」就是讲它们。
  2. Reflection 是「自己批评自己、再改」:生成 → 评估 → 修正的反馈循环。本书强调 Producer–Reviewer(生成者–评审者)分离——用两个不同角色/prompt,避免「自己审自己」的认知偏差。Anthropic 叫它 Evaluator-Optimizer,是同一个模式的不同名字。
  3. Tool Use 是「让 LLM 走出静态训练数据」:通过 function calling 调外部 API/数据库/代码。本书给出六步循环(定义工具→LLM 决策→生成调用→执行→观察→处理),并把它泛化成「工具可以是委派给另一个专门 Agent」。
  4. Planning 是「给目标,自己拆步骤、还能动态重规划」。但本书给了一个关键判据:当问题解法已经明确且可重复时,把 Agent 限制在固定工作流里更高效——Planning 只在「解法未知/需发现」时才用。
  5. Multi-Agent 是「多专职 Agent 分工协作」:任务分解 + 标准通信协议 + 共享本体。本书列出六种通信模型(单 Agent/网络/主管/主管即工具/层级/自定义)和多种协作拓扑(顺序交接、并发、辩论共识、层级、专家团、评审)。
  6. Andrew Ng 的成熟度排序很关键:Reflection 与 Tool Use 在生产里已相当可靠;Planning 与 Multi-Agent「很强大但不成熟、难预测」。选型时先落地前两者,别一上来就堆后两者。

来源:Andrew Ng, Agentic Design Patterns Part 1 · xindoo 中文版 Ch4–7 · Anthropic, Building Effective Agents


二、为什么这四个模式是「智能体」的心脏

第一篇 讲的 Prompt Chaining/Routing/Parallelization 都属 Anthropic 的「Workflow」——流程由开发者编排,LLM 不掌舵。而本篇这四个模式,恰好是 Anthropic 判据里「Agent」一侧的核心能力:它们让 LLM 从「按既定路径执行」走向「自我评估、调用工具、自主规划、协作」。

Anthropic 的原话很到位——「Agent 通常就是在循环里、基于环境反馈使用工具的 LLM」。这条描述里,「自我评估」对应 Reflection,「使用工具」对应 Tool Use,「规划循环」对应 Planning,「协作」对应 Multi-Agent。换句话说,这四个模式共同构成了一个最小可用智能体的能力底座。Ng 选它们四个作为「能驱动进步」的关键模式,正是这个原因。

来源:Anthropic, Building Effective Agents · Andrew Ng 四模式系列


三、Reflection:自我反思循环

3.1 定义与机制

定义:一种自我改进机制——Agent 评估自己的输出/过程,并用评估结果迭代地精修响应。

机制:引入一个反馈循环——① 执行,产生初始输出;② 按准则(准确性/连贯性/完整性/指令遵循)评估,由另一次 LLM 调用或规则集完成;③ 反思/修正——找出改进点并重新生成;④ 可选地迭代,直到达到质量阈值或停止条件。

本书的关键强调——Producer–Reviewer(生成者–评审者)分离:用两个专门的角色(或两次不同 system prompt 的 LLM 调用),让评审者用全新的、聚焦的视角和结构化反馈来指导生成者修改。这避免了「Agent 审自己工作」的认知偏差

3.2 Andrew Ng 的版本

Ng 的具体编程示例非常直观:① 生成任务 X 的代码;② 重 prompt「这是为任务 X 写的代码:[代码]。仔细检查其正确性、风格和效率,给出建设性批评」;③ 用「原代码 + 反馈」重 prompt 让它重写;④ 重复批评/重写循环。他还给出两个扩展——(a) 给 LLM 工具来评估输出(跑单测、网搜核对事实);(b) 实现成双 Agent(一个专职生成、一个专职批评)。Ng 自评 Reflection「相对基础」但「带来惊人的性能提升」。

3.3 适用场景

有明确评估准则、且质量/准确率/约束遵循很重要的任务:代码生成 + 调试、创意写作润色、复杂问题求解(错了能回溯)、摘要精修、计划校验。Anthropic 推荐用于「有客观评分或迭代精修能带来可测价值」的任务——两个信号:(1) 人的反馈能明显改进 LLM 输出;(2) LLM 自己能提供这种反馈。

3.4 陷阱与权衡

  • 延迟和算力随每次迭代增长——质量收益 vs 额外调用。
  • 没有好停止条件会陷入无意义或无限循环
  • 评审者可能与生成者共享盲点(尤其同模型时)——角色分离能缓解但不消除。
  • 收益递减:后面的迭代通常加料很少。

来源:xindoo 中文版 Chapter 4: Reflection · Andrew Ng, Part 2: Reflection · Anthropic, Evaluator-Optimizer


四、Tool Use / Function Calling:让 Agent 会行动

4.1 定义与机制

定义:通过(典型地是)function calling,让 Agent 调用外部 API、数据库、服务或代码执行,从而摆脱 LLM 静态训练数据的限制。

机制(本书的六步循环)

  1. 工具定义:把每个函数的用途、名字、参数、类型描述给 LLM;
  2. LLM 决策:给定请求 + 工具目录,模型决定是否/需要哪个工具;
  3. 生成函数调用:模型发出结构化(通常 JSON)请求,命名工具 + 参数;
  4. 执行:编排层拦截,跑真实函数;
  5. 观察:结果返回给 Agent;
  6. 处理(可选但常见):LLM 把输出整合进最终答案,或决定下一步(再调工具、反思、作答)。

本书的泛化:把「function call」拓宽成「tool call」——一个工具可以是 API 端点、DB 查询,甚至委派给另一个专门 Agent。这个泛化为 Multi-Agent 埋下伏笔。

4.2 Andrew Ng 的版本

Ng 的两个标志性例子:(a) 网搜——问「按评论最好的咖啡机?」,LLM 发出 {tool: web-search, query: "coffee maker reviews"},后处理调用函数把结果喂回;(b) 代码执行——问「100 美元 7% 复利 12 年」,LLM 发出 {tool: python-interpreter, code: "100 * (1+0.07)**12"}。他还点出规模问题:工具有几百个时塞不进上下文,要用启发式挑相关子集(类比文本的 RAG)——引 Gorilla 论文。

4.3 适用场景

几乎所有 Agent 必须「行动或取动态信息」的场景:实时数据(天气/股价)、DB/API 交互(电商库存/支付)、计算分析(计算器/数据科学库)、发通信(邮件/消息)、沙箱执行代码。

4.4 陷阱与权衡

  • 幻觉/格式错的工具调用——模型编参数或用错工具名。
  • 错误传播——坏的工具结果会污染最终答案,需要健壮的错误处理。
  • 延迟(往返)和复杂度;Agent 可能过度调用工具。
  • 工具描述本身要写好,否则模型误用。
  • ⚠️ 安全:工具能采取真实世界动作(发邮件、花钱)——需要 Guardrails(Ch18) 和常需 Human-in-the-Loop(Ch13)

来源:xindoo 中文版 Chapter 5: Tool Use · Andrew Ng, Part 3: Tool Use


五、Planning:目标导向与动态重规划

5.1 定义与机制

定义:Agent 构思并承诺一串从初始状态走向目标状态的动作,并在新信息到来时动态修订计划的能力。

机制:规划 Agent 把复杂目标当黑箱——你定义目标和约束(如「组织团建,预算 X、N 人」),Agent 自主搞清怎么做:理解初始状态和目标状态,生成连接它们的最优动作序列。关键是:初始计划只是起点,不是固定脚本——自适应才是核心价值。当首选场地不可用时,好的 Agent 会记录新约束、重评估、重规划(建议替代方案),而不是直接失败。这本质是把状态空间遍历变成目标导向行为。

5.2 Andrew Ng 的版本与「智能体时刻」

Ng 的 HuggingGPT 例子:「画一个和这张男孩图姿势一样的女孩」分解成 ① 检测男孩图姿势 ② 按该姿势渲染女孩,发出结构化计划 {tool: pose-detection, ...} {tool: pose-to-image, ...}。他还有个难忘轶事——他的「AI 智能体时刻」:一次演示中研究 Agent 的网搜 API 撞了限流,Agent 居然自己改用维基百科搜索工具(Ng 都忘了自己给过它),完成了任务。这正是「Agent 以你没预料的方式自主行动」的写照。他坦承 Planning「不那么成熟」「很难预测它会做什么」。

5.3 本书的关键判据(重要)

本书给出一个非常实用的灵活性 vs 可预测性权衡,原话大意:「动态规划是个特定工具,不是万能解。当问题的解法已经明确且可重复时,把 Agent 限制在预定的固定工作流里更高效。」决策就一个问题:「怎么做」是需要被发现的,还是已知的? 已知 → 用 Prompt Chaining/Routing

5.4 适用场景

流程自动化(入职流程拆子任务)、机器人/自主导航(约束下路径规划)、结构化信息综合(多阶段研究报告)、多步客服诊断、任何「需要一串相互依赖操作」的问题。

5.5 陷阱与权衡

  • 比固定工作流更不可预测、更难调试
  • 对简单任务杀鸡用牛刀,只增延迟成本。
  • 计划质量受限于 LLM 推理能力,坏计划会传播。

来源:xindoo 中文版 Chapter 6: Planning · Andrew Ng, Part 4: Planning


六、Multi-Agent Collaboration:分工协作

6.1 定义与机制

定义:多个各具专门角色/工具/知识的 Agent 协作达成共同目标,通过任务分解把单 Agent 能力扩展到复杂、跨域任务。

机制:建立在任务分解上——把高层目标拆成子问题,按工具/数据/专长分给最合适的 Agent,通过标准通信协议 + 共享本体协调以保证输出连贯。本书详列两套维度:

协作拓扑:顺序交接、并发处理、辩论共识、层级(管理者委派工人)、专家团、评审 - 评审者。

通信/交互模型(六种)

模型描述风险
① 单 Agent基线
② 网络(Network)去中心化点对点协调复杂
③ 主管(Supervisor)中央枢纽单点故障 + 瓶颈
④ 主管即工具提供资源而非发号施令
⑤ 层级(Hierarchical)多层主管复杂
⑥ 自定义定制混合

6.2 Andrew Ng 的版本

Ng 的标志性例子:通过一个虚拟公司来构建软件——Agent 扮演软件工程师、产品经理、设计师、QA 工程师(引 ChatDev「一个跑虚拟软件公司的 Agent 集合」)。他特别澄清一个反直觉点:这些 Agent 往往是同一个 LLM 被 prompt 成不同角色,他给了三个理由:(1) 有效(AutoGen 论文消融显示多 Agent 优于单 Agent);(2) 让 LLM 每次专注一个子任务(利于长上下文理解);(3) 是有用的开发者抽象,类比把程序拆成进程/线程。他再次把它与 Planning 并列为「不那么可预测」。

6.3 适用场景

复杂研究/分析(搜索→摘要→趋势→综合)、软件开发(需求→编码→测试→文档)、创意活动、金融分析、客服升级、供应链优化、网络故障定位。

6.4 陷阱与权衡

  • 通信开销与规模化时的连贯性——跨多 Agent 管消息传递和一致决策很难。
  • 主管模型引入单点故障和瓶颈(过载时)。
  • 成本和延迟随 Agent 数/调用数倍增。
  • 协调 bug、冲突决策、「涌现」的非预期行为。
  • ⚠️ 可能过度工程——简单任务上一个 prompt 良好的单 Agent 可能优于多 Agent 系统。

来源:xindoo 中文版 Chapter 7: Multi-Agent · Andrew Ng, Part 5: Multi-Agent Collaboration


七、四模式横向对比

维度ReflectionTool UsePlanningMulti-Agent
核心动作自评 + 自改调外部能力自主拆步 + 重规划分工协作
是否带循环是(反馈循环)是(调用循环)是(规划 - 执行循环)是(协调循环)
Anthropic 对应Evaluator-Optimizer增强 LLM 的 toolsAgent / Orchestrator-WorkersAgent / Orchestrator-Workers
Ng 成熟度评价可靠可靠难预测难预测
主要代价迭代延迟/算力往返延迟 + 错误传播不可预测 + 难调试通信开销 + 成本倍增
过度使用风险无意义循环过度调工具简单任务杀鸡牛刀过度工程,单 Agent 更好

来源:Andrew Ng 四模式系列 · Anthropic, Building Effective Agents


八、按用途选型决策表

你的用途推荐方案
想让输出能自我纠错、质量更高Reflection(Producer–Reviewer 分离)
Agent 要查实时数据 / 调 API / 跑代码Tool Use / Function Calling
目标复杂、步骤无法预设Planning(但先问「解法是否已知」,已知则退回工作流)
单 Agent 搞不定、要分工Multi-Agent(简单任务别上,单 Agent 可能更好)
要可靠落地,先选哪两个Reflection + Tool Use(Ng 评二者最可靠)
要做「评审 - 改进」的轻量多 AgentReflection 的双 Agent 版本(生成者 + 评审者)
要工具能被发现/互通/跨厂商把 Tool Use 升级成 MCP

一句话总原则:先用 Reflection + Tool Use 把可靠收益拿到手;Planning 和 Multi-Agent 留给「解法未知」或「单 Agent 真不够」的场景——它们更强大,但也更贵、更难预测。


九、参考资料

Andrew Ng 四模式系列(DeepLearning.AI The Batch)

原书与对照

姊妹篇