多 Agent 协调模式：五种方法以及何时使用它们

五种多 Agent 协调模式、它们的取舍，以及何时从一种模式演进到另一种模式。

在上一篇文章中，我们探讨了什么时候多 Agent 系统能带来价值，什么时候单 Agent 才是更好的选择。本文面向那些已经做出这个判断、现在需要决定哪种协调模式适合自己问题的团队。

我们见过一些团队会根据“听起来是否高级”来选择模式，而不是根据当前问题是否适合来选择。我们建议从可能可行的最简单模式开始，观察它在哪里吃力，然后再逐步演进。本文会分析五种模式的工作机制和局限：

• Generator-verifier，适用于有明确评估标准、对输出质量要求很高的场景

• Orchestrator-子Agent，适用于任务拆分清晰、子任务边界明确的场景

• Agent 团队，适用于可并行、相互独立、运行时间较长的子任务

• Message bus，适用于事件驱动流水线，以及 Agent 生态逐渐扩大的场景

• Shared-state，适用于协作型工作，多个 Agent 需要基于彼此发现继续推进

模式 1：Generator-verifier

这是最简单的多 Agent 模式之一，也是部署最广泛的模式之一。我们在上一篇文章中把它介绍为 verification 子Agent 模式；这里使用更宽泛的 generator-verifier 说法，因为 generator 不一定必须是 orchestrator。

它如何工作

generator 接收任务并产出初始结果，然后把结果交给 verifier 进行评估。verifier 检查输出是否满足所需标准，并决定接受它作为完成结果，或带着反馈拒绝它。如果被拒绝，反馈会传回 generator，generator 据此生成修订后的尝试。这个循环会持续进行，直到 verifier 接受输出，或达到最大迭代次数。

适用场景

假设有一个支持系统，用来为客户工单生成邮件回复。generator 会结合产品文档和工单上下文生成初始回复。verifier 会对照知识库检查准确性，根据品牌指南评估语气，并确认回复覆盖了客户提出的每个问题。未通过的检查会带着反馈返回给 generator，反馈会指出具体问题，比如某个功能被错误归到了不对应的价格层级，或工单中的某个问题没有回答。

当输出质量很关键，并且评估标准可以明确表达时，使用这种模式。它适用于代码生成（一个 Agent 写代码，另一个 Agent 编写并运行测试）、事实核查、基于评分标准的评审、合规校验，以及任何“错误输出的代价高于多跑一轮生成”的领域。

它的困难之处

verifier 的效果取决于它的标准。如果只告诉 verifier 检查输出“好不好”，却没有进一步标准，它就会草率放行 generator 的输出。团队最常见的失败方式，是实现了这个循环，却没有定义“验证”到底意味着什么，于是制造出有质量控制的假象，但没有实质。（我们在上一篇文章中讨论过这种早期胜利问题。）

这种模式还假设生成和验证是可以分离的技能。如果评估一个创意方案和生成一个创意方案一样困难，verifier 就可能无法可靠地发现问题。

最后，迭代循环可能卡住。如果 generator 无法处理 verifier 的反馈，系统就会来回震荡，无法收敛。设置最大迭代次数，并配合兜底策略（升级给人工处理，或返回带有说明的最佳尝试），可以防止它变成无限循环。

模式 2：Orchestrator-子Agent

层级关系定义了这种模式。一个 Agent 充当团队负责人，负责规划工作、分派任务并综合结果。子Agent 负责具体职责并回报结果。

lead Agent 接收任务并决定如何处理。它可能自己完成部分子任务，同时把其他子任务派发给 子Agent。子Agent 完成工作后返回结果，orchestrator 再把这些结果综合成最终输出。

Claude Code 使用的就是这种模式。main Agent 会自己写代码、编辑文件并运行命令；当它需要搜索大型代码库或调查独立问题时，会在后台派发 子Agent，这样主任务可以继续推进，同时结果陆续返回。每个 子Agent 都在自己的上下文窗口中运行，并返回提炼后的发现。这样可以让 orchestrator 的上下文聚焦在主要任务上，同时并行进行探索。

以自动化代码审查系统为例。当一个 pull request 到来时，系统需要检查安全漏洞、验证测试覆盖率、评估代码风格，并判断架构一致性。每项检查都不同，需要不同上下文，并会产生明确输出。orchestrator 会把每项检查派发给专门的 子Agent，收集结果，然后综合成一份统一的 审查。

当任务拆分清晰、子任务之间依赖很少时，使用这种模式。orchestrator 维持对整体目标的连贯理解，而 子Agent 专注于具体职责。

orchestrator 会变成信息瓶颈。当某个 子Agent 发现了与另一个 子Agent 工作相关的信息，这些信息必须先回到 orchestrator，再由它转发。如果 security 子Agent 发现了一个会影响 architecture 子Agent 分析的认证缺陷，orchestrator 必须识别这个依赖关系，并正确路由信息。经过几次这样的转交后，关键细节往往会丢失，或在摘要中被省略。

顺序执行也会限制吞吐量。除非明确并行化，否则 子Agent 会一个接一个运行，这意味着系统承担了多 Agent 的 token 成本，却没有获得速度收益。

模式 3：Agent 团队

当工作可以拆成多个并行子任务，并且这些子任务可以长期独立推进时，orchestrator-子Agent 可能会变得不必要地受限。

coordinator 会启动多个 worker Agent 作为独立进程。队友从共享队列中领取任务，跨多个步骤自主工作，并在完成时发出信号。

它与 orchestrator-子Agent 的区别在于 worker 的持久性。orchestrator 会为一个有边界的子任务启动一个 子Agent，子Agent 返回结果后就结束。teammate 会在多个任务之间持续存活，积累上下文和领域专长，从而随着时间提升表现。coordinator 分配工作并收集结果，但不会在每个任务之间重置 worker。

假设要把一个大型代码库从一个框架迁移到另一个框架。一个 teammate 可以独立迁移每个服务，处理自己的依赖、测试套件和部署配置。coordinator 把每个服务分配给一个 teammate，每个 teammate 自主完成迁移流程：更新依赖、修改代码、修复测试、验证结果。coordinator 收集完成的迁移，并在整个系统上运行集成测试。

当子任务相互独立，并且能从持续的多步骤工作中受益时，使用这种模式。每个 teammate 会积累自己领域的上下文，而不是每次派发时都从零开始。

独立性是关键要求。不同于 orchestrator-子Agent 可以由 orchestrator 在 子Agent 之间协调并转发信息，teammate 是自主运行的，很难共享中间发现。如果一个 teammate 的工作影响了另一个 teammate，双方可能都不知道，它们的输出也可能发生冲突。

完成检测也更困难。由于 teammate 会自主工作，耗时也不固定，coordinator 必须处理部分完成的情况，比如一个 teammate 两分钟完成，另一个需要二十分钟。

共享资源会让这两个问题更加复杂。当多个 teammate 操作同一个代码库、数据库或文件系统时，两个 teammate 可能编辑同一个文件，或做出不兼容的修改。这种模式需要仔细划分任务，并配备冲突解决机制。

模式 4：Message bus

随着 Agent 数量增加、交互模式变复杂，直接协调会变得难以管理。message bus 引入了一个共享通信层，让 Agent 可以发布和订阅事件。

Agent 通过两个基本操作交互：publish 和 subscribe。Agent 订阅自己关心的主题，router 负责投递匹配的消息。具备新能力的新 Agent 可以开始接收相关工作，而不需要重新连接已有关系。

安全运营自动化系统很好地展示了这种模式的优势。告警来自多个来源，triage Agent 会按严重程度和类型对每个告警分类，把高严重级别的网络告警路由给 network investigation Agent，把凭证相关告警路由给 identity analysis Agent。每个 investigation Agent 可能会发布补充信息请求，由 context-gathering Agent 来完成。发现结果会流向 response coordination Agent，由它决定合适的处理动作。

这种流水线适合 message bus，因为事件会从一个阶段流向下一个阶段，团队可以随着威胁类别演变添加新的 Agent 类型，也可以独立开发和部署 Agent。

当工作流由事件自然形成，而不是由预先设定的顺序决定，并且 Agent 生态很可能继续增长时，使用这种模式。

事件驱动通信的灵活性会让追踪更困难。当一个告警触发五个 Agent 之间的一连串事件时，要理解发生了什么，就需要仔细的日志记录和关联分析。相比跟踪 orchestrator 的顺序决策，调试会更困难。

路由准确性也很关键。如果 router 错分或丢弃了某个事件，系统会静默失败：什么都没处理，但也不会崩溃。基于 LLM 的 router 提供了语义灵活性，但也引入了自身的失败模式。

模式 5：Shared state

前面几种模式中的 orchestrator、team lead 和 message router，都会集中管理信息流。shared state 通过让 Agent 直接读写同一个持久化存储，移除了中间协调者。

Agent 自主运行，从共享数据库、文件系统或文档中读取和写入信息。没有中心 coordinator。Agent 检查存储中是否有相关信息，基于发现采取行动，并把自己的发现写回去。工作通常从一个初始化步骤开始，由它向存储中写入问题或数据集；当满足终止条件时结束：达到时间限制、达到收敛阈值，或由指定 Agent 判断存储中已经包含足够答案。

以研究综合系统为例，多个 Agent 分别调查一个复杂问题的不同方面。一个 Agent 探索学术文献，另一个分析行业报告，第三个查看专利申请，第四个监控新闻报道。每个 Agent 的发现都可能影响其他 Agent 的调查。学术文献 Agent 可能发现一位关键研究者，而行业 Agent 应该进一步研究这位研究者所在的公司。

使用 shared state 时，发现会直接进入存储。行业 Agent 可以立即看到学术 Agent 的发现，而不需要等待 coordinator 转发信息。Agent 会基于彼此的工作继续推进，共享存储也会变成不断演进的知识库。

shared state 还消除了 coordinator 这个单点故障。如果任何一个 Agent 停止，其他 Agent 仍然可以继续读写。在 orchestrator 和 message-bus 系统中，coordinator 或 router 失败会让一切停下来。

如果没有显式协调，Agent 可能会重复工作，或采取相互矛盾的方法。两个 Agent 可能会独立调查同一条线索。Agent 之间的交互会产生系统行为，而不是由自上而下的设计完全决定，这会让结果更难预测。

更难处理的失败模式是响应式循环。例如，Agent A 写入一个发现，Agent B 读取后写入后续内容，Agent A 看到这个后续内容又继续回应。系统会不断消耗 token，却没有真正收敛。重复工作和并发写入都有已知的工程解决办法（锁、版本控制、分区）。响应式循环则是行为问题，需要一等公民级别的终止条件：时间预算、收敛阈值（连续 N 轮没有新发现），或指定一个 Agent，专门判断存储中是否已经包含足够答案。把终止条件当作事后补丁的系统，往往会无限循环，或在某个 Agent 的上下文填满时随意停止。

如何选择模式以及在模式之间演进

正确模式取决于系统中的几个结构性问题。在上一篇文章中，我们主张以上下文为中心进行拆分，也就是按每个 Agent 需要什么上下文来划分工作，而不是按它做什么类型的工作来划分。这个原则在这里同样适用。这些模式的区别，在于它们如何管理上下文边界和信息流。

Orchestrator-子Agent 与 Agent 团队

两者都涉及一个 coordinator 把工作分派给其他 Agent。关键问题是 worker 需要保留上下文多久。

• 当子任务短小、聚焦，并且会产生明确输出时，选择 orchestrator-子Agent。代码审查系统很适合这里，因为每项检查会运行自己的分析、生成报告，并在一次有边界的调用中返回。子Agent 不需要跨多个周期保留上下文。

• 当子任务需要持续的、多步骤工作时，选择 Agent 团队。代码库迁移就适合这种模式，因为每个队友都会真正熟悉自己负责的服务：依赖关系图、测试模式、部署配置。这些积累下来的上下文会提升表现，而一次性的 Dispatch 无法复现这种效果。

当 子Agent 需要在多次调用之间保留状态时，Agent 团队 是更合适的选择。

Orchestrator-子Agent 与 message bus

两者都能处理多步骤工作流。关键问题在于：工作流结构是否可预测。

• 当步骤顺序事先已知时，选择 orchestrator-子Agent。代码审查系统遵循固定流程：接收一个 PR、运行检查、综合结果。

• 当工作流由事件推动，并且可能根据发现的内容而变化时，选择 message bus。安全运营系统无法预先知道会收到哪些告警，也无法预知这些告警需要走什么调查路径。新的告警类型可能出现，并且需要新的处理方式。message bus 通过把事件路由给有能力处理的 Agent 来适应这种变化，而不是遵循预先固定的步骤。

当 orchestrator 中的条件逻辑不断增加，用来处理越来越多不同情况时，message bus 会让这种路由关系变得更明确，也更容易扩展。

Agent 团队 与 shared state

两者都涉及 Agent 自主工作。关键问题在于：Agent 是否需要彼此的发现。

• 当 Agent 处理彼此不交互的独立分区时，选择 Agent 团队。代码库迁移就适合这种模式，因为每个队友负责自己的服务，最后由协调者汇总结果。

• 当 Agent 的工作具有协作性，并且发现应该在它们之间实时流动时，选择 shared state。研究综合系统更适合这种模式，因为 academic Agent 发现了一位关键研究者后，这个信息会立刻对 industry Agent 的调查产生价值。

一旦队友之间需要相互沟通，而不仅仅是共享最终结果，shared state 会让这种协作更自然。

Message bus 与 shared state

两者都支持复杂的多 Agent 协调。关键问题在于：工作是以离散事件的形式流动，还是逐步积累成一个共享知识库。

• 当 Agent 在流水线中响应事件时，选择 message bus。安全运营系统按阶段处理告警，每个事件都会在完成前触发下一步。这个模式很适合把事件路由给有能力处理的 Agent。

• 当 Agent 需要基于长期积累的发现继续推进时，选择 shared state。研究综合系统会持续收集知识。Agent 会反复回到存储中，查看其他人发现了什么，并据此调整自己的调查方向。

message bus 仍然有一个 router，这意味着有一个中心组件决定事件去哪里。shared state 是去中心化的。如果优先目标是消除单点故障，shared state 在这方面更彻底。

如果 message bus 系统中的 Agent 发布事件是为了共享发现，而不是触发动作，那么 shared state 更合适。

入门

生产系统通常会组合多种模式。一种常见的混合方式是：整体工作流使用 orchestrator-子Agent，而协作较多的子任务使用 shared state。另一种方式是：使用 message bus 做事件路由，同时用 Agent 团队 风格的 workers 处理每种事件类型。这些模式是构建模块，并不是互斥选项。

下表总结了每种模式适用的场景。

对于大多数使用场景，我们建议从 orchestrator-子Agent 开始。它能用最低的协调开销处理最广泛的问题。观察它在哪些地方表现吃力，然后在具体需求变清楚后，再逐步演进到其他模式。

在接下来的文章中，我们会结合生产实现和案例研究，深入分析每一种模式。关于什么时候值得投入多 Agent 系统，可以参见 Building multi-Agent systems: when and how to use them。

致谢

作者 Cara Phillips，Eugene Yan、Jiri De Jonghe、Samuel Weller 和 Erik S. 亦有贡献。