Anthropic 把多 Agent 协调归纳成五种模式，我照着自家系统对了一遍，发现三点跟直觉相反的东西。

先说最该记住的一句：多 Agent 不是默认选项。官方给的口径是先用单 Agent，多 Agent 会带来 3-10 倍的 token 开销，只有三种情况才值得上——上下文污染（一个子任务的信息把另一个的推理搅浑了）、并行加速（任务能真拆开同时跑）、专业化（不同任务要不同工具集和领域知识）。都不沾边的话，单 Agent + 一个好 prompt 几乎总是更优解。

五种模式

1. Generator-Verifier（生成-验证） 一个生成，一个按明确标准验，不过就带反馈重生成，直到通过或撞上最大迭代次数。最广泛部署的一种。 坑在于：验证器如果只被告知”看看好不好”，它会橡皮图章式放行，给你一个质量控制的假象。标准必须具体、可评估（比如”处理空输入/零/负数”这种能打分带阈值的）。 不适用：评估和生成一样难的活（创意写作，验证器不比生成器更会判断）；说不清什么叫”好”的活；生成器改不动的活——那会在 max_iterations 里来回振荡，得设兜底。

2. Orchestrator-Subagent（编排-子 Agent） 一个领导拆任务、综合结果，多个子 Agent 各带独立上下文执行。三段式：规划 → 并行派发 → 综合。Claude Code 自己就用这个——主 Agent 写代码改文件，把翻代码库这种探索活甩给后台子 Agent，子 Agent 返回精炼结果，主上下文保持干净。 最反直觉的一条原则：按上下文分解，不按工作类型分解。“一个写功能、一个写测试、一个审查”是错的——每次交接都掉上下文，等于玩传话游戏。正确做法是谁写这个功能谁写它的测试，只有上下文真能隔离时才拆。 不适用：编排器会变成信息瓶颈（子 Agent 之间的依赖必须它识别并路由，转几手关键细节就丢了）；不显式并行就没有速度收益，白花多 Agent 的钱。

3. Agent Teams（Agent 团队） 跟上一个的区别就一个词：worker 的持久性。Orchestrator 的子 Agent 干完就销毁、下次从零；Teams 的队友一直活着，跨多个任务攒上下文和专长。像项目经理外包 vs. 带一个固定团队——队友越做越熟。 适合大规模代码库迁移、批量翻译、多步持续的独立子任务。 不适用：队友之间不能直接通信，A 影响到 B 时两边都不知道；完成时间不均衡（一个 2 分钟一个 20 分钟）；共享资源会打架，得做任务分区和冲突处理。

4. Message Bus（消息总线） Agent 多了以后直连协调管不过来，改成发布/订阅。每个 Agent 只声明订阅什么、能发布到什么，新 Agent 加入只需订阅主题，不动已有连接。 跟 Orchestrator 的本质区别：Orchestrator 的流程是预先定好的，Message Bus 的流程是从事件里涌现的——不用提前规划”告警 A 走哪条路”，总线按事件类型自动路由。 不适用：因果链难追（一个告警级联五个 Agent，出事得翻日志还原）；路由准确性是命门，分类错了或丢了事件系统会静默失败——什么都没干也不报错；固定三步的流程用这个是杀鸡用牛刀。

5. Shared State（共享状态） 没有中央协调者，各 Agent 读写同一个存储，自主运行、读别人的发现、写自己的结果。 最容易翻车的是终止条件——没有显式终止条件的共享状态系统会无限循环烧 token。 不适用：可能重复劳动（两个 Agent 独立查同一条线索）；反应式循环（A 写→B 读到再写→A 又读到…不收敛）；行为是涌现的、不确定。作者点出一个区分很好：重复工作和并发写入有成熟工程方案（锁、版本、分区），但反应式循环是行为问题，得靠一等公民级别的终止条件治。

我的三点判断

一、这五种不是并列的菜单，是一条按耦合度递减排的谱系。 Generator-Verifier 是两点一线，Orchestrator 是星型，Teams 是星型+记忆，Message Bus 把中心换成了广播，Shared State 连中心都不要了。往右走一格，灵活性和扩展性上去一格，可观测性和确定性就掉一格。选型的真问题不是”哪个更先进”，而是”我能容忍多少不确定性、我调试得起吗”。默认应该从最左边选起，被具体痛点推着才往右挪。

二、“按上下文分解不按工作类型分解”是最值钱的一条，也是最容易违反的。 因为按工作类型拆特别符合人的直觉——像分工。但 Agent 之间的交接成本远高于人类同事，人交接靠共同记忆和随时追问补，Agent 只有你塞给它的那段上下文。这条我们自己踩过：把”深扒”和”写稿”拆成两个 worker，写稿那个拿不到深扒时的现场判断，只能照着结论重新编一遍语气。合成一个反而更好。

三、多 Agent 系统真正的失败模式不是慢，是静默。 五种模式的”不适用”里反复出现同一件事：橡皮图章式放行、编排器丢细节、队友产出冲突、路由丢事件、循环烧 token——它们的共同点是系统不报错。传统系统挂了会 crash，多 Agent 系统坏了会继续输出看起来像样的东西。所以配套的不是更强的模型，是终止条件、显式标准、可追溯日志这些看着无聊的工程件。

对照我们自己

我们现在用的是 Orchestrator-Subagent（主会话判断 + 后台 worker 执行）+ Generator-Verifier（发送前的审稿链）的组合，Shared State 用在文件总线上。对照下来该补的是两条：worker 的验证标准还不够具体（容易橡皮图章），以及共享状态那条路的终止条件应该更显式一点。

原文：《Claude 多 Agent 协调 5 种设计模式》，渔夫 AIDaily 配套代码：https://github.com/anxiong2025/claude-multi-agent（tutorials/ 下五个可运行脚本，各对应一种模式）