多 Agent 系统的 5 种协调模式：选错了模式，再强的 Agent 也白搭
引言
我见过太多团队在搭建多 Agent 系统时犯同一个错误——先选最复杂的架构，再硬把问题塞进去。结果就是：一个本该用 50 行代码搞定的问题，变成了 5000 行的分布式系统，还跑不稳定。
Anthropic 最近发了一篇实践文章 Multi-agent coordination patterns，系统梳理了 5 种多 Agent 协调模式，以及每种模式适合什么场景、会在哪里翻车。这篇文章帮我理清了很多之前模糊的认知，今天分享一下我的理解和延伸思考。
核心观点只有一句：从最简单的模式开始，观察它在哪里挣扎，再演进到更复杂的模式。
本文提纲
- 模式一：Generator-Verifier（生成-验证）
- 模式二：Orchestrator-Subagent（编排者-子 Agent）
- 模式三：Agent Teams（Agent 团队）
- 模式四：Message Bus（消息总线）
- 模式五：Shared State（共享状态）
- 如何选择和演进
模式一：Generator-Verifier——最简单也最实用
这是最简单的多 Agent 模式，也是实际部署最多的一种。
工作原理
MERMAID_BLOCK_0
Generator（生成者）接收任务，产出初始结果。Verifier（验证者）根据明确标准检查结果是否达标。如果没过，验证者把具体的修改建议返回给生成者，循环往复，直到通过或达到最大迭代次数。
适合什么场景
举个实际例子：客服邮件自动回复系统。一个 Agent 根据工单内容生成回复草稿，另一个 Agent 对照知识库检查准确性、评估语气是否符合品牌调性、确认每个问题都被回应了。如果发现某个功能被错误归属到了错误的定价档位，或者某个工单问题没被回复，就打回去修改。
适用条件：
- 输出质量要求高，错误成本大于多跑一轮的成本
- 验证标准可以明确列出（不是"好不好看"这种主观判断）
- 生成和验证是可分离的技能
代码生成（一个写代码，一个写测试并运行）、事实核查、合规审查、基于评分标准的评分——都适合这个模式。
哪里会翻车
最常见的问题：验证者形同虚设。 如果你只告诉验证者"检查输出好不好"，它大概率会走过场，对什么都说好。验证者好不好，完全取决于你给它的评判标准够不够具体。
另一个坑：循环卡死。 如果生成者没法根据反馈有效改进，系统就会在"生成→拒绝→生成→拒绝"之间无限循环。一定要设置最大迭代次数，并且准备兜底策略（比如上报人工，或者返回最佳尝试并附带说明）。
模式二：Orchestrator-Subagent——最通用的起点
层级关系是这个模式的核心：一个 Agent 当"组长"，负责规划、分配任务、综合结果；子 Agent 各自处理具体工作。
工作原理
MERMAID_BLOCK_1
编排者接收到任务后，决定怎么拆分。它可以自己处理一些子任务，同时把其他子任务分派给子 Agent。子 Agent 完成工作后返回结果，编排者把所有结果综合成最终输出。
Claude Code 就是这个模式。主 Agent 负责写代码、编辑文件、运行命令，同时在后台派子 Agent 去搜索大型代码库或调查独立问题。每个子 Agent 有自己的上下文窗口，返回精炼后的发现。这样主 Agent 的上下文保持聚焦，探索任务并行进行。
适合什么场景
自动化代码审查系统：PR 进来后，需要检查安全漏洞、测试覆盖率、代码风格、架构一致性。每个检查都是独立的，需要不同的上下文，产出清晰的结果。编排者把每个检查分派给专门的子 Agent，收集结果，综合成统一审查报告。
适用条件：
- 任务拆分方式明确
- 子任务之间的依赖关系少
- 子任务有明确的边界和输出
哪里会翻车
编排者成为信息瓶颈。 当一个子 Agent 发现了对另一个子 Agent 有用的信息，这条信息必须经过编排者转发。如果安全子 Agent 发现了一个影响架构分析的认证缺陷，编排者得识别出这个依赖关系并正确路由信息。几次转发之后，关键细节往往被丢失或被过度压缩。
顺序执行限制吞吐量。 除非显式并行化，子 Agent 一个接一个运行——这意味着你付出了多 Agent 的 token 成本，却没得到速度上的好处。
模式三：Agent Teams——当子任务需要持续工作
当工作可以拆分为长时间运行的独立子任务时，Orchestrator-Subagent 模式就显得过于束缚了。Agent Teams 的关键区别：Worker 是持久的，不是一次性的。
工作原理
MERMAID_BLOCK_2
协调者生成多个 Worker Agent 作为独立进程。Worker 从共享队列中认领任务，自主完成多步骤工作，完成后发出信号。与 Orchestrator-Subagent 的区别在于：编排者每次为单个有界子任务生成子 Agent，子 Agent 返回结果后就终止。而 Team Worker 在多个任务之间保持活跃，不断积累上下文和领域专长，性能随时间提升。
适合什么场景
大型代码库框架迁移：每个 Worker 独立迁移一个服务，包括自己的依赖、测试套件和部署配置。协调者把每个服务分配给一个 Worker，每个 Worker 自主完成整个迁移流程：依赖更新、代码修改、测试修复、验证。协调者收集完成的迁移结果，运行全系统集成测试。
适用条件：
- 子任务独立，不需要互相通信
- 子任务需要持续的、多步骤的深入工作
- Worker 积累的上下文能提升后续任务的质量
哪里会翻车
独立性是硬性要求。 不像 Orchestrator-Subagent 有编排者居中协调，Team Worker 自主运行，没法方便地共享中间发现。如果一个 Worker 的结果影响另一个 Worker，两边都不知道，产出可能冲突。
完成检测更难。 Worker 自主工作，耗时差异大——一个 2 分钟完成，另一个可能要 20 分钟。协调者必须处理部分完成的情况。
共享资源是地雷。 多个 Worker 操作同一个代码库、数据库或文件系统时，可能同时编辑同一个文件或做出不兼容的修改。需要仔细的任务分区和冲突解决机制。
模式四：Message Bus——为复杂事件流而生
当 Agent 数量增加、交互模式变复杂时，直接协调变得难以管理。Message Bus 引入了一个共享通信层。
工作原理
MERMAID_BLOCK_3
Agent 通过两个原语交互：发布（Publish）和订阅（Subscribe）。Agent 订阅自己关心的主题，Router 把匹配的消息投递过去。新增 Agent 不需要改动现有连接，只要订阅相关主题就行。
适合什么场景
安全运营自动化系统：告警从多个来源到达，分类 Agent 按严重程度和类型分类，把高危网络告警路由到网络调查 Agent，凭据相关告警路由到身份分析 Agent。每个调查 Agent 可能发布信息富集请求，由上下文收集 Agent 处理。发现结果流向响应协调 Agent，决定采取什么行动。
适用条件：
- 工作流由事件驱动，而非预设序列
- Agent 生态系统可能持续增长
- 需要独立开发和部署各个 Agent
哪里会翻车
事件驱动通信让追踪变难。 一个告警触发 5 个 Agent 之间的事件级联，要搞清楚发生了什么，需要完善的日志和关联分析。调试一个事件流比跟踪编排者的顺序决策困难得多。
路由准确性是命门。 如果 Router 错分或丢了一个事件，系统会悄无声息地失败——什么都没处理，但也没崩溃。基于 LLM 的 Router 提供了语义灵活性，但也引入了自己的失败模式。
模式五：Shared State——去中心化的终极形态
前面四种模式都有一个中心化的信息管理者（编排者、协调者、Router）。Shared State 直接去掉中间人，让所有 Agent 通过一个共享存储来协调。
工作原理
MERMAID_BLOCK_4
Agent 自主运行，读写共享的数据库、文件系统或文档。没有中心协调者。Agent 检查存储中的相关信息，据此行动，再把发现写回去。工作通常从一个初始化步骤开始（向存储中放入问题或数据集），到满足终止条件结束（时间限制、收敛阈值、或某个指定 Agent 判断存储中已有充分答案）。
适合什么场景
研究综合系统：多个 Agent 调查一个复杂问题的不同方面——一个探索学术文献，一个分析行业报告，一个审查专利申请，一个监控新闻报道。每个 Agent 的发现都可能影响其他 Agent 的调查方向。学术文献 Agent 发现了一位关键研究员，行业 Agent 立刻可以深入调查这位研究员的公司。
在 Shared State 模式下，发现直接写入存储，行业 Agent 无需等待协调者路由就能看到学术 Agent 的发现。Agent 之间相互构建，共享存储成为不断演进的知识库。
另一个优势：没有单点故障。 任何一个 Agent 停了，其他 Agent 继续读写。在编排者和消息总线系统中，协调者或 Router 挂了，整个系统停摆。
哪里会翻车
重复劳动和矛盾方向。 没有显式协调，两个 Agent 可能独立调查同一条线索，或者采取矛盾的方法。
反应性循环是最棘手的失败模式。 Agent A 写了一条发现，Agent B 读了并写了跟进，Agent A 看到跟进又回复……系统持续消耗 token 却不收敛。重复劳动和并发写入有工程层面的解决方案（锁、版本控制、分区）。反应性循环是行为层面的问题，需要设置一级终止条件：时间预算、收敛阈值（连续 N 轮没有新发现）、或一个专门负责判断"够了"的 Agent。把终止当作事后才考虑的问题，系统要么无限循环，要么在某个 Agent 上下文满了时随意停止。
如何选择和演进
这五种模式不是互斥的——生产系统经常混合使用。一个常见组合：用 Orchestrator-Subagent 管理整体工作流，其中某个需要深度协作的子任务用 Shared State。另一个组合：Message Bus 做事件路由，Agent Team 风格的 Worker 处理每种事件类型。
Anthropic 建议大多数场景从 Orchestrator-Subagent 开始——它以最少的协调开销覆盖了最广泛的问题类型。观察它在哪里挣扎，然后按需演进。
快速决策表
| 场景特征 | 推荐模式 |
|---|---|
| 输出质量关键，有明确评估标准 | Generator-Verifier |
| 任务拆分明确，子任务有界 | Orchestrator-Subagent |
| 并行工作负载，独立长时间子任务 | Agent Teams |
| 事件驱动管道，Agent 生态不断增长 | Message Bus |
| 协作式研究，Agent 需要共享发现 | Shared State |
| 要求无单点故障 | Shared State |
模式间的演进判断
Orchestrator-Subagent vs Agent Teams：看子任务需要维持上下文多久。如果子任务短、聚焦、产出明确（如代码审查的各种检查），选 Orchestrator-Subagent。如果子任务需要持续的、多步骤的深入工作（如逐个迁移服务），选 Agent Teams。
Orchestrator-Subagent vs Message Bus：看工作流的可预测性。如果步骤序列预先可知（PR 审查的固定流水线），选 Orchestrator-Subagent。如果工作流随事件涌现且可能不断变化（安全运营中的各种告警），选 Message Bus。
Agent Teams vs Shared State：看 Agent 之间是否需要彼此的发现。如果工作在独立分区上互不干扰（每个 Worker 迁移一个服务），选 Agent Teams。如果发现需要实时流动（研究调查），选 Shared State。
Message Bus vs Shared State：看信息是作为离散事件流动，还是累积为共享知识库。如果 Agent 对管道中的事件做反应（安全告警的逐级处理），选 Message Bus。如果 Agent 在持续积累的发现之上构建（研究综合），选 Shared State。
作者: TheAIEra
来源: 公众号：AI 人工智能时代
本文首发于 AI 人工智能时代，转载请注明出处。