OpenClaw 接入 Telegram、Discord、Slack 还是 WhatsApp？先安全接通一个

先别同时配置 Telegram、WhatsApp、Discord 和 Slack。更稳妥的起点，是在一个自己能管理的机器人、工作区或手机号里，先批准一位私信用户，让一条测试消息完整地进出 OpenClaw；这条链路没有跑通前，不要急着把机器人拉进群、开放给更多人或接入第二个平台。

你的实际使用场景	先选哪个	第一次只开放到哪里
个人或小团队，需要独立机器人账号	Telegram	一位私信用户，之后再加一个群并保留 @ 提及
必须用手机号和现有 WhatsApp 对话	WhatsApp	一个批准号码；群聊与其他号码随后单独增加
有自己管理的私有服务器或社区频道	Discord	一位私信用户，或一个私有服务器里的一个频道
团队已经以 Slack 工作区为中心	Slack	一位私信用户，或一个使用稳定 Channel ID 的频道

截至 2026 年 7 月 13 日，OpenClaw 官方中文渠道配置显示：Telegram 随核心 openclaw 包发布，Discord、Slack 和 WhatsApp 属于独立插件。它们不是同一套“填 token、重启就好”的配置：四个平台的身份、连接方式、凭证和权限边界都不同。

第一次测试统一采用收紧状态：私信使用 pairing，群组使用 allowlist，群消息保留 @ 提及。不要为了让测试“立刻有反应”而把 dmPolicy 改成 open 并加入通配符，也不要把真实 token、Slack signing secret、二维码或 WhatsApp 会话目录发进聊天、截图和 issue。

接通的标准不是“配置已保存”或“机器人在线”，而是：指定用户发出的消息进入 Gateway，智能体或模型完成处理，回复再回到同一个私聊、频道或线程。保存这一次 probe、同一时间段日志和可见回复，才算完成第一个渠道。

加渠道前，先证明 Gateway 和模型能工作

如果 Gateway 本身不可达，或模型认证没有通过，再正确的 Telegram token 也不会产生回复。先把底层和渠道问题分开，用只读命令确认当前运行的是谁：

hljs bash
openclaw status
openclaw gateway probe
openclaw doctor
openclaw channels list --all
openclaw channels status --probe

这些命令各自回答一个问题：

openclaw status 用于确认当前安装和总体运行状态；
openclaw gateway probe 证明 CLI 能否真正连到 Gateway；
普通 openclaw doctor 先报告问题，不应把 doctor --fix 当成渠道安装步骤；
channels list --all 会区分已安装、已配置、已启用和可安装的渠道；
channels status --probe 在 Gateway 可达时探测真实账号；Gateway 不可达时，它只能退回到配置摘要，不能证明平台连接正常。

开始渠道配置前，至少确认以下几点：

终端使用的 OpenClaw 与 Gateway 服务实际运行的版本和路径一致；
Gateway probe 正常；
WebChat、CLI 或已有入口可以完成一次模型回复；
目标渠道显示为核心、已安装或可安装，而不是只在配置里手写了一个名字；
不需要先执行无关的重装、重置或写入修复。

若这里就失败，应先处理 OpenClaw 安装、Gateway 或模型路线，不要同时修改渠道。否则后面看到“机器人不回复”，你无法判断是平台入口、OpenClaw 运行时还是模型提供商出了问题。

选渠道不是比功能，而是确定谁来负责

中文教程常把“支持哪些平台”写成列表，但真正影响第一次成功的是账号和部署归属。

渠道	平台身份	连接方式	你必须能管理的东西	不适合先选的情况
Telegram	BotFather 创建的独立 bot	核心渠道；默认 long polling，可选 webhook	bot token、数字用户 ID、群 ID、隐私模式与提及规则	真实需求其实是团队工作区、服务器角色或手机号身份
WhatsApp	一个可扫码绑定的 WhatsApp 号码	外部插件；Gateway 持有 Baileys 链接会话	号码归属、Linked devices、会话目录与手机号白名单	无法稳定保管扫码会话，或不清楚谁能重新绑定
Discord	Developer Portal 中的 application 和 bot	插件，通过 Discord Gateway	privileged intents、邀请权限、Server/Channel/User ID	无权管理服务器或无法审查 bot 的实际权限
Slack	某个 workspace 中安装的 Slack app	插件，Socket Mode 或 HTTP Request URLs	app、workspace、transport、tokens/signing secret、scopes/events	无法安装 app，或无法提供所选 transport 的网络条件

没有“所有人都应该先用 Telegram”或“Discord 一定最好”的结论。个人 bot 和团队工作区不是一个身份合同；Socket Mode 和扫码会话也不是同一类运行责任。先选自己能持续维护、能轮换凭证、能确认管理员的那一条。

同样，不要在第一个平台里同时加多个账号。两个 Telegram bot、两个 Slack workspace，或个人/工作两个 WhatsApp 号码，都会让日志、凭证和路由多出一层歧义。

接通前，把五件事写清楚

无论选哪个平台，都先记录五项内容。只填好 token 只完成了其中一项。

必须明确的项目	要回答的问题	验收证据
身份	用户看到的是哪个 bot、app、workspace、server 或手机号？谁能管理它？	平台账号和稳定 ID，不包含秘密值
传输	渠道在核心包还是插件中？走 polling、Discord Gateway、Socket、HTTP 还是二维码会话？	安装状态、transport 与运行连接
凭证/会话	使用 bot token、app token、signing secret 还是 linked session？	SecretRef、受保护环境变量或目录位置
访问	哪位用户、哪个私聊、群、频道和命令可以触发？是否必须 @ 提及？	pairing 与 ID 白名单
证明	用哪条消息验证入站、模型、出站与可见回复？	probe、限定时间日志和同位置回复

如果其中一项还没有负责人，就不要继续。例如：

“接 Slack”还没有回答是 Socket Mode 还是 HTTP Request URLs；
“接 WhatsApp”还没有回答绑定哪个号码、谁能重新扫码；
“Discord bot 在线”还没有证明指定用户能在指定频道收到回复；
“Telegram 已配对”还没有允许任何群，也没有授权群里的其他人。

凭证只能留在 Gateway 主机

发布配置示例时，不要写出看起来像真实 token 的长字符串。更安全的方式是让配置引用受保护的环境变量或 SecretRef。例如 Discord 可以只记录变量名：

hljs json5
{
  channels: {
    discord: {
      enabled: true,
      token: {
        source: "env",
        provider: "default",
        id: "DISCORD_BOT_TOKEN"
      }
    }
  }
}

DISCORD_BOT_TOKEN 的值应由 Gateway 服务环境提供。Telegram bot token、Slack bot/app token、Slack signing secret、WhatsApp auth 目录和二维码都遵守同一原则：可以记录字段、负责人和存放方式，不能把值发给聊天机器人、贴进截图、提交到 Git 或塞进完整日志。

先接 Telegram：从一位私信用户开始

OpenClaw Telegram 官方中文页使用准确的 @BotFather 创建 bot。Telegram 是核心渠道，默认通过 long polling 工作，也可选择 webhook。它不使用 openclaw channels login telegram；设置 token 后启动 Gateway 即可。

创建 bot 并保护 token

在 Telegram 中确认账号正是 @BotFather，运行 /newbot，完成名称和 username。把返回的 token 放到 Gateway 主机。默认账号可以使用 TELEGRAM_BOT_TOKEN 环境变量；命名账号需要各自的 botToken 或 tokenFile。

环境变量已经配置后，可以让当前渠道向导引用它：

hljs bash
openclaw channels add --channel telegram --use-env
openclaw gateway

不要直接把 token 写在 shell 命令参数里，否则可能进入 history、进程信息或终端截图。

批准第一次私信

从准备授权的 Telegram 账号给 bot 发一条私信。默认 dmPolicy: "pairing" 会返回一次性配对码。只批准自己刚触发、平台和账号都匹配的请求：

hljs bash
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

当前配对码一小时后过期。它授权的是这位用户的私信入口，不代表此人已经能在所有群触发机器人，更不代表其他配对用户自动成为敏感命令的 owner。

群 ID 和用户 ID 不要放反

Telegram 群配置需要区分两类数字：

正数用户 ID：放在 allowFrom 或 groupAllowFrom，决定群里的谁可以触发；
负数群/超级群 chat ID（常以 -100 开头）：放在 channels.telegram.groups 下，决定哪个群被允许。

打开 openclaw logs --follow，在目标群里发一条可识别消息，从日志读取 ID。第一次加群时保留 requireMention: true，用 @botusername 触发。Telegram Privacy Mode 也影响 bot 能看到哪些群消息；不要因为一次没触发就直接关闭隐私模式或把 bot 设为管理员。

Telegram 验收：probe 解析到预期 bot；已批准用户发一条唯一短消息；日志显示入站和模型完成；同一私聊收到准确回复。私聊通过后，再只增加一个群并用 @ 提及重测。

再看 WhatsApp：先决定绑定哪个号码

OpenClaw WhatsApp 官方中文页说明当前路线是 WhatsApp Web/Baileys 外部插件，由 Gateway 持有链接会话，不存在另一条单独的 Twilio WhatsApp 渠道。

手工安装当前插件的命令是：

hljs bash
openclaw plugins install clawhub:@openclaw/whatsapp

专用号码还是个人号码

专用号码更推荐，因为 OpenClaw 身份、白名单和自聊行为更清楚。个人号码/自聊也受支持，但需要明确：发件人与已链接账号可能是同一个人，谁能解绑设备，换机器时会话由谁迁移。

配置里只使用手机号占位符，第一次关闭群访问：

hljs json5
{
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      allowFrom: ["<YOUR_NUMBER_E164>"],
      groupPolicy: "allowlist",
      groupAllowFrom: ["<YOUR_NUMBER_E164>"]
    }
  }
}

扫码链接并批准一位用户

hljs bash
openclaw channels login --channel whatsapp

登录只支持二维码。应在 Gateway 主机的交互终端中操作，确保手机能及时扫描实时二维码；经聊天或截图转发的二维码可能在送达前就过期。扫码后产生的 auth 目录等同凭证，不能随意复制、上传或让两台 Gateway 同时争用。

收到第一条私信配对请求后：

hljs bash
openclaw pairing list whatsapp
openclaw pairing approve whatsapp <CODE>
openclaw channels status --channel whatsapp --probe

WhatsApp 验收：probe 显示预期号码的 linked session 正常；批准号码的测试消息进入 Gateway；回复回到同一聊天。做到这一点之前，不添加群聊、更多号码或第二个账号。

Discord：先在私有服务器里验证最小权限

OpenClaw Discord 官方中文页要求先创建 application 和 bot。Discord 的在线圆点只说明部分连接状态，不能替代入站、模型和回传验收。

只启用第一次需要的 intents

在 Discord Developer Portal 的 Bot 页面启用：

Message Content Intent：普通文本路线必需；
Server Members Intent：建议开启；使用角色白名单、名称转 ID 或 channel-audience access groups 时必需；
Presence Intent：仅在确实需要 presence 更新时增加。

邀请 URL 使用 bot 和 applications.commands scopes。第一次文本测试至少给目标频道 View Channels、Send Messages、Read Message History、Embed Links 和 Attach Files；Add Reactions 可选。只有需要 thread 时才加入 Send Messages in Threads。Voice、moderation、roles、presence 都不是首测要求。

保存 token，再配对私信或允许一个频道

在 Gateway 主机配置 DISCORD_BOT_TOKEN，使用当前 catalog 安装/添加路线：

hljs bash
openclaw channels add --channel discord --use-env
openclaw channels status --channel discord --probe

若从私信开始：

hljs bash
openclaw pairing list discord
openclaw pairing approve discord <CODE>

若从服务器频道开始，优先用私有服务器、一个频道、一个用户，并使用数字 ID：

hljs json5
{
  channels: {
    discord: {
      groupPolicy: "allowlist",
      guilds: {
        "YOUR_SERVER_ID": {
          requireMention: true,
          users: ["YOUR_USER_ID"]
        }
      }
    }
  }
}

Discord 验收：probe 确认 bot 身份和必需 intents；允许用户在允许的私信或频道发出唯一消息；回复回到同一位置。若 bot 在线但群消息没有入站，先查 Message Content Intent、guild/channel/user 白名单和 @ 提及，不要先授予管理员权限。

Slack：先选 Socket 还是 HTTP

Slack 的第一步不是复制一大串 scope，而是确定 Gateway 如何接收事件。OpenClaw Slack 官方中文页给出两条主要路线。先安装官方插件：

hljs bash
openclaw plugins install @openclaw/slack

部署条件	Socket Mode	HTTP Request URLs
Gateway 是否要有公网入口	不需要	需要可访问的 HTTPS、DNS/TLS 和事件路径
网络方向	Gateway 主动连接 Slack WebSocket	Slack 向 Gateway 发送签名 HTTPS 请求
所需凭证	Bot token + 带 `connections:write` 的 App-Level Token	Bot token + Signing Secret
常见适用环境	单个 Gateway、开发机、无法接收入站 HTTPS 的内网	多副本 Gateway、已有反向代理或 webhook 基础设施

两种 transport 在消息和交互能力上可以达到一致，选择依据是网络和扩展责任，而不是功能排行榜。Socket 的 bot/app token 必须属于同一个 Slack app 和 workspace；HTTP 的 signing secret 必须与接收请求的 app 匹配。

从最小 manifest 开始

官方页面维护当前 minimal 和 recommended manifest。第一次只做私信或 @ 提及时，先用最小范围；文件、reaction、更多 history、App Home、slash command 和交互能力等到明确需要时再增加。旧教程里“把所有 history 和 write scopes 全开”的做法，会让权限审计和故障归因都变难。

Slack 私信默认支持配对：

hljs bash
openclaw pairing list slack
openclaw pairing approve slack <CODE>

频道白名单使用稳定的 Channel ID（例如 C...），不要把 #频道名直接当 key。allowlist 模式下，名称 key 可能不匹配，结果看起来就像“app 已连接但不回消息”。频道消息默认保留 @ 提及门控。

Slack 验收：probe 能解析匹配的 app 凭证和 transport；指定 workspace 的一位用户从私信或允许频道发出消息；回复回到同一 DM 或 thread。若出现 configured_unavailable、token mismatch、missing scope 或签名失败，只修对应凭证/transport，不扩大用户访问。

用一条消息走完七个环节

现在验证的是消息链路，不是配置文件。一个 token 可以有效，但发送者被白名单拒绝；Socket 可以连接，但事件未订阅；模型可以完成，但回复被发到错误线程。

发送测试前，同时打开状态和日志：

hljs bash
openclaw channels status --probe --json
openclaw channels logs --channel all
openclaw logs --follow

让指定用户从指定入口发送一条带唯一标记的短消息，例如：请只回复 CHANNEL-OK-714。记录本地时间、平台账号和准确目标（私聊、群、server channel、workspace channel 或 WhatsApp chat）。

环节	通过时应该看到什么	第一处失败通常属于谁
身份	probe 解析到预期 bot、app、workspace 或号码	选错账号、凭证或 linked session
传输	核心/插件运行且平台连接健康	插件、Gateway 网络、Socket/HTTP、polling 或 QR 会话
访问	发送者和目标符合 pairing/allowlist/mention	配对、用户 ID、群/频道 ID、guild/workspace 或命令授权
入站	唯一测试消息出现在对应日志时间窗	平台事件、intent、subscription、privacy 或路由
模型	预期智能体/模型完成这次请求	provider 认证、模型、限流、超时或 agent binding
出站	日志显示向原渠道和原目标发送	平台发言权限、签名、session、thread 或发送错误
可见回复	指定用户在同一位置看到准确回复	目标/线程错位、客户端可见性或最终投递

七项全部通过才算接通。保存脱敏记录：账号标签、目标 ID 或哈希、probe 结果、时间戳、必要错误行和可见回复。删除 token、signing secret、二维码、session 文件、私聊正文和无关日志。

每次只扩大一个边界

第一条私信成功后，下一步不是“全部开放”，而是增加一项，再走同一条验收链路。

下一步	新增加了什么	继续前必须重测
把一位用户从 pairing 变成明确 allowlist	持久身份授权	同一用户的私信入站、模型与可见回复
加一个群或频道	共享目标和稳定 ID	一位允许用户的 @ 提及
加一个可选功能	scope、event、intent、文件、command 或互动	新功能动作 + 原来的纯文本回复
加更多用户	更多人可以触发	允许用户和不允许用户都要测试
加第二个账号/渠道	新身份、凭证、transport、路由和故障负责人	新路线完整七步验收

open 不是 pairing 的自然下一档，而是另一种运行模式。开放私信需要明确的通配符，意味着任何找到机器人账号的人都有机会触发。只有在确实要做公共 bot、工具能力已经收紧、滥用控制和负责人都明确时才考虑。

命令权限也要单独检查。配对一位私信用户，并不意味着他自动成为所有群和敏感命令的 owner。让 commands.ownerAllowFrom、渠道白名单、群内用户限制和工具审批与真实操作人员保持一致。

失败时，只修第一处没有证明的环节

不要在一次尝试里同时重装插件、换 token、重启 Gateway、改群策略和换模型。这样即使恢复，也无法知道哪一项真正修复了问题。

看到的现象	先留在哪个环节	最小下一步
`channels list --all` 里没有目标渠道	catalog/插件/安装	使用当前渠道页和 `channels add --channel <name>`
Gateway probe 失败	OpenClaw 运行时	暂停渠道配置，先修 Gateway
probe 报凭证无效或无法解析	secret 或平台身份	核对选中的账号；必要时只轮换这一项
已连接但没有入站事件	pairing、allowlist、mention、intent、subscription 或 privacy	对照指定发送者和目标 ID
有入站但模型没有完成	agent/model/provider	独立验证模型路线，不扩大渠道权限
模型完成但没有可见回复	出站权限、目标/thread、session 或平台发送	查看出站日志和实际 destination
在线但仍沉默	已配置渠道的运行故障	使用中文 OpenClaw 无回复排查找到第一处断点
token、二维码或会话目录泄露	平台凭证与事件响应	撤销/轮换这一项，解绑会话并重新完成验收

每做一个修改，都重新发送原来的唯一测试消息，并确认回复回到原位置。不要把“状态变绿”当成回复已经恢复。

常见问题

OpenClaw 第一个消息渠道应该选哪个？

选择自己能管理身份和部署边界的那一个。个人独立 bot 可以先看 Telegram；必须使用手机号时看 WhatsApp；有私有服务器时看 Discord；团队工作流已经在 workspace 中时看 Slack。不要根据“功能最多”决定首选。

为什么显示 channel 或 plugin unavailable？

先运行 openclaw channels list --all。Telegram 当前在核心包中，Discord、Slack、WhatsApp 当前属于插件。使用 openclaw channels add --channel <name> 或对应官方页面的当前安装说明，不要从旧教程猜包名。

Telegram 要运行 `openclaw channels login telegram` 吗？

不要。Telegram 由准确的 @BotFather 创建 bot，并在 Gateway 主机配置 token。交互式 channels login 适合 WhatsApp 这类二维码/会话渠道。

私信配对后，群聊是否自动可用？

不会。pairing 只批准对应私信身份。群聊还需要允许群/频道 ID、群内发送者规则和 @ 提及；Discord/Slack 还涉及 guild、workspace、channel 和平台权限。

Discord 第一次文本测试要开哪些权限？

Message Content Intent 必须开启。邀请使用 bot 和 applications.commands scopes，目标频道至少需要 View Channels、Send Messages、Read Message History、Embed Links 和 Attach Files。角色/受众规则需要 Server Members Intent；reaction、thread、voice、moderation 和 presence 随需求后加。

Slack 应该选 Socket Mode 还是 HTTP Request URLs？

单个 Gateway、能向 Slack 发出 WebSocket、但不方便提供公网 HTTPS 时选 Socket Mode。多副本 Gateway 或已有公网 webhook 基础设施时选 HTTP。前者使用 bot token + app-level token，后者使用 bot token + signing secret。

token、signing secret 和 WhatsApp 会话放在哪里？

放在 Gateway 主机的受保护环境变量、文件或当前 SecretRef 中。不要放进聊天、截图、issue、Git、完整日志和文章示例。WhatsApp auth 目录和二维码同样属于凭证。

机器人显示在线，但为什么没有回复？

在线只证明部分 transport。运行 openclaw channels status --probe，打开日志，发送一条唯一消息，然后依次确认身份、访问、入站、模型、出站和可见回复。不要先随机增加权限。

什么时候可以接第二个渠道？

第一个渠道必须先为指定用户走完七步验收，并在增加一个群或一个持久 allowlist 后仍然正常。第二个渠道会带来新的身份、插件/transport、凭证、访问策略和故障负责人，应当单独验收。

WhatsApp 必须使用专用号码吗？

不是必须，但更推荐。专用号码能把 OpenClaw 身份和白名单边界分开；个人号码/自聊也受支持。无论哪种方式，都要明确号码和 linked session 的负责人，并先验证一位批准用户。

一个受保护、能完成完整回复的渠道，就是第一阶段的完成。下一次扩展前，先说清楚新增了什么、谁负责，以及用哪条相同测试证明它没有破坏原来的链路。

OpenClaw 接入 Telegram、Discord、Slack 还是 WhatsApp？先安全接通一个

文章目录

加渠道前，先证明 Gateway 和模型能工作

选渠道不是比功能，而是确定谁来负责

接通前，把五件事写清楚

凭证只能留在 Gateway 主机

先接 Telegram：从一位私信用户开始

创建 bot 并保护 token

批准第一次私信

群 ID 和用户 ID 不要放反

再看 WhatsApp：先决定绑定哪个号码

专用号码还是个人号码

扫码链接并批准一位用户

Discord：先在私有服务器里验证最小权限

只启用第一次需要的 intents

保存 token，再配对私信或允许一个频道

Slack：先选 Socket 还是 HTTP

从最小 manifest 开始

用一条消息走完七个环节

每次只扩大一个边界

失败时，只修第一处没有证明的环节

常见问题

OpenClaw 第一个消息渠道应该选哪个？

为什么显示 channel 或 plugin unavailable？

私信配对后，群聊是否自动可用？

Discord 第一次文本测试要开哪些权限？

Slack 应该选 Socket Mode 还是 HTTP Request URLs？

token、signing secret 和 WhatsApp 会话放在哪里？

机器人显示在线，但为什么没有回复？

什么时候可以接第二个渠道？

WhatsApp 必须使用专用号码吗？

文章标签

分享这篇文章

相关文章

OpenClaw 发消息不回复？先找到消息卡在哪一步

OpenAI Workspace Agents 怎么用：先确认权限，再构建、触发和治理

OpenClaw 安装失败怎么修？先找到第一条有效报错

文章目录

加渠道前，先证明 Gateway 和模型能工作

选渠道不是比功能，而是确定谁来负责

接通前，把五件事写清楚

凭证只能留在 Gateway 主机

先接 Telegram：从一位私信用户开始

创建 bot 并保护 token

批准第一次私信

群 ID 和用户 ID 不要放反

再看 WhatsApp：先决定绑定哪个号码

专用号码还是个人号码

扫码链接并批准一位用户

Discord：先在私有服务器里验证最小权限

只启用第一次需要的 intents

保存 token，再配对私信或允许一个频道

Slack：先选 Socket 还是 HTTP

从最小 manifest 开始

用一条消息走完七个环节

每次只扩大一个边界

失败时，只修第一处没有证明的环节

常见问题

OpenClaw 第一个消息渠道应该选哪个？

为什么显示 channel 或 plugin unavailable？

Telegram 要运行 openclaw channels login telegram 吗？

私信配对后，群聊是否自动可用？

Discord 第一次文本测试要开哪些权限？

Slack 应该选 Socket Mode 还是 HTTP Request URLs？

token、signing secret 和 WhatsApp 会话放在哪里？

机器人显示在线，但为什么没有回复？

什么时候可以接第二个渠道？

WhatsApp 必须使用专用号码吗？

文章标签

分享这篇文章

相关文章

OpenClaw 发消息不回复？先找到消息卡在哪一步

OpenAI Workspace Agents 怎么用：先确认权限，再构建、触发和治理

OpenClaw 安装失败怎么修？先找到第一条有效报错

Telegram 要运行 `openclaw channels login telegram` 吗？