13 · 多 Agent 协作

⏱ 40 分钟 ｜ ⭐ 核心

🎯 一句话

多 Agent 不是「更聪明」，是「用 15 倍的 token 换并行度和上下文隔离」。 先证明单 Agent 做不到，再拆。

⚖️ 一、先说代价

   官方公开数据（研究系统，编排器-工作者架构）：
   · 比单 Agent 高出 90.2% 的任务表现
   · 消耗约 15 倍 token  ⭐
   · BrowseComp 上 95% 的性能方差中，token 用量占 80%

   → 结论：多 Agent 只适合【高价值任务】
   → 而且很大一部分收益其实来自"花了更多 token"，不是架构本身

🔑 先做这个对照实验：把给多 Agent 的 token 预算全给单 Agent（让它多试几轮、多验证几次）， 看差距还有多大。很多时候差距会大幅缩小。

🧩 二、多 Agent 真正的两个价值

不是"更聪明"，而是这两个结构性的好处：

如果你的任务两条都不占（不能并行、不需要隔离），那多 Agent 只是在烧钱。

🗂️ 三、五种协作模式

① 编排器-子 Agent（默认起点）⭐

   编排器：规划 → 派发 → 综合
      ├──► 子 Agent 1（干净上下文）──► 摘要
      ├──► 子 Agent 2 ──► 摘要
      └──► 子 Agent 3 ──► 摘要

适合：任务分解清晰、子任务之间依赖少 局限：一个子 Agent 的发现该影响另一个时，编排器成瓶颈 为什么是默认：以最小的协调复杂度覆盖最广的问题范围

② 生成器-验证器

   生产者产出 → 审阅者按标准评估 → 不过就回炉

适合：标准可显式定义的质量关键场景 ⚠️ 局限：「检查一下好不好」这类含糊标准会失败——必须能写成具体条目

③ Agent 团队（持久化工作者）

   任务队列 ←──┬── 工作者A（持久，跨任务保持状态）
               ├── 工作者B
               └── 工作者C

和子 Agent 的关键区别：

④ 消息总线

   Agent 们发布/订阅事件主题，松耦合

适合：流程由发现的事件涌现（如安全运营中心：发现异常 → 触发调查 → 触发响应） ⚠️ 局限：执行路径难追踪；路由错误会静默失败

⑤ 共享状态

   多个 Agent 直接读写同一个持久化存储，无中央协调者

适合：研究综合——发现相互启发 ⚠️ 局限：可能重复劳动或无界循环，必须有显式终止条件

⭐ 这五种模式，行业里叫什么

上面五种的机制你已经知道了。但面试官、框架文档、论文报的是英文术语， 听不出来是同一件事就会白吃亏。这张表只是一层索引，不是新知识：

⚠️ 一个高频混淆：Handoff 不是一种架构，是一个动作。 它指「A 把控制权连同对话一起交给 B，之后由 B 直接和用户对话」。 它可以发生在消息总线里，也可以发生在编排器里——它回答的是「怎么交接」，不是「谁指挥谁」。

🔑 别把这张表当重点：会背这些词不代表知道什么时候不该用， 而「先做等预算对照实验」才是这一章真正想让你带走的东西（第一节）。

🧭 四、选型口诀

   子任务【短、产出离散】        → 编排器-子 Agent
   子任务【持续多步、需累积上下文】→ Agent 团队

   流程【预先定好】              → 编排器
   流程【由事件涌现】            → 消息总线

   工作【可分区、彼此独立】      → Agent 团队
   发现【需要即时互通】          → 共享状态

   有【可显式定义的质量标准】     → 生成器-验证器

🔑 不确定就用编排器-子 Agent。 它是最容易调试、最容易理解的一种。

🧠 五、编排器的两种脑子：走一步看一步，还是先出计划

上面解决的是「谁指挥谁」。还有一个正交的问题没回答：编排器（或任何 Agent）到底什么时候做计划？

教程到这里只给了两极：第 6 章的提示词链是「人预先定死的计划」， 编排器-工作者是「模型现场拆」。中间还有一档常被单独点名的模式。

它们各自解决什么：

• ReAct 就是你在第 1 章写的那个循环。 它的两个问题都很实际：① 每一步的完整观察都要塞回上下文（第 4 章的腐烂）， 长任务里前面的观察会把后面的挤掉；② 没有全局视野——它只知道下一步， 所以容易在两个工具之间来回打转——这就是「无效搜索 / 死循环」的来源， 护栏是第 12 章的 max_steps 和显式终止条件。

• Plan-and-Execute 用一次规划换来两样东西：全局视野（能看出第 5 步依赖第 2 步的产物） 和便宜的执行（执行阶段不需要每步都动用最贵的模型）。 ⚠️ 但它有一个结构性弱点：计划是在信息最少的那一刻做出来的。 所以它必须配一个重规划触发条件，否则执行器会硬着头皮把错的计划走完。

• ReWOO 再往前推一步：把「推理规划」和「工具观察」彻底解耦。 规划时就把各步串起来（第 3 步要用第 1 步的结果），执行时工具返回的内容不回模型， 由执行器按占位符回填，最后才让模型看一次汇总。 ⭐ 省的是往返次数和上下文体积——这和第 8 章 「代码执行 + MCP：数据在沙箱里流转、不过模型」是同一个思想。 ⚠️ 代价也一样：不能根据观察改变路线，只适合「工具结果不影响下一步该调什么」的任务。

什么时候该触发重规划（Plan-and-Execute 少了这一环就等于把错误写死）：

   · 某一步连续失败 N 次（不是偶发抖动，是这条路走不通）
   · 观察到与计划前提【矛盾】的事实
   · 预算过半但完成度明显不足
   · 冒出了计划里根本没有的新子目标

🔑 把这一节压成一句：区别不在「有没有计划」，在于计划是谁做的、什么时候做的、还改不改。

   人预先写死     → 提示词链（第 6 章）
   模型开头做一次  → Plan-and-Execute（错了要能重规划）
   模型边走边拆    → 编排器-工作者（本章 ①）
   压根不做        → ReAct

⚠️ 别默认「有计划就更好」：计划本身要花一次昂贵的调用，而且信息最少的时候做的计划最容易错。 判据还是第 6 章那条——你能提前画出流程图吗？画得出来的部分才值得先规划。

🏭 六、生产级的四条真实教训

来自公开的多 Agent 研究系统实践：

① ⭐ 按复杂度显式分配投入

   ❌ 不管什么问题都派 10 个子 Agent
   ✅ 在编排器提示词里显式规定：

      简单查找  → 1 个 Agent，3–10 次工具调用
      中等对比  → 2–4 个 Agent，各 10–15 次调用
      复杂研究  → 10+ 个 Agent，各有明确分工

   💡 不这么规定的话，模型会在简单问题上过度投入（也是 token 黑洞的主因）

② 并行化的威力

   主导 Agent 同时启动 3–5 个子 Agent
   子 Agent 内部同时用 3+ 个工具
   → 复杂查询的研究时间减少最多 90%

③ ⭐ 让 Agent 改进自己的工具

📌 官方数据：一个「工具测试 Agent」重写工具描述后，任务完成时间下降 40%。

这是第 7 章「评估驱动改进循环」的多 Agent 版本。

④ 含糊的委派指令 = 重复劳动

   ❌ 「去研究一下市场情况」
      → 三个子 Agent 查了同样的东西，回来三份重复报告

   ✅ 每个子任务必须明确：
      · 目标（要回答什么具体问题）
      · 输出格式（多长、什么结构）
      · 工具指引（该用哪些工具）
      · 边界（不要做什么、别人在做什么）

# 结构化委派模板
subtask = {
    "goal": "找出 2026 年 Q2 三家主要竞品的定价变化",
    "output_format": "每家一段，含具体价格和变化时间，300字以内",
    "tools": ["web_search", "read_page"],
    "boundaries": "只看官方定价页，不要看第三方评测；不要分析原因（别人在做）",
}

🚨 七、三个只有上生产才会遇到的问题

🏗️ 八、架构前瞻：大脑与双手解耦

为什么这么拆：第 12 章的命题—— harness 会编码过时的假设，所以架构必须能容纳「尚未被发明的 harness」。

实际收益（官方数据）： - 凭据不进沙箱 → 提示注入偷不到密钥（第 15 章） - 容器按需配置 → 首 token 延迟 p50 降约 60%、p95 降超 90%

🕳️ 九、六个常见坑

📚 延伸阅读

• 多 Agent 协作的五种模式
• 我们如何构建多 Agent 研究系统
• 规模化托管 Agent：大脑与双手解耦
• 用一组并行 Claude 构建 C 编译器
• ⭐⭐ 博弈论与集体决策 09 · 正常形博弈 —— 本章的多个 Agent 目标一致，难点是工程（怎么编排、怎么传上下文）。⭐ 一旦 agent 之间目标冲突，全部换一套工具：那一套讲多个有各自利益的 agent 会怎么互相算计、什么时候会卡在对谁都不好的结果上（囚徒困境），以及规则该怎么设计才防得住

👉 这一节对应的框架：CrewAI / AutoGen 把这几种协作模式做成了现成的。上它们之前先看 16b · 框架这层皮 里那份「该不该上框架」的清单。

✅ 检查点

1. 多 Agent 的代价是多少？在决定用它之前该做什么对照实验？
2. 多 Agent 真正的两个价值是什么？（不是"更聪明"）
3. 五种协作模式各适合什么？默认该选哪个？为什么？
4. 子 Agent 和 Agent 团队的关键区别？
5. 「按复杂度显式分配投入」是什么意思？不做会怎样？
6. 结构化委派要包含哪四项？
7. 状态错误复利怎么解决？
8. 编排器-子 Agent、消息总线、共享状态在行业里分别叫什么？为什么说 Handoff 不是一种架构？
9. ReAct、Plan-and-Execute、ReWOO 的区别是什么？Plan-and-Execute 的结构性弱点是什么、要怎么补？

🛑 可以停在这里

⚡ 走神救援

多Agent不是更聪明，是用15倍token换并行度和上下文隔离——先证明单Agent做不到再拆。官方数据：比单Agent高90.2%的任务表现、约15倍token，且BrowseComp上95%的性能方差里token用量占80%——⭐很大一部分收益其实来自"花了更多token"而不是架构，所以先做等预算对照实验（把预算全给单Agent，差距往往大幅缩小）。两个真价值：并行度（研究时间最多减少90%）和⭐上下文隔离；两条都不占就只是烧钱。五模式：⭐编排器-子Agent是默认（最小协调复杂度、最好调试）、生成器-验证器（⚠️含糊标准会失败，必须写成具体条目）、Agent团队（持久累积上下文 vs 子Agent用完即弃；⚠️完成检测复杂）、消息总线（⚠️路由错误会静默失败）、共享状态（⚠️必须有显式终止条件）。⭐行业术语对照（机制你已经会了，只是名字对不上）：编排器-子Agent＝Supervisor、消息总线＝Swarm/Group Chat、共享状态＝Blackboard 黑板架构、Agent团队＝Crew/Team、生成器-验证器＝Generator-Critic/Reflection；⚠️Handoff 不是架构是动作（A 把控制权连同对话交给 B），它回答「怎么交接」不是「谁指挥谁」。另一个正交问题是计划什么时候做：ReAct（不做计划，每步看观察——⚠️观察全进上下文会腐烂，且没有全局视野容易在两个工具间绕圈）／Plan-and-Execute（开头一次性出完整计划，换来全局视野＋便宜执行；⚠️结构性弱点是计划做在信息最少的那一刻，所以必须配重规划触发条件：某步连续失败 N 次、观察到与计划前提矛盾、预算过半完成度不足、冒出计划里没有的新子目标）／ReWOO（把推理规划和工具观察解耦，规划 1 次＋汇总 1 次、工具结果不回模型，和第 8 章「代码执行+MCP」同源；⚠️代价是中途改不了路线）。⭐区别不在有没有计划，在于计划是谁做的、什么时候做的、还改不改：人预先写死＝提示词链，模型开头做一次＝Plan-and-Execute，模型边走边拆＝编排器-工作者，压根不做＝ReAct。四条教训：①⭐按复杂度显式分配投入——「简单查找1个Agent、3–10次调用；中等对比2–4个各10–15次；复杂研究10+个」，⚠️不规定就会在简单问题上过度投入，这是token黑洞主因；②并行：同时启3–5个子Agent；③让Agent改进自己的工具——重写工具描述后完成时间下降40%；④⚠️含糊委派=重复劳动（「研究一下市场情况」→三份重复报告），结构化委派要含目标/输出格式/工具指引/边界。生产三问题：💀状态错误会复利→从出错点恢复而非从头重跑；非确定性→全量trace＋标注Agent身份；没有发布窗口→彩虹部署。另：子Agent返回太长照样淹没主上下文；解耦后凭据不进沙箱，容器按需配置让首token延迟p50降约60%、p95降超90%。

下一节 👉 14-评测Evals.md