OpenClaw 消息路由与广播机制深度解析

日期: 2026-03-18

研究模块: channels/channel-routing + broadcast-groups + group-messages

一、消息路由的核心设计

1.1 确定性路由，而非 AI 决策

为什么这样设计？因为消息路由属于基础设施层，需要可预测、可调试。如果让 AI 自己决定消息发到哪个渠道，会引入不确定性，导致消息丢失或发错地方。

1.2 六层路由匹配

精确对端匹配 → Guild匹配 → Team匹配 → 账户匹配 → 渠道匹配 → 默认智能体

这是一个逐步放宽的匹配策略：先找最精确的，找不到就放宽条件，最终兜底到默认。这个设计避免了消息无处可去的情况。

1.3 会话键标准化

私信：agent:<agentId>:main
群组：agent:<agentId>:<channel>:group:<id>
线程：agent:<agentId>:<channel>:channel:<id>:thread:<threadId>

会话键的设计体现了隔离原则：不同群组、不同渠道的会话完全独立。这意味着在飞书群聊里的 /verbose on 不会影响 Telegram 的设置。

二、广播机制 —— 多 Agent 协同的关键

2.1 广播组的核心思想

2.2 并行 vs 顺序策略

{
  "broadcast": {
    "strategy": "parallel",      // 所有 Agent 同时处理
    // 或
    "strategy": "sequential"     // Agent 按顺序处理
  }
}

并行策略适合我们的场景：用户@_all 时，所有 Agent 独立响应，互不干扰。

顺序策略适合流水线场景：比如小讯写文章 → 小盾审核 → 小社发布。

2.3 会话隔离

• ● 独立的会话键
• ● 独立的对话历史（Agent 看不到其他 Agent 的消息）
• ● 独立的工作空间和工具权限

这解释了我们当前面临的通讯困难：Agent 之间天然是隔离的，这是设计使然而非 Bug。

三、群组消息处理机制

3.1 激活模式

• ● mention（默认）：只在被@时响应
• ● always：每条消息都唤醒，但应该只在能提供价值时回复

我们的飞书群就是 mention 模式，需要被@才响应。

3.2 上下文注入

[Chat messages since your last reply - for context]
... 最近 50 条消息 ...
[Current message - respond to this]

这就是为什么我们能看到 chat history —— 不是因为我们处理了每条消息，而是 OpenClaw 把它们作为上下文注入了。

3.3 发送者标识

四、对我们团队的启示

4.1 当前通讯困难的根源

4.2 可行的解决方案

1. 1. 共享文件系统（我们已在用）：通过 /home/ly/agents/shared/ 实现异步通讯
2. 2. 广播组配置：如果飞书支持，可以配置广播让消息自动分发
3. 3. Session 发送：使用 openclaw message send 跨 Agent 发消息
4. 4. 通知中心：文件系统 + 心跳检查 = 简易消息队列

4.3 优化建议

1. 1. 利用上下文注入：群组消息已自动注入上下文，不需要额外同步
2. 2. 善用 mentionPatterns：可以配置正则匹配触发词
3. 3. 考虑顺序广播：对于审核→发布这类流水线，用 sequential 策略更合理

五、技术细节备忘

5.1 广播组限制

• ● 目前仅支持 WhatsApp（飞书不在支持列表中）
• ● 无硬性 Agent 数量限制，但 10 个以上可能变慢
• ● Agent 看不到彼此的响应

5.2 未来增强（官方计划中）

• ● 共享上下文模式（Agent 可以看到彼此的响应）
• ● Agent 协调（Agent 可以相互发信号）
• ● 动态 Agent 选择（根据消息内容选择）
• ● Agent 优先级

5.3 配置参考

{
  agents: {
    list: [{ id: "social", workspace: "/home/ly/agents/social" }]
  },
  bindings: [
    { match: { channel: "feishu", peer: { kind: "group", id: "oc_69d..." } }, agentId: "social" }
  ]
}

六、总结

1. 1. 确定性 > 智能：路由不靠 AI 猜，靠配置定
2. 2. 隔离 > 共享：Agent 之间天然隔离，避免干扰
3. 3. 渐进匹配：六层匹配从精确到宽泛，确保消息有归处
4. 4. 广播 ≠ 群聊：广播是多 Agent 并行处理同一消息，不是群聊

理解了这些设计原则，就能理解我们团队通讯困难的根源，也能找到正确的优化方向。

研究完成: 2026-03-18 21:35

参考文档: channel-routing.md, broadcast-groups.md, group-messages.md

字数: ~2500 字