多智能体协调模式选型指南：5种模式何时用、怎么迭代？

Shadow：最近，我的AgentOS扩展更多的场景，从情报研究（最新、学术研究、微信群用户洞察等），到生产洞察。系统越来越复杂，面临多智能体如何稳定迭代升级的问题，选型是最头疼的，选得不好，浪费时间还要返工。今天，这篇文章可以帮助我们在选型的时候考虑地更全面，少踩坑。

以下为正文⬇️

-----

你有没有过这种感觉：建了一个"豪华团队"，每个成员都很聪明，但凑在一起反而效率变低了？

多智能体系统也面临同样的困境。

不是每个Agent不够聪明，而是当智能体数量变多时，协调的开销吃掉所有收益。10个智能体需要45条连接线来两两通话，20个就变成了190条。

真正的问题不是"选哪个模式最先进"，而是"我的瓶颈到底在哪里"。

就像人类团队一样：小团队靠一个领导直接指挥就够了，大一点就需要明确的分工，再大就需要流程和规范。

最重要的是，到达瓶颈的时候，自然就知道如何迭代，而不是一开始就用最复杂的架构。

你在构建多智能体系统时，是否也遇到过这样的困惑：选Orchestrator-Subagent还是Agent Teams？Shared State听起来很美，但什么时候该用它？

Anthropic官方最新发布的多智能体协调指南给出了答案：不要一开始就选最优解，而是从最简单的开始，碰到瓶颈再升级。

"加更多Agent"的核心挑战

在讨论5种协调模式之前，先理解为什么很多团队的多智能体架构会失败。

工程师@pvergadia提出了一个被广泛认可的观察：多智能体协调存在O(n²)问题。

当n个智能体点对点通信时，所需集成连接数为C=n(n-1)/2。这意味着10个智能体需要45个连接点，20个智能体需要190个。"Just add another agent"的思路在生产环境中会发生可怕的连接数爆炸。

这才是多智能体架构的核心挑战。

不是单个智能体不够聪明，而是协调开销会随着规模非线性增长。

多智能体协调的O(n²)问题

多智能体协调的O(n²)问题

5种协调模式解析

模式一：Generator-Verifier

Generator-Verifier模式

Generator-Verifier模式

工作原理：Generator生成初始输出，Verifier评估是否满足标准。如果不满足，反馈给Generator进行修订，循环直到Verifier接受或达到最大迭代次数。

什么时候用它：输出质量至关重要且评估标准可以明确定义的场景。例如：

代码生成（一个智能体写代码，另一个写和运行测试）、事实核查、合规验证。

模式二：Orchestrator-Subagent

Orchestrator-Subagent模式

Orchestrator-Subagent模式

工作原理：一个主智能体充当团队负责人，计划工作、委托任务和汇总结果。子智能体处理特定任务并报告回来。Claude Code使用的正是这个模式：主智能体自己编写代码、编辑文件和运行命令，当需要搜索大型代码库或调查独立问题时，在后台分派子智能体。

什么时候用它：任务分解清晰且子任务相互依赖最小的场景。Orchestrator保持对整体目标的全局视角，而子智能体专注于特定任务。

局限：Orchestrator成为信息瓶颈。当子智能体发现与另一个子智能体工作相关的内容时，该信息必须通过Orchestrator传播。经过多次这样的传递，关键细节通常会丢失。

模式三：Agent Teams

工作原理：协调器将多个工作智能体作为独立进程生成。队友从共享队列中认领任务，在多个步骤中自主工作，并发出完成信号。与Orchestrator-Subagent的关键区别在于队友持久性：队友在多次任务中保持活动，积累上下文。

什么时候用它：子任务独立且受益于持续的多步骤工作。代码库迁移场景是典型案例：队友可以独立迁移每个服务，有自己的依赖项、测试套件和部署配置。

局限：队友自主操作，不能轻易共享中间发现。如果一个队友的工作影响另一个，两者都不知道，输出可能冲突。

模式四：Message Bus

Message Bus消息总线模式

Message Bus消息总线模式

工作原理：引入共享通信层，智能体可以在其中发布和订阅事件。智能体订阅它们关心的话题，路由器传递匹配的消息。新智能体可以开始接收相关工作，而无需重新连接现有连接。

什么时候用它：事件驱动管道，工作流程从事件中出现而不是预定序列，且智能体生态系统可能增长。

安全运营自动化是典型场景：警报从多个来源到达，分诊智能体按严重程度分类路由，每个调查智能体发布充实请求而上下文收集智能体满足这些请求。

局限：事件驱动通信的灵活性使追踪更加困难。调试比following Orchestrator的顺序决策更难。路由准确性至关重要：如果路由器错误分类或丢弃事件，系统会静默失败。

模式五：Shared State

Shared State共享状态模式

Shared State共享状态模式

工作原理：让智能体直接协调通过持久存储来消除中间人，所有智能体都可以读写。没有中央协调器。智能体检查存储中相关信息，作用于发现的内容，并将发现写回。

什么时候用它：智能体的工作是协作性的，发现应该实时流动。情报研究系统是典型案例：一个智能体探索学术文献，另一个分析行业报告，第三个检查专利。

每个智能体的发现直接进入存储，其他智能体可以立即看到并在此基础上继续工作。

Anthropic内部数据显示，采用Claude Opus 4作为主智能体、Sonnet 4作为子智能体的多智能体系统，比单体Opus 4表现提升90.2%。

局限：没有明确协调，智能体可能重复工作或追求矛盾的方法。更危险的是反应循环：智能体A写发现，智能体B读取并写后续，A看到后续并响应，系统继续在不会收敛的工作上燃烧token。

模式选择决策树

Orchestrator-Subagent

vs Agent Teams：

两者都涉及协调器分派工作。问题是工作智能体需要多长时间维护其上下文。当子智能体需要跨调用保留状态时，Agent Teams是更好的选择。

Orchestrator-Subagent

vs Message Bus：

两者都可以处理多步骤工作流程。问题是工作流程结构有多可预测。当步骤顺序提前已知时选Orchestrator-Subagent；当工作流程从事件中出现时选Message Bus。

Agent Teams

vs Shared State：

两者都涉及智能体自主工作。问题是智能体是否需要彼此的发现。当智能体在不会相互影响的独立分区上工作时选Agent Teams；当智能体的工作是协作性的且发现应该实时流动时选Shared State。

Message Bus

vs Shared State：

两者都支持复杂的多智能体协调。问题是工作作为离散事件流动还是累积成共享知识库。Message Bus仍然有路由器（中心组件），Shared State是去中心化的。如果消除单点故障是优先项，Shared State更完全地提供这一点。

建议

Anthropic建议从Orchestrator-Subagent开始。

它以最少的协调开销处理最普遍的问题。

观察它在哪里出现瓶颈，然后根据特定需求迭代到其他模式。

在实际应用中经常组合不同模式。

常见的混合使用Orchestrator-Subagent处理整体工作流程，使用Shared State处理协作密集的子任务。

另一个使用Message Bus进行事件路由，使用Agent Teams风格的工作智能体处理每种事件类型。

这不是一道有标准答案的考题，而是一个需要根据真实情况逐步迭代的过程。

参考

[1] Anthropic Claude Blog - Multi-agent coordination patterns — Anthropic

[2] ByteByteGo - How Anthropic Built a Multi-Agent Research System — ByteByteGo

[3] Twitter @pvergadia - multi-agent O(n²) problem — Twitter

[4] Reddit r/AI_Agents - Six months running multi-agent in production — Reddit