11. Channels：多平台消息入口怎么接入

这篇解决什么问题

OpenClaw 支持很多聊天平台。

但 Agent Runtime 不应该关心“这条消息来自 Telegram 还是 Feishu”。它需要的是统一的内部事件。

Channel 层就是做这件事。

相关目录

src/channels/
src/channels/inbound-event/
src/channels/message/
src/channels/allowlists/
src/channels/transport/
src/pairing/
extensions/<channel>/
src/config/types.<channel>.ts

一些官方 channel 能力在 extensions/ 里。

Channel 的基本职责

一个 channel 通常要处理：

平台凭证
收消息
发消息
消息格式转换
文件/图片/语音附件
sender/account/thread 识别
allowlist / pairing
错误和限流
状态检查

这些都不应该塞进 Agent Runtime。

inbound event 为什么重要

平台消息进入 OpenClaw 后，要变成统一的 inbound event。

这样 Gateway 才能用同一套逻辑处理不同平台：路由到 agent、绑定 session、触发 auto-reply、调用 runtime。

pairing 和 allowlist

README 明确说：远程 DM 是不可信输入。

默认 DM policy 往往是 pairing。未知发送者会拿到 pairing code，而不是直接进入 Agent。

批准方式类似：

openclaw pairing approve <channel> <code>

所以“bot 不回复陌生 DM”不一定是故障，可能是安全策略生效。

写一个新 channel 要想什么

至少要处理：

如何接收平台消息
如何识别 sender / chat / thread
如何发回文本和附件
如何做认证和 allowlist
如何处理平台限流
如何暴露状态给 doctor/status
是否需要 plugin extension

排障顺序

1. channel token / app secret 是否正确
2. webhook 或长连接是否正常
3. Gateway 是否运行
4. allowlist / pairing 是否通过
5. inbound event 是否生成
6. session routing 是否命中正确 agent
7. outbound delivery 是否失败

实践：Channel 入口检查

从一个已经接入的 Channel 发一条带唯一标记的消息，用 3—5 分钟按本文顺序观察：Gateway、pairing/allowlist、inbound event、session routing、outbound delivery。不要为完成练习把 DM policy 改成 open。

完成标准

• Gateway 正常运行；
• 已确认发送者通过 pairing 或 allowlist；
• 唯一标记得到回复，或能把失败定位到七步排障顺序中的某一步；
• 回复回到原 Channel。

多走一步

用一个尚未批准的测试发送者验证 pairing 默认行为；只观察 pairing code，不批准未知真实用户。

下一篇看什么

下一篇看 Sessions。