多智能体协同模式：五种核心架构详解

来源：Anthropic 官方多智能体协同指南，宝玉(@dotey) 推荐。原文探讨了五种经过生产验证的多智能体协调模式，本文基于原文中英文对照整理，方便读者理解每种模式的机制、适用场景和失败模式。

前言

多智能体系统的核心问题是：多个 LLM 实例在独立对话上下文下运行，如何通过代码实现协调？

在这篇官方指南中，Anthropic 梳理了五种经过生产验证的多智能体协调模式：

Generator-verifier（生成-验证者）
Orchestrator-subagent（调度-子智能体）
Agent teams（智能体团队）
Message bus（消息总线）
Shared state（共享状态）

模式一：Generator-verifier（生成-验证者）

机制

一个 Agent 负责生成输出，另一个 Agent 负责根据明确标准评估输出质量。

典型案例：代码生成场景 --- 一个 Agent 写代码，另一个 Agent 运行测试。

何时有效

当验证标准可以明确界定时，此模式效果显著。Generator 产出内容，Verifier 用独立视角审查，不依赖生成过程的理解。

失败模式

Anthropic 特别警告：

如果团队在实现循环时没有明确定义"验证"的含义，就会制造"虚假的质量控制"------看起来有评估环节，实际上没有实质把关。

另一个常见失败：Verifier 跑了一两个测试看到通过就宣布成功。必须要求完整测试套件运行并制定明确的综合检查标准。

适用场景

质量保证（运行测试套件、lint 代码、按 schema 验证输出）
合规检查（验证文档是否符合政策要求）
输出验证（确认生成内容符合规格再交付）
事实核查（由独立 Agent 验证生成内容中的论断或引用）

模式二：Orchestrator-subagent（调度-子智能体）

机制

一种层级结构：Lead Agent（调度者）负责任务分解，将边界清晰的子任务分配给专门的 Subagents。Claude Code 已采用此模式：主 Agent 在处理主要工作的同时，派发后台 Subagents 搜索大型代码库。

核心实现

python 复制代码

# Lead Agent 分解问题为独立子任务
facets = await lead_agent.decompose_query(query)

# 并行派发 Subagents 研究每个子任务
tasks = [research_subagent(facet) for facet in facets]
results = await asyncio.gather(*tasks)

# Lead Agent 综合各 Subagent 的发现
return await lead_agent.synthesize(results)

何时有效

上下文保护：子任务产生的上下文量大（超过 1000 tokens）但大部分与主任务无关时，Subagent 提供隔离
并行化：任务可自然拆分为独立部分（跨多来源的研究、跨多组件的测试）
专业化：不同任务需要不同的工具集、系统提示或专业知识

失败模式

Anthropic 指出：

Orchestrator-Subagent 会产生信息瓶颈------关键细节在通过中心协调者路由时经常丢失。

另一个陷阱：按问题类型而非上下文边界分解任务（"一个 Agent 写功能，另一个写测试，第三个做审查"），会产生大量协调开销，每个交接都会损失上下文。

适用场景

适合大多数需要多智能体协同的场景，是新团队的最佳起点，协调开销最低，能处理最广泛的问题类型。

模式三：Agent teams（智能体团队）

机制

多个命名 Agent 组成团队，通过消息路由实现持续协作。每个 Agent 有明确角色，通过消息传递进行通信和协调。Claude Code Agent Teams 正是基于此模式：多个 AI Agent 并行工作，分别处理不同任务部分，同时中心协调者追踪进度并综合结果。

关键协调方式

通过共享文件系统传递结果
通过工具调用结果共享信息
通过顺序检查点同步进度
不是通过 Agent 间直接通信

主要优势

优势	说明
并行性	多个任务同时执行
更大有效上下文	团队总体上下文大于任何单个 Agent
专业化	不同 Agent 可专注不同任务部分

何时有效

任务足够大、多面，或需要真正并行执行时，Agent teams 的协调开销才能被收益覆盖。对于小型任务，Agent teams 反而增加不必要的复杂度。

失败模式

上下文隔离问题：Agent 之间共享上下文的方式如果不清晰，会导致信息丢失或重复
合并冲突：当多个 Agent 同时修改相关资源时，冲突处理成本高昂
Token 密集度：Agent teams 通常比单一 Agent 消耗更多 token

模式四：Message bus（消息总线）

机制

多个 Agent 通过一个共享消息总线进行通信和协调。消息总线作为所有 Agent 之间的中央通信层，Agent 发布消息到总线，并从总线订阅它们需要处理的消息。

与 Orchestrator-subagent 的区别

维度	Message bus	Orchestrator-subagent
通信模式	发布/订阅	点对点任务分配
协调中心	无单一协调者	Lead Agent 主导
耦合度	松散耦合	层级耦合
适用场景	事件驱动、工作流自动化	任务分解、结果综合

何时有效

事件驱动的工作流场景
需要多个 Agent 对同一事件作出反应
工作流步骤之间的依赖关系复杂但清晰

失败模式

消息路由复杂时，调试困难
需要额外的消息队列基础设施
消息格式不匹配导致 Agent 间通信失败

模式五：Shared state（共享状态）

机制

彻底移除中心协调者。Agent 直接从持久化存储中读写，实时建立在彼此的发现之上。

何时有效

研究综合系统：一个 Agent 的发现立即影响另一个 Agent 的调查方向
Agent 之间需要频繁共享状态但不需要严格的消息传递
任务可以自然地分解为"读-处理-写"循环

优势

消除中心协调者带来的瓶颈
更高的并行度
更自然的团队协作模式

失败模式

状态一致性挑战：多个 Agent 同时写入可能产生冲突
调试困难：状态变化链路不直观
缺乏中央视图：难以追踪整体进度

模式选择决策框架

按任务独立性选择

任务特征	推荐模式
独立子任务，无交叉依赖	Parallelization（并行处理）
任务有明确分工，需要协调者	Orchestrator-subagent
任务需要持续协作和消息传递	Agent teams / Message bus
任务需要共享上下文和实时协作	Shared state

按验证需求选择

验证需求	推荐模式
需要明确的生成-验证循环	Generator-verifier
需要黑盒验证（不依赖生成上下文）	Generator-verifier
需要持续验证每个步骤	Evaluator-optimizer

Anthropic 建议

对于大多数应用，Anthropic 推荐从 Orchestrator-subagent 开始。它以最小的协调开销处理最广泛的问题类型。

生产系统通常会组合使用多种模式------比如整体工作流用 Orchestrator-subagent，子任务中需要紧密协作的部分用 Shared state。

各模式的失败模式汇总

模式	主要失败模式
Generator-verifier	无限循环（Generator 无法响应反馈）；过早宣布通过（未运行完整验证）
Orchestrator-subagent	信息瓶颈（关键细节在协调者处丢失）；按问题类型而非上下文分解
Agent teams	上下文隔离不清；合并冲突；Token 消耗过高
Message bus	消息路由复杂；基础设施开销大
Shared state	状态一致性冲突；调试困难；缺乏全局视图

实战建议

1. 从单一 Agent 开始

一个设计良好的单一 Agent + 适当的工具，往往比多智能体系统完成更多工作。多智能体系统引入开销：每个额外 Agent 都代表一个新的潜在故障点、额外需要维护的 Prompts，以及意外行为的另一个来源。

2. 只有当以下情况才使用多智能体

上下文污染降低性能时：当子任务的上下文累积影响后续任务质量时
任务可以并行运行时：当任务可自然分解为独立部分时
专业化能改进工具选择或任务专注度时：当不同任务需要不兼容的工具集或专业领域时

3. 按上下文分解，而非按问题类型

问题类型分解（通常适得其反）：按工作类型划分（一个 Agent 写功能，另一个写测试，第三个审查），会产生持续的协调开销。

上下文分解（通常有效）：按上下文边界分解------处理一个功能的 Agent 也应该处理它的测试，因为它已经拥有必要的上下文。

4. 设置明确的验证检查点

无论选择哪种模式，都要确保有清晰的验证点，让 Subagents 可以在不需要完整上下文的情况下验证工作。

总结对比

模式	协调复杂度	适用场景	代表应用
Generator-verifier	⭐	需要明确验证标准的任务	代码生成+测试、合规检查
Orchestrator-subagent	⭐⭐	需要任务分解和结果综合	研究调研、代码审查
Agent teams	⭐⭐⭐	需要多角色持续协作	复杂软件开发、商业策划
Message bus	⭐⭐⭐	事件驱动、松散耦合的工作流	自动化工作流、事件处理
Shared state	⭐⭐	需要实时共享发现的研究任务	研究综合、协作式探索

参考来源

Anthropic 官方博客 ：《When to use multi-agent systems (and when not to)》 www.claude.com/blog/buildi...
Anthropic 工程博客 ：《How we built our multi-agent research system》 www.anthropic.com/engineering...
宝玉(@dotey) X 转发 ： x.com/dotey/statu...
Claude Code Agent Teams ： www.mindstudio.ai/blog/what-i...
Multi-agent Coordination Patterns (daily.dev 整理)： app.daily.dev/posts/multi...

本文基于 Anthropic 官方文档整理，保留原文核心内容，仅做中文化处理和必要结构调整。如需深入了解，建议阅读原文。