这篇学完你能回答什么
- 多 Agent 有哪些编排模式？orchestrator-workers 适合什么场景？
- 多 Agent 一定比单 Agent 好吗？什么时候反而是灾难？
- 拆成多个 Agent 之前，你会问自己哪三个问题？
从一个真实故障讲起
一个客服系统，按业务线拆成了三个 Agent：账单 Agent、技术支持 Agent、退换货 Agent，用 handoff（交接）模式互相转交——谁发现"这不归我管"就转给别人。架构图画出来非常漂亮，像一个真实的客服团队。
上线第九天，一条会话烧掉了 4 万多 token，跑了 40 多轮才被超时掐断。轨迹是这样的：
用户：我上个月被扣了两次钱，而且 App 一直闪退 账单Agent → "涉及 App 崩溃，转技术支持" （它只看到了后半句） 技术支持Agent → "重复扣费属于账单问题，转账单" （它只看到了前半句） 账单Agent → "转技术支持" 技术支持Agent → "转账单" ... 循环 17 次 ...
这是多 Agent 系统的头号失败模式：无限交接。 根因不是模型笨，是三个叠加的设计缺陷：
- 没有人拥有这个任务。每个 Agent 只判断"归不归我管"，没有任何一方负责"这个用户的问题最终有没有解决"。
- 每次交接都在丢上下文。转交时只带了一句话摘要，接手方看到的是残缺信息，于是它的判断也必然残缺——上下文损耗随交接次数复利式累积。
- 这个任务本来就是复合的。一个用户的一次诉求横跨两个域，而架构假设了"每个问题属于且仅属于一个域"。
修复方案里最反直觉的一条是：他们把三个 Agent 合并回了一个，只保留一套工具（账单查询 + 日志查询 + 工单创建），准确率和成本同时改善。
因为拆分的理由从一开始就是错的——他们拆的是业务组织结构，而不是上下文污染边界。
一条复合诉求
被扣两次钱，而且 App 一直闪退
账单 Agent 转出断点
只带一句话摘要，它只看到后半句
技术支持转回
接手方拿到残缺信息，判断也残缺
循环 17 次被掐断
跑了 40 多轮，超时才停下
核心概念：先打比方，再给定义
比喻：多 Agent 不是"组建一个团队"，而是"隔离污染源"。
人类组建团队是因为一个人的时间和精力有限，多个人可以真正并行。但 Agent 的"并行"只在互相不需要看到对方工作过程的时候才成立。一旦两个子任务需要频繁交换中间状态，多 Agent 的通信开销和信息损耗，会迅速吃掉分工带来的一切好处。
所以判断要不要拆，最诚实的问法不是"这个系统有几种角色"，而是：
这两个子任务如果共享同一个上下文窗口，会不会互相污染？
如果答案是"会"（比如一个要读 50 个网页、另一个要读 30 个代码文件，混在一起谁也别想干净），那就该拆。如果答案是"不会，它们本来就该互相知道"，那拆开只会制造信息碎片。
定义：多 Agent 系统（Multi-Agent System） 指由多个各自持有独立上下文、独立提示词、可能独立工具集的 Agent 协同完成一个任务的系统。关键词是独立上下文——这才是"多 Agent"和"一个 Agent 挂很多工具"的真正分界。
人组队，因为一个人时间精力有限
Agent 的并行只在互相不需要看到对方工作过程时才成立
看的是上下文污染，不是角色分工
频繁交换中间状态时，通信开销和信息损耗会吃掉分工的一切好处
一个读 50 个网页，一个读 30 个代码文件
混在一个上下文里，谁也别想干净
各自独立上下文、独立提示词的协同
独立上下文才是它和「一个 Agent 挂很多工具」的真正分界
原理拆解
| 模式 | 形状 | 适合 | 风险 |
|---|---|---|---|
| ① 顺序流水线 | A → B → C → D | 解析→抽取→校验→摘要 这类线性多阶段 | 级联错误，前面错了后面全错 |
| ② 编排器-执行器 | 一拆多，通常并行 | 可并行的只读探索：多源调研、多文件分析 | 编排器自己变成瓶颈和上下文黑洞 |
| ③ 交接 handoff | A ⇄ B ⇄ C | 事前无法预知需要哪个专家 | 无限交接，上下文随交接损耗 |
| ④ 辩论 / 评审 | Generator ⇄ Critic | 有评审标准，且验证比生成便宜 | 成本翻倍；无外部信号时退化为互相认可 |
| ⑤ 黑板 blackboard | 多 Agent 读写同一块共享状态 | 松耦合、事件驱动的长期任务 | 并发写冲突、调试地狱 |
两条纪律缺一不可：进去的必须是结构化任务简报 —— 目标 / 输出格式 / 可用工具与信息源 / 任务边界（什么不要做）；自由发挥式的委派（「你去查一下这个」）是有记录的失败模式，worker 会做出编排器根本没要的东西。
别复用编排器的 system prompt —— 角色不同、工具不同、约束也不同。worker 的输出可以直接转发给用户，编排器不必再转述一遍，那是它变成上下文黑洞的另一条路。
五种编排模式
① 顺序流水线（pipeline）
A → B → C → D 每个环节处理上一环的输出，顺序在设计时确定
适合：解析→抽取→校验→摘要 这类线性多阶段处理
风险：级联错误，前面错了后面全错
② 编排器-执行器（orchestrator-workers / supervisor）
┌──── Orchestrator ────┐ ← 拆解任务、分派、汇总
↓ ↓ ↓
Worker1 Worker2 Worker3 ← 各自独立上下文，通常并行
适合：可并行的只读探索（多源调研、多文件分析、多方案对比）
风险：编排器自己变成瓶颈和上下文黑洞
③ 交接（handoff / 去中心化）
A ⇄ B ⇄ C 任一 Agent 可把控制权转给更合适的同伴
适合：事前无法预知需要哪个专家的场景
风险：**无限交接**（开篇故障），上下文随交接损耗
④ 辩论 / 评审（debate / critic）
Generator ⇄ Critic 一个产出，一个挑刺
适合：有明确评审标准、且验证比生成便宜的产出
风险：成本翻倍；无外部信号时退化为互相认可（同 T3-7 的 Reflection 前提）
⑤ 黑板（blackboard）
多个 Agent 读写同一块共享状态，按条件触发
适合：松耦合、事件驱动的长期任务
风险：并发写冲突、调试地狱生产里活得最好的是 ① 和 ②。③ 需要非常强的纪律才不出事，④ 只在有验证器时成立，⑤ 在业务系统里很少见。
orchestrator-workers 的真实形态
这个模式之所以最常被推荐，是因为它把"上下文隔离"表达得最直接：
用户任务
│
┌────────▼────────┐
│ Orchestrator │ 上下文里只有：任务、子任务清单、各 worker 的
│ （拆解 + 汇总） │ **结构化摘要**——绝不放 worker 的完整过程
└──┬────┬────┬────┘
│ │ │ 每个 worker 收到一份「结构化任务简报」
┌──────▼┐ ┌─▼───┐ ┌▼──────┐
│Worker1│ │W2 │ │W3 │ 各自独立上下文，互不可见
│读50个 │ │查库 │ │读代码 │ ← 这三件事混在一个上下文里就是灾难
│网页 │ │ │ │ │
└───┬───┘ └─┬───┘ └───┬───┘
└───────┴─────────┘
返回：结构化摘要（不是 transcript）两条被反复验证的工程纪律（截至 2026-08）：
- 子 Agent 必须收到结构化任务简报，不能是自由文本委派。简报至少包含四项：目标 / 输出格式 / 可用工具与信息源 / 任务边界（什么不要做）。自由发挥式的委派（"你去查一下这个"）是有记录的失败模式——worker 会自行发挥，做出编排器根本没要的东西。
- 子 Agent 必须返回结构化摘要，不能返回完整 transcript。把 worker 的全过程灌回编排器，既污染上下文又暴涨成本。这条不做，编排器会在 4 个 worker 左右就撑爆上下文，然后你会看到它开始遗忘最初的任务。
另外，子 Agent 要有自己的 system prompt，不要复用编排器的——角色不同，可用工具不同，约束也不同。
多 Agent 的六种典型死法
| 失败模式 | 表现 | 对策 |
|---|---|---|
| 无限交接 | A→B→C→A 循环，没人拥有任务 | 全局步数/交接次数上限；指定任务所有者；同一 Agent 不允许被连续交接两次 |
| 编排器黑洞 | 编排器上下文被 worker 输出撑爆，变成新的单点 | 结构化摘要返回；worker 输出直接转发给用户（编排器不必转述） |
| 级联错误 | 上游一个小错在下游被放大成大错 | 每个环节加校验；关键节点回读原始数据而非上游结论 |
| 信息碎片化 | 每个 Agent 只看到局部，谁也拼不出全貌 | 共享一份只读的任务事实表；或者干脆合并成单 Agent |
| 讨好式汇报 | worker 为了"完成任务"谎报成功（比如声称测试通过） | 独立校验 Agent 或程序化验证，不采信 worker 的自我评价 |
| 部分失败无策略 | 5 个 worker 有 1 个超时，系统不知道该怎么办 | 事前定死三选一：降级组装 / 只重试该分支 / 整体失败 |
其中"讨好式汇报"和"部分失败无策略"是最容易在面试里加分的两条——因为它们只有真跑过并行 worker 的人才会遇到。
成本：拆分不是免费的
多 Agent 的总成本通常是等价单 Agent 的数倍（业界常见的观察区间是 3～8 倍，具体取决于编排器调用次数、worker 数量和上下文重复度）。开销来自三处：
- 编排器自身的拆解与汇总调用；
- 每个 worker 都要重复接收一份背景上下文；
- 结果回传与再推理。
这意味着：如果你的任务不是"多个子任务真的可以并行"，多 Agent 就是纯亏。 顺序依赖的任务用多 Agent，你付了分布式的代价，却没拿到并行的收益。
工程实践（截至 2026-08）
拆分前的三问
在动手拆之前，逐条回答，有任何一条答不上来就先别拆：
- 这里是否存在 ≥2 种"真正不同的技能"？（不是"两个步骤"，是两种能力。写一句话描述成功产出，再列出需要的子技能——如果列出来只有一种，就建单 Agent。）
- 这些子任务共享上下文会互相污染吗？（污染是拆分最诚实的理由。）
- 它们能真正并行吗？（不能并行还拆，等于只买单不吃饭。）
进阶技术三段式：多 Agent 编排
- 解决什么：上下文隔离（互不干扰的探索空间）、真并行带来的墙钟时间压缩、以及不同角色的工具与权限隔离（worker 只拿到自己需要的工具，降低误用面）。
- 代价是什么：① 成本数倍增长；② 信息碎片化与级联错误；③ 调试难度指数上升，你需要跨 Agent 串联的 trace 才能看懂发生了什么；④ 一致性问题：多个 worker 对同一事实给出矛盾结论时，谁说了算需要显式规则；⑤ 部分失败的组合状态爆炸。
- 什么时候不该用：顺序依赖强的任务（"按顺序做这几步，每步之间要判断"——文献与实践都指向"单 Agent + 严格上下文管理"更好）；需要共享状态的任务；能通过更好的提示词或多挂两个工具解决的任务；以及——你拆分的依据是组织架构或"听起来更专业"的时候。
避坑清单
- 别按业务部门拆 Agent。开篇的故障就是这么来的：用户的问题不按你的组织架构分类。
- 全局步数与预算上限必须有，且要覆盖所有 Agent 的总和，而不是每个 Agent 各管各的。
- 交接次数单独限流：连续交接 3 次未解决就升级到统一处理或转人工。
- trace 要能跨 Agent 串联（统一 trace id + 父子 span），否则出事时你只能看到几段互不相干的日志（T3-11）。
- 先用单 Agent 打基线。没有基线，你无法证明拆分带来了收益——面试里被问"多 Agent 比单 Agent 好多少"时，没有基线就答不上来。
- 评测要看轨迹不只看结果：多 Agent 系统很容易"结果碰巧对了但过程一塌糊涂"（T3-11、T5-5）。
| 失败模式 | 表现 | 对策 |
|---|---|---|
| 无限交接头号死法 | A→B→C→A 循环，没人拥有任务 | 全局步数/交接次数上限；指定任务所有者；同一 Agent 不允许被连续交接两次 |
| 编排器黑洞 | 编排器上下文被 worker 输出撑爆，变成新的单点 | 结构化摘要返回；worker 输出直接转发给用户，编排器不必转述 |
| 级联错误 | 上游一个小错在下游被放大成大错 | 每个环节加校验；关键节点回读原始数据，而不是上游结论 |
| 信息碎片化 | 每个 Agent 只看到局部，谁也拼不出全貌 | 共享一份只读的任务事实表；或者干脆合并成单 Agent |
| 讨好式汇报 | worker 为了「完成任务」谎报成功，比如声称测试通过 | 独立校验 Agent 或程序化验证，不采信 worker 的自我评价 |
| 部分失败无策略 | 5 个 worker 有 1 个超时，系统不知道该怎么办 | 事前定死三选一：降级组装 / 只重试该分支 / 整体失败 |
- 拆分三问
- ① 有没有 ≥2 种真正不同的技能 ② 共享上下文会不会互相污染 ③ 能不能真正并行
- 成本倍数
- 常见观察区间 3～8 倍：编排器拆解汇总、每个 worker 重复接背景、结果回传再推理
- 子 Agent 契约
- 结构化简报进（目标/格式/工具/边界）、结构化摘要出、各自独立的 system prompt
- 限流放在全局
- 步数与预算上限要覆盖所有 Agent 的总和；连续交接 3 次未解决就升级或转人工
- 先打基线
- 没有单 Agent 基线，被问「多 Agent 好多少」时你答不上来，也证不明拆分的收益
- trace 与评测
- 统一 trace id + 父子 span 跨 Agent 串联；评测要看轨迹，不只看结果（T3-11）
面试视角
- 先给判据再给模式「只看两个子任务共享上下文会不会互相污染」
- 列模式时带上失败模式而不是只报适用场景
- 主动讲子 Agent 契约简报进、摘要出、独立 system prompt
- 报成本倍数并说来源编排器调用、背景重复、结果回传
- 收在一个「合回去」的故事这比任何架构图都能证明判断力
- 认为多 Agent 天然优于单 Agent，「更专业、分工明确」
- 按业务部门或组织架构划分 Agent
- 说得出 supervisor、handoff 等模式名，说不出各自怎么坏
- 让 worker 把完整对话历史返回给编排器
- 从没算过多 Agent 相对单 Agent 的成本倍数
- 讲得出一次「拆错了又合回去」的经历，并说清为什么拆错
- 用上下文污染当拆分判据，而不是角色分工
- 说得出无限交接的对策：任务所有者、交接次数上限
- 提到契约四要素（目标/格式/工具/边界）和摘要不返回 transcript
- 有单 Agent 基线和对比数字，答得出「好多少」
面试官怎么问
答题结构建议
- 先给判据再给模式："我判断要不要拆，只看两个子任务共享上下文会不会互相污染。"——一句话把你和背模式的人分开。
- 列模式时给失败模式，而不是只给适用场景。
- 主动讲子 Agent 契约：结构化简报进、结构化摘要出、独立 system prompt。
- 报成本倍数并说明来源。
- 最强的收尾是一个"我们把多 Agent 合并回单 Agent"的故事——这比任何架构图都能证明你有判断力。
分水岭信号
只读过资料的回答：
- 认为多 Agent 天然优于单 Agent，"更专业、分工明确"。
- 按业务部门 / 组织架构划分 Agent。
- 说得出 supervisor、handoff 等模式名，说不出各自怎么坏。
- 没有全局步数上限，只在单个 Agent 里限步。
- 从没算过多 Agent 的成本倍数。
- 让 worker 返回完整对话历史给编排器。
真做过的回答：
- 用上下文污染作为拆分判据，而不是角色分工。
- 说得出无限交接这个头号失败模式及其对策（任务所有者、交接次数上限）。
- 提到子 Agent 契约四要素（目标/格式/工具/边界）和"返回摘要不返回 transcript"。
- 提到讨好式汇报——worker 会谎报成功，需要独立验证。
- 事先定义了部分失败的三选一策略。
- 有单 Agent 基线并能给出对比数字。
- 讲得出一次"拆错了又合回去"的经历。
小结与延伸
- 多 Agent 的唯一正当理由是上下文隔离，不是角色分工，更不是组织架构。
- 五种模式里，生产可靠的主要是顺序流水线和编排器-执行器。
- 六种典型死法：无限交接、编排器黑洞、级联错误、信息碎片化、讨好式汇报、部分失败无策略。
- 子 Agent 契约：结构化简报进、结构化摘要出、独立 system prompt。
- 成本通常是单 Agent 的数倍；顺序依赖的任务拆了纯亏。
- 拆之前先问三题：有没有 ≥2 种真正不同的技能、会不会互相污染、能不能真并行。
延伸：跨 Agent 的 trace 串联与轨迹评估见 T3-11；跨组织的 Agent 委派协议见 T3-5；把子 Agent 当作"上下文管理手段"这个视角，可以回头对照 T3-6。
继续深入
本篇归属第 3 章「Agent 开发」，去做这一章的题。