# 16.2 多智能体协作与编排模式

本节讲清在 OpenClaw 中如何用多个智能体协同完成复杂任务。当前官方语义里，多智能体的核心不是“Node 级路由”，而是 **`agentId`、`accountId` 与 `bindings`** 三个原语：每个 `agentId` 代表一套独立的工作区、认证档案和会话存储；每个 `accountId` 代表某个渠道上的一个账号实例；`bindings` 负责把进入 Gateway 的消息确定性路由到目标智能体。人格、长期边界和团队规则主要沉淀在各自工作区文件（如 `AGENTS.md`、`SOUL.md`、`USER.md`）里，而不是依赖单个内联 `systemPrompt` 字段。

> **澄清**：Anthropic 提供了 Agent SDK（原 Claude Code SDK），用于构建自定义智能体应用。本节不讨论 Agent SDK 本身的用法，而是聚焦 OpenClaw 原生的多智能体配置与协作模式。如需了解 Agent SDK，请参见 [Anthropic 官方文档](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/sdk)。

***

## 16.2.1 多智能体的架构选择

在 OpenClaw 中实现多智能体协作，最常见的是两条路径：

| 路径                 | 机制                                                          | 适用场景                 |
| ------------------ | ----------------------------------------------------------- | -------------------- |
| **绑定路由（Bindings）** | Gateway 根据 `channel/accountId/peer` 等匹配规则把消息路由到不同 `agentId` | 业务域隔离、多账号承载、不同渠道人格分流 |
| **Agent 级委托**      | 主 Agent 将子任务交给其他 Agent 或外部能力处理                              | 任务分解、专家协作、质量校验       |

两者可以组合使用：Gateway 先用 `bindings` 把请求送到合适的业务智能体，业务智能体再把细分任务委托给其他专家智能体或工具。

## 16.2.2 通过 bindings 实现多智能体分工

最简单的多智能体模式是通过 `agents.list` 和 `bindings` 实现业务分工。每个 Agent 使用独立工作区和会话存储，Gateway 根据渠道账号、会话对端或群组等条件将消息路由到对应 Agent：

```jsonc
{
  agents: {
    list: [
      {
        id: "support",
        default: true,
        name: "Support",
        workspace: "~/.openclaw/workspace-support",
        agentDir: "~/.openclaw/agents/support/agent",
        model: { primary: "anthropic/claude-haiku-4-5" },
      },
      {
        id: "ops",
        name: "Ops",
        workspace: "~/.openclaw/workspace-ops",
        agentDir: "~/.openclaw/agents/ops/agent",
        model: { primary: "anthropic/claude-sonnet-4-6" },
      },
      {
        id: "analyst",
        name: "Analyst",
        workspace: "~/.openclaw/workspace-analyst",
        agentDir: "~/.openclaw/agents/analyst/agent",
        model: { primary: "anthropic/claude-opus-4-6" },
      },
    ],
  },
  bindings: [
    { agentId: "support", match: { channel: "whatsapp", accountId: "support" } },
    { agentId: "ops", match: { channel: "telegram", accountId: "ops" } },
    {
      agentId: "analyst",
      match: {
        channel: "discord",
        peer: { kind: "group", id: "123456789012345678" },
      },
    },
  ],
  channels: {
    whatsapp: {
      accounts: {
        support: {},
      },
    },
    telegram: {
      accounts: {
        ops: {
          botToken: "${TELEGRAM_BOT_TOKEN_OPS}",
        },
      },
    },
  },
}
```

> **注意**：当前多智能体配置强调“每个 Agent 一套工作区文件和状态目录”。像客服语气、运维边界、分析报告模板这类差异，推荐分别写进各自工作区的 `AGENTS.md`、`SOUL.md`、`USER.md`，而不是把所有人格差异都塞进同一段内联提示词。

路由规则由 `bindings` 定义，按 `channel`、`accountId`、`peer`、`guildId`、`teamId` 等维度做确定性匹配。多账号与绑定规则的完整细节见 [第七章多渠道分发](https://yeasy.gitbook.io/openclaw_guide/di-er-bu-fen-jin-jie-shi-yong/07_multi_agent)。

## 16.2.3 三种协作编排模式

当任务复杂到单个 Agent 无法独立完成时，需要多 Agent 协作。以下三种模式覆盖了大多数生产场景：

### 模式一：串联（顺序委托）

前一个 Agent 的输出作为后一个 Agent 的输入，适用于有明确前后依赖的流水线。

{% @mermaid/diagram content="graph LR
User\["用户请求"] --> A1\["协调 Agent<br/>任务分解"]
A1 --> A2\["分析 Agent<br/>数据处理"]
A2 --> A3\["校验 Agent<br/>质量检查"]
A3 --> Result\["最终结果"]" %}

图 16-1：串联协作模式

典型场景：用户提交研究请求 → 协调 Agent 分解为子任务 → 分析 Agent 执行数据分析 → 校验 Agent 检查结果质量 → 返回最终报告。

实现方式：协调 Agent 的工具列表中包含一个“委托”工具（如 `agent.delegate`），通过该工具向指定 Agent 发送子任务并等待结果。

### 模式二：并联（同步扇出）

多个 Agent 同时处理独立的子任务，最后汇聚结果。适用于子任务之间没有依赖的场景。

{% @mermaid/diagram content="graph TD
User\["用户请求"] --> Coord\["协调 Agent"]
Coord --> A1\["Agent A<br/>市场分析"]
Coord --> A2\["Agent B<br/>技术评估"]
Coord --> A3\["Agent C<br/>成本测算"]
A1 --> Merge\["协调 Agent<br/>汇聚结论"]
A2 --> Merge
A3 --> Merge
Merge --> Result\["综合报告"]" %}

图 16-2：并联协作模式（扇出-汇聚）

典型场景：评估一个技术方案 → 同时从市场、技术、成本三个角度分析 → 汇总为综合评估报告。

### 模式三：路由分发（入口分类 + 专家转接）

根据请求内容动态选择最合适的专家 Agent 处理，类似于“智能前台”。与 `bindings` 负责的静态入口分发不同，这一步发生在某个入口 Agent 已经接住请求之后，由它再决定是否把任务转给更专业的 Agent。

实现方式：入口 Agent 使用轻量模型（如 Haiku）快速分类请求意图，然后将任务转交给对应的专家 Agent。这种模式的好处是路由策略可以随对话上下文动态调整，而不受静态入口绑定的限制。

## 16.2.4 Agent 委托的工程约束

多 Agent 协作在工程上需要注意以下约束：

**Token 预算控制**：每次 Agent 委托都会消耗额外的 token（子 Agent 需要接收完整的上下文）。深层嵌套委托会导致 token 成本指数增长。建议委托深度不超过 2 层，并在协调 Agent 的提示词中明确指定“不要进一步委托”。

**超时与中断**：子 Agent 的执行时间可能较长（特别是涉及工具调用时）。需要为委托设置合理的超时，并处理超时后的降级策略（如返回部分结果或提示用户稍后查看）。超时配置与 Agent Loop 的工具执行机制相关，详见 [10.5](https://yeasy.gitbook.io/openclaw_guide/di-san-bu-fen-shi-xian-yuan-li-yu-gong-cheng-luo-di/10_agent_loop/10.5_tool_execution)。

**上下文传递**：委托时传递给子 Agent 的上下文应精简到必要信息，避免将完整对话历史传入。过大的上下文不仅浪费 token，还可能导致子 Agent 偏离指定任务。

**审计追溯**：每次 Agent 委托应在审计日志中记录委托链路（谁委托了谁、传入什么任务、返回什么结果），便于故障排查和成本归因。这与 [9.2.3](https://yeasy.gitbook.io/openclaw_guide/di-san-bu-fen-shi-xian-yuan-li-yu-gong-cheng-luo-di/09_gateway_protocol/9.2_control_plane) 的证据链要求一致。

## 16.2.5 与 Claude Agent SDK 的互补关系

Anthropic 的 Agent SDK 和 OpenClaw 的多智能体机制解决的是不同层面的问题：

| 维度       | OpenClaw 多智能体                     | Claude Agent SDK         |
| -------- | --------------------------------- | ------------------------ |
| **定位**   | 运行平台：管理 Agent 的生命周期、路由、连接、安全      | 开发框架：定义 Agent 的行为逻辑和编排规则 |
| **模型绑定** | 多供应商（Anthropic、OpenAI、Moonshot 等） | 仅 Claude 模型              |
| **部署形态** | Gateway + Agent Runtime 长驻进程      | 嵌入应用代码，按需启动              |
| **工具管理** | Tool Policy + 沙箱 + MCP            | MCP 原生支持                 |
| **适用场景** | 需要多渠道接入、安全管控、持久会话的生产系统            | 需要精细编排逻辑的独立应用            |

在实际项目中，两者可以互补：用 Agent SDK 开发复杂的编排逻辑，然后将其作为 OpenClaw 的一个 Agent 或 MCP 服务器接入，借助 OpenClaw 的渠道接入、安全审批和会话管理能力服务终端用户。

***