夜雨聆风一个助手，所有平台
使用 AI 助手最大的摩擦点之一，是它只活在一个专属界面里。你已经习惯了在 Telegram 处理工作消息、在 WhatsApp 联系家人、在 Discord 和朋友玩游戏——但你的 AI 助手在另一个 App 里，需要你专门切过去。每次切换，上下文就断了。
OpenClaw 的通道系统解决的就是这个问题。它让同一个 Agent——同一套记忆、同一套技能、同一个人格——同时出现在你已经使用的所有平台上，而你不需要改变任何使用习惯。你在哪里发消息，助手就在哪里回你。
目前支持的平台包括：WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、BlueBubbles、IRC、Microsoft Teams、Matrix、Feishu、LINE、Mattermost、Nextcloud Talk、Nostr、Synology Chat、Tlon、Twitch、Zalo、Zalo Personal、WebChat，共 22 个，还在持续增加。
内置通道与插件通道
这 22 个平台并不是全部写死在 OpenClaw 主仓库里的。按照集成方式，它们分为两类。
内置通道直接放在 src/ 目录下，与 Gateway 编译在一起。Telegram 在 src/telegram/，Discord 在 src/discord/，Slack 在 src/slack/，Signal 在 src/signal/，WhatsApp（Baileys）在 src/whatsapp/，WebChat 在 src/web/。这些是使用最广泛、维护最活跃的平台，由核心团队直接负责。
插件通道以独立 npm 包的形式发布，通过在 package.json 里声明 openclaw 字段被 Gateway 自动发现和加载。Matrix、LINE、Feishu、Mattermost、Nextcloud Talk、Zalo 等都属于这一类，通常由社区贡献者维护。安装方式与普通 npm 包完全一样：
openclaw plugins install @openclaw-community/channel-matrix这个分层设计让核心仓库保持精简，同时允许长尾平台通过插件生态得到支持。插件通道与内置通道在 Gateway 眼里是完全对等的——同样的生命周期管理、同样的健康监控、同样的路由规则，没有任何区别对待。
统一的提供者模式
虽然每个平台的技术实现各不相同，但所有通道适配器都遵循一套统一的提供者模式（Provider Pattern）。
每个平台的核心入口是一个 monitorXxxProvider() 函数，比如 Telegram 对应 src/telegram/bot.ts 里的 createTelegramBot()，Discord 对应 src/discord/monitor/provider.ts 里的 monitorDiscordProvider()。这个函数接受配置对象，返回一个生命周期托管的连接实例，负责三件事：注册平台事件监听器、管理连接的启动和断开、把收到的平台事件规范化为 OpenClaw 内部格式后推送给 Gateway 流水线。
Gateway 在通道启动时调用这个函数，得到连接实例，之后通过统一接口管理这个通道的整个生命周期。从 Gateway 的视角来看，所有通道都是一样的——不管背后是 Telegram 的长轮询还是 Discord 的 WebSocket 事件流。
消息处理的六阶段流水线
一条消息从平台到达 Agent，要经过六个阶段，每个阶段都有明确的职责。
第一阶段：平台事件接收。每个 Channel Monitor 实现一个平台特定的事件处理器，监听来自平台的原始事件。Telegram 使用 grammY 库（带有请求序列化和速率限制）；Discord 使用 @buape/carbon 库；Signal 通过 SSE（Server-Sent Events）接收事件；WhatsApp 通过 Baileys 的 WebSocket 连接。
第二阶段：规范化。平台原始事件被转换为统一的 MsgContext 结构。这个结构包含：消息文字内容、媒体附件（图片、语音、文件）、发送者身份、目标会话标识符、平台特定的 reply-to 信息、以及是否是群组消息等字段。Telegram 的规范化在 src/telegram/bot-message-context.ts 里，Discord 在 src/discord/monitor/message-handler.process.ts 里，各自处理各自平台的特殊性。
第三阶段：去重。网络抖动、平台重试、重连时的事件重放，都可能导致同一条消息被处理多次。去重层负责拦截这种情况。Telegram 的实现是 createTelegramUpdateDedupe()，跟踪最近处理过的 update ID，重连时跳过已处理的更新。不同平台有不同的去重策略，但结果一样：每条消息只被处理一次。
第四阶段：访问控制。这是安全门卫，决定这条消息有没有资格进入 Agent 执行流程。具体规则由 dmPolicy 和 groupPolicy 控制，下一节详细说明。
第五阶段：命令分发或 Agent 执行。消息通过访问控制后，先检查是不是命令（/status、/model、/think 等）。如果是命令，走快速路径直接处理，完全不进入 Agent 执行流程。如果是普通消息，构建完整的执行上下文，传给 PiEmbeddedRunner 启动 Agent。
第六阶段：回复投递。Agent 生成的回复被拆分（chunking）、格式化，通过平台特定的发送函数投递出去。Telegram 的发送在 src/telegram/send.ts，Discord 在 src/discord/send.ts，以此类推。
访问控制：dmPolicy 的四种模式
访问控制是通道系统里设计最精细的部分，通过 dmPolicy 字段控制谁的私信消息能触发 Agent 回复。
pairing 模式是默认模式，也是最推荐的个人使用模式。只有通过设备配对流程的账号，才能触发 AI 回复。未配对的陌生人发来消息时，Bot 会返回一个配对码；你用这个码在 CLI 里运行 openclaw channels pair 完成配对，那个人的账号就被加入白名单。这个机制让你不需要事先知道对方的平台 ID，同时又保持了对陌生来访者的控制。
allowlist 模式需要在配置里明确填入允许访问的账号 ID 列表。只有 allowFrom 数组里的账号发来的消息才会被处理，其余一律忽略。适合明确知道使用者身份、不需要动态配对的场景。
open 模式对任何人开放，任何账号发来的消息都会触发 AI 回复。必须同时配置 allowFrom: ["*"]，这个强制要求是为了确保你清楚地知道自己在做什么，而不是误配置了一个对公众开放的 AI 接口。适合公开的 Bot 服务场景，但要警惕 API 用量和成本失控。
disabled 模式完全关闭私信接入，Bot 不响应任何私信。通常用于"只处理群组消息"的场景，或者临时下线某个通道而不删除配置。
Zod schema 在加载配置时对这些组合做了额外的跨字段验证：open 模式必须有 allowFrom: ["*"]，allowlist 模式必须至少有一个 allowFrom 条目，否则配置校验失败。这是防止你把一个看起来像 allowlist 的配置实际上当成 open 在运行。
群组消息的访问控制通过 groupPolicy 字段控制，支持按服务器/群组 ID 的精细白名单，并通过 requireMention: true 要求必须 @mention Bot 才触发回复——防止 Bot 响应群里所有人的每一条消息。
多账号支持与账号级配置
同一个平台可以配置多个账号，典型场景是"一个个人账号，一个工作账号"。配置结构如下：
{channels: {telegram: {// 顶层默认配置dmPolicy: "pairing",accounts: {personal: {botToken: { env: "TELEGRAM_PERSONAL_TOKEN" },// 只有这个账号改变默认值dmPolicy: "allowlist",allowFrom: ["tg:123456789"],},work: {botToken: { env: "TELEGRAM_WORK_TOKEN" },// 其余字段继承顶层默认值}}}}}
账号级配置通过 resolveXAccount() 函数（比如 Telegram 对应 src/telegram/accounts.ts 里的 resolveTelegramAccount()）与顶层配置浅合并。每个账号得到一个完整的独立配置对象，在 Gateway 里以各自独立的 Channel Monitor 实例运行。
两类平台的接入差异：轮询 vs Webhook
从接入方式来看，这 22 个平台分为两大类，直接影响部署配置。
长轮询类平台（Telegram、WhatsApp、Discord、Signal、iMessage）不需要公网 IP 或域名。它们的工作方式是：Channel Monitor 主动向平台服务器发请求，问"有没有新消息？"，平台保持连接直到有消息到达（长轮询），或者维持一个常驻 WebSocket 连接（Discord）。对防火墙来说，这是纯外向流量，无需开放任何入站端口。
Webhook 类平台（Slack、Google Chat、LINE）需要一个公网可访问的 HTTPS 地址，因为平台会主动向你的服务器推送消息。这意味着你需要一个域名、一个公网 IP，以及一个合法的 TLS 证书。在 VPS 部署时，通常通过 nginx 反向代理来满足这个要求；在家庭网络环境下，Tailscale Funnel 是最简便的方案。
这个区别在部署决策上很重要。如果你只打算接入 Telegram 和 Discord，完全不需要公网服务器，在家里的 Mac Mini 或 树莓派上部署就够了；一旦你需要 Slack 或 Google Chat，就必须考虑公网暴露方案。
以 Telegram 为例：从 Token 到第一条回复
Telegram 是 OpenClaw 官方最推荐的第一个接入通道，理由是：设置简单（只需要一个 Bot Token）、不需要公网 IP、连接最稳定、语音消息支持好。
完整接入流程如下。
在 Telegram 里找 @BotFather，发送 /newbot，按提示填写 Bot 名称和用户名，BotFather 返回一个形如 123456:ABC... 的 Token。把这个 Token 写进配置：
{channels: {telegram: {enabled: true,botToken: { env: "TELEGRAM_BOT_TOKEN" },dmPolicy: "pairing",}}}
配置热更新会让 Gateway 立刻启动 Telegram Monitor。这时找到你的 Bot 发一条任意消息，Bot 会返回一个配对码。在终端里运行：
openclaw channels pair --channel telegram --code <配对码>配对完成，你的 Telegram 账号进入白名单。再发一条消息，Agent 开始响应。
整个过程大约五分钟，不需要任何外部服务器，不需要配置 Webhook，不需要申请平台开发者权限。
回复投递：分片、格式、typing 指示符
回复不是一个大块文字直接发过去，而是经过分片处理之后按顺序投递的。
分片逻辑在 src/auto-reply/chunk.ts 里，会根据平台的消息长度限制（比如 Telegram 单条消息最长 4096 字符）把长回复切分成多条连续消息。流式生成的回复支持两种模式：partial（每生成一个 chunk 就立刻更新消息，用于实时打字效果）和 block（全部生成完毕再发送，避免消息抖动）。
不同平台对富文本的支持程度不同。Telegram 支持 Markdown 和 HTML，Discord 支持 Markdown，Slack 使用自己的 Block Kit 格式。OpenClaw 通过 channel_hints 机制允许在 Skill 的回复里为不同平台指定不同的富文本格式：如果当前通道有对应的 hint，就用 hint 里的格式；否则回退到纯文本。
typing 指示符（"Bot 正在输入..."）在 Agent 开始执行时触发，执行结束时取消，让对话更有"实时感"。各平台的实现不同——Telegram 调用 sendChatAction('typing')，Discord 通过 channel.sendTyping()——但向上暴露的接口是统一的。
小结
OpenClaw 的通道系统是一套标准化的平台适配层。它用统一的提供者模式抹平了 22 个平台之间的协议差异，用六阶段流水线处理从接收到投递的全过程，用 dmPolicy 的四种模式覆盖从个人私用到公开服务的访问控制需求，用内置/插件分层让核心精简、长尾扩展。
从你的角度来看，无论在哪个平台发消息，面对的都是同一个 Agent，同一套记忆，同一种人格。通道的切换对 Agent 是透明的。
下一篇，我们进入 Session 管理，看消息进来之后是怎么确定"这条消息属于哪段对话"的，以及 OpenClaw 如何在多平台、多用户、多线程的复杂场景下维持对话的隔离边界。
源码参考：src/telegram/bot.ts · src/discord/monitor/provider.ts · src/slack/monitor/provider.ts · src/signal/monitor.ts · src/security/dm-policy-shared.ts · src/channels/mention-gating.ts · src/auto-reply/chunk.ts基于 commit bf6ec64f 版本
