多智能体协作别先堆人：五种模式，以及什么时候该换架构

前言

很多多智能体项目失败，不是因为智能体不够多，而是因为协作方式选错了。

一个系统里塞进 5 个、10 个、甚至更多智能体，并不自动等于“更智能”。如果任务边界、上下文流动和终止条件没有设计好，多智能体只会把一个问题变成多个问题：更贵、更慢、更难调试。

在上一篇文章中，Anthropic 讨论了一个更前置的问题：什么时候多智能体系统值得投入，什么时候一个单智能体反而更合适。

这篇文章面向已经做出这个判断的团队：既然决定要上多智能体系统，接下来应该选择哪一种协作模式？

很多团队在做选择时，会被“听起来更高级”的架构吸引，而不是从问题本身出发。Anthropic 给出的建议很克制：先从能解决问题的最简单模式开始，观察它在哪里吃力，再逐步演进。

换句话说，多智能体架构不是炫技题，而是分工题。真正要问的不是“要不要更多 agent”，而是：信息应该怎么流动？上下文应该由谁保留？失败应该在哪里被发现？

这篇文章重点拆解五种多智能体协作模式，可以把它们当成一张架构选型地图：

•生成器-验证器：适合质量要求高、评价标准明确的输出任务。

•编排器-子智能体：适合任务拆分清晰、子任务边界明确的工作流。

•智能体团队：适合可以并行推进、相互独立、耗时较长的子任务。

•消息总线：适合事件驱动流水线，以及会不断扩展的智能体生态。

•共享状态：适合协作型工作，多个智能体需要基于彼此发现继续推进。

模式总览插图

模式一：生成器-验证器

生成器-验证器模式

如果只想先改善输出质量，这是最容易落地的一种模式：一个负责产出，一个负责挑错。

这是最简单、也最常见的多智能体模式之一。Anthropic 在上一篇文章中把它称为“验证子智能体模式”，这里使用更宽泛的“生成器-验证器”说法，因为生成器未必一定是编排器。

它如何工作

生成器接收任务，产出初稿，然后把结果交给验证器评估。验证器检查输出是否满足标准：如果通过，就接受结果；如果不通过，就带着具体反馈退回给生成器。

生成器再根据反馈修改，进入下一轮。这个循环会持续到验证器接受结果，或者达到最大迭代次数。

一个典型例子是客服邮件自动回复系统：

•生成器根据产品文档和工单上下文生成回复。

•验证器检查回复是否符合知识库、是否符合品牌语气、是否覆盖了用户提出的每一个问题。

•如果发现问题，验证器不会只说“不好”，而是指出具体缺陷，比如某个功能被错误归到了某个价格档位，或者某个工单问题没有被回答。

适合什么场景

当输出质量非常关键，并且评价标准可以被明确写出来时，这个模式很有用。

适用场景包括：

•代码生成：一个智能体写代码，另一个智能体写测试并运行测试。

•事实核查：生成结果之后，由另一个智能体对事实来源和一致性做检查。

•基于评分表的评估：例如作文评分、客服质量评分、合规检查。

•高代价错误场景：如果错误输出的成本高于多跑一轮生成，就值得引入验证器。

它的问题在哪里

这个模式真正的关键不是“有一个验证器”，而是“验证标准是否足够清晰”。

没有标准的验证器，本质上只是一个更礼貌的复读机。

如果只告诉验证器“看看这个结果好不好”，它很容易变成橡皮图章。很多团队的失败点就在这里：系统看起来有质量控制，实际上没有定义“什么叫合格”。

此外，这个模式默认“生成”和“验证”是可以分开的能力。如果评估一个创意方案和生成一个创意方案一样难，验证器就不一定能稳定发现问题。

还有一个常见风险是循环卡住：生成器无法消化验证器反馈，于是系统在“退回-重做-再退回”之间震荡。实际系统需要设置最大迭代次数，并准备兜底策略，比如转人工、返回带风险提示的最佳版本。

模式二：编排器-子智能体

编排器-子智能体模式

当任务天然可以拆成几块，而且每一块都有明确交付物时，就会进入第二种模式：一个总负责人，多个专门执行者。

这个模式的核心是层级结构。一个智能体像团队负责人一样规划任务、分派任务、整合结果；多个子智能体负责具体工作，并把结果汇报回来。

它如何工作

编排器接收任务之后，先判断怎么完成。它可以自己处理一部分，也可以把某些子任务分发给更专门的子智能体。

子智能体完成任务后返回结果，编排器再把这些结果综合成最终输出。

一个例子是自动化代码审查系统。一个 pull request 到来之后，系统可能要同时检查：

•是否有安全漏洞；

•测试覆盖是否足够；

•代码风格是否符合规范；

•架构设计是否一致。

这些检查彼此不同，需要的上下文也不同。编排器可以把它们交给不同的子智能体，最后统一汇总成一份代码审查意见。

适合什么场景

当任务可以清晰拆分，且子任务之间依赖很少时，这个模式最合适。

它的优势在于：编排器保留对整体目标的统一视角，而子智能体可以专注处理某个明确职责。

它的问题在哪里

编排器很容易变成信息瓶颈。

它掌握全局，也承担了全局的堵点。

如果安全子智能体发现了一个身份认证漏洞，而这个发现会影响架构子智能体的判断，那么信息必须先回到编排器，再由编排器转发。只要这种转发多几轮，细节就很容易在摘要和转述中丢失。

另一个问题是吞吐量。除非系统明确并行化，否则子智能体可能一个接一个执行。这样既付出了多智能体的 token 成本，又没有获得并行带来的速度收益。

当任务本身可以长时间独立并行推进时，编排器-子智能体模式就可能显得过于束缚。

模式三：智能体团队

智能体团队模式

如果子任务不是“一次调用就能结束”，而是需要长时间积累上下文，系统就更像一个持续协作的团队，而不是临时分派任务的流水线。

智能体团队模式中，协调者会启动多个 worker 智能体。它们像团队成员一样，从共享任务队列中领取任务，跨多个步骤独立工作，并在完成后发出信号。

它如何工作

它和“编排器-子智能体”的关键区别在于：worker 是持续存在的。

编排器-子智能体模式里，子智能体通常只负责一个有边界的子任务，完成后就结束。而智能体团队中的 worker 会在多个任务之间持续存活，积累上下文和领域熟悉度。

举个例子：把一个大型代码库从一个框架迁移到另一个框架。

每个服务都有自己的依赖、测试套件和部署配置。协调者可以把不同服务分配给不同 teammate。每个 teammate 独立推进迁移：更新依赖、修改代码、修测试、做验证。最后协调者收集迁移结果，并跑全系统集成测试。

适合什么场景

当子任务彼此独立，并且需要持续、多步骤工作时，这个模式更合适。

它的好处是每个 teammate 会逐步理解自己负责的领域，而不是每次都从零开始。

它的问题在哪里

独立性是这个模式的前提。

智能体团队最怕的不是人手不够，而是大家同时改同一件事，却彼此不知道。

和编排器-子智能体不同，智能体团队里的 teammate 不容易共享中间发现。如果一个 teammate 的改动会影响另一个 teammate，双方可能都不知道，最终产出就会冲突。

完成状态也更难判断。有的 teammate 两分钟完成，有的要二十分钟。协调者必须处理“部分完成”的状态。

共享资源会进一步放大问题。多个 teammate 同时操作同一个代码库、数据库或文件系统时，可能会改到同一个文件，或者做出互不兼容的变更。因此，这个模式需要非常谨慎的任务切分和冲突解决机制。

模式四：消息总线

消息总线模式

当系统不再是固定流程，而是由各种事件不断触发下一步动作时，消息总线会比一个巨大的编排器更自然。

当智能体数量增加、交互关系变复杂时，直接协调会越来越难管理。消息总线引入一个共享通信层，让智能体通过发布和订阅事件来协作。

它如何工作

智能体通过两个基本动作协作：

•发布：把事件发到某个主题。

•订阅：监听自己关心的主题。

路由器负责把匹配的消息送到对应智能体。新的智能体可以订阅相关主题，开始接收任务，而不需要重写已有连接关系。

安全运营自动化系统很适合这个模式：

•多个来源不断产生告警；

•分诊智能体根据严重程度和类型分类；

•高危网络告警进入网络调查智能体；

•凭证相关告警进入身份分析智能体；

•调查智能体可以继续发布信息补充请求；

•上下文收集智能体补齐资料；

•最后结果流向响应协调智能体，由它判断下一步动作。

这个场景适合消息总线，因为事件从一个阶段流向下一个阶段，新的威胁类别可以通过增加新智能体来处理，各个智能体也可以相对独立地开发和部署。

适合什么场景

当工作流不是预先固定的顺序，而是由事件触发和演化出来时，可以考虑消息总线。

如果智能体生态未来很可能增长，消息总线也更容易扩展。

它的问题在哪里

事件驱动的灵活性，会带来追踪困难。

消息总线把系统变得更可扩展，也把问题变得更分散。

当一个告警触发五个智能体之间的一连串事件时，想弄清楚“到底发生了什么”，需要非常严密的日志和关联 ID。相比顺着编排器的决策链排查，消息总线更难调试。

路由准确性也很关键。如果路由器误分类，或者漏掉某个事件，系统可能不会崩溃，却什么也没处理。这种静默失败很危险。

如果路由器本身由 LLM 驱动，虽然能获得语义灵活性，但也会引入新的失败模式。

模式五：共享状态

共享状态模式

如果多个智能体真正需要互相启发，而不是只把最终结果交上来，那么“共享状态”会比“层层转发”更接近协作本身。

前面几种模式中，编排器、团队负责人、消息路由器都在集中管理信息流。共享状态模式则把中介拿掉，让所有智能体直接读写一个持久化存储。

它如何工作

智能体自主运行，直接从共享数据库、文件系统或文档中读取信息，并把新发现写回去。

这里没有中心协调者。智能体检查共享存储中是否有相关信息，基于已有信息行动，再把结果写回共享存储。

系统通常由一个初始化步骤开始，比如把问题或数据集写入共享存储；结束条件则可能是时间限制、收敛阈值，或者由某个指定智能体判断“答案已经足够”。

一个例子是研究综合系统。多个智能体分别调查一个复杂问题的不同方面：

•一个看学术文献；

•一个分析行业报告；

•一个检查专利文件；

•一个监控新闻报道。

每个智能体的发现都可能影响其他智能体的调查方向。比如学术文献智能体发现了某位关键研究者，行业分析智能体就可以立刻去研究这位研究者所在公司的情况。

在共享状态模式中，这类发现会直接进入共享存储。其他智能体不必等协调者转发，就能马上看到并接着推进。共享存储逐渐变成一个不断演化的知识库。

共享状态还有一个重要优势：它消除了协调者这个单点故障。某个智能体停掉，其他智能体仍然可以继续读写。

适合什么场景

当多个智能体需要不断基于彼此发现推进工作时，共享状态最自然。

它尤其适合研究、知识综合、复杂调查、长期协作等任务。

它的问题在哪里

没有显式协调之后，智能体可能会重复劳动，也可能追求相互矛盾的方向。

共享状态的问题不在于大家看不到彼此，而在于大家都看到了彼此，却没有人负责让系统停下来。

两个智能体可能同时调查同一条线索。更复杂的问题是反应式循环：A 写入一个发现，B 读到后写入后续判断，A 又读到 B 的判断并继续回应，系统不断消耗 token，却没有真正收敛。

重复工作、并发写入等问题可以用工程手段缓解，比如锁、版本控制、任务分区。但反应式循环属于行为问题，需要把终止条件当成一等公民来设计：

•时间预算；

•收敛阈值，例如连续 N 轮没有新发现；

•指定一个智能体专门判断共享存储中的答案是否已经足够。

如果把终止条件当成事后补丁，系统很容易无限循环，或者在某个智能体上下文满了之后随意停止。

如何在这些模式之间选择和演进

编排器-子智能体 vs 智能体团队

选型时，最有用的不是记住五个名字，而是问清楚几个结构性问题。

Anthropic 强调，正确模式取决于系统中的几个结构性问题。

上一篇文章提出过一个原则：按“每个智能体需要什么上下文”来拆分，而不是按“每个智能体做什么类型的工作”来拆分。这个原则在选择协作模式时同样适用。

这些模式的差别，本质上在于它们如何管理上下文边界和信息流。

编排器-子智能体 vs 智能体团队

两者都有协调者负责分派任务。关键问题是：worker 需要维持上下文多久？

•选择编排器-子智能体：当子任务短、聚焦、输出明确时。例如代码审查系统，每个检查可以在一次有边界的调用中完成，并返回报告。

•选择智能体团队：当子任务需要持续、多步骤推进时。例如代码库迁移中，每个 teammate 会逐步熟悉自己负责的服务、依赖图、测试模式和部署配置。这种积累不是一次性派发能替代的。

如果子智能体需要跨多次调用保留状态，智能体团队通常更合适。

编排器-子智能体 vs 消息总线

编排器-子智能体 vs 消息总线

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

•选择编排器-子智能体：当步骤顺序提前就知道。例如代码审查的流程相对固定：收到 PR，运行检查，综合结果。

•选择消息总线：当流程由事件驱动，并且会根据发现不断变化。例如安全运营系统无法预知会收到什么告警，也无法预知每个告警需要怎样的调查路径。

当编排器里的条件分支越来越多，只为适配不断扩张的场景时，消息总线会把这种路由逻辑显式化，也更便于扩展。

智能体团队 vs 共享状态

智能体团队 vs 共享状态

两者都让智能体自主工作。关键问题是：智能体之间是否需要彼此的中间发现？

•选择智能体团队：当不同智能体处理互不干扰的分区。例如代码库迁移中，每个 teammate 负责自己的服务，最后由协调者合并结果。

•选择共享状态：当工作本身是协作式的，并且一个智能体的发现应该实时影响另一个智能体。例如研究综合系统中，学术智能体发现关键研究者后，行业智能体应当马上看到并调整调查方向。

一旦 teammate 之间不只是交付最终结果，而是需要在过程中互相沟通，共享状态通常更自然。

消息总线 vs 共享状态

消息总线 vs 共享状态

两者都能支持复杂的多智能体协作。关键问题是：工作是以离散事件流动，还是逐渐积累成共享知识库？

•选择消息总线：当智能体在流水线中响应事件。比如安全运营系统里，告警逐阶段处理，一个事件触发下一个动作。

•选择共享状态：当智能体需要长期基于积累的发现推进。比如研究综合系统中，智能体会反复回到共享存储，看别人发现了什么，再调整自己的调查。

消息总线仍然有路由器，也就是仍然存在一个决定事件去向的中心组件。共享状态则更去中心化。

如果消除单点故障是优先目标，共享状态更彻底。

如果一个消息总线系统里的智能体开始频繁发布事件，只是为了分享发现，而不是触发动作，那么共享状态可能是更好的架构。

从哪里开始

如果只能带走一句话：不要一开始就追求最复杂的多智能体协作。

生产系统经常会混合使用多种模式。

常见组合包括：

•用编排器-子智能体处理整体工作流，再在某个高度协作的子任务中使用共享状态。

•用消息总线路由事件，再让智能体团队式 worker 处理每一种事件类型。

这些模式不是互斥选项，而是构建块。

下面是一个简化选择表：

对大多数用例，Anthropic 建议从“编排器-子智能体”开始。它能覆盖最广的问题类型，同时协调开销最低。

真正重要的是：先让系统跑起来，观察它在哪里挣扎，再根据具体问题演进到其他模式。

架构不是一次选定的标签，而是一组随着问题成熟而变化的协作方式。

多智能体系统的核心，不是“让更多智能体加入”，而是让每个智能体知道：该看什么上下文、该把发现交给谁、什么时候应该停下来。

致谢

原文由 Cara Phillips 撰写，Eugene Yan、Jiri De Jonghe、Samuel Weller 和 Erik S. 参与贡献。

声明：本文由山行整理自：https://claude.com/blog/multi-agent-coordination-patterns[1]，如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～

参考链接

[1] https://claude.com/blog/multi-agent-coordination-patterns: https://claude.com/blog/multi-agent-coordination-patterns