消息在OpenClaw中是如何被分发的?

今天聊聊OpenClaw的底层原理——消息路由机制。

别看这几个字挺抽象，但它直接决定了你的消息能不能准确送到对应的"大脑"里。

想象一下：你给微信助手发了一条消息，这条消息会经过以下路径：

用户发送消息 → 渠道（WhatsApp/Telegram/微信等）→ Gateway（网关）

Gateway是整个OpenClaw的控制平面，你可以把它理解为公司的前台接待处。所有外部消息都必须先经过它。

补充一句：Gateway默认监听 ws://127.0.0.1:18789，它不直接暴露到公网，而是通过Tailscale或SSH隧道来远程访问。

关键来了——消息到了Gateway之后，不是直接扔给AI就完事了。它会经过一个路由匹配过程：

消息 → 提取特征（channel, accountId, peer, guildId...）→ 匹配binding → 分发给对应Agent

这里有几个核心概念需要搞清楚：

OpenClaw的路由规则是确定性的，遵循一个优先级顺序：

1. peer匹配 → 最精确，具体到某个人或某个群
2. guildId → Discord服务器级别
3. teamId → Slack工作区级别
4. accountId → 账户级别
5. channel → 渠道级别（最宽泛）
6. 默认Agent → 谁都匹配不上时交给默认的Agent

简单理解：越具体的规则越优先。

比如你设置了两条规则：

• 规则A：WhatsApp上的+15551230001发来的消息 → 交给Agent "work"
• 规则B：所有WhatsApp消息 → 交给Agent "home"

当+15551230001发来消息时，由于规则A更具体，消息会交给"work"Agent，而不是"home"。

默认情况下，OpenClaw运行在单智能体模式：

• agentId = "main"
• 所有消息都交给这个默认的"大脑"处理

但如果你想让它更强大呢？可以开启多智能体模式：

{  agents: {    list: [      { id: "chat", workspace: "~/.openclaw/workspace-chat" },      { id: "work", workspace: "~/.openclaw/workspace-work" },    ]  },  bindings: [    { agentId: "chat", match: { channel: "whatsapp" } },    { agentId: "work", match: { channel: "telegram" } },  ]}

这样一来：

• WhatsApp的消息 → 交给"chat"这个Agent（适合日常闲聊）
• Telegram的消息 → 交给"work"Agent（适合深度工作）

一个服务器，同时扮演多个角色。

小结一下：

OpenClaw的消息路由机制其实不复杂——

就是根据消息的特征（渠道、账户、发送者），按照优先级匹配规则，把消息分发给对应的Agent。

在理解这些基础概念之后，对于openclaw的扩展玩法

比如灵活配置多智能体、渠道隔离等高级玩法，相信能更加得心应手。