“多智能体协作指南：五种主流模式怎么选、怎么用？”

在之前的一篇文章中，我们探讨了多智能体 (Multi-agent) 系统何时能发挥最大价值，以及什么时候只用单个智能体 (Agent) 其实更好。这篇文章则是为那些已经决定采用“多智能体”路线的团队准备的：面对手头的问题，到底该选哪种协作模式？

我们常常看到，有些团队在挑选模式时，只顾着选听起来“高大上”的，却忽略了到底适不适合手头的问题。我们的建议是：从最简单的、能跑通的模式开始，观察它在哪里会遇到瓶颈，然后再逐步升级。 今天这篇文章，我们就来拆解五种常见模式的运作原理和局限性：

• 生成 - 验证者 (Generator-verifier)：适用于看重输出质量、且有明确评估标准的场景。
• 调度 - 子智能体 (Orchestrator-subagent)：适用于任务拆解清晰、子任务边界分明的场景。
• 智能体团队 (Agent teams)：适用于可以并行处理、互不干扰且需要长时间运行的子任务。
• 消息总线 (Message bus)：适用于事件驱动的流水线作业，以及系统还在不断扩展新智能体的场景。
• 共享状态 (Shared-state)：适用于需要高度协作、智能体之间需要互相参考别人发现的场景。

模式一：生成 - 验证者 (Generator-verifier)

这是最简单的多智能体模式，也是目前落地应用最广泛的模式之一。在我们之前的文章中，曾将其称为“验证子智能体模式”，这里我们使用更宽泛的“生成 - 验证者”来称呼它，因为这里的“生成者”不一定非得是个指挥全局的调度者。

它是如何运作的

生成者 (Generator) 接到一个任务后，会先给出一版初步结果，然后把它传给验证者 (Verifier) 去评估。验证者会检查这个结果是否符合规定的标准。如果符合，就盖章通过；如果不符合，验证者会把具体的修改意见（反馈）打回去。生成者拿着这些反馈再重新修改一版。这个“修改 - 审核”的循环会一直进行，直到验证者满意，或者达到了系统设定的最大修改次数限制。

它在何时最好用

想象一个用来回复客户工单的自动邮件系统。生成者利用产品文档和工单详情写出一封初稿。验证者则充当“质检员”：核对知识库看事实准不准、检查语气符不符合品牌要求、确认客户提到的每个问题是不是都回答了。如果检查没通过，验证者会把具体问题甩回给生成者，比如指出“把某个功能错误地归到了低配版里”或者“漏答了某个问题”。

当输出质量至关重要，而且你能把“什么是好结果”用明确的标准写出来时，用这个模式准没错。它非常适合代码生成（一个智能体写代码，另一个写测试并运行）、事实核查、按固定评分表打分、合规性审查，以及任何“一次错误的代价远大于多跑一圈修改流程”的领域。

它的局限性在哪

这个系统的下限，完全取决于验证者的审核标准有多细。（注：如果你只告诉验证者“帮我看看这东西好不好”，却不给它具体的条条框框，它往往就会变成一个闭着眼睛盖“合格”章的橡皮图章。） 团队在应用这个模式时最常犯的错误，就是建好了循环机制，却没定义清楚“验证”到底意味着什么，这只会营造出一种“我们在做质量控制”的虚假繁荣。

另外，这种模式假设“生成”和“验证”是两种可以拆开的技能。但如果你要评估的是一个绝妙的创意，评估它的难度可能和想出它一样高，这时候验证者往往就不太靠谱了。

最后，这种循环很容易陷入“死胡同”。如果生成者就是无法解决验证者提出的问题，系统就会在两者之间来回踢皮球，永远无法收敛。因此，必须设置一个最大循环次数限制，并准备好后备方案（比如转交人工，或者带着提示说明返回当前最好的一版），防止它变成死循环。

模式二：调度 - 子智能体 (Orchestrator-subagent)

这个模式的核心在于“层级制”。有一个像“团队主管”一样的核心智能体负责规划工作、分发任务，并最终汇总结果；而各个子智能体 (Subagents) 则负责处理具体的分摊工作，做完后向上级汇报。

它是如何运作的

主导的调度者 (Orchestrator) 收到任务后，会先思考该怎么动手。它可以自己解决一部分，把剩下的指派给不同的子智能体。等小弟们把活干完、交上结果后，调度者再把这些碎片拼成一份完整的最终答案。

Claude Code 用的就是这种模式。主智能体自己负责写代码、改文件、跑命令，但当它需要在庞大的代码库里大范围搜索，或者需要调查一些独立问题时，它就会在后台派发给子智能体。这样主线工作不会停，搜索结果也会源源不断地送回来。每个子智能体都在自己独立的上下文窗口 (Context window) 里工作，只返回精炼后的调查结果。（注：这就好比老板的脑子（上下文）只需专注于大方向，而查资料等繁杂信息都在员工的大脑里消化，从而保证老板的思路不被琐事塞满。）

它在何时最好用

想想一个自动化的代码审查 (Code review) 系统。当有人提交了新代码，系统需要检查安全漏洞、验证测试覆盖率、评估代码风格、并检查架构一致性。这几个检查方向互不干涉，需要的背景知识也不同，并且都能产出清晰的报告。此时，调度者就可以把任务分发给几个专门的子智能体，等它们查完，再把报告融合成一份全面的审查意见。

当任务拆解非常明确，且子任务之间互相没啥依赖时，这个模式非常得心应手。调度者能时刻保持对大目标的掌控，而子智能体则心无旁骛地干好自己的细分工作。

它的局限性在哪

调度者很容易变成信息的“瓶颈”。一旦某个子智能体发现了可能影响另一个子智能体工作的信息，这个情报必须先上报给调度者，再由调度者下发。比如，查安全的智能体发现了一个认证漏洞，这个漏洞恰好会影响查架构的智能体的分析。如果信息在上下级之间倒手太多次，关键细节很容易就在被一次次“总结汇报”的过程中弄丢了。

另外，如果不做专门的并行处理，子智能体会按顺序一个个干活。这意味着你要花着多智能体处理数据（Token）的钱，却享受不到“人多干活快”的速度优势。

模式三：智能体团队 (Agent teams)

当一份大工作可以被拆成多个并行的子任务，而且这些任务需要花很长时间独立完成时，“组长派活”的层级制就会显得太死板了。

它是如何运作的

一个协调者 (Coordinator) 会创建出多个作为独立进程运行的团队成员 (Teammates)。这些成员会从一个共享的任务队列里自己“抢单”，接单后自主完成多步操作，干完再举手示意。

它和“调度 - 子智能体”最大的区别在于成员的持久性。调度者通常是为了一件小事临时叫出一个子智能体，干完就解散。但在团队模式里，成员们是长期存在的，它们在接手一个个任务的过程中，会不断积累领域知识和上下文，越干越熟练。协调者只管派活和收作业，并不会在每次任务结束后把它们的记忆清空。

它在何时最好用

假设你要把一个庞大的代码库从一个框架迁移到另一个框架。每个团队成员都可以独立负责迁移其中一个服务模块，自己处理依赖项、改代码、修测试 bug、做验证。协调者把一个个模块分给成员，成员们自主完成这一整套迁移流程。最后协调者把所有迁移好的模块攒在一起，跑一遍系统级的集成测试。

当子任务相互独立，且需要跨越多步、长时间处理时，用这个模式最爽。因为每个成员都在不断积累自己那个小领域的经验，而不是每次接活都像个失忆的新手。

它的局限性在哪

“独立”是这个模式的生命线，也是软肋。不像调度模式里有个组长帮忙传话，团队成员们都是闷头干活的，彼此之间很难共享中间进度。如果 A 的工作会影响到 B，他们俩却毫不知情，最后交上来的结果可能就打架了。

进度管理也是个让人头疼的问题。因为大家干活的时间长短不一，有的两分钟搞定，有的要弄二十分钟，协调者必须得有耐心处理这种“参差不齐”的部分完成状态。

如果大家还要抢夺公共资源，问题就更大了。当多个成员同时在改同一个代码库、数据库或文件时，很容易发生两个人改同一个文件或者做出互相冲突的修改。这就要求我们在任务分配时划好“楚河汉界”，并准备好冲突解决机制。

模式四：消息总线 (Message bus)

随着智能体数量增加，大家互动的方式越来越复杂，直接让他们面对面交流会变成一场灾难。这时候，消息总线 (Message bus) 就登场了：它提供了一个共享的通讯大厅，让智能体们通过“发布”和“订阅”来协调工作。

它是如何运作的

智能体只靠两个基本动作交流：发布 (Publish) 和订阅 (Subscribe)。智能体会订阅自己关心的“话题”，一个路由器 (Router) 会把相关的消息精准推给它们。（注：这就好比在一个大型公司群里，有人在群里发需求，相关部门的人看到了自动领走，你根本不需要知道具体是谁接了单。） 如果未来有了新功能的智能体加入，它们只要订阅相应的话题就能直接上岗，完全不需要改动现有的网络线路。

它在何时最好用

自动化安全运营系统是这个模式的完美舞台。各种渠道的警报像雪片一样飞来，一个“分诊智能体”负责评估严重程度和类型，把高危的网络警报推给“网络调查智能体”，把账号相关警报推给“身份分析智能体”。调查智能体在干活时，可能还会发布一条“需要更多背景”的需求，专门负责收集情报的智能体看到后就会去帮忙。最后，所有的发现都会流向“响应协调智能体”，由它来拍板怎么处理。

这种流水线简直就是为消息总线量身定制的：事件从上一个环节顺畅地流向下个环节；随着新型威胁出现，团队可以随时往里塞新的安保智能体；各个智能体的开发和部署也可以互不干扰。

当系统是一个由事件驱动的流水线（工作流是由突发事件决定的，而不是定死的顺序），而且你的智能体团队未来很可能会继续扩编时，选它。

它的局限性在哪

这种事件驱动的通讯过于灵活，导致排查问题非常困难。当一个警报像多米诺骨牌一样触发了五个智能体的连锁反应时，想搞清楚中间到底发生了什么，你必须查阅非常仔细的日志记录并进行关联对比。这可比跟着“调度者”一步步按顺序查 bug 痛苦多了。

路由器的分发准确性也至关重要。如果路由器把消息分错了类，或者干脆漏发了，系统就会陷入“静默崩溃”——它不报错，没死机，但就是什么也不干。基于大语言模型 (LLM) 的路由器虽然能在理解语义上更灵活，但也带来了 LLM 特有的失灵风险（比如理解偏差或幻觉）。

模式五：共享状态 (Shared state)

在前几种模式里，无论是调度者、协调者还是路由器，本质上都在充当信息流的“中间商”。而共享状态 (Shared state) 模式则彻底干掉了中间商，它让所有智能体共同面对一个持久化的存储区（比如数据库、文件系统或文档），大家可以直接从中读取信息、写入结果。

它是如何运作的

在这个模式下，没有所谓的“中心指挥官”。智能体们像在一个公共的大黑板前工作：他们看着黑板上有什么线索，拿走自己能处理的去干活，有了新发现再写回黑板上。通常，启动流程就是在黑板上写下一个大问题或放下一堆初始数据；当满足某个结束条件时，工作就停止——比如时间到了、大家很久没新发现了（收敛阈值），或者某个被专门指派的智能体站出来说“黑板上的答案已经足够好了”。

它在何时最好用

想象一个负责跨领域综合研究的系统。为了调查一个复杂问题，有的智能体负责翻学术论文，有的看行业报告，有的扒专利文件，还有的盯着新闻动态。每个人查到的东西都可能成为别人的关键线索。比如，看论文的智能体偶然发现了一位核心研究员，看行业报告的智能体立马就可以去深挖这家研究员背后的公司。

在共享状态下，所有的发现都直接上黑板。看行业的智能体立马就能看到看论文智能体的新发现，根本不用等协调者来回传话。大家互相踩着对方的肩膀往上爬，这块共享黑板也就渐渐变成了一个不断进化演进的知识库。

这种模式还有一个好处：消除了单点故障。即便某个智能体宕机了，其他人依然能对着黑板继续读写。但在调度模式或消息总线模式里，一旦指挥官或路由器罢工，整个系统就全瘫痪了。

它的局限性在哪

失去了统一指挥，智能体很容易会重复造轮子，或者南辕北辙。比如两个智能体可能不约而同地去调查了同一条线索。系统的最终行为是大家碰撞出来的，而不是从上往下设计好的，这也让结果变得难以预测。

最致命的故障模式是陷入 “反应式死循环” (Reactive loops)。比如，智能体 A 写下了一个发现，智能体 B 看到后写了一句补充，A 看到补充后又回了一句…… 整个系统就像两个机器人在无限套娃聊天，疯狂燃烧昂贵的算力 (Token) 却无法得出结论。针对重复工作和并发写入，工程师们有成熟的解决办法（比如加锁、版本控制、分区）；但这这种“无限套娃”是一个行为模式问题，你必须在系统设计之初就设定好“一票否决”的终止条件：比如只给固定的时间预算，或者一旦连续几轮都没有新发现就强制停止，或者指派一个“裁判”智能体随时判定答案是否已经圆满。（注：如果忽略了停止机制的设计，系统要么会无限循环到破产，要么会因为某个智能体的大脑（上下文窗口）被塞满而死机。）

如何在不同模式间选择与进化

选哪种模式，取决于你对系统的几个核心结构问题的判断。在我们之前的文章中，我们提倡围绕“上下文”来拆解工作（Context-centric decomposition），即按照每个智能体“需要知道哪些背景信息”来分工，而不是按“它干什么类型的活”来分工。这个原则在这里同样适用。这五种模式最大的区别，就在于它们如何划分上下文的边界，以及如何管理信息的流动。

调度 - 子智能体 vs. 智能体团队

两者都有一个“分配工作”的协调者。怎么选？问自己：干活的智能体需要长时间保留记忆（上下文）吗？

• 选调度 - 子智能体：如果子任务短平快，目标集中，且输出明确。代码审查系统就适用，因为每次检查都是单次的：跑分析、出报告，直接交差。子智能体不需要在多次任务间保留记忆。
• 选智能体团队：如果子任务需要跨越多步、长时间处理才能出成效。代码库迁移适用这个，因为成员们需要长期对付同一个服务模块，慢慢摸透它的依赖关系、测试规律和部署配置。这种积累下来的背景知识，是“用完即走”的调度模式给不了的。

当子智能体需要在多次被唤醒之间记住以前的状态时，智能体团队是更好的选择。

调度 - 子智能体 vs. 消息总线

两者都能处理多步工作流。怎么选？问自己：你的工作流程是可以提前预测的吗？

• 选调度 - 子智能体：如果步骤早就定好了。就像代码审查系统，永远是那三板斧：接收提交请求、跑检查、汇总结果。
• 选消息总线：如果工作流是由突发事件触发的，而且随时可能改变方向。安全运营系统永远猜不到下一秒会来什么警报，或者需要开展什么调查。它甚至需要随时容纳新类型的警报。消息总线通过把事件推给能干活的智能体来适应这种变数，而不是死守着预设的剧本。

如果为了应付越来越多的特殊情况，你的“调度者”脑子里的“If-Else”判断语句越堆越多，那么是时候换成消息总线，让分发机制变得更加清晰和容易扩展了。

智能体团队 vs. 共享状态

两者里的智能体都是自主干活的。怎么选？问自己：智能体之间需要互相对答案、抄作业吗？

• 选智能体团队：如果大家各人自扫门前雪，互不干涉。代码库迁移中，每个人负责自己的服务，最后统一合并就行。
• 选共享状态：如果这是一场需要高度协作的任务，且线索需要实时流转。综合研究系统就很合适，看论文的智能体只要有新发现，看行业的智能体立马就能用上。

一旦团队成员们不再仅仅是交差时汇总结果，而是需要在干活途中频繁互通有无，那赶紧换成共享状态模式吧，它会让交流顺畅得多。

消息总线 vs. 共享状态

两者都擅长处理复杂的多智能体协作。怎么选？问自己：任务是像流水线一样一个个解决事件，还是为了慢慢攒出一个知识库？

• 选消息总线：如果智能体是对流水线上的事件做出反应。安全系统就是一环扣一环，处理完上一步才触发下一步。这个模式对“精准派活”非常在行。
• 选共享状态：如果智能体是要基于日积月累的线索持续深入。综合研究系统是在不断汇聚知识。智能体们会反复回到黑板前，看看别人发现了什么，然后调整自己的调查方向。

记住，消息总线里依然有个“路由器”在中心掌控全局决定谁接活。而共享状态是彻头彻尾的去中心化。如果你非常在意消除“单点故障”，共享状态能给你最大的安全感。

另外，如果你的消息总线系统里，大家发布消息主要只是为了“共享情报”而不是为了“触发别人的动作”，那说明你选错了，这活儿更适合共享状态模式。

新手指南

在真实的商业环境（生产环境）中，我们往往会混搭使用这些模式。一种常见的组合是：大方向的工作流用调度 - 子智能体，而在某个需要大量协作的子任务里套用共享状态。还有的系统会用消息总线来分发事件，而在处理每类事件的末端挂上一个个智能体团队。这些模式本质上是积木，并非水火不容。

下表总结了各种模式的适用场景：

适用场景	推荐模式
看重输出质量，且有明确的评估标准	生成 - 验证者 (Generator-Verifier)
任务拆解清晰，子任务边界分明且短平快	调度 - 子智能体 (Orchestrator-Subagent)
工作量可并行，且子任务独立、需要长时间运行	智能体团队 (Agent Teams)
事件驱动的流水线，智能体生态系统还在不断增长	消息总线 (Message Bus)
协作式研究，智能体之间需要频繁共享新发现	共享状态 (Shared State)
绝对不允许出现单点故障导致系统瘫痪	共享状态 (Shared State)

对于绝大多数刚刚起步的需求，我们强烈建议从“调度 - 子智能体 (Orchestrator-subagent)”开始。 它能以极低的协调成本搞定最广泛的问题。先用它跑起来，观察系统在哪里卡了脖子，然后再根据具体痛点进化到其他模式。

在接下来的文章中，我们将结合生产级别的实际案例，深入探讨每种模式的具体落地做法。如果你想回顾“我们到底什么时候值得投入多智能体系统”，请参阅：《构建多智能体系统：何时及如何使用它们》。

致谢

本文由 Cara Phillips 撰写，Eugene Yang, Jiri De Jonghe, Samuel Weller 以及 Erik Schluntz 亦有贡献。