OpenClaw 多 Agent 协作怎么配？从角色拆分、消息路由到 Sub-Agent 并行编排，一篇讲透

很多人一听"多 Agent 协作"，第一反应就是： 是不是要搞得特别复杂？是不是要配一堆机器人？是不是得像搭微服务一样折腾半天？

本文侧重点（第二篇）：OpenClaw 多 Agent 协作的进阶配置与实战技巧，涵盖 Sub-Agent 并行编排。本文适合已掌握基础配置的用户，深入讲解复杂场景。如需回顾基础概念，请参考 OpenClaw 多 Agent 协作配置指南（第一篇）。

其实不是。

OpenClaw 官方对多 Agent 的定义非常清楚：它的目标不是把一个助手拆成一团混乱的分身，而是在同一个 Gateway 里运行多个彼此隔离的 agent，每个 agent 有自己的 workspace、自己的 agentDir、自己的会话存储，然后再通过 bindings 把不同来源的消息路由到对应 agent。换句话说，多 Agent 协作的核心不是"数量"，而是分工 + 隔离 + 路由。

这篇文章就按最适合小白听懂的方式讲： 你为什么要配多 Agent，OpenClaw 里的"一个 agent"到底是什么，最基础的配置怎么做，消息怎么路由，什么时候该用 Sub-Agent，什么时候又不该乱上多 Agent，以及最容易踩的坑到底有哪些。所有关键点，都尽量按官方当前文档来讲。\n\n## 二、多 Agent 与平台选择的关系\n\n在配置多 Agent 之前，你需要先了解 OpenClaw 在不同操作系统上的差异。Linux、macOS 和 Windows 在 Gateway 管理、权限模型、服务启动方式等方面都有显著不同，这些差异会直接影响多 Agent 的部署策略。\n\n关于 OpenClaw 在 Linux、macOS、Windows 三大平台上的详细差异和坑点，请参考OpenClaw 平台差异完整指南。\n\n

一、先把最重要的概念想明白：OpenClaw 里的"一个 Agent"到底是什么？

很多新手会把 agent 理解成"一个聊天窗口"或者"一个模型选项"。 这理解太浅了。

OpenClaw 官方对一个 agent 的定义是：一个完全隔离的"脑子"。它至少拥有三样独立的东西：

• 自己的 workspace，里面放文件、AGENTS.md、SOUL.md、USER.md、本地笔记和人格规则。
• 自己的 state directory（agentDir），这里保存认证配置、模型注册表和按 agent 生效的配置。
• 自己的 session store，默认在 ~/.openclaw/agents/<agentId>/sessions，保存聊天历史和路由状态。

最容易忽略、但最致命的一条是：auth profiles 是按 agent 隔离的。官方明确写了，每个 agent 从自己的 ~/.openclaw/agents/<agentId>/agent/auth-profiles.json 读取认证信息；不要在不同 agent 之间复用同一个 agentDir，否则会引发认证和 session 冲突。真要共享认证，应该复制 auth-profiles.json 到另一个 agent 的 agentDir，而不是共用目录。

这句话你一定要记住：

多 Agent 不是"一个助手换几个名字"，而是"几个彼此隔离的助手，各自有各自的脑子和抽屉"。

三、什么时候你才真的需要多 Agent？

不是所有人都要一上来就配多 Agent。 很多人一个 main agent 就够了。

OpenClaw 官方文档给出的多 Agent 场景，更适合下面这些需求：

1）角色真的不一样

比如你想要：

• 一个 工作助手，负责 Slack、邮件、任务整理
• 一个 家庭助手，只负责消息提醒和生活安排
• 一个 技术助手，专门在代码目录里工作
• 一个 内容助手，只负责写作和资料整理

这种情况下，把它们塞进一个 agent 里，迟早会互相污染。一个 agent 的 workspace、会话和认证都是混在一起的，多了以后很容易乱。OpenClaw 官方的多 Agent 路由文档和多 Agent sandbox 文档，都把"personal + family"或"work + restricted family"作为典型例子。

2）安全边界不一样

比如：

• 主 agent 可以读写、跑命令
• 家庭 agent 只能读，不能写，不能执行 shell
• 某个对外回复 agent 只允许消息和搜索，不允许碰本地文件

OpenClaw 官方明确支持按 agent 覆盖全局 sandbox 和 tool policy。也就是说，不同 agent 可以有不同的工具许可和沙箱策略。

3）消息入口不一样

比如：

• Telegram 上来的消息走 ops agent
• Slack 某个 team 的消息走 support agent
• 某个特定群组走 family agent

OpenClaw 官方把这个叫 bindings：用匹配规则把 inbound message 路由到指定 agent。

4）组织级代理，而不是个人助手

如果你已经不是"我自己一个人用"，而是想让某个代理助手以自己的身份在组织里工作，比如代理收信、代理发信、代理排日程，那就更接近官方文档里的 Delegate Architecture。这其实也是多 Agent 路由向组织场景的延伸。

四、最基础的多 Agent 配法：先别想复杂，先把两个 agent 跑通

OpenClaw 官方 CLI 已经把最基础的多 Agent 管理做成了现成命令。常见命令包括：

openclaw agents list
openclaw agents list --bindings
openclaw agents add work --workspace ~/.openclaw/workspace-work
openclaw agents add ops --workspace ~/.openclaw/workspace-ops --bind telegram:ops --non-interactive
openclaw agents bindings
openclaw agents bind --agent work --bind telegram:ops
openclaw agents unbind --agent work --bind telegram:ops

这些命令的作用非常直观： 先创建 agent，再查看已有绑定，再把某个渠道/账号绑定给某个 agent。

最适合新手的第一步

别一上来建五六个。 先建两个就够：

• main：保留主助手
• work：专门干工作相关的事

例如：

openclaw agents add work --workspace ~/.openclaw/workspace-work

这一步做完以后，work 就会有：

• 独立 workspace
• 独立 agentDir
• 独立 sessions
• 独立 auth store 路径（如果你后面给它配认证）

然后你再决定：哪些消息进 main，哪些进 work。

五、消息到底是怎么路由到不同 Agent 的？

这一步是多 Agent 协作的核心。

OpenClaw 官方 Channel Routing 文档写得非常清楚： 一条入站消息进来以后，系统会按一套优先级规则选出一个 agent。顺序大致是：

1. 精确 peer 匹配
2. 父级 peer / thread 继承
3. Discord 的 guild + roles
4. Discord 的 guild
5. Slack 的 team
6. accountId
7. channel 级匹配
8. 默认 agent（agents.list[].default，否则第一个列表项，最后回退到 main）

这句话翻译成人话就是：

谁来处理一条消息，不是拍脑袋，而是按绑定规则层层匹配出来的。

最简单的配置思路

如果你现在不是做很复杂的 Discord/Slack 组织配置，最实用的就是从两类绑定开始：

1）按渠道账号分

比如 Telegram 的某个 bot 交给 work agent。

2）按具体群/具体对话分

比如某个 Telegram 群组、某个 Slack team、某个 Discord guild，直接绑定给某个 agent。

官方还给了一个非常直白的配置例子：

{
  "agents": {
    "list": [
      {
        "id": "support",
        "name": "Support",
        "workspace": "~/.openclaw/workspace-support"
      }
    ]
  },
  "bindings": [
    { "match": { "channel": "slack", "teamId": "T123" }, "agentId": "support" },
    { "match": { "channel": "telegram", "peer": { "kind": "group", "id": "-100123" } }, "agentId": "support" }
  ]
}

意思很简单： Slack 某个团队和 Telegram 某个群，都丢给 support 这个 agent 去处理。

六、一个特别容易踩的坑：默认 DM 会共享会话，多人使用时要先做隔离

这一步很多人一开始不会意识到，但它很重要。

OpenClaw 官方 Session Management 文档明确写了： 默认情况下，所有私聊可能共享一个主 session，这对单用户设置没问题；但如果有多个人都能私聊你的 agent，就可能出现上下文串线。官方给出的修法是启用 DM isolation，例如：

{
  "session": {
    "dmScope": "per-channel-peer"
  }
}

可选值里，main 是默认共用，per-peer 按发送者隔离，per-channel-peer 按渠道 + 发送者隔离，而且官方明确推荐多人使用时优先考虑这个方案。

这对多 Agent 协作尤其重要。 因为很多人以为"我都分了 agent 了，就不会串"。 其实不一定。

如果你的 DM scope 还在共享模式，多个人来找同一个 agent，依旧可能共享上下文。 所以当你从"我自己玩"走向"多人使用"时，dmScope 几乎是必修项。

七、多 Agent 不只是"多个 agent 各干各的"，还可以"同一条消息让多个 agent 一起看"

这里要讲一个很多人会忽略，但很强的能力：Broadcast Groups。

OpenClaw 官方文档说明，Broadcast Groups 允许多个 agent 同时处理同一条消息。当前范围主要是 WhatsApp web channel，而且状态标为 Experimental。官方给出的例子非常典型：

• 一个开发群里同时让 CodeReviewer、DocumentationBot、SecurityAuditor、TestGenerator 一起看同一条消息
• 一个国际支持群里同时让不同语言 agent 回答
• 一个支持 agent 负责主答，另一个 QA agent 只在发现问题时补充回应

示例配置长这样：

{
  "broadcast": {
    "strategy": "parallel",
    "120363403215116621@g.us": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"]
  }
}

这套能力和普通 bindings 的区别在于：

• 普通 bindings：一条消息只选一个 agent
• broadcast groups：一条消息可以让多个 agent 同时跑

但我要提醒你： 这能力虽然很酷，不适合新手上来就用。因为它更像团队协作场景，不像最基础的"分工路由"。

八、Sub-Agent 和"多 Agent 路由"不是一回事，别混了

这是很多人第一次接触 OpenClaw 多 Agent 时最容易搞混的一点。

多 Agent Routing 是什么？

它是静态角色分工。 也就是：

• 不同 agent 有不同 workspace / auth / session / 工具策略
• 不同来源的消息被路由给不同 agent 处理

Sub-Agents 又是什么？

官方文档定义得非常明确：Sub-Agents 是从一个已有 agent run 中临时派生出来的后台 agent 运行。它们在自己的 session 里跑，结束后再把结果回传给请求者所在的聊天渠道。它们会作为 background task 被跟踪，还支持 /subagents list、/subagents kill、/subagents log、/subagents spawn 等命令。

比如：

/subagents spawn <agentId> <task> [--model <model>] [--thinking <level>]

这条命令的意思，不是"给系统长期加一个新 agent"，而是临时拉一个后台 agent 去并行处理某项任务。

小白怎么区分最简单？

一句话：

多 Agent 路由：长期固定分工 Sub-Agent：临时并行打工仔

这两个东西经常一起出现，但不是一回事。

九、多 Agent 协作最稳的配置方式，不是先追求"多"，而是先追求"角色干净"

很多新手一听多 Agent，就会自然地想：

• 一个负责模型 A
• 一个负责模型 B
• 一个负责写作
• 一个负责搜索
• 一个负责审查
• 一个负责消息
• 一个负责总结

看上去很厉害，实际上很容易把自己绕进去。

OpenClaw 官方示例里最值得学的，不是"配很多 agent"，而是每个 agent 的边界很清晰。例如官方在多 Agent sandbox 文档里的例子里，family agent 就是典型的受限型角色：沙箱全开、工具只允许 read，明确拒绝 exec、write、edit、apply_patch、process、browser。这就说明官方推荐的思路是：先定义边界，再定义角色。

所以如果你现在问我： OpenClaw 多 Agent 怎么配最稳？

我的答案是：

第一步：按"职责冲突"拆，不按"想象中很帅"拆

比如：

• main：你自己的主助手
• work：只碰工作内容
• family：只读、只提醒、只聊天
• ops：只负责运维通道

第二步：先做两个，再做三个

别一口气建五个以上。 先确认：

• 路由有没有生效
• 会话有没有串
• auth 有没有各自独立
• 工具权限有没有按预期生效

第三步：角色一定要写进各自 workspace

每个 agent 都有自己的 workspace，所以 AGENTS.md、SOUL.md 这些文件要写出角色差异，否则你只是"多开了几个壳"，不是"真的分工"。

十、最容易踩的 6 个坑

坑 1：复用同一个 agentDir

这是最危险的坑之一。官方明确说了：Never reuse agentDir across agents，否则会发生 auth / session collisions。

坑 2：主 Agent 能用，就以为新 Agent 也自动有认证

不对。每个 agent 读自己的 auth store。你如果新建了一个 agent，还得考虑它有没有自己的认证。

坑 3：只建 agent，不配 bindings

这会导致所有消息继续走默认 agent，你还以为"多 Agent 没生效"。绑定规则才决定谁接哪条消息。

坑 4：多人私聊时忘了改 dmScope

不改的话，不同人可能共享同一上下文。

坑 5：以为多 Agent 自动就安全

不对。真正的安全边界来自 per-agent 的 sandbox 和 tool policy。不同 agent 要按角色单独设。

坑 6：把 Sub-Agent 当成长期分工

Sub-Agent 是临时后台任务，不是替代长期角色架构。

十一、给小白一套能直接抄的上手顺序

如果你今天就想把 OpenClaw 多 Agent 跑起来，我建议你按这个顺序来：

1）先保留 main

不要动原主 agent。 先让现有链路继续稳定。

2）新增一个 work agent

openclaw agents add work --workspace ~/.openclaw/workspace-work

3）给 work 准备自己的 workspace 文件

写清楚：

• 它负责什么
• 不负责什么
• 用什么语气
• 允许哪些工作模式

4）如果需要，给 work 单独补认证

别默认继承。 必要时复制 auth-profiles.json，但不要共用 agentDir。

5）把一个渠道或一个群先绑定给 work

比如先从 Telegram 某个群、Slack 某个 team 开始。

6）如果多人会私聊，顺手把 dmScope 改掉

优先考虑 per-channel-peer。

7）跑一周，确认没串，再继续扩

这比一次建五个 agent 强太多。

结语：多 Agent 不是炫技，而是把复杂需求拆成清晰角色

很多人第一次听"多 Agent 协作"，会觉得这是一种很高级、很炫的玩法。 其实 OpenClaw 官方整个多 Agent 体系，最核心的思想反而很朴素：

让不同职责、不同安全边界、不同消息入口，交给不同的脑子处理。

所以你真要把这件事配好，不需要先追求"我有多少 agent"，而是先追求：

• 角色够不够清楚
• 路由够不够明确
• 认证够不够独立
• 会话会不会串
• 工具权限有没有按角色收紧

只要这五件事想明白了，OpenClaw 的多 Agent 协作就不会乱，反而会非常顺。

基础回顾

• OpenClaw 多 Agent 协作配置指南（第一篇） - 多 Agent 基础配置与角色拆分
• OpenClaw 多 Agent 通信失败怎么办？消息路由、角色配置与上下文隔离排查 - 多 Agent 通信排障
• OpenClaw 审批机制全解：allow-once、allow-always、deny 到底该怎么选？ - 审批机制详解