Multi-Agent 架构全景：10 种协作模式深度解析

随着 AI Agent 的快速发展，单一 Agent 已经难以完成复杂任务。越来越多的 AI 系统开始采用 Multi-Agent（多智能体）架构，通过多个专职 Agent 协同完成复杂任务。

从 ChatGPT 的 Tool Use、Cursor 的多工具协同、Claude Code 的自主编程，到 Devin 的全自动开发、OpenAI Swarm 的多智能体框架------这些系统的核心能力之一就是 Agent 协作模式 （其二就是上下文工程，后面我会在单开一篇文章讲解）。

本文将系统介绍当前主流的 6 种 Multi-Agent 协作模式，深入分析各自的优缺点与适用边界。

模式	强项	短板	典型组合建议
Router	快速分流、低成本	路由错则错	Router + Specialist +（可选）Critic
Planner-Executor	长链路可控	依赖规划质量	Planner + Executor + Verifier + Memory
Manager-Worker	大任务并行	管理汇总开销	Manager + Workers + Synthesizer
Swarm	创意/探索	发散难收敛	Swarm + 明确终止条件 + Aggregator
Blackboard	异步接力/增量	状态一致性难	Blackboard + 认领/锁 + Publisher
Pipeline	稳定标准化	不灵活	Pipeline + 质量门/回退
Debate/Critic	高可靠/低风险	成本高	Proposer + Critics + Judge
Voting	稳健性	成本随 N 增	多 Solver + Aggregator（加权/一致性）
Auction	资源优化调度	估价难	Auctioneer + bidders + SLA
Tool编排	企业工具落地	编排复杂	Orchestrator + 专用工具agents + 审计

一、为什么需要 Multi-Agent？

1.1 单一 Agent 的典型工作流

复制代码

用户问题 → 单一 Agent → 调用工具 → 返回结果

看起来简洁，但当任务复杂度上升时，这种模式会迅速崩塌。

1.2 单一 Agent 的三大瓶颈

瓶颈一：任务复杂度限制

一个 Agent 很难同时具备以下能力并做到都擅长：

能力	示例
数据查询	写 SQL 查 BigQuery
搜索	调用 Google Search API
编程	生成并执行 Python 代码
文件处理	读写 CSV、Excel
网页浏览	爬取并解析网页内容

当所有能力堆在一个 Agent 上，模型需要在每次推理时从海量能力中选择正确的路径，错误率会随能力数量指数增长。

瓶颈二：Prompt 复杂度爆炸

如果把所有能力写在一个 System Prompt 里：

复制代码

System Prompt = 角色定义 + SQL 语法规则 + 搜索工具说明 + 代码执行规范 + 数据分析指南 + ...

Prompt 长度可能达到 数千甚至上万 token，导致：

模型注意力分散，指令遵循能力下降
不同领域的指令互相干扰
每次调用都消耗大量 token，成本飙升

瓶颈三：上下文污染

多个任务共享同一个对话上下文，会导致：

推理错误：前一个任务的中间结果干扰后续推理
Token 浪费：无关信息占据宝贵的上下文窗口
幻觉加剧：上下文中的噪声信息增多，模型更容易"胡说八道"

1.3 Multi-Agent 的核心思想

复制代码

复杂任务 → 任务拆分 → 多个专职 Agent → 协同完成 → 整合结果

本质就是软件工程中的"关注点分离"（Separation of Concerns）------每个 Agent 只做一件事，把一件事做好。

二、10种 Multi-Agent协作模式详解

1） Router / Dispatcher（路由分发）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
       ┌─────────┐
       │ Router  │  ← 仅负责分类/分流，不做深推理
       └────┬────┘
            │
   ┌────────┼────────┐
   ▼        ▼        ▼
┌──────┐ ┌──────┐ ┌──────┐
│Agent │ │Agent │ │Agent │  ← 并行执行（或路由到其中一个）
│  A   │ │  B   │ │  C   │
└──┬───┘ └──┬───┘ └──┬───┘
   │        │        │
   └────────┼────────┘
            ▼
     ┌─────────────┐
     │ Synthesizer │  ← 合并/统一口径/结构化输出
     └─────────────┘

执行流程示例

用户："VitaWord 收入下降了，获客花费有变化吗？"

Router 判断 ：需要 monetization_agent（收入/转化） + acquisition_agent（获客/投放）
两个 Agent 并行查询/分析（互不干扰）
Synthesizer 合并结论（收入变化 + CAC/CPA 变化 + 可能原因 + 建议）
返回综合回答

优缺点

维度	优点	缺点
结构复杂度	简单，易工程化	路由规则/分类器需要持续维护
成本/延迟	通常低；可只调用必要 agent	路由错会导致"整体跑偏"
适配任务	领域明确的请求	跨领域长链路任务不够强（需叠加 Planner）

2） Planner--Executor（规划--执行）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
      ┌──────────┐
      │ Planner  │  ← 拆解步骤/依赖/验收标准
      └────┬─────┘
           ▼
   ┌────────────────┐
   │ Task / Step List│  ← 计划（可迭代更新）
   └────┬───────────┘
        ▼
 ┌───────────────┐
 │ Executor(s)   │  ← 执行每一步（工具/检索/代码/SQL）
 └────┬──────────┘
      ▼
 ┌───────────────┐
 │ Verifier/QA   │  ← 每步校验，失败触发重试/重规划
 └────┬──────────┘
      ▼
 ┌───────────────┐
 │ Final Answer  │
 └───────────────┘

执行流程示例

用户："帮我定位 VitaWord 收入下降的原因，并给出本周可执行的改进动作。"

Planner 拆解 ：
1. 拉取收入分解（订阅/广告/内购）
2. 对比上周/上月
3. 分渠道获客成本变化
4. 漏斗（曝光→点击→注册→付费）定位
5. 形成动作清单
Executor 执行每一步（跑 SQL/查报表/调用分析工具）
Verifier 校验：数据口径一致、时间窗一致、是否缺失关键维度
汇总输出（原因排序 + 证据 + 预计影响 + 行动项）

优缺点

维度	优点	缺点
可控性	强（有计划、验收、可回放）	计划质量决定上限
适配任务	长链路、多步骤、可验证任务	状态管理/重规划逻辑带来工程复杂度
成本	可按步骤精细化预算	步骤多时调用成本上升

3） Manager--Worker / Hierarchical（经理--工人/层级委派）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
      ┌──────────┐
      │ Manager  │  ← 拆分子任务、分配负责人、设定交付物
      └────┬─────┘
           │
   ┌───────┼────────┐
   ▼       ▼        ▼
┌────────┐┌────────┐┌────────┐
│Worker A││Worker B││Worker C│ ← 并行交付子结果
└───┬────┘└───┬────┘└───┬────┘
    └──────┬───────┬────┘
           ▼
      ┌──────────┐
      │ Manager  │  ← 汇总/冲突消解/二次分派
      └────┬─────┘
           ▼
     ┌───────────┐
     │ Deliverable│
     └───────────┘

执行流程示例

用户："做一份 VitaWord 本月经营复盘（收入、获客、留存、竞品）并给建议。"

Manager 拆分：收入分析（A）、投放与获客成本（B）、留存与漏斗（C）、竞品调研（D）
Workers 并行产出（各自跑数/检索/总结）
Manager 汇总：统一口径、消解矛盾、形成一份复盘报告
输出最终文档

优缺点

维度	优点	缺点
并行与扩展	强，适合"大任务拆小并行"	管理/汇总开销大
质量控制	Manager 可制定交付标准	信息在层级中可能失真
适配任务	项目式交付、报告/方案	需要清晰的子任务边界与接口

4） Swarm / Team-of-Peers（对等群体协作）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
   ┌─────────────────┐
   │ Shared Chat Room │  ← 对等讨论空间
   └───┬─────┬───────┘
       ▼     ▼
  ┌────────┐ ┌────────┐
  │Agent A │↔│Agent B │  ← 互相质疑/补充/修正
  └────────┘ └────────┘
       ↕           ↕
     ┌────────┐  ┌────────┐
     │Agent C │↔ │Agent D │
     └────────┘  └────────┘
            ▼
      ┌──────────┐
      │ Aggregator│ ← 提炼共识/输出
      └──────────┘

执行流程示例

用户："我们该如何解释 VitaWord 收入下滑？给出 5 个可能假设与验证路径。"

Agent A 提出"定价/续费下降"、Agent B 提出"投放质量下降"、Agent C 提出"渠道政策变化"、Agent D 提出"产品体验导致留存下降"
互相挑战：要求证据/可验证指标
Aggregator 汇总：输出假设清单 + 每条所需数据与验证 SQL/报表

优缺点

维度	优点	缺点
创造性	强，适合发散探索	易跑题发散，难收敛
鲁棒性	不依赖单点	成本和时延通常较高
适配任务	头脑风暴、假设生成	不适合严格流程/强一致交付

5） Blackboard（黑板系统/共享工作台）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
     ┌─────────────┐
     │ Blackboard   │ ← 共享：任务池/证据/中间产物/状态
     └───┬─────┬────┘
         │     │
   ┌─────▼─┐ ┌─▼─────┐
   │Agent A│ │Agent B│  ← 订阅/触发/认领任务
   └──┬────┘ └──┬────┘
      │ write     │ write
      └─────┬─────┘
            ▼
     ┌─────────────┐
     │ Blackboard   │
     └─────┬───────┘
           ▼
     ┌─────────────┐
     │ Publisher    │ ← 汇总发布/对外输出
     └─────────────┘

执行流程示例

用户："持续监控 VitaWord 收入与获客，发现异常自动生成日报。"

黑板写入：每日任务（拉数、同比环比、异常检测、原因归因）
Agent A 认领"收入分解"、Agent B 认领"投放成本"、Agent C 认领"异常检测"
结果持续写回黑板（带版本与时间窗）
Publisher 每天固定时间读取黑板生成日报并发布

优缺点

维度	优点	缺点
解耦与并发	强，适合异步协作	状态/版本/冲突处理复杂
可持续运行	很适合长期任务与增量产出	需要任务认领、锁、幂等等机制
适配任务	持续监控、流水线、增量构建	对"即时一次性问答"略重

6） Pipeline（固定流水线）

架构

text 复制代码

┌──────┐  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐
│ User │→ │Agent A  │→ │Agent B  │→ │Agent C  │→ │ Output │
└──────┘  │(提纲)   │  │(写作)   │  │(润色)   │  └────────┘
          └────────┘  └────────┘  └────────┘

执行流程示例

用户："写一篇 VitaWord 收入复盘博客。"

A：生成大纲与章节
B：按大纲写正文
C：润色、统一术语、补充结论与行动项
输出最终文章

优缺点

维度	优点	缺点
稳定性	很稳定、易监控	不够灵活，异常分支难处理
质量	可通过"质量门"逐段把控	上游错误会累积传播
适配任务	标准化生产流程	需要临时探索/重规划时不适配

7） Debate / Critic--Judge（辩论/评审裁决）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
      ┌──────────┐
      │ Proposer  │ ← 生成候选答案/方案
      └────┬─────┘
           ▼
   ┌────────────────┐
   │ Critics (N个)   │ ← 找错误：事实/逻辑/合规/风险
   └────┬───────────┘
        ▼
      ┌──────────┐
      │ Judge     │ ← 选择/融合/要求改写
      └────┬─────┘
           ▼
      ┌──────────┐
      │ Final     │
      └──────────┘

执行流程示例

用户："对外发布：解释 VitaWord 收入下降原因并给投资人说明。"

Proposer 出一版对外口径
Critic1 （事实）查数据口径；Critic2 （PR）检查措辞风险；Critic3（法务）检查合规
Judge 融合并要求 Proposer 按修改意见重写
输出可发布版本

优缺点

维度	优点	缺点
可靠性	高，能显著降低幻觉/不当表述	成本高，链路更长
风险控制	强，适合对外/合规	Judge 标准不清会"来回拉扯"
适配任务	高风险输出、关键决策材料	低价值/即时响应不划算

8） Voting / Ensemble（投票/集成）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
   ┌────────┼────────┐
   ▼        ▼        ▼
┌──────┐ ┌──────┐ ┌──────┐
│Agent1│ │Agent2│ │Agent3│  ← 独立求解/互不看对方
└──┬───┘ └──┬───┘ └──┬───┘
   └────────┼────────┘
            ▼
     ┌─────────────┐
     │ Aggregator  │ ← 投票/加权/一致性选择
     └─────────────┘
            ▼
        ┌────────┐
        │ Output  │
        └────────┘

执行流程示例

用户："VitaWord 收入下降更可能是价格、留存还是获客？给出判断。"

3 个 agent 独立分析（各自使用不同提示/不同证据优先级）
Aggregator 以"证据充分性+一致性"投票/加权
输出最可能因素与证据列表

优缺点

维度	优点	缺点
稳健性	强，减少单点失误	成本随 agent 数量上升
实现难度	中等	融合策略不当会"多数不等于正确"
适配任务	可比较、可验证的问题	开放式创作类收益有限

9） Auction / Market（竞价/市场式调度）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
      ┌──────────┐
      │ Auctioneer│ ← 发布任务/收集报价
      └────┬─────┘
           ▼
   ┌────────┼────────┐
   ▼        ▼        ▼
┌────────┐┌────────┐┌────────┐
│Agent A ││Agent B ││Agent C │ ← 报价：成本/时延/置信度
└──┬─────┘└──┬─────┘└──┬─────┘
   └────────┼──────────┘
            ▼
     ┌─────────────┐
     │ Winner Agent │ ← 中标执行
     └─────────────┘
            ▼
        ┌────────┐
        │ Output  │
        └────────┘

执行流程示例

用户："拉取并分析 VitaWord 各渠道 CAC 变化，要求 2 分钟内返回。"

Auctioneer 发布任务（带 SLA：2 分钟）
Agent A （快但粗）报价低时延、低成本；Agent B （慢但准）报价高；Agent C（平衡）
选择满足 SLA 的最优组合（比如 C 或 A）
中标 agent 执行并返回

优缺点

维度	优点	缺点
资源优化	能显式平衡成本/时延/质量	报价/置信度评估难
扩展性	高，适合大规模任务	工程实现复杂（调度、信用体系）
适配任务	平台级调度、批任务	小系统/小规模不一定值当

10） Tool-Orchestration（工具编排型多 Agent）

架构

text 复制代码

         ┌──────┐
         │ User │
         └──┬───┘
            ▼
   ┌──────────────────┐
   │ Orchestrator Agent│ ← 决策：调用哪个工具agent、何时停止
   └───┬───────┬──────┘
       ▼       ▼
┌──────────┐ ┌──────────┐
│SearchAgent│ │SQLAgent   │ ← 各自封装工具能力
└────┬─────┘ └────┬─────┘
     ▼            ▼
┌──────────┐  ┌──────────┐
│Web/Docs  │  │DB/Warehouse│
└──────────┘  └──────────┘
       \        /
        ▼      ▼
     ┌─────────────┐
     │ Synthesizer  │ ← 整理引用/证据/格式
     └─────────────┘
            ▼
        ┌────────┐
        │ Output  │
        └────────┘

执行流程示例

用户："VitaWord 收入下降，帮我拉取关键指标并给出归因。"

Orchestrator 先调用 SQLAgent 拉收入分解与漏斗
再调用 SearchAgent 查近期活动/版本/渠道政策变更（证据）
Synthesizer 汇总数据证据 + 文字归因 + 建议
返回结果（带引用与口径说明）

优缺点

维度	优点	缺点
工程落地	强：权限、审计、观测清晰	可能退化成"单体 orchestrator"
可控性	可精细化限制工具权限与数据范围	编排逻辑与状态机复杂
适配任务	企业助手、带工具的复杂任务	纯聊天类收益不明显

统一小结：10 种模式速览（优缺点总表）

模式	强项	短板	典型组合建议
Router	快速分流、低成本	路由错则错	Router + Specialist +（可选）Critic
Planner-Executor	长链路可控	依赖规划质量	Planner + Executor + Verifier + Memory
Manager-Worker	大任务并行	管理汇总开销	Manager + Workers + Synthesizer
Swarm	创意/探索	发散难收敛	Swarm + 明确终止条件 + Aggregator
Blackboard	异步接力/增量	状态一致性难	Blackboard + 认领/锁 + Publisher
Pipeline	稳定标准化	不灵活	Pipeline + 质量门/回退
Debate/Critic	高可靠/低风险	成本高	Proposer + Critics + Judge
Voting	稳健性	成本随 N 增	多 Solver + Aggregator（加权/一致性）
Auction	资源优化调度	估价难	Auctioneer + bidders + SLA
Tool编排	企业工具落地	编排复杂	Orchestrator + 专用工具agents + 审计

在大规模系统中也会采用 多种模式的混合架构 ，就像现代软件系统不会只用一种设计模式一样。关键不在于选择"最好的"模式，而在于 根据实际业务场景选择最合适的组合。