多 Agent 协作模式

多 Agent 是被高估最多的主题。本篇的立场写在前面：多 Agent 是解决”上下文放不下”和”工作可并行”的工具，不是让 agent 更聪明的魔法。先用 Anthropic 的模式词汇把正确用法讲清，再看两个系统各自怎么实现，最后列翻车方式。

:::info 学习目标 完成本篇后你能够：实现一个最小的 orchestrator-workers 并算清收益总账；用检查清单判断一个需求是否真的需要多 agent；说出子 agent 的契约要素（任务、预算、可否提问）。 前置：第 8 篇的 sub-agent 隔离可用。预计时长：60 分钟。 :::

:::note 本章术语速查（新手建议先读）

• Orchestrator-Workers（编排者-工人）：一个主 agent 拆任务分给多个下属 agent 并行干，最后汇总。
• Evaluator-Optimizer（生成-评审）：一个 agent 干活，另一个按标准挑毛病，循环到合格。
• 上下文隔离：worker 的中间过程留在自己的窗口里，只向主 agent 汇报结论。
• 协调失败率：多 agent 协作出错的概率——拆得越多，失败点越多，这是多 agent 的主要代价。 :::

三种正确用法

模式一：orchestrator-workers（编排者-工人）。 一个主 agent 拆解任务、分发工人、汇总结果。适用：任务可并行分解且子任务互不依赖——“在三个子目录里分别查找 X”或 Anthropic 自己的多 agent 研究系统（并行搜索多个来源）。

模式二：evaluator-optimizer（生成-评审循环）。 一个 agent 产出，另一个按标准评审，循环到合格。适用：有明确评判标准且生成比验证容易——代码走查、事实核查、文稿打磨。

模式三：专业分工（角色隔离）。 不同 agent 挂不同工具与提示词——有写权限的 worker、只读的 reviewer、面向用户的 assistant。价值不在”多个大脑”，在权限与上下文的隔离（第 8、12 篇的延续）。

两个系统的实现

Codex：ThreadManager::spawn_subagent + multi_agents 工具族（handlers 里有 multi_agents/multi_agents_v2），子 agent 是完整线程——独立 rollout、独立 turn 循环；agent 间的消息（InterAgentCommunication）作为独立事件类型进会话日志，编排者发起新 turn 的通信还会被标记（trigger_turn: true）——多 agent 的协作史全程可审计。

dsh：ctx.subagents 服务 + tool-subagent 工具，设计上更激进——提供方可插拔：进程内 spawn/fork 之外，还有 ACP、真实 Codex、真实 Claude Code、经 TS SDK 的完整 Harness 运行时，“把一个轮次委托给另一个产品”与”新建子 agent”在同一接口之后。实验性的 Agent Teams 在其上加持久花名册、任务板与信箱。边界规则也值得学：dsh 的子 agent 不能调用 ask_user_question（DELEGATED_CALLER 拒绝）——提问权归直接面对人类的 agent。

算一笔成本账：orchestrator 把任务拆给 3 个 worker，每个 worker 自己跑 5 步探索——总 token ≈ 单 agent 的 3~4 倍（每个 worker 各带一份系统提示与工具 schema）。换来的收益是并行延迟与上下文隔离。只有当”省下的时间 × 业务价值 > 多花的 token 成本 + 协调失败率”时，多 agent 才划算——这笔账要在设计期就算，不要上线后才发现。

对照第 8 篇：那篇的 sub-agent 是上下文隔离手段（探索外包、结论回传）；本篇多了并行与评审两个动机。同一条技术路径，三种业务用途。

四种典型翻车

1. 为智能而多智能体：任务本来就一条流程能解决，拆成多 agent 后徒增协调失败点。Anthropic 的原则反着说最清楚：先找到最简单的方案，数一数它为什么不够。
2. 过程污染主上下文：worker 把全部探索过程回传给 orchestrator——隔离白做了。契约必须是”结论 + 关键引用”，两系统的做法一致（dsh 明确子 agent 结果以紧凑消息回流；Codex 的 agent 间通信是独立事件不进主对话）。
3. 没有完成判据：worker 之间互相等待、或永远”再检查一遍”。每个 worker 的任务必须有可判定的完成条件与步数上限。
4. 评审者比生成者弱：evaluator-optimizer 里 judge 水平不足时，循环在噪音上收敛。judge 模型至少与生成者同级，rubric 明确到可执行。

何时不用多 Agent（检查清单）

• 单 agent + 好工具 + 压缩能解决？→ 用单 agent。
• 问题是”上下文放不下”？→ 只需要第 8 篇的 sub-agent 隔离，不需要”协作”。
• 需要的是并行加速且子任务无依赖？→ orchestrator-workers，正确。
• 有客观评审标准？→ evaluator-optimizer，正确。
• 都不是？→ 别用。

随堂练习（带验收标准）

1. 最小编排：实现 orchestrator-workers。验收：串行 vs 并行的总耗时对比有数字，worker 失败时主 agent 能降级汇总；
2. 总账：统计并行省下的延迟 vs 协调开销（token 翻倍、失败率上升）——允许的结论是”不值得”，多 Agent 的收益必须每季度重新论证；
3. 反例演练：把一个单 agent 能完成的任务强行拆成三个 worker，记录失败/重复/遗漏——亲手制造一次”为智能而多智能体”的翻车；
4. 读 dsh 的 tool-subagent 源码（packages/subagent/），列出它的委托参数（任务、预算、可否提问），对照本篇的契约三要素。