OpenClaw通道实战：新手也能接通的可靠消息入口

2026-06-16阅读 0热度 0

OpenClaw

如果你已经按上一篇跑通了本地闭环，那么现在你应该至少已经做到两件事：

1. openclaw gateway 已经正常运行

2. 你能打开 dashboard，并在浏览器里和 Agent 说话

这一篇要做的事很具体：把“浏览器里能聊”推进成“在真实消息软件里也能聊”。

如果还没完成上面那两个前提，先不要继续折腾通道，回到第 1 篇把本地链路跑通。因为很多人卡在接通道，不是通道本身难，而是把四件事混在了一起：

1. Gateway 本身有没有跑稳

2. 某个通道有没有完成登录或配对

3. 谁能给它发消息、群里怎么触发

4. 不同人的上下文会不会混在一起

所以这一篇不追求“大而全”，只追求一个结果：让一个真实入口稳定收消息、稳定回消息。

一、先把这几个词用人话讲明白

后面会反复出现几个词，先用最简单的方式理解：

• channel：外部消息入口，比如 Telegram、WhatsApp、Discord

• DM：私聊，也就是你和 Agent 一对一聊天

• pairing：先明确允许哪些人能私聊它，而不是默认谁都能来

• requireMention：群里只有真的 @ 到它时，才算一次有效触发

可以先不背配置键名，只记住这些词背后的意思：OpenClaw 接通道，不只是“登录一个账号”，而是在定义谁能触发它、在哪里触发它、触发后会不会串上下文。

二、为什么第 2 篇先讲通道，而不是先讲架构

因为对多数人来说，OpenClaw 真正变得“有用”，不是你打开了 Dashboard，而是：

• 在 Telegram 给它发一句话

• 或者你在 WhatsApp 给它发一句话

• 然后它真的从外部世界回了你一句

这一步一旦跑通，你再去看后面的 Gateway、routing、session、multi-agent，会顺很多。反过来，如果你还没把任何一个真实通道跑通，就先看完整个体系结构，往往会觉得“概念都懂了，但系统还是不像真的”。

三、第一个通道怎么选

先说结论，再解释。

1. 如果你想要最可控的 Bot 体验，先接 Telegram

原因很简单：

• 机器人模式清晰

• botToken 和群组 / topic 配置粒度明确

• 适合先验证 DM、群聊 mention gating、custom commands、history limit 这些能力

官方配置参考里，Telegram 这一层支持的控制面也很细，比如 dmPolicy、allowFrom、groups.*.requireMention、topics.*、historyLimit、streaming。所以如果你的目标是“我想先把 channel 规则看明白”，Telegram 很适合作为第一站。

2. 如果你关心日常触达，先接 WhatsApp

这是一个实践判断，不是官方排序。很多人真正每天会用的入口其实是 WhatsApp，因为它更接近日常收发消息的路径。但它的运维感也更强一些，因为你会更早碰到 linked session、read receipts、media limit、多账号等问题。

官方配置参考里，WhatsApp 默认就把很多真实世界问题摆在你面前，比如 dmPolicy: "pairing"、groupPolicy: "allowlist"、groups."*".requireMention: true、sendReadReceipts、accounts。也就是说，它很适合做“真实使用入口”，但不一定是最适合拿来理解规则边界的第一站。

3. 如果你做团队或社区运营，先接 Discord

Discord 更适合下面这种场景：

• 本来就有现成频道

• 你想先验证机器人在 server / channel 里的行为

• 你关心的是提及、频道级访问、团队消息而不是个人 DM

所以第一个通道并没有绝对标准，只有一个更实际的判断：选一个你今天就能真正给它发消息的入口。

四、第一阶段不要同时做 DM 和群聊

OpenClaw 的配置参考把 DM 和 group 的策略拆得很明确，这其实已经在提醒你：DM 不是群聊，pairing 不是 allowlist，group open 也不等于“随便谁都能触发”。

官方默认策略是很有方向感的：DM 默认 pairing，group 默认 allowlist。这意味着 OpenClaw 在设计上并不鼓励你“一接好通道就全面开放”。

更稳的顺序是：

1. 先只跑 DM

2. 保持 dmPolicy: "pairing" 或小范围 allowlist

3. 确认一个 sender 能稳定来回收发

4. 再去碰群聊、topic、forum thread、频道提及

这是最典型的“先缩小入口，再扩大边界”。

五、一个真正可跑的最小通道配置，应该长什么样

以 Telegram 为例，一个适合第一阶段的配置，不应该追求多，而应该追求边界清楚：

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "your-bot-token",
      dmPolicy: "pairing",
      allowFrom: ["tg:123456789"],
      groups: {
        "-1001234567890": {
          requireMention: true
        }
      }
    }
  }
}

这里最关键的不是字段多，而是这三个意图清晰：

1. dmPolicy 决定谁能先进入 DM

2. allowFrom 决定你最小允许谁试用

3. requireMention 决定群里不是每句话都能把 Agent 拉起来

如果你用 WhatsApp，思路一样，只是字段换成相应 provider 的格式：

{
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      allowFrom: [" 15555550123"],
      groups: {
        "*": { requireMention: true }
      },
      groupPolicy: "allowlist"
    }
  }
}

重点不是抄哪个 provider，而是建立同一个判断：一个通道配置，至少要同时回答“谁能私聊我”和“群里什么时候才算有效触发”。

六、群聊 mention gating 不是体验优化，而是系统边界

很多人第一次看 requireMention: true，会把它理解成“减少噪音”。这当然对，但还不够。

它更重要的作用是：降低无意触发，避免群里所有消息都进入上下文，把 Agent 的注意力限定在明确被点名的时刻。这件事到了生产环境就更关键了。因为如果群聊默认开放、默认全量触发，那你后面谈工具权限、沙箱、审计，其实都会更痛苦。

所以从第二篇开始，就应该把 requireMention 当成边界配置，而不是交互小功能。

七、多人 DM 时，别让不同 sender 共用一个上下文

官方配置示例里专门给了一个很值得注意的建议：

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

这个设置解决了一个特别接地气的问题：如果你的机器人会被多个人 DM，而这些 DM 又共享一个主会话，那记忆和上下文就会互相污染。

所以当你的 DM 不再只是你自己一个人使用时，session.dmScope: "per-channel-peer" 基本就不再是“高级优化”，而是默认建议。这一点尤其适用于多人共用的 Telegram bot、多人都能发消息的 Discord/Slack/Teams 机器人，或者你准备让家庭成员或同事也能 DM 你的 Agent。

八、文本先跑通，再碰媒体、语音和 webhook

OpenClaw 文档把媒体、语音、webhook、Gmail Pub/Sub 都拆成了独立主题，这本身就是一个信号：不要在第一个通道阶段把这些能力一起上。

更稳的顺序应该是：

1. 先纯文本 DM

2. 再打开群聊 mention

3. 再碰图片、语音、media limits

4. 最后才是 webhook、cron、Gmail 这类外部自动触发

因为只要文本回路没跑稳，后面所有更复杂的入口都会放大排障成本。

九、给通道接入的最小 checklist

1. Gateway 已经稳定运行，本地 Dashboard 可用

2. 只启用一个 channel，不同时开多个入口

3. 先做 DM，不先做 group

4. dmPolicy 和 allowFrom 已经明确

5. 群聊默认 requireMention: true

6. 多人 DM 场景下，考虑 session.dmScope: "per-channel-peer"

7. 先验证文本消息收发，再逐步增加媒体和自动化

十、这一篇之后，你该建立什么认知

到这里，你应该开始把 channel 理解成：它不是“接个平台账号”这么简单，而是 OpenClaw 的第一层安全边界、会话边界和路由边界。你一旦把这个认知建立起来，下一篇再去看 Gateway、Channels、Control UI 到底怎么协同，就会顺很多。

参考链接

• Configuration Reference：https://docs.openclaw.ai/gateway/configuration-reference

• Configuration Examples：https://docs.openclaw.ai/gateway/configuration-examples

• Features：https://docs.openclaw.ai/concepts/features

这一篇属于 OpenClaw 系列的「入门」阶段。上一篇：OpenClaw 新手入门：30 分钟打通第一条消息。下一篇：OpenClaw 架构入门：Gateway、Channel、Control UI 如何协同。