13 · 多 Agent 协作

⏱ 40 分钟 ｜ ⭐ 核心

🎯 一句话

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

⚖️ 一、先说代价

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

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

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

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

🗂️ 三、五种协作模式

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

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

② 生成器-验证器

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

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

和子 Agent 的关键区别：

④ 消息总线

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

⑤ 共享状态

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

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

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

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

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

🧭 四、选型口诀

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

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

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

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

它们各自解决什么：

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

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

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

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

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

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

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

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

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

② 并行化的威力

③ ⭐ 让 Agent 改进自己的工具

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

这是第 7 章「评估驱动改进循环」的多 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 不是更聪明，是用十几倍 token 换并行度和上下文隔离——先证明单 Agent 做不到再拆。

⚠️ 官方数据里性能方差的绝大部分由 token 用量解释——⭐ 很大一部分收益其实来自「花了更多 token」而不是架构，所以先做等预算对照实验（把预算全给单 Agent，差距往往大幅缩小）。真价值只有两个：并行度和上下文隔离；两条都不占就只是烧钱。

⭐ 编排器-子 Agent 是默认选择（协调复杂度最小、最好调试）。其余四种模式各有各的失败方式：生成器-验证器要求把标准写成具体条目（含糊必失败）、消息总线的路由错误会静默失败、共享状态必须有显式终止条件。

⭐ 另一个正交问题是计划什么时候做：ReAct 不做计划（⚠️ 观察全进上下文会腐烂、没有全局视野容易绕圈）、Plan-and-Execute 开头一次做完（⚠️ 结构性弱点是计划做在信息最少的那一刻，所以必须配重规划触发条件）、ReWOO 把规划和观察解耦（⚠️ 代价是中途改不了路线）。

⭐ 区别不在有没有计划，在于计划是谁做的、什么时候做的、还改不改。

⚠️ 必须按复杂度显式分配投入（几个 Agent、各调用几次）——不规定就会在简单问题上过度投入，这是 token 黑洞的主因。⚠️ 含糊委派等于重复劳动：「研究一下市场情况」会换回三份内容雷同的报告。

💀 生产上最贵的一条：状态错误会复利——要能从出错点恢复，而不是从头重跑。

下一节 👉 14-评测Evals.md