Harness

多 Agent 编排模式实战——6 种模式，挑一种现在就上路

目标读者：正在用 Agent 做日常开发，想从单 Agent 升级到多 Agent 但不知道怎么组织的开发者

一、我们先拆了内容流水线

我们刚把内容生产流水线拆成了四个 Agent：

• 研究 Agent：搜资料、读文档、提取关键模式
• 写作 Agent：笔记 → 文章初稿
• 审计 Agent：检查文章深度、事实准确性
• 发布 Agent：建页面、构建、部署、验证

四个 Agent 由我（Supervisor）统一协调。我定选题、拆任务、分派、聚合结果。

做了这件事之后，网站从 17 篇涨到 25 篇，我的总投入从"写一篇半天"降到了"定方向 5 分钟 + 审核 5 分钟"。

但这不是重点。重点是在拆的过程中，我开始认真思考一个问题：

当你手上的 Agent 从 1 个变成 N 个，你用什么方式把它们组织起来？

组织方式选错，Agent 越多越乱。选对，3 个 Agent 能干 10 个人的活。

这就像搭积木——搭法决定了你搭的是塔还是废墟。下面这 6 种搭法，是目前业界经过验证的主流方案。

---

二、6 种编排模式速览

先拉一张总表，心里有个全局：

模式	一句话	控制方式	状态管理	Agent 数量	适合场景
Supervisor-Worker	一个老板拆活大家干	集中调度	老板持有	1+N	确定性任务分解
Pipeline	上一人做完交给下一人	流水线	沿管道传递	链式串联	有明确工序的任务
Debate	几个专家各说各的再投票	辩论规则	共享议题	3-5	需要多视角分析的决策
Swarm	每人干自己的，谁有空谁接	无中心	分布式	动态弹性	不确定任务量的场景
Hierarchical	大老板下面有小老板，小老板下面有员工	树状递归	分层持有	树形多级	大规模复杂任务分解
StateGraph	你画一张图，Agent 按图走	有向图	全局状态	按图定义	需要精确控制执行流程

下面一个一个拆开看。

---

三、Supervisor-Worker——最直接、最常用

怎么用

用户：「写一篇关于 LangGraph 的文章」
    ↓
Supervisor（你当前用的 Hermes 主会话）
    ├── 研究 Agent：查 LangGraph 资料 → 整理关键点
    ├── 写作 Agent：根据研究结果写初稿
    ├── 审计 Agent：检查事实准确性和结构完整性
    └── 发布 Agent：构建页面 → 部署上线

做了什么

Supervisor 是唯一的决策中心。它负责：

• 理解任务（用户到底想要什么）
• 拆解子任务（这件事需要几步）
• 选 Worker（每个步骤交给谁做）
• 管理生命周期（超时怎么办、失败怎么重试）
• 聚合结果（把各 Worker 的产出拼成最终交付物）

Worker 之间不直接通信。一切通过 Supervisor 中转。

Key Design Dimensions

维度	我们的做法	优缺点
通信方式	Supervisor 中转	✅ 简单可靠，❌ 决策中心成为瓶颈
控制流	集中调度	✅ 清晰可控，❌ Supervisor 需处理所有细节
状态管理	Supervisor 持有	✅ 单一真相来源
Agent 数量	1 Supervisor + N Workers	N 受限于 Supervisor 的上下文窗口
终止条件	Supervisor 判断任务是否完成	✅ 人工可随时介入

最成功的案例：Klarna

Klarna 用 Supervisor-Worker 模式部署了 35 个 Agent，处理了 230 万次对话。

数据很具体：

• 35 个 Agent 覆盖客服、退款、订单查询等场景
• 每个 Agent 是一个专门的 Worker
• Supervisor 角色由路由层承担——识别意图后交给对应 Agent
• 2 个月处理 230 万次，相当于 700 名全职客服的工作量

这证明了 Supervisor-Worker 在确定性任务场景下的可扩展性——35 个 Agent 不是上限，只是一个实际跑通了的数字。路由和调度做得好，几百个 Worker 也是可能的。

Hermes 的实现方式

在 Hermes 里就是 delegate_task：

Supervisor 会话（当前对话）
    │  delegate_task("研究 RAG 的最新进展")
    ▼
Worker 子会话（独立终端）
    │  跑 web_search、读论文、写摘要
    ▼
返回结构化结果给 Supervisor

不需要额外的框架、不需要画图、不需要安装任何东西。就是在你的工具链里加一句 delegate_task 调用。

---

四、Pipeline——流水线拆得越细越快

什么时候用

Pipeline 和 Supervisor-Worker 的区别很简单：

• Supervisor-Worker：多个 Agent 做不同的事，结果拼在一起
• Pipeline：多个 Agent 做同一个过程的多个环节，结果传递

最典型的例子就是我们的内容生产流水线：

研究 → 写作 → 审计 → 发布

这不只是概念上的流水线——它就是我们的实际工作流。研究 Agent 产出素材，写作 Agent 接收素材产出初稿，审计 Agent 检查质量，发布 Agent 上线。

对比 Supervisor-Worker

对比维度	Supervisor-Worker	Pipeline
任务性质	并行/独立子任务	串行/递进工序
数据流	各 Worker 返回 Supervisor	前一步输出是下一步输入
失败影响	只影响一个 Worker	后面全部卡住
并行度	高（各 Worker 独立跑）	低（必须等前一步）
适用复杂度	中高	中

两种变体

1. 严格流水线： 上一步处理完数据→传递给下一步。像工厂传送带，每个环节完成后再移动到下一站。适用于数据加工、文档审批等场景。

2. 并行流水线： 上一步完成后，同时通知多个下游 Agent 执行不同的任务。像广播——研究完成后，写作和审计同时开始（但审计审的是初稿，所以一般还是写作先完成）。

陷阱

Pipeline 的最大问题是效率取决于最慢的一环。如果审计 Agent 写一篇审一篇，而写作 Agent 写两篇审才审一篇，那流水线就堵在审计这里。

解决方案：批处理缓冲——写作 Agent 产出多篇后，审计 Agent 一次性审完。

---

五、Debate——让 Agent 吵起来

什么时候用

当你面对一个决策，自己拿不准的时候。

比如判断"这个方案应该选 A 还是 B"，你让多个 Agent 分别站在不同立场分析：

Agent 1（保守派）：
    "选 A，因为风险可控，已有成熟方案。"

Agent 2（激进派）：
    "选 B，因为虽然风险大，但长期收益是 10 倍。"

Agent 3（成本派）：
    "选 A，B 的前期投入太大，我们的资源不够。"

Agent 4（机会派）：
    "选 B，A 的市场窗口已经过了，不创新就是等死。"

你（或者一个判官 Agent）听完四个立场，再做决策。

使用前提

Debate 模式有效的条件是：Agent 有自己的角度和判断标准。如果四个 Agent 看问题的方式都一样，辩论就变成了"同一个观点的四遍复述"。

所以好的 Debate 模式会给每个 Agent 分配不同的角色和 prompt。不是问"你怎么看"，而是说"你是一个生存优先的创业者，你怎么选"。

对比其他模式

对比维度	Debate	其他模式
输出	一个决策/判断	一个产物/行动
成功条件	Agent 有差异化角度	Agent 准确完成任务
失败模式	四个 Agent 看法一样 → 没意义	单个出错导致全链失败
典型 Agent 数	3-5 个	1-N 个

不适合做什么

Debate 不适合产出型任务——让三个 Agent 辩论"第一段怎么写"，大概率写出四不像。它适合的是判断型任务：风险评估、方案选型、策略决策。

---

六、Swarm——去中心化的蚂蚁

什么时候用

当任务量不确定、任务类型不可预测的时候。

Swarm 没有 Supervisor。每个 Agent 独立运行，各有各的技能。有任务来了，谁有空谁认领。

任务队列
    ├── Agent A（擅长搜索）→ 在空闲中，认领搜索任务
    ├── Agent B（擅长写作）→ 忙，跳过
    ├── Agent C（擅长审计）→ 空闲，认领审计任务
    └── Agent D（擅长搜索）→ 空闲，认领另一个搜索任务

和 Supervisor-Worker 的区别

对比维度	Supervisor-Worker	Swarm
调度中心	有	无
Agent 角色	预分配	动态认领
扩展性	受限于 Supervisor 能力	理论无限扩展
可观测性	高（所有决策可追溯）	低（谁做了什么难追踪）
实现复杂度	低	高

真实案例

Google 的 Agent2Agent (A2A) 协议就是为 Swarm 模式设计的——Agent 之间通过标准协议发现彼此、协商任务、交换结果。每个 Agent 都是独立的个体，没有中心调度。

但坦率说，Swarm 模式在企业落地场景里是最少见的。它适合：

• 大规模爬虫/监控集群
• 客服机器人池（谁空闲谁接单）
• 社区驱动的插件生态系统

如果是 10 个以内的 Agent 团队，Supervisor-Worker 或 Pipeline 通常就够了。Swarm 多出来的复杂度，10 个 Agent 以下体会不到好处。

---

七、Hierarchical——递归套娃

什么时候用

当你的任务大到连 Supervisor 都管不过来的时候。

Hierarchical 模式就是把 Supervisor 递归化：

CEO Agent
    ├── 部门经理 Agent A
    │   ├── 员工 Agent A1
    │   └── 员工 Agent A2
    ├── 部门经理 Agent B
    │   ├── 员工 Agent B1
    │   └── 员工 Agent B2
    └── 部门经理 Agent C
        └── 员工 Agent C1

CEO 只跟部门经理对话。每个部门经理管理自己的 Worker 团队。

什么时候真的需要

不是任务大了就需要分层。判断标准很简单：

如果 Supervisor 的上下文窗口已经被 N 个 Worker 撑爆了，就需要分层。

Hermes 的 delegate_task 已经在帮我们做这件事了——每个 Worker 是一个独立的会话，有自己的上下文窗口。但如果你有几十个 Worker 同时跑，Supervisor 光看结果摘要就会被撑爆。这时候就需要中间层 Manager Agent 来聚合。

模式和复杂度

Hierarchical 和 Supervisor-Worker 不是互斥的。Hierarchical 是在 Supervisor-Worker 上再包一层，形成一个树状结构。

层级	模式	复杂度
1 层	Supervisor-Worker	几行 delegate_task
2 层	部门经理 + 团队	需要 Manager Agent 逻辑
3 层	区域性层级	每个区域有自己的 Manager
N 层	理论无上限	每多一层，通信和状态管理复杂度指数级上升

2 层以上请三思——不是做不了，而是你需要回答"我是不是真的需要这么多层"。

---

八、StateGraph——把流程画成图

什么时候用

当你的 Agent 流程不是线性的，而是充满条件分支和循环的时候。

        用户输入
            ↓
     ┌────────────┐
     │  信息分析   │
     └─────┬──────┘
           │
      信息足够吗？
      ┌──┴──┐
    是│     │否
      ▼     ▼
  ┌──────┐ ┌────────┐
  │ 生成  │ │ 补充查询│
  │ 回答  │ └───┬────┘
  └──┬───┘     │
     │         │
     └────┬────┘
          ▼
      ┌────────┐
      │ 输出   │
      └────────┘

这是 LangGraph 的核心模型——StateGraph（状态图）。

StateGraph 三要素

LangGraph 的 StateGraph 由三部分组成：

1. State（状态）——全局共享的数据对象

{
    "messages": [...],        // 消息历史
    "current_input": "...",   // 当前输入
    "intermediate_results": {...},  // 中间结果
    "status": "running"       // 状态标志
}

State 在节点间传递，可以被任何节点读取和修改。

2. Node（节点）——执行一个函数

Node("analyze", analyze_function)
Node("search", search_function)
Node("generate", generate_function)

每个节点是 Agent 的一步操作——查资料、做分析、写回答。

3. Edge（边）——控制流向

Edge("analyze", "search", condition=information_missing)
Edge("analyze", "generate", condition=information_sufficient)

边可以是有条件的（条件边）——"如果信息不够，就跳到搜索，否则直接生成"。

和传统流程图的关系

StateGraph 本质上就是一个有向图：

• 流程图里的方框 = StateGraph 的 Node
• 流程图里的箭头 = StateGraph 的 Edge
• 流程图里的决策菱形 = StateGraph 的条件边

核心区别只有一个：图是可以持久化和恢复的——节点跑了一半系统崩了，重启后从上次中断的地方继续，不需要全部重来。

和其他模式的映射

读到这里你会发现：前面讲的 5 种模式，其实都可以用 StateGraph 表达。

模式	在 StateGraph 里的表达
Supervisor-Worker	1 个路由 Node → N 个 Worker Node → 1 个聚合 Node
Pipeline	按顺序连接的 Node 链
Debate	N 个并行 Node → 1 个决策 Node
Swarm	动态添加/删除 Node
Hierarchical	子图嵌套（一个 Node 内部是另一个 StateGraph）

StateGraph 不是第 6 种模式，而是所有模式的底层建模工具。

LangGraph 和我们的关系

回到现实：我们用 LangGraph 吗？

目前不用。 我们用 Hermes 的 delegate_task 就能实现同样的效果：

我们的做法	对应 StateGraph 概念
Supervisor	StateGraph（持有全局状态）
delegate_task	Node（执行一个子任务）
顺序写代码	Edge（定义执行顺序）
if-then-else 分支	条件边
回调结果检查	条件判断 + 重试

LangGraph 的价值在于：

• 状态持久化——进程重启后恢复执行
• 人机回路——在任意节点插入人工审核
• 可视化——LangSmith 可以展示图执行情况

这些在企业级场景（运行几小时甚至几天的长流程）中很有价值。但对我们当前的场景——一篇文章 15 分钟就能写完——delegate_task 已经足够了。

---

九、关键设计维度

不管选哪种模式，都要考虑五个维度：

1. 通信方式

方式	描述	适用场景
Supervisor 中转	全部通过中心 Agent 转发	5 个以下 Agent
共享存储	Agent 读写同一份状态	需要全局上下文
消息队列	异步发布/订阅	Swarm 模式
协议通信	A2A/MCP 标准协议	跨系统协作

经验： 5 个 Agent 以内，Supervisor 中转足够了。消息队列和协议通信增加的复杂度，小场景根本用不上。

2. 控制流

方式	描述	典型模式
集中调度	一个中心控制执行顺序	Supervisor-Worker
流水线	固定的执行链	Pipeline
条件分支	根据中间结果动态选择路径	StateGraph
无中心	每个 Agent 自主决策	Swarm

3. 状态管理

这是最容易犯错的维度。状态放在哪里、怎么传递、出错后怎么恢复，决定了你的多 Agent 系统是稳定的还是脆弱的。

方式	风险	推荐场景
Agent 各自持有	数据不一致	小规模探索
中心持有	单点故障	大多数场景
数据库持久化	需要运维	生产环境
事件日志重放	实现复杂	金融/合规场景

4. Agent 数量

• 1-3 个：简单的 Supervisor-Worker 或 Pipeline
• 3-10 个：需要明确的状态管理，考虑引入路由
• 10-50 个：分层或专用调度器
• 50+：消息队列 + 弹性扩容，参考 Klarna 模式

5. 终止条件

不是所有 Agent 任务都能明确结束。你需要定义：

• 什么时候任务算"完成"？（Supervisor 判断所有子任务返回结果）
• 什么时候算"失败"？（超时/N 次重试后）
• 什么时候需要人工介入？（关键决策/不确定情况）

---

十、从今天可以做的三件事

读完全文，你不需要学会所有 6 种模式。从这三件事开始就行：

1. 把你的一个手工行为拆成两个 Agent

不要一开始就想搞 5 个 Agent。拿出你今天最常做的一件事（比如写文章、修 bug、做调研），拆成两步：

改之前：做调研 + 写总结（你自己干完）
改之后：
├── Agent 1：做调研（搜资料、整理观点）
└── Agent 2：根据调研写总结（写好你审）

你只多了一个 Agent，但做了最关键的改变——让研究和写作解耦。这看起来简单，但这是从单 Agent 到多 Agent 最重要的一步。

2. 明确你的通信方式

无论你选哪种编排模式，先把通信规则定下来：

规则 1：Worker 之间不直接通信
规则 2：所有结果回到 Supervisor
规则 3：Supervisor 只做拆解和聚合，不做执行

三个规则足够覆盖 80% 的场景。等你遇到规则不够用的时候，你已经不是初学者了。

3. 拒绝架构溢出

这句话我写给自己，也写给你：

不要因为你听说过 LangGraph 就去用 LangGraph，而是因为用 delegate_task 搞不定才去学 LangGraph。

Klarna 用 Supervisor-Worker 跑了 35 个 Agent 处理 230 万次对话。如果 35 个 Agent 都能用最"朴素"的模式跑通，那你的 3 个 Agent 需要的可能只是几行 delegate_task。

---

十一、最后说两句

我把 6 种模式全写出来了，不是因为你要全部掌握。

是因为：

你知道有 6 种选项，和只知道 1 种（甚至不知道这是在做选择），做出的系统是完全不同的。

• 知道 Pipeline 模式的人，把内容流水线拆成 Agent 链路只花了 10 分钟思考。
• 知道 Swarm 模式的人，能判断"我的场景需不需要消息队列"。
• 知道 StateGraph 模式的人，能用 delegate_task 做出类似的效果而不引入新框架。

多 Agent 编排不在乎你会多少框架。在乎你选择模式的时候，心里清楚"为什么是它，而不是别的"。

---

参考

• LangGraph 官方文档