多智能体协调模式深度解析：五种架构模式的原理、选型与最佳实践

一、引言

随着 AI Agent 从单体智能迈向多智能体协作，如何让多个智能体有效协调工作已成为构建生产级 AI 系统的核心挑战。与微服务架构的演进类似，多智能体系统也面临着任务分解、通信协调、状态管理、容错处理等经典分布式系统问题。

本文基于 Claude Blog 的多智能体协调模式 一文，深入解析五种核心协调模式的架构设计、工作原理、适用场景及工程实践建议，配合详细的架构图和流程图，帮助开发者在实际项目中做出合理的技术选型。需要说明的是，原文更偏向模式辨析与选型建议，本文在其框架基础上补充了工程实现视角、架构抽象与落地实践。

核心原则

在深入每种模式之前，需要牢记一个核心原则：

从最简单的模式开始，根据实际需求逐步演进，而不是盲目选择最复杂的方案。

graph LR
    A[单 Agent] -->|"遇到瓶颈"| B[Generator-Verifier]
    A -->|"任务可分解"| C[Orchestrator-Subagent]
    C -->|"需要持久上下文"| D[Agent Teams]
    C -->|"事件驱动"| E[Message Bus]
    C -->|"需要协作研究"| F[Shared State]
    
    style A fill:#2d2d44,stroke:#667eea,color:#fff
    style B fill:#667eea,stroke:#764ba2,color:#fff
    style C fill:#f093fb,stroke:#f5576c,color:#fff
    style D fill:#4facfe,stroke:#00f2fe,color:#fff
    style E fill:#43e97b,stroke:#38f9d7,color:#1a1a2e
    style F fill:#fa709a,stroke:#fee140,color:#1a1a2e

二、模式一：生成器-验证器（Generator-Verifier）

2.1 核心机制

生成器-验证器是最基础也是最直观的多智能体模式。其核心思想是将创作与审核分离为两个独立的智能体角色，通过迭代反馈循环不断提升输出质量。

2.2 工作流程

sequenceDiagram
    participant T as 任务输入
    participant G as 生成器 Agent
    participant V as 验证器 Agent
    participant O as 最终输出

    T->>G: 提交任务需求
    
    loop 迭代循环 (≤ MAX_ITERATIONS)
        G->>G: 生成/修订输出
        G->>V: 提交输出结果
        V->>V: 按标准评估
        
        alt 通过验证
            V->>O: ✅ 输出验证通过
        else 未通过
            V->>G: ❌ 返回详细反馈
            Note over G,V: 生成器根据反馈修订
        end
    end
    
    Note over G,V: 超过最大迭代 → 执行回退策略

2.3 典型应用场景

2.4 优势与局限

mindmap
  root((Generator-Verifier))
    优势
      质量保证机制
        迭代改进确保高质量输出
        每次循环都有明确反馈
      职责分离
        生成与验证解耦
        可独立优化各自能力
      可预测性
        循环次数可控
        有明确的终止条件
    局限
      标准依赖
        验证标准必须明确
        模糊标准导致橡皮图章效应
      技能假设
        验证必须比生成更容易
        创意型任务难以客观验证
      循环风险
        可能陷入停滞
        需要回退策略

2.5 工程实践建议

设计验证器的关键要素：

1. 明确的评估标准：验证器必须有清晰、可量化的判断依据，避免主观评估
2. 结构化反馈：验证器应返回具体的改进建议，而非简单的"通过/不通过"
3. 迭代上限：设置合理的 MAX_ITERATIONS（通常 3-5 次），防止无限循环
4. 回退策略：超过最大迭代次数时，应有明确的降级处理方案

# 伪代码示例：Generator-Verifier 核心循环
MAX_ITERATIONS = 5

def generator_verifier_loop(task, criteria):
    output = generator.generate(task)
    
    for i in range(MAX_ITERATIONS):
        result = verifier.evaluate(output, criteria)
        
        if result.passed:
            return output  # 验证通过，返回结果
        
        # 将反馈传递给生成器进行修订
        output = generator.revise(output, result.feedback)
    
    # 超过最大迭代，执行回退策略
    return fallback_strategy(output, task)

三、模式二：编排器-子智能体（Orchestrator-Subagent）

3.1 核心机制

编排器-子智能体是最通用的多智能体模式。一个**主管智能体（Orchestrator）**负责全局规划，将复杂任务分解为子任务，分发给专门化的子智能体执行，最后汇总结果。这与微服务架构中的 API Gateway 模式异曲同工。

3.2 工作流程

sequenceDiagram
    participant U as 用户
    participant O as 编排器
    participant S1 as 安全检查 Agent
    participant S2 as 测试覆盖 Agent
    participant S3 as 代码风格 Agent
    participant S4 as 性能分析 Agent

    U->>O: 提交代码审查任务
    O->>O: 分析任务，制定审查计划
    
    par 并行执行
        O->>S1: 安全漏洞扫描
        O->>S2: 测试覆盖率检查
        O->>S3: 代码规范检查
        O->>S4: 性能热点分析
    end
    
    S1-->>O: 安全报告
    S2-->>O: 测试报告
    S3-->>O: 风格报告
    S4-->>O: 性能报告
    
    O->>O: 汇总各子报告
    O->>U: 统一代码审查报告

3.3 与智能体团队模式的关键区别

graph TB
    subgraph "Orchestrator-Subagent"
        OA[编排器] -->|创建| SA1[子Agent ①]
        OA -->|创建| SA2[子Agent ②]
        OA -->|创建| SA3[子Agent ③]
        SA1 -->|完成后销毁| OA
        SA2 -->|完成后销毁| OA
        SA3 -->|完成后销毁| OA
    end
    
    subgraph "Agent Teams"
        CO[协调器] -->|生成| TA1[成员 ①]
        CO -->|生成| TA2[成员 ②]
        CO -->|生成| TA3[成员 ③]
        TA1 -.->|持续存在| TA1
        TA2 -.->|持续存在| TA2
        TA3 -.->|持续存在| TA3
    end
    
    style OA fill:#f093fb,stroke:#f5576c,color:#fff
    style CO fill:#43e97b,stroke:#38f9d7,color:#1a1a2e
    style SA1 fill:#4facfe,color:#fff
    style SA2 fill:#4facfe,color:#fff
    style SA3 fill:#4facfe,color:#fff
    style TA1 fill:#667eea,color:#fff
    style TA2 fill:#667eea,color:#fff
    style TA3 fill:#667eea,color:#fff

核心区别在于生命周期：

• Orchestrator-Subagent：子智能体是临时性的，每次任务结束即销毁
• Agent Teams：团队成员持续存在，在多次任务分配中积累上下文

3.4 优势与局限

3.5 工程实践建议

1. 显式并行化：对于无依赖关系的子任务，应明确使用并行执行策略
2. 结果标准化：所有子智能体的输出格式应标准化，方便编排器汇聚
3. 超时控制：为每个子智能体设置独立的超时时间
4. 降级处理：某个子智能体失败时，编排器应能继续处理其他结果

# 伪代码示例：并行编排子智能体
import asyncio

async def orchestrate_code_review(code_diff):
    # 1. 制定审查计划
    plan = orchestrator.plan(code_diff)
    
    # 2. 并行分发子任务
    tasks = [
        security_agent.scan(code_diff),
        test_agent.check_coverage(code_diff),
        style_agent.check_style(code_diff),
        perf_agent.analyze(code_diff),
    ]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    
    # 3. 汇总结果（容忍部分失败）
    valid_results = [r for r in results if not isinstance(r, Exception)]
    return orchestrator.synthesize(valid_results)

四、模式三：智能体团队（Agent Teams）

4.1 核心机制

智能体团队模式是编排器模式的"增强版"。协调器生成一组持久化的团队成员，这些成员从共享任务队列中认领任务，自主完成多步骤工作。成员在多次任务分配中保持状态和上下文，不断积累专业能力。

4.2 工作流程

stateDiagram-v2
    [*] --> 协调器初始化
    协调器初始化 --> 生成团队成员
    生成团队成员 --> 填充任务队列
    
    state 团队并行工作 {
        state 成员A {
            A_认领 : 认领任务
            A_执行 : 执行工作
            A_完成 : 报告完成
            A_认领 --> A_执行 : 自主决策
            A_执行 --> A_完成 : 多步骤
            A_完成 --> A_认领 : 认领下一个
        }
        
        state 成员B {
            B_认领 : 认领任务
            B_执行 : 执行工作
            B_完成 : 报告完成
            B_认领 --> B_执行 : 自主决策
            B_执行 --> B_完成 : 多步骤
            B_完成 --> B_认领 : 认领下一个
        }
    }
    
    填充任务队列 --> 团队并行工作
    团队并行工作 --> 全部完成检测
    全部完成检测 --> 结果汇总
    结果汇总 --> [*]

4.3 典型应用场景

大规模代码库迁移是智能体团队模式的经典场景：

graph TB
    CO[协调器<br/>Migration Coordinator] -->|分配| Q[共享任务队列]
    
    Q -->|服务 Alpha| W1[成员 A<br/>Alpha 迁移工作者]
    Q -->|服务 Beta| W2[成员 B<br/>Beta 迁移工作者]  
    Q -->|服务 Gamma| W3[成员 C<br/>Gamma 迁移工作者]
    
    W1 --> W1_1[更新依赖] --> W1_2[修改代码] --> W1_3[修复测试] --> W1_4[验证通过 ✅]
    W2 --> W2_1[更新依赖] --> W2_2[适配API] --> W2_3[回归测试] --> W2_4[验证通过 ✅]
    W3 --> W3_1[迁移数据库] --> W3_2[更新ORM] --> W3_3[数据验证] --> W3_4[验证通过 ✅]
    
    style CO fill:#43e97b,color:#1a1a2e
    style Q fill:#fa709a,color:#1a1a2e
    style W1 fill:#4facfe,color:#fff
    style W2 fill:#4facfe,color:#fff
    style W3 fill:#4facfe,color:#fff

每个成员从头到尾负责一个完整服务的迁移，包括依赖更新、代码修改、测试修复——而不是每完成一步就销毁重建。这种方式让成员积累关于该服务的深度上下文。

4.4 优势与局限

quadrantChart
    title Agent Teams 适用性评估
    x-axis "任务间依赖性 (低 → 高)" 
    y-axis "需要的上下文深度 (浅 → 深)"
    quadrant-1 "⚠️ 不推荐"
    quadrant-2 "✅ 最佳适用区"
    quadrant-3 "考虑 Orchestrator"
    quadrant-4 "考虑 Shared State"
    "代码库迁移": [0.2, 0.85]
    "并行测试": [0.15, 0.3]
    "多服务重构": [0.35, 0.9]
    "协作研究": [0.8, 0.7]
    "简单批处理": [0.1, 0.15]
    "关联任务处理": [0.75, 0.45]

关键局限：

• 独立性要求：成员间难以共享中间发现，任务必须足够独立
• 完成检测：成员完成时间不一致，需要设计完善的完成检测机制
• 资源冲突：多个成员同时操作共享资源（如同一代码库）可能产生冲突

4.5 工程实践建议

1. 任务粒度设计：确保每个任务足够独立，一个成员能端到端完成
2. 领域划分：按服务、模块或数据分区划分任务，最小化交叉依赖
3. 冲突防护：为共享资源（如 Git 仓库）实施锁机制或分支隔离
4. 进度追踪：实现统一的进度上报和健康检查机制

五、模式四：消息总线（Message Bus）

5.1 核心机制

消息总线模式借鉴了事件驱动架构（EDA），智能体通过 publish（发布） 和 subscribe（订阅） 两个原语进行松耦合交互。路由器负责将消息按 topic 匹配并分发给订阅者。

5.2 工作流程

sequenceDiagram
    participant AS as 告警源
    participant MB as 消息总线
    participant R as 路由器
    participant SI as 安全调查 Agent
    participant PO as 性能优化 Agent
    participant RC as 响应协调 Agent

    AS->>MB: publish("security.alert.critical", {type: "SQL注入", severity: "critical"})
    MB->>R: 路由消息
    R->>SI: 匹配 subscribe("security.*")
    R->>RC: 匹配 subscribe("security.alert.critical")
    
    SI->>SI: 调查分析
    SI->>MB: publish("security.investigation.complete", {findings: ...})
    MB->>R: 路由调查结果
    R->>RC: 匹配 subscribe("security.investigation.*")
    
    RC->>RC: 协调响应
    RC->>MB: publish("response.action", {action: "isolate", target: ...})
    
    Note over AS,RC: 新增 Agent 只需订阅相关 topic，无需修改已有 Agent

5.3 消息路由机制

graph LR
    subgraph "Topic 层次结构"
        T1["security.*"]
        T2["security.alert.critical"]
        T3["security.investigation.*"]
        T4["perf.*"]
        T5["perf.latency.*"]
        T6["log.*"]
    end
    
    subgraph "订阅者匹配"
        S1["安全调查 Agent<br/>→ security.*"]
        S2["响应协调 Agent<br/>→ security.alert.critical"]
        S3["性能优化 Agent<br/>→ perf.*"]
        S4["日志归档 Agent<br/>→ log.*"]
    end
    
    T1 -.-> S1
    T2 -.-> S1
    T3 -.-> S1
    T2 -.-> S2
    T4 -.-> S3
    T5 -.-> S3
    T6 -.-> S4

    style T1 fill:#f5576c,color:#fff
    style T2 fill:#f5576c,color:#fff
    style T3 fill:#f5576c,color:#fff
    style T4 fill:#43e97b,color:#1a1a2e
    style T5 fill:#43e97b,color:#1a1a2e
    style T6 fill:#4facfe,color:#fff

5.4 优势与局限

5.5 工程实践建议

1. Topic 设计规范：采用层次化命名（如 security.alert.critical），支持通配符匹配
2. 消息幂等性：确保订阅者能安全处理重复消息
3. 死信队列：未被任何订阅者匹配的消息应进入死信队列
4. 可观测性：为每条消息添加 trace ID，实现端到端链路追踪
5. 路由测试：定期验证路由规则的准确性，防止消息丢失或误分发

六、模式五：共享状态（Shared State）

6.1 核心机制

共享状态模式是最去中心化的协调方式。没有中央编排器，所有智能体通过读写共享的数据存储（数据库、文件系统或文档）进行隐式协调。每个智能体自主检查存储、执行工作、写回发现。不过，这并不意味着底层存储天然没有单点，实际落地仍需依赖高可用与分布式设计。

6.2 工作流程

sequenceDiagram
    participant SS as 共享状态存储
    participant LA as 文献 Agent
    participant IA as 行业 Agent
    participant PA as 专利 Agent
    participant SA as 合成 Agent

    Note over SS: 初始状态：研究课题已写入

    par 自主工作循环
        loop 文献研究循环
            LA->>SS: 读取当前发现
            LA->>LA: 搜索学术论文
            LA->>SS: 写入：发现关键研究者 Dr. Smith
        end
        
        loop 行业研究循环
            IA->>SS: 读取当前发现
            Note over IA: 发现 Dr. Smith，跟进调查
            IA->>IA: 搜索行业应用
            IA->>SS: 写入：Dr. Smith 在 TechCorp 任职
        end

        loop 专利分析循环
            PA->>SS: 读取当前发现
            PA->>PA: 检索相关专利
            PA->>SS: 写入：TechCorp 持有 3 项相关专利
        end
    end

    SA->>SS: 读取所有发现
    SA->>SA: 交叉引用、合成报告
    SA->>SS: 写入最终综合报告

    Note over SS: 终止条件满足 → 输出最终报告

6.3 典型应用场景

研究合成系统是共享状态模式的最佳实践场景：

graph TB
    subgraph 共享状态存储
        DB[(共享数据库)]
        DB --- K1[关键词列表]
        DB --- K2[已发现实体]
        DB --- K3[交叉引用关系]
        DB --- K4[综合结论]
    end
    
    A1[📚 文献Agent] <-->|读写| DB
    A2[🏢 行业Agent] <-->|读写| DB
    A3[📜 专利Agent] <-->|读写| DB
    A4[🌐 新闻Agent] <-->|读写| DB
    A5[🧬 合成Agent] <-->|读写| DB
    
    style DB fill:#fa709a,color:#1a1a2e
    style A1 fill:#667eea,color:#fff
    style A2 fill:#667eea,color:#fff
    style A3 fill:#667eea,color:#fff
    style A4 fill:#667eea,color:#fff
    style A5 fill:#43e97b,color:#1a1a2e

6.4 优势与局限

mindmap
  root((Shared State))
    优势
      去中心化
        协调层无中心编排器
        配合高可用存储可降低单点风险
      协作性
        智能体可实时借鉴发现
        涌现式知识构建
      灵活性
        新Agent随时加入
        无需预定义工作流
    局限
      重复工作
        多个Agent可能做相同的事
        缺乏全局任务分配
      反应循环
        Agent间互相触发
        可能无限消耗资源
      一致性
        并发写入可能冲突
        需要终止条件设计
      可预测性差
        执行路径不确定
        调试和复现困难

6.5 反应循环（Reactive Loop）防护

共享状态模式最大的风险是反应循环——智能体 A 的输出触发智能体 B，B 的输出又触发 A，形成无限循环消耗资源。

graph LR
    A[Agent A] -->|写入发现| SS[(共享存储)]
    SS -->|触发| B[Agent B]
    B -->|写入新发现| SS
    SS -->|触发| A
    
    STOP[⚠️ 终止条件] -.->|打破循环| SS
    
    style STOP fill:#f5576c,color:#fff
    style SS fill:#fa709a,color:#1a1a2e

防护策略：

1. 时间限制：设置总运行时间上限
2. 收敛检测：当新增发现低于阈值时停止
3. 迭代上限：限制每个智能体的最大读写次数
4. 重复检测：识别并忽略已处理过的发现

七、模式对比与选型决策

7.1 综合对比表

7.2 模式选择决策流程

7.3 关键决策问题

graph TD
    Q1{需要持续积累上下文？}
    Q1 -->|子任务短且清晰| A1[Orchestrator-Subagent]
    Q1 -->|需要长期上下文| A2[Agent Teams]
    
    Q2{工作流可预测？}
    Q2 -->|步骤已知| B1[Orchestrator-Subagent]
    Q2 -->|由事件动态产生| B2[Message Bus]
    
    Q3{协作需求？}
    Q3 -->|独立分区工作| C1[Agent Teams]
    Q3 -->|需实时共享发现| C2[Shared State]
    
    Q4{工作流性质？}
    Q4 -->|离散事件管道| D1[Message Bus]
    Q4 -->|积累知识库| D2[Shared State]
    
    style A1 fill:#f093fb,color:#fff
    style A2 fill:#4facfe,color:#fff
    style B1 fill:#f093fb,color:#fff
    style B2 fill:#43e97b,color:#1a1a2e
    style C1 fill:#4facfe,color:#fff
    style C2 fill:#fa709a,color:#1a1a2e
    style D1 fill:#43e97b,color:#1a1a2e
    style D2 fill:#fa709a,color:#1a1a2e

八、组合使用与演进策略

8.1 模式组合

生产环境中很少只使用单一模式，更常见的是模式组合。

graph TB
    subgraph "组合示例：智能代码审查系统"
        U[用户提交 PR] --> ORCH[编排器<br/>Orchestrator]
        
        ORCH -->|分发| GV["生成器-验证器<br/>(代码修复建议)"]
        ORCH -->|分发| TEAM["智能体团队<br/>(多文件分析)"]
        ORCH -->|分发| SS["共享状态<br/>(知识积累)"]
        
        GV --> R1[修复方案 + 验证通过]
        TEAM --> R2[各文件分析报告]
        SS --> R3[历史代码模式知识]
        
        R1 --> ORCH
        R2 --> ORCH
        R3 --> ORCH
        
        ORCH --> FINAL[综合审查报告]
    end
    
    style ORCH fill:#f093fb,color:#fff
    style GV fill:#667eea,color:#fff
    style TEAM fill:#4facfe,color:#fff
    style SS fill:#fa709a,color:#1a1a2e

8.2 演进路径

graph LR
    S1["🟢 起步<br/>单 Agent"] -->|"质量不够"| S2["🔵 阶段 2<br/>Generator-Verifier"]
    S1 -->|"任务太复杂"| S3["🟣 阶段 2<br/>Orchestrator-Subagent"]
    S3 -->|"需要长期上下文"| S4["🔷 阶段 3<br/>Agent Teams"]
    S3 -->|"事件驱动需求"| S5["🟩 阶段 3<br/>Message Bus"]
    S3 -->|"协作研究需求"| S6["🟡 阶段 3<br/>Shared State"]
    S4 -->|"跨团队协作"| S7["⭐ 阶段 4<br/>混合模式"]
    S5 -->|"需要知识积累"| S7
    S6 -->|"需要事件触发"| S7
    
    style S1 fill:#2d2d44,stroke:#fff,color:#fff
    style S2 fill:#667eea,color:#fff
    style S3 fill:#f093fb,color:#fff
    style S4 fill:#4facfe,color:#fff
    style S5 fill:#43e97b,color:#1a1a2e
    style S6 fill:#fa709a,color:#1a1a2e
    style S7 fill:#fee140,color:#1a1a2e

核心建议：

1. 从 Orchestrator-Subagent 起步：适用面最广，协调开销最小
2. 观察瓶颈：记录系统在哪里遇到困难
3. 按需演进：根据具体瓶颈引入其他模式
4. 保持简单：能用简单模式解决的问题，不要过度设计

九、总结

多智能体协调不是"越复杂越好"的技术竞赛，而是需要根据问题特征选择最合适的协调模式的工程决策。下表提供了快速决策参考：

关键要点：

• 起步从简：从最简单的满足需求的模式开始
• 组合使用：生产系统通常会组合多种模式
• 按需演进：观察系统瓶颈，有针对性地引入更复杂的模式
• 工程优先：选择团队能驾驭的模式，而不是最炫酷的模式

参考资料：

• Multi-agent coordination patterns: Five approaches and when to use them | Claude Blog
• Building effective agents | Anthropic

× 爱折腾的工程师

真诚赞赏，手留余香

2元 5元 10元 50元 100元 任意金额

2元

使用微信扫描二维码完成支付

• ← Previous Post
• Next Post →