OpenClaw 多 Agent 通信失败怎么办？消息路由、角色配置与上下文隔离排查

很多人第一次配 OpenClaw 多 Agent，最容易产生一种错觉：我已经建了两个 Agent，为什么它们还是不像我想的那样协作？

有时候是 Telegram 消息明明发给了工作助手，却被主助手接走。

有时候是某个 Agent 看起来在线，节点工具却死活调不起来。

还有时候更诡异：不是没回应，而是回应了，但上下文像串台，A 的对话记忆跑到了 B 身上。

这类问题最折磨人的地方在于，它表面上都像多 Agent 通信失败，但真正的根因可能完全不同。

在 OpenClaw 的官方设计里，多 Agent 相关故障至少会落到这几层：

• 路由层：消息到底被分给了哪个 Agent
• 会话层：不同人、不同渠道、不同 Agent 的上下文是否真的隔离
• 认证/状态层：这个 Agent 自己有没有独立 auth store 和 sessions
• 节点/审批层：节点虽然连上了，但命令是否真的被允许执行
• 后台协作层：你以为在用多 Agent 路由，其实问题出在 Sub-Agent 后台任务上

OpenClaw 官方文档对这些层是分开讲的：多 Agent 路由、会话管理、节点排障、频道绑定、Sub-Agents 都有独立说明。换句话说，你看到的是通信问题，系统看到的却可能是路由命中问题、会话隔离问题或节点审批问题。

本文侧重点：多 Agent 通信失败的消息路由、bindings、session 隔离、dmScope、node pairing、审批与 Sub-Agent 并行排查。如果你尚未完成 OpenClaw 基础安装，请先阅读 OpenClaw 安装失败怎么办？从环境到权限的完整排查；如果是 provider 配置问题，请参考 OpenClaw provider 配置指南：OpenAI、Anthropic、OpenRouter 到底怎么接。

一、先纠正一个误区：很多多 Agent 通信失败，其实不是 Agent 之间在通信

先说一句最关键的人话：

OpenClaw 的多 Agent，核心不是 Agent 之间互发消息，而是不同入站消息被路由给不同 Agent 处理。

官方对 Multi-Agent Routing 的定义非常清楚：目标是在一个运行中的 Gateway 里，管理多个彼此隔离的 Agent，每个 Agent 有独立的 workspace、agentDir 和 sessions；而入站消息通过 bindings 被路由给具体的 Agent。也就是说，多 Agent 的第一性原理不是 Agent 互相聊天，而是 Gateway 决定哪条消息归谁。

这点一旦想明白，你排障思路就会立刻清楚很多：

• 如果消息发错 Agent，优先查 bindings 和 routing rules
• 如果同一个 Agent 里上下文串了，优先查 session.dmScope
• 如果 Agent 看起来在，但工具调不起来，优先查 node pairing / approvals
• 如果后台分工任务没回来，优先查 Sub-Agent 运行状态，而不是怀疑多 Agent 路由本身

二、先看结构：一个 Agent 到底包含什么

OpenClaw 官方把一个 Agent 定义成一个完全隔离的脑子，它至少有三样独立的东西：

1. 独立的 workspace，放 AGENTS.md、SOUL.md、USER.md、本地文件和人格规则
2. 独立的 state directory（agentDir），存 auth profiles、model registry 和 per-agent config
3. 独立的 session store，默认在 ~/.openclaw/agents/<agentId>/sessions 下保存会话和路由状态

官方还特别强调：auth profiles 是按 Agent 隔离的，每个 Agent 从自己的 ~/.openclaw/agents/<agentId>/agent/auth-profiles.json 读取认证信息，主 Agent 的认证不会自动共享给其他 Agent。

这意味着一个非常高频的坑：

你以为是通信失败，其实是新 Agent 自己就没吃到正确的认证或状态文件。

所以只要你建了第二个、第三个 Agent，就一定要记住一句话：

能用的不是这个 Gateway，而是这个具体 Agent。

主 Agent 能跑，不代表 work、ops、family 这些 Agent 也天然能跑。

三、最常见的第一类故障：消息发到了错误的 Agent

这是多 Agent 最常见、也最容易误判的一类问题。

你以为工作群应该进 work agent，结果消息还是被 main 接走了。

这不是 OpenClaw 抽风，而通常是 bindings 没配对，或匹配规则没命中。

官方给出的 routing rules 很明确，而且是确定性的、按优先级匹配：

1. peer 精确匹配
2. parentPeer 线程继承
3. Discord 的 guildId + roles
4. Discord 的 guildId
5. Slack 的 teamId
6. 渠道的 accountId
7. 渠道级匹配
8. 都没命中时，回退到默认 Agent（agents.list[].default，否则列表第一个，最后一般回到 main）

如果同一层匹配到多个 binding，则配置顺序里靠前的那个赢；如果一个 binding 同时写了多个匹配字段，比如 peer + guildId，那它们是 AND 关系，必须同时命中。官方还专门提醒：省略 accountId 只会匹配默认账号；想做渠道级的全账号兜底，要用 accountId: "*"。

这就解释了为什么很多人会出现这种情况：

你明明写了 channel 级规则，但后来又加了多账号，结果原来那条规则只命中了默认账号，其他账号消息全掉回了默认 Agent。

这不是系统坏了，是 routing rule 的精确性比你想象中更高。

这类问题怎么查最稳

先别猜，直接检查：

openclaw agents list --bindings
openclaw agents bindings
openclaw channels status --probe

agents list --bindings 和 agents bindings 可以让你确认：现在到底有哪些绑定规则存在，消息理论上该被谁接。

而 channels status --probe 能帮你确认账号本身是不是活着、Gateway 是不是能看到这个渠道。官方 CLI 文档也说明，交互式 openclaw channels add 在配置账号时，会直接问你要不要现在把这些 channel account 绑定给 agents；如果你是非交互方式加的渠道，它不会自动帮你写 bindings。

最容易漏掉的一个细节

如果你只有一个渠道，但用了多个账号，那频道能用不代表这个账号的消息会去正确的 Agent。

OpenClaw 明确把 channel account 和 agent binding 视为两件事。账号配好了，只表示渠道能连；绑定写对了，才表示消息会去你想让它去的 Agent。

四、第二类高频故障：不是消息发错了，而是上下文串了

这类问题比没回应更隐蔽，也更危险。

你会觉得：

• 明明是不同的人私聊
• 明明是不同入口
• 为什么上下文像共享了一样？
• 甚至一个人的内容，另一个人好像也知道了

OpenClaw 官方在 Session Management 里讲得非常直接：

默认情况下，所有 DM 共享一个 session，这是为了单用户连续性设计的；但如果有多个人都能给你的 Agent 发私聊，而你没开 DM isolation，那么所有用户就会共享同一个会话上下文。

官方甚至直接举了一个非常扎眼的例子：Alice 的私聊内容可能会被 Bob 继承到。

官方推荐的修法也很清楚：

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

它的含义是：按渠道 + 发送者来隔离 DM，会话不再一锅煮。

官方还给了其他几个选项：

• main：默认，所有 DM 共享
• per-peer：按发送者隔离
• per-channel-peer：按渠道 + 发送者隔离，官方推荐
• per-account-channel-peer：按账号 + 渠道 + 发送者隔离

如果同一个人会从多个渠道联系你，还可以用 session.identityLinks 让这些身份共享同一会话。

为什么这会被误判成多 Agent 通信失败

因为从用户视角看，现象很像：

• A 的内容跑到 B 里去了
• 主助手像在偷听另一个助手
• 多个入口像没有隔离

但本质上，这不是 Agent 之间互相串线，而是同一个 Agent 的 DM session 没有正确隔离。

这类问题怎么查

先看当前 session 状态：

openclaw status
openclaw sessions --json

官方文档说明，openclaw status 会显示 session store path 和最近活动；openclaw sessions --json 能列出当前所有 sessions。再配合聊天里的 `` 和 /context list，你能很快看出来：现在到底是不是多人在共用一个会话。

如果你的使用模式已经不是我自己一个人，而是：

• 多个人都能 DM 这个 bot
• 同一个渠道里多个用户会和它互动
• 一个共享 inbox 绑定到一个 Agent

那就别犹豫，尽快把 dmScope 调到 per-channel-peer，并用 openclaw security audit 再复查一下。官方的安全文档和 security CLI 都把这件事当成共享 inbox 的关键加固项。

五、第三类故障：Node 看起来在线，但工具死活调用失败

这类情况也经常被误会成多 Agent 通信失败，尤其是在你让某个 Agent 去调用本机节点能力时。

比如：

• macOS 节点明明显示 connected
• openclaw nodes status 里也能看到
• 但 system.run、camera.*、screen.* 就是失败

官方的 Nodes 和 Node Troubleshooting 文档对此讲得很明白：

Telegram / WhatsApp 等消息是落在 Gateway 上的，不是落在 node 上的。Node 是外围设备，通过 WebSocket 以 role: node 接进 Gateway，暴露的是命令面，比如 canvas.*、camera.*、device.*、system.*。所以 node 看起来在线，不等于 node 上所有命令都自动可用。

官方 Node Troubleshooting 还给了非常实用的命令阶梯：

openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe
openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>
openclaw approvals get --node <idOrNameOrIp>

官方给的健康信号也很清楚：

• node 已连接并且 paired for role node
• nodes describe 里包含你正在调用的 capability
• exec approvals 显示的是你预期的 mode / allowlist

这里最容易混淆的三道门

官方文档专门把它们拆开：

1. Device pairing：这台 node 能不能接进 Gateway
2. Node command policy：这个 node 声明的命令 Gateway 允不允许
3. Exec approvals：比如 system.run 这种宿主机命令，是否需要审批

常见错误码里，官方特别点名了：

• SYSTEM_RUN_DENIED：通常是 exec approvals 没通过
• NODE_BACKGROUND_UNAVAILABLE：iOS/Android 上前台要求没满足
• 各种 *_PERMISSION_REQUIRED：权限矩阵没过，比如相机、屏幕录制、定位等

一句话点醒

Node 在线 ≠ Node 可用 ≠ Node 有权执行。

很多看起来像 Agent 之间通信失败的问题，其实只是：你的 Agent 成功把任务发到 Gateway 了，但 Gateway 往 node 调命令时，被 pairing / capability / approvals 卡住了。关于审批机制的详细说明，请参考 OpenClaw 审批机制全解：allow-once、allow-always、deny 到底该怎么选？。

六、第四类故障：你以为在玩多 Agent 路由，其实问题出在 Sub-Agent 后台任务

这是进阶用户很容易踩的坑。

OpenClaw 的 Sub-Agents 和 多 Agent 路由 不是一回事。

官方定义很明确：Sub-agents 是从现有 agent run 中临时派生出来的后台 agent run，它们跑在自己的 session 里，session key 形如 agent:<agentId>:subagent:<uuid>，完成后会把结果回传到请求者所在的聊天渠道，并作为 background task 被跟踪。

常见控制命令包括：

/subagents list
/subagents log <id|#>
/subagents info <id|#>
/subagents send <id|#> <message>
/subagents steer <id|#> <message>
/subagents kill <id|#|all>
/subagents spawn <agentId> <task> [--model ...] [--thinking ...]

为什么这会被误判成多 Agent 通信失败

因为从表面看，现象很像：

• 主 Agent 派了子任务
• 子任务像没回来
• 或者回来了，但不在你期待的地方
• 你以为是 work agent 和 review agent 没协同好

但本质上，Sub-Agent 是后台任务系统，不是长期路由系统。

如果是 Sub-Agent 跑飞了、挂了、没 announce 回来，你要查的是：

• 子任务有没有真的 spawn 成功
• 它自己的 session 是否还在
• /subagents list 里有没有它
• /subagents log 里有没有失败信息

而不是先去改 bindings。

怎么判断自己现在遇到的是哪种问题

很简单：

• 固定渠道固定角色，总是发错人 → 查多 Agent 路由
• 某次临时派出去的后台任务没回来 → 查 Sub-Agent

一句话区分：多 Agent 路由是长期分工，Sub-Agent 是临时打工。

七、一个非常现实的边界：多 Agent 不是多租户隔离系统

这点很少有人主动提，但其实非常重要。

OpenClaw 官方安全文档反复强调：它默认的安全模型是个人助手信任边界，也就是一个受信任操作者边界上的一个 Gateway，可以有多个 Agents；但它不是 hostile multi-tenant security boundary，不适合让彼此不信任、甚至对抗性的用户长期共用一个 gateway / agent 体系。官方建议，如果存在 mixed-trust 或 adversarial-user 场景，应该拆成独立 Gateway、独立凭证，最好连 OS 用户/主机也拆开。

这是什么意思？

就是说，如果你现在把多 Agent 理解成：

一个 Gateway，十几个人随便用，每个人都觉得彼此隔离得很安全

那你已经超出了官方推荐姿势。

OpenClaw 自己都说得很直白：

如果多个人都能给同一个 tool-enabled agent 发消息，那他们本质上共享的是同一套 delegated tool authority。session isolation 可以帮你做隐私和上下文隔离，但不会把一个共享 Agent 自动变成真正的多租户授权系统。

所以，如果你现在的通信失败其实发生在一个高度共享、多人共同使用的环境里，那你要先问的问题甚至不是路由为什么没中，而是：

这是不是本来就该拆 Gateway，而不是只拆 Agent。

八、最稳的排查顺序：别乱改，按这套来

如果你今天就碰到了多 Agent 通信失败，最稳的顺序是这个：

第一步：先看基础健康状态

openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe

这是 OpenClaw 官方 Troubleshooting 和 Node Troubleshooting 都放在前面的命令阶梯。先确认不是 Gateway 自己就坏了。健康信号包括 Runtime: running、RPC probe: ok，以及 channels status --probe 里出现 works 或 audit ok 等结果。如果 Gateway 状态异常，建议查看 OpenClaw 日志怎么看？一篇文章找到真正根因。

第二步：确认 routing/bindings 有没有命中

openclaw agents list --bindings
openclaw agents bindings

确认目标渠道、目标账号、目标 peer/team/guild 是否真的绑到了你以为的 Agent。尤其检查有没有默认账号、accountId 和 fallback Agent 混淆的问题。

第三步：确认是不是会话隔离问题

openclaw sessions --json

再配合聊天里的 `` 和 /context list 看现在是不是多人共用同一 DM session。必要时把 session.dmScope 改成 per-channel-peer 或 per-account-channel-peer。

第四步：如果涉及 node 工具，单独查 node

openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>
openclaw approvals get --node <idOrNameOrIp>

看 capability 是否声明、pairing 是否完成、system.run 之类是否被 approvals 卡住。

第五步：如果是后台协作，查 Sub-Agent

/subagents list
/subagents log <id|#>
/subagents info <id|#>

看子任务是不是根本没 spawn 成功，还是 spawn 了但卡在运行中，还是结果没有 announce 回来。

九、给新手的一句最重要提醒

真正高效的排查，不是问：

为什么 OpenClaw 多 Agent 不工作？

而是先把问题切开，问成下面四句之一：

1. 这条消息到底进了哪个 Agent？
2. 这个 Agent 的会话到底有没有隔离？
3. 任务是不是已经发到 node 了，只是被权限/审批挡住？
4. 我遇到的是多 Agent 路由问题，还是 Sub-Agent 后台任务问题？

只要你能把这四句问对，OpenClaw 多 Agent 的绝大多数通信失败，都会从一团雾变成一个具体故障点。上面这些判断路径，都能在 OpenClaw 官方关于 multi-agent、session、nodes、subagents 和 security 的文档里找到对应依据。

十、结语

OpenClaw 多 Agent 最难的地方，从来不是能不能多建几个 Agent，而是你能不能分清：

• 谁负责接消息
• 谁负责记上下文
• 谁负责跑命令
• 谁负责做临时后台任务

你一旦把这四件事混在一起，任何问题看起来都像多 Agent 通信失败。

你把它们拆开看，很多问题就会立刻变简单。

最后送你一句最实用的话：

多 Agent 不怕复杂，怕的是路由、会话、节点、后台任务全混着查。

把这几个层拆开，你就不会再被 OpenClaw 的看起来像串台吓住了。

延伸阅读

• OpenClaw 安装失败怎么办？从环境到权限的完整排查 - 基础安装和环境排查
• OpenClaw provider 配置指南：OpenAI、Anthropic、OpenRouter 到底怎么接 - provider 认证和模型配置
• OpenClaw 审批机制全解：allow-once、allow-always、deny 到底该怎么选？ - 审批机制详解
• OpenClaw 日志怎么看？一篇文章找到真正根因 - 日志排查技巧
• OpenClaw 常见报错总表：安装、模型、审批、权限一次看懂 - 全面报错排查