多智能体架构的 5 种经典模式

多智能体系统的架构设计，说白了就是“怎么让一群AI Agent 高效协作干活”。选对了模式，事半功倍；选错了，轻则效率低下，重则陷入死循环。下面这五种经典模式，覆盖了从简单到复杂、从稳定到灵活的各种场景，值得仔细琢磨。

多智能体架构的 5 种经典模式

① Supervisor / Orchestrator（监督者模式）

┌─────────────┐
│  Supervisor │← 总控 Agent，分解任务、指派、聚合
└──┬──┬──┬───┘
   │  │  │
┌──▼──┴──┐  ┌────────┐
│ Agent A  │  │ Agent B  │  │ Agent C  │← Agent 之间不直接通信
└─────────┘  └─────────┘  └─────────┘

• 控制流
  ：集中式，所有调用经过 Supervisor

• Agent 关系
  ：主从关系，Agent 之间互不知晓

• 适用场景
  ：任务可被清晰分解成独立子任务，需要一个总控来协调

• 代表框架
  ：AutoGen、CrewAI

• 优点
  ：逻辑清晰、易调试、不会出现 Agent 间循环通信

• 缺点
  ：Supervisor 成单点、不支持 Agent 间直接协作

监督者模式是最直观的——一个“项目经理”Agent 负责拆解任务、分配给小 Agent，最后汇总结果。各小 Agent 彼此独立，不直接通信，所有指令都走 Supervisor。好处是流程清清楚楚，出问题也好定位；坏处是 Supervisor 一旦挂了，整个系统就瘫痪，而且小 Agent 之间没法互相帮助。

② Collaborative / Peer-to-Peer（协作式/对等式）

┌────────┐←──→┌────────┐
│ Agent A  │      │ Agent B  │
└───┬────┘      └────┬───┘
    │               │
┌────────┐         │
│ Agent C  │←───────┘
└─────────┘

• 控制流
  ：去中心化，Agent 之间自由通信

• Agent 关系
  ：平等关系，任何 Agent 可以呼叫任何 Agent

• 适用场景
  ：需要 Agent 之间协商讨论的开放性问题（如头脑风暴、代码审查）

• 代表框架
  ：ChatDev、MetaGPT

• 优点
  ：灵活、Agent 可以相互纠错、适合创意型任务

• 缺点
  ：容易死循环、通信不可预测、调试困难、token 消耗大

这种模式更像一个开放讨论组：所有 Agent 地位平等，谁都可以跟谁说话。适合那些没有标准答案、需要集思广益的创意任务，比如头脑风暴、代码审查。但自由也带来混乱——很容易陷入无限循环，或者某个 Agent 不断重复同一句话，调试起来让人头大，token 消耗也是蹭蹭往上飙。

③ Hierarchical（层级式）

┌─────────────┐
│ Top Supervisor │
└──┬───────┬──┘
   │       │
┌──▼────────┐  ┌──▼──────────┐
│ Mid Sup. A │  │ Mid Sup. B   │
└──┬────┬───┘  └──┬────┬─────┘
   │    │         │    │
   ▼    ▼         ▼    ▼
┌────┐┌────┐┌────┐┌────┐
│ A1  ││ A2  ││ B1  ││ B2  │
└────┘└────┘└────┘└────┘

• 控制流
  ：多层树状委托

• Agent 关系
  ：上级管理下级，同级不通信

• 适用场景
  ：超复杂任务需要层层分解（如大型软件开发中的架构师 → 模块负责人 → 开发者）

• 代表框架
  ：AutoGen 的嵌套 Chat、LangGraph 的 subgraph

• 优点
  ：可以处理极复杂任务、职责分明

• 缺点
  ：系统重、延迟大、层级越多越难调试

当任务复杂到超出单个监督者的能力范围时，就需要分层管理。顶层 Supervisor 只管几个中层，中层再管底层，层次分明，职责清晰。就像大公司的组织架构：CEO -> 部门总监 -> 项目经理 -> 一线员工。这种方法能处理极其庞大的任务，但代价是系统笨重、延迟高，而且层级一多，排查问题就像在迷宫里找路。

④ Debate / Reflection（辩论式/反思式）

┌────────┐┌────────┐┌────────┐
│ Agent A  │───→│ Agent B  │───→│ Agent C  │← 串行评审链
│ (生成)   │    │ (批判)   │    │ (仲裁)   │
└────────┘└────────┘└────────┘

• 控制流
  ：串行流水线，每个 Agent 评审上一个的结果

• Agent 关系
  ：生成者 → 批判者 → 仲裁者

• 适用场景
  ：对质量要求极高的场景（如生成合规文件、法律文书、代码安全审查）

• 代表框架
  ：LangGraph 的 reflection 模式、Multi-Agent Debate

• 优点
  ：输出质量高、能自我纠错

• 缺点
  ：延迟大（串行）、成本高（多次 LLM 调用）

辩论或反思模式有点像学术论文的同行评审：一个 Agent 先写初稿，第二个 Agent 负责挑刺，第三个 Agent 做最终裁定。通过多轮批判和反馈，最终输出质量极高。代码安全审查、法律文书生成这类场景特别适合，因为容错率极低。但代价也很明显——串行流程导致延迟大，且每轮都要调用大模型，成本不菲。

⑤ Dynamic / Graph-based（动态图式）

┌────────┐
│ Agent A  │───┐
└────────┘   │
             ▼
┌───┴─────┐  ┌────────┐
│ 条件判断  │  │ Agent B  │ ← 根据状态动态决定下一步
└───┬─────┘  └────────┘
    │
    │
┌────────┐   │
│ Agent C  │←──┘
└────────┘

• 控制流
  ：图结构，边带条件，动态路由

• Agent 关系
  ：无固定关系，由图的状态机定义

• 适用场景
  ：流程多变、需要根据中间结果决定下一步

• 代表框架
  ：LangGraph（核心就是这种）

• 优点
  ：最灵活、可处理复杂分支、天然支持人机协作

• 缺点
  ：图设计复杂、需要定义所有状态和边

动态图式是五种模式里最灵活、但也最复杂的。它把整个流程抽象成一个有向图，节点是 Agent，边是带条件的路由。Agent 根据中间结果动态决定下一步走向，甚至支持人工介入。LangGraph 就是这种模式的典型代表。它的优点在于能处理极其复杂的业务流程，比如客服对话中根据用户意图跳转到不同处理模块；缺点也很明显——设计图本身就需要大量精力，所有状态和转移条件都得提前定义好，否则系统可能走到死胡同。