如果你正在搭建一个多 Agent 系统，你很快就会遇到一个灵魂拷问：

这些 Agent 之间到底怎么「配合」？

是把一个「总指挥」Agent 放在中间，让它分派任务？还是让所有 Agent 平等对话，谁有空谁干？或者搞一个「监工」Agent 来监督一群干活 Agent？再或者让 Agent 排成一条流水线，一个接一个处理？

答案是：看你的场景。

但问题在于，大多数人做选择时靠的是「直觉」——哪个模式听起来更酷就用哪个。结果就是：系统上线后，状态不一致、任务重复执行、Agent 互相死锁……然后花几周来重构。

这篇文章是《多Agent 系统架构设计》系列的第一篇。我打算从分布式系统工程的角度，把四种基本的编排模式讲透。每种模式的拓扑结构、适用场景、状态管理策略、容错设计，以及——作为一个做了十几年 Flink/Kafka/Pulsar 的人——我会用你熟悉的分布式系统概念来类比。

如果你还没看过我之前写的 Agents 互联！A2A/MCP/ANP/ACP 四大协议详解，建议先读那篇。编排模式决定了你要用什么样的通信协议，两者是「上层拓扑」和「下层连接」的关系。

为什么编排模式是架构设计的「第一性原理」？

在聊具体模式之前，先想清楚一个问题：为什么需要编排？

单 Agent 的架构很简单：一个 LLM 循环（感知 → 规划 → 行动 → 观察），调几个工具，完成任务。所有状态都在一个进程里，不存在协调问题。

但当你把 N 个 Agent 放在一起时，就出现了三个新问题：

1. 任务怎么分：谁来决定哪个 Agent 做什么？
2. 状态怎么管：Agent A 的执行结果怎么影响 Agent B 的决策？
3. 错了怎么办：Agent C 挂了，谁负责重新调度？

这三个问题，就是编排模式要回答的。不同的编排模式，本质上是控制权的分配方式不同——是把控制权集中在一个中心节点，还是分散到所有 Agent 中。

四种编排模式速览

模式一：Orchestrator-Worker — 当你有「总指挥」

拓扑结构

这是最直观的模式：一个中心 Orchestrator Agent 负责任务分解、调度、结果聚合；一群 Worker Agent 负责执行具体任务。

         ┌─────────────────────┐
         │   Orchestrator      │
         │   (任务分解 + 调度)   │
         └──────────┬──────────┘
                    │
      ┌─────────────┼─────────────┐
      │             │             │
   ┌──▼──┐      ┌──▼──┐      ┌──▼──┐
   │Worker│      │Worker│      │Worker│
   │  A   │      │  B   │      │  C   │
   └──────┘      └──────┘      └──────┘

核心设计理念

Orchestrator 是大脑，Worker 是手脚。Orchestrator 维护全局状态视图，Worker 只做执行，不做决策。

如果你做过 Flink，这其实就是 JobManager → TaskManager 的映射。 JobManager 负责 Checkpoint 协调、任务分片、故障恢复；TaskManager 只管执行算子。Orchestrator-Worker 的本质就是把「决策」和「执行」分离。

状态管理策略

• 中心化状态：Orchestrator 维护任务队列、Worker 心跳、执行结果
• Worker 无状态：Worker 不持久化任何状态，全量依赖 Orchestrator 下发
• 同步模式：Orchestrator 等 Worker 返回结果后再做下一步决策

容错设计

• Worker 挂了 → Orchestrator 检测心跳超时，把任务重新分配给另一个 Worker（类似 Flink 的 Task Failover）
• Orchestrator 挂了 → 系统整体不可用，需要 Orchestrator 自身做 HA（主备或 Raft 共识）
• 推荐做法：Orchestrator 用 etcd/ZooKeeper 做选主，Worker 用注册中心做服务发现

适用场景

✅ 任务可分解为独立子任务：比如并行做 N 个文档分析，每个 Worker 处理一篇 ✅ 需要全局可见性：比如做竞品分析，Orchestrator 需要知道所有 Worker 的结果才能合成最终报告 ✅ 子任务之间没有依赖：Worker A 不需要等 Worker B 的结果

不适用场景

❌ 子任务之间有复杂的依赖关系（需要 Chain 或 DAG） ❌ Worker 数量超过百级（Orchestrator 会成为瓶颈） ❌ 需要低延迟的实时协作（中心调度增加了转发延迟）

真实案例

• CrewAI 的 SequentialProcess / HierarchicalProcess 模式本质上就是 Orchestrator-Worker
• LangGraph 的 StateGraph 中，你可以把编译后的图执行器看作一个轻量 Orchestrator
• OpenAI 的 Assistants API 中，Thread + Run 的模型也是 Orchestrator-Worker 的变体

模式二：Peer-to-Peer — 当Agent们「平等对话」

拓扑结构

没有中心节点，所有 Agent 都可以互相通信。每个 Agent 既是生产者也是消费者，通过 Gossip 协议或共享消息总线来协调。

         ┌──────┐
    ┌────│Agent │◄────┐
    │    │  A   │     │
    │    └──────┘     │
    │                  │
 ┌──▼──┐          ┌──▼──┐
 │Agent│◄────────►│Agent│
 │  B   │          │  C   │
 └──────┘          └──────┘

核心设计理念

没有「总指挥」，所有 Agent 通过协商或竞争来完成任务。每个 Agent 有自己的局部视图，通过消息交换来达成全局一致。

做过 Kafka Consumer Group 的话，你会觉得这个模式很熟悉。 同一个 Group 下的 Consumer 通过协调器分配 Partition，每个 Consumer 各自消费，没有中心调度器告诉它们「你去读 Partition 0，你去读 Partition 1」。靠的是协议（比如 Kafka 的 rebalance 协议）而不是命令。

状态管理策略

• 分布式状态：每个 Agent 维护自己的局部状态
• 最终一致性：通过 Gossip 或消息传递来同步
• 异步模式：Agent 之间不互相等待，通过事件驱动

容错设计

• 单个 Agent 挂了 → 其他 Agent 通过 Gossip / 心跳检测到，任务被其他 Agent 捡起
• 网络分区 → 每个分区独立运行，恢复后做状态合并（类似 CRDT 思路）
• 没有单点故障，但可能出现「脑裂」——两个 Agent 同时认为自己在负责同一个任务

适用场景

✅ Agent 之间需要灵活协作：谁有空谁接任务，不需要提前分配 ✅ 系统规模大、动态变化：Agent 可以随时加入或退出 ✅ 低延迟、高可用：没有中心瓶颈，任一 Agent 挂了不影响整体

不适用场景

❌ 需要严格的事务一致性（分布式事务在 P2P 下非常难做） ❌ 调试和审计需求高（消息流向不固定，难以追踪） ❌ 子任务之间有严格的依赖顺序

真实案例

• CrewAI 的 Process.sequential 其实不算 P2P，但它的「可选 Agent 投票」机制接近 P2P 协商
• AutoGen 的 GroupChat 模式：多个 Agent 围绕一个话题讨论，谁拿到发言权谁说话
• Kafka 流处理中，多个 Processor 节点通过内部 Topic 交换数据，本质上是 P2P 消息传递

模式三：Supervisor — 当你要「分层管理」

拓扑结构

一种介于集中和分散之间的模式：Supervisor Agent 不直接做事，而是管理一组 Worker Agent，并且 Supervisor 之间可以形成层级结构。

         ┌──────────────┐
         │  Top Supervisor│
         └──────┬───────┘
                │
      ┌─────────┼─────────┐
      │         │         │
   ┌──▼──┐  ┌──▼──┐  ┌──▼──┐
   │Supv │  │Supv │  │Supv │
   │  A  │  │  B  │  │  C  │
   └──┬──┘  └──┬──┘  └──┬──┘
      │        │        │
   ┌──┼──┐  ┌──┼──┐  ┌──┼──┐
   │  │  │  │  │  │  │  │  │
   W1 W2 W3 W4 W5 W6 W7 W8 W9

核心设计理念

Supervisor 的职责不是「做任务」，而是「管 Agent」。它监控 Worker 的健康状态、重启失败的 Worker、上报汇总信息给上层 Supervisor。

如果你用过 Kubernetes，这其实就是 ReplicaSet → Pod 的映射。 ReplicaSet 不跑业务代码，它只确保有 N 个 Pod 在跑。Pod 挂了它重新拉起。Supervisor 模式的核心思想就是分层管理、职责分离。

状态管理策略

• 分层状态：每层 Supervisor 维护自己管辖范围内的聚合状态
• 状态上卷：下层 Supervisor 定期向上层汇报摘要（心跳 + 统计指标）
• 命令下发：上层 Supervisor 向下传递策略配置（不传具体任务）

容错设计

• Worker 挂了 → 直接 Supervisor 重启或替换，对上层透明
• Supervisor 挂了 → 下层 Supervisor 或 Worker 进入「降级模式」，等待恢复
• 顶级 Supervisor 挂了 → 需要 HA 保障（主备或共识算法）
• 容错隔离性是最大优势：一个 Worker 挂了不影响其他 Worker

适用场景

✅ 系统规模大，需要分层管理：比如 100+ Agent 的系统，不可能一个 Orchestrator 管所有 ✅ 不同 Worker 类型差异大：不同类型的 Worker 需要不同的管理策略 ✅ 需要审计和治理：每层 Supervisor 可以记录日志和决策

不适用场景

❌ 系统规模小（< 10 Agent），分层管理引入不必要的复杂度 ❌ 任务需要快速跨层协作（跨 Supervisor 的通信延迟高） ❌ 需要全局一致性视图（分层意味着信息延迟）

真实案例

• Pulsar 的分层架构：BookKeeper 中的 Auditor（审计节点）负责监控 Bookie 的健康状态，和 Supervisor 模式异曲同工
• LangGraph 的自定义 Checkpoint + 中断恢复机制，可以理解为一种 Supervisor 式的容错
• Kubernetes Operator 模式：Operator 作为 Supervisor 监控自定义资源的状态

模式四：Chain — 当Agent们「排成流水线」

拓扑结构

Agent 按顺序排列，前一个 Agent 的输出作为后一个 Agent 的输入。数据像流水线一样流过各个处理节点。

  ┌──────┐    ┌──────┐    ┌──────┐    ┌──────┐
  │Agent │──►│Agent │──►│Agent │──►│Agent │
  │  A   │    │  B   │    │  C   │    │  D   │
  └──────┘    └──────┘    └──────┘    └──────┘
  输入         处理         处理         输出

核心设计理念

每个 Agent 只做一件事，做完传给下一个。数据流的方向是固定的，不存在回环或并行。

做过数据管道（Flink DataStream / Kafka Streams）的话，你对这个模式再熟悉不过了。 一个 Source Operator → 三个 Transformation → 一个 Sink Operator，数据按确定性顺序流过每个算子。Chain 模式就是把这个思路搬到 Agent 世界。

状态管理策略

• 隐式传递：状态随数据流自然传递，不单独维护
• 无共享状态：每个 Agent 只处理当前输入，不需要访问其他 Agent 的状态
• 同步/异步混合：可以同步处理（等前一个 Agent 完成），也可以在 Agent 之间加队列做异步缓冲

容错设计

• 单个 Agent 挂了 → 从上游重放数据（类似 Flink 的 Checkpoint）
• 链中某个 Agent 处理失败 → 重试或进入补偿流程
• 整体吞吐受限于最慢的 Agent（瓶颈效应）
• 可以用 Kafka/Pulsar Topic 做 Agent 间的缓冲队列，解耦生产和消费速率

适用场景

✅ 处理流程是确定性的：数据清洗 → 特征提取 → 分类 → 输出 ✅ 每个步骤有明确输入输出：步骤之间耦合度低 ✅ 需要审计和可追溯性：每条数据经过的 Agent 路径是固定的

不适用场景

❌ 需要并行处理（Chain 本质是串行的） ❌ 需要 Agent 之间双向通信（Chain 是单向的） ❌ 链太长（超过 10 个 Agent）会导致延迟累积

真实案例

• 大多数 RAG Pipeline：Query Agent → Retrieval Agent → Rerank Agent → Generation Agent，就是标准的 Chain
• 企业审批流程：创建 Agent → 审批 Agent → 执行 Agent → 通知 Agent
• Flink DataStream 的直接映射：Source → Map → Filter → Sink

实战场景：四种模式怎么选？

场景化选择比理论更重要。来看几个真实场景，看看每种模式怎么落地。

场景一：智能客服系统

场景二：代码审查系统

场景三：企业 Agent 部署管理

场景四：多 Agent 协作研究

混合模式：现实世界的常态

在实际系统中，你很少会只用一种模式。大多数生产系统是混合的。

比如一个真实的电商 Agent 系统：

                    ┌──────────────────────┐
                    │   Orchestrator       │ (主入口)
                    │   (用户意图识别)      │
                    └──────────┬───────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
     ┌────▼────┐        ┌────▼────┐         ┌────▼────┐
     │ 搜索    │        │ 下单    │         │ 售后    │
     │ Supervisor│       │ Chain   │         │ P2P    │
     │ (管3个搜索│       │(检→付→发)│         │(多客服)  │
     │  Agent)  │        │         │         │         │
     └──────────┘        └─────────┘         └─────────┘

• 入口层：Orchestrator-Worker，由 Orchestrator 判断用户意图，路由到对应子系统
• 搜索域：Supervisor 管理多个搜索 Agent（商品搜索、价格比较、库存查询）
• 下单域：Chain 模式（下单检查 → 支付 → 发货通知）
• 售后域：Peer-to-Peer，多个客服 Agent 自由接单

这就是多 Agent 系统的真实面貌——不是选一种模式，而是用组合拳。

选择指南：一张决策树

需要全局可见性 + 顺序控制？
├── 是 → 子任务可并行？
│   ├── 是 → Orchestrator-Worker
│   └── 否 → 子任务有严格顺序？
│       ├── 是 → Chain
│       └── 否 → 需要混合
└── 否 → 系统规模 > 50 Agent？
    ├── 是 → Supervisor（分层管理）
    └── 否 → Agent 需要自由协作？
        ├── 是 → Peer-to-Peer
        └── 否 → Supervisor 或混合

写在最后

这篇文章我们从分布式系统工程的角度，拆解了四种基本的编排模式。每种模式都不是银弹，但理解它们的设计哲学——控制权如何分配、状态如何管理、错误如何恢复——能帮你在面对具体的多 Agent 系统设计时，做出有依据的选择，而不是靠直觉。

下一篇预告：通信层 — Agent 之间到底怎么「说话」？

当你确定了编排模式后，下一个问题就是：Agent 之间用什么协议？MCP 和 A2A 在架构中的角色是什么？同步 vs 异步怎么选？事件总线是否必要？

我会在第二篇中，从你的 MCPZERO 网关经验出发，讲清楚 Agent 通信层的架构设计。

📌 本系列连载： 一、编排模式 — 四种基本拓扑（本篇） 二、通信层 — Agent 通信架构选择 三、演进路径 — 从单 Agent 到多 Agent 四、未来范式 — Agent 即服务与 Agent Mesh