很多团队把 Agent 做到第二阶段都会遇到同一个问题：

  • 单个 Agent 已经不够用，要拆“角色分工”。

  • 一台机器放不下所有任务，要跨多台主机部署。

  • 代理之间需要通信协作，但又不能互相污染上下文。

这篇文章基于 OpenClaw 官方文档，系统讲清三件事：单机多 Agent 怎么搭、多 OpenClaw 主机怎么协作、代理间如何通信才稳定可控。

1. 先统一心智模型：OpenClaw 的多 Agent 不是“多人格提示词”

在 OpenClaw 里，一个 agent 本质是一个“完整隔离单元”，它拥有自己的：

  • workspace（包括 AGENTS.md/SOUL.md/USER.md 与本地文件上下文）

  • agentDir（认证与 agent 级状态）

  • sessions（会话与路由状态）

所以“多 Agent”是工程级隔离，而不是同一上下文里改几段提示词。

2. 单机多 Agent：推荐的标准架构

先给结论：一个 Gateway + 多个 agent + 显式 bindings 路由 是官方推荐范式。

2.1 架构骨架

  • 一台主机只跑一个 Gateway（官方架构约束）。

  • Gateway 持有所有渠道连接（Telegram/WhatsApp/Slack/…）。

  • 通过 bindings 把不同 channel/account/peer 的入站消息，确定性路由到不同 agent。

  • 每个 agent 使用独立 workspace 和 agentDir，避免认证与会话冲突。

2.2 最小配置示例（单机多 Agent）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "agents": {
    "list": [
      {
        "id": "assistant",
        "default": true,
        "workspace": "~/.openclaw/workspace-assistant",
        "agentDir": "~/.openclaw/agents/assistant/agent"
      },
      {
        "id": "research",
        "workspace": "~/.openclaw/workspace-research",
        "agentDir": "~/.openclaw/agents/research/agent"
      }
    ]
  },
  "bindings": [
    {
      "agentId": "research",
      "match": {
        "channel": "telegram",
        "peer": { "kind": "direct", "id": "tg:123456789" }
      }
    },
    {
      "agentId": "assistant",
      "match": { "channel": "telegram" }
    }
  ]
}

2.3 单机模式下的通信方式

同一 Gateway 内，agent 间协作优先走 session 工具：

  • sessions_send：向另一个 session 发消息并等待结果（可超时控制）。

  • sessions_spawn：派生隔离子代理执行长任务，完成后回传摘要。

这两类通信在同一 Gateway 内是“内生通信”，上下文边界更清晰、可追踪性更好。

3. 多 OpenClaw 主机：现实可用的 3 种协作拓扑

这里最容易误解：OpenClaw 官方当前核心是“单 Gateway 控制面”。跨主机协作不是默认内建成“跨 Gateway 透明 RPC”。

所以工程上要用“桥接层”把多主机连起来。

3.1 拓扑 A：渠道桥接（推荐起步）

  • Host-A 的 agent 通过消息渠道（如 Telegram Bot/群）发任务。

  • Host-B 作为另一个 OpenClaw 实例在同渠道接收并处理。

  • 处理结果再通过渠道回发到 Host-A 或人工会话。

优点：部署快，稳定性高，几乎不用改 OpenClaw 内核。

3.2 拓扑 B：Webhook / Hook 事件桥接

  • Host-A 将任务打包成结构化事件（JSON）投递给 Host-B 的接收端。

  • Host-B 的 Hook/入口会话消费事件并触发 agent 执行。

  • 回传可走 webhook 回调或消息渠道。

优点：便于与现有后端系统集成，适合平台化。

3.3 拓扑 C：外部任务总线桥接（企业场景）

  • 两台 OpenClaw 通过外部队列/任务系统（如 Redis Streams、Kafka、SQS）解耦。

  • OpenClaw 只做“智能执行器”，任务编排交给外部工作流层。

优点：吞吐与治理能力最好，但实施复杂度最高。

4. 代理间通信与协作：建议采用“分层协议”

4.1 协作协议（建议）

  • 控制消息：任务编号、优先级、超时、重试策略。

  • 业务消息：输入参数、上下文摘要、期望输出格式。

  • 回执消息：状态（accepted/running/done/failed）、结果摘要、错误分类。

4.2 角色分工（建议）

  • Orchestrator Agent：接任务、拆解、派发、汇总。

  • Worker Agent：按契约执行单一子任务。

  • Reviewer Agent：做一致性检查与质量门禁。

4.3 三条硬规则

  • 幂等键：每个任务都要有业务 id，重复投递可安全去重。

  • 超时与降级：sessions_send/外部桥接必须有 timeout 与 fallback。

  • 上下文最小化：跨代理只传“必要上下文 + 结构化结果”，不要整段历史硬转发。

5. 实操中的常见坑

  • 把多个 agent 复用同一个 agentDir，导致认证/会话冲突。

  • bindings 规则不够具体，出现“路由命中漂移”。

  • 把跨主机协作当成同机 sessions_send，结果通信链路设计不完整。

  • 没有幂等，重试时重复执行副作用（重复发消息/重复写库）。

  • 没有统一状态模型，排障时看不到“任务卡在哪一跳”。

6. 给团队的落地建议（从 0 到 1）

  • 第一步：先在单机把“多 Agent + bindings + sessions_spawn”跑顺。

  • 第二步：引入一种跨主机桥接（先渠道桥接，再升级 webhook/队列）。

  • 第三步：补齐治理（幂等、重试、审计、告警、权限边界）。

这样做的好处是：每一步都可验证，不会把复杂度一次性打满。

7. 总结

OpenClaw 的多 Agent 架构要点可以压缩成一句话：

同机协作用 Gateway 内生会话工具，跨机协作用外部桥接层；隔离、路由、幂等是稳定性的三根柱子。

如果你正在做多代理系统，不要先追求“最智能”，先把“能稳定协作”做出来。

参考资料（权威来源）