海外三家怎么比？Slack、Telegram、Discord 在两边的接入方式并列
Slack、Telegram、Discord 这三个是两边都覆盖的海外渠道。差异不在「有没有」，在接入方式与所处位置。
形态前提：WorkBuddy 是商业闭源桌面客户端，三个渠道各有独立官方接入指南；OpenClaw 是 MIT 开源自托管 Gateway 网关，这三个在它的核心渠道列表里（文档首页定位句就点了 Discord、Slack、Telegram）。
依据：WorkBuddy 官方文档《Slack 接入指南》《Telegram 接入指南》《Discord 接入指南》（
Platform-Integration/下三篇）；OpenClaw 官方中文文档zh-CN/（快速开始）与zh-CN/channels/下各页。核对日均为 2026-08-16。各平台侧规则以对应平台官方为准。我们没有安装任何一方。
一、位置差异：核心 vs 平级
OpenClaw 的文档首页定位句里直接列了这三个：
支持 Discord、Google Chat、iMessage、Matrix、Microsoft Teams、Signal、Slack、Telegram、WhatsApp、Zalo 等。
它们是 OpenClaw 的核心渠道——而微信、QQ Bot、腾讯元宝在文档里是归在「Regional platforms（中文区渠道）」分组下的。
WorkBuddy 侧则相反：九个平台平级列在助理功能的支持表里，全部标注「✅ 支持」，且每个都有独立的官方接入指南。
这个位置差异本身就反映了两边的重心——一个的核心渠道是海外主流 IM，一个把国内外平台同等对待。
二、WorkBuddy 侧三家的接入要点
Slack
官方明确用的是 Socket Mode：
该集成使用助理远程控制能力，并通过 Socket Mode 建立连接，无需公网 Webhook 地址。
两个 Token 认前缀：xapp- 是 App Token（Socket Mode 生成时创建，scope 要有 connections:write）；xoxb- 是 Bot Token（Install to Workspace 后获得）。
六个 Bot 权限：app_mentions:read、chat:write、im:history、im:read、im:write、files:read、files:write。
两个事件：message.im 和 app_mention，加完要点 Save Changes。
★ 最容易漏的最后一步：保存后 WorkBuddy 会显示一个 gateway pairing code，你要回 Slack 打开与 bot 的私聊窗口，把这个配对码发给它，渠道状态才会变 Connected。
Telegram
九个平台里流程最短的之一：搜 @BotFather → 发 /newbot → 输显示名 → 输用户名（必须唯一且以 bot 结尾）→ 拿 Bot API Token → 填进 WorkBuddy（侧边栏助理图标 → 助理 Settings → Channels → Telegram）→ Save。
★ 必须先发 /start：官方 FAQ 明确「Bot 显示 unavailable → 确认你已经打开 bot 对话并发送过 /start」。这是 Telegram 的机制——bot 不能主动给没跟它说过话的人发消息。
前置条件最松：只要一个 Telegram 账号，不需要企业账号、管理员权限、实名认证。
Token 可重置：BotFather 里 /mybots → 选 bot → API Token → Revoke current token。
官方还给了两个实用点：/clear 清理当前会话历史；接收支持 Markdown 格式的执行结果。
Discord
★ 三个 Privileged Gateway Intents 必开：Presence Intent、Server Members Intent、Message Content Intent，开完点 Save Changes。
其中 Message Content Intent 是致命的那个——官方 FAQ 明确：「Bot 不回复消息 → 确认 Developer Portal 中已启用 Message Content Intent」。不开的表现是 bot 在线但收不到消息内容，没有任何报错。
Bot Token 只显示一次：官方标了「重要」——Token 只会完整显示一次，如果丢失需要重新生成（可 Reset Token 重来）。
邀请链接：OAuth2 → URL Generator → Scopes 选 bot + applications.commands → Bot Permissions 选 Send Messages、Read Message History、Attach Files、Use Slash Commands。
一个好用的分诊：看 bot 的在线状态——离线查你的电脑（客户端没运行 / 助理没启用）；在线但不回复查 Message Content Intent。
三、OpenClaw 侧
这三个在 OpenClaw 是核心渠道，走的是它统一的渠道体系。官方在快速开始里给的整体流程是：装 OpenClaw → openclaw onboard --install-daemon 完成引导并安装服务 → 连接渠道。
准入用 OpenClaw 的配对和允许列表模型（openclaw pairing list <channel> / approve）。
具体每个渠道的配置细节以 OpenClaw 官方文档为准——本文重点是并列关系与 WorkBuddy 侧的可操作项。
四、并列对照
| WorkBuddy | OpenClaw | |
|---|---|---|
| 这三家的位置 | 九平台之一，平级 | 核心渠道（首页定位句里就列了） |
| 配置方式 | 各自独立的图形化接入指南 | 统一的渠道体系 + 命令行 |
| 前置门槛 | 各平台各自的凭证；先得有 WorkBuddy 客户端 | 先得有一个跑起来的 Gateway 网关（Node 22.22.3+ / 24.15+ / 25.9+，自备模型 API 密钥） |
| 准入控制 | 官方未提供这三个平台的准入配置说明 | 配对与允许列表模型 |
| 独有覆盖 | 企业微信、钉钉（OpenClaw 首页列表未出现） | iMessage、Signal、WhatsApp、Microsoft Teams、Google Chat、Matrix 等 |
五、三家在 WorkBuddy 侧的配置量排序
如果你要在这三个里挑一个先配：
| 平台 | 凭证数 | 额外配置 | 有无发布审核 |
|---|---|---|---|
| Telegram | 1 个 Token | 无 | 无 |
| Discord | 1 个 Token | 三个 Intents + 邀请权限四项 | 无 |
| Slack | 2 个 Token | 六个权限 + 两个事件 + 一次配对 | 无 |
三个都没有「应用必须发布」这一关——那是钉钉与飞书才有的。
建议：想快速验证这套东西好不好用，从 Telegram 开始；团队在哪个就用哪个。
六、两边共同的三条
一、宿主得活着。 WorkBuddy 官方在助理文档「注意事项」里明写电脑需要保持开机并运行 Tencent WorkBuddy；OpenClaw 的 Gateway 网关同理（官方在 Cron 文档里写明网关必须处于运行状态）。
二、频道里别人也能指挥它。 Slack 和 Discord 官方都把「私聊」和「频道 @ 提及」分开列了——Discord 那边写得尤其明白：私聊 bot 发送私密任务。
而 bot 背后连的是你的机器。所以：私密任务走私聊；敏感数据别在频道场景下处理（结果会发在频道里）。
三、凭证别带多余空格。 官方在多个平台指南里反复提醒。先粘到纯文本编辑器看一眼首尾再填——首尾空白肉眼看不出来，但会让配置直接失败。
七、我们不写的东西
- 不写谁的海外渠道支持更好——需逐项验证，我们没做；
- 不复述 OpenClaw 各渠道页的配置细节——以其官方文档为准；
- 不写消息延迟、稳定性等表现——不在双方官方文档里；
- 不写在特定网络环境下的可用性——不在官方文档范围内。
八、三家各自的官方排查表
WorkBuddy 侧三篇指南都给了排查表，放在一起看很有价值——故障现象和对应的检查点差别很大。
Slack（官方五条）：
| 问题 | 处理方式 |
|---|---|
| Bot 没有响应 | 确认 WorkBuddy 正在运行，且助理已启用 |
| Socket Mode 连接失败 | 确认 App Token 已包含 connections:write 权限 |
| Bot Token 无效 | 重新安装 Slack App 到工作区，重新获取 Bot Token |
| 收不到消息事件 | 确认 message.im 和 app_mention 事件已保存 |
| 连接中断 | 检查网络，WorkBuddy 会自动尝试重连 |
最后一条是好消息：偶发的短暂失联，等一下可能就自己好了。
Telegram（官方四条）：Bot 没有响应 → 确认客户端运行且助理已启用；消息无法送达 → 检查电脑和 Telegram 客户端两边的网络；Bot Token 无效 → 在 BotFather 里重新生成并更新；Bot 显示 unavailable → 确认已打开对话并发送过 /start。
Discord（官方五条）：Bot 显示离线 → 确认客户端运行且助理已启用；Bot 不回复消息 → 确认已启用 Message Content Intent；出现 Missing Permissions → 用 URL Generator 重新生成邀请链接重新邀请；Bot Token 无效 → Developer Portal 里重置并更新；服务器中看不到 bot → 确认已完成 OAuth2 邀请流程。
三张表的共同点：第一条都是「确认客户端在运行且助理已启用」——这也印证了那条共同前提。
三张表的差异点：Slack 的坑在权限 scope 与事件保存；Telegram 的坑在没发 /start；Discord 的坑在Intent 没开。每家有每家的静默失败方式，知道往哪儿查能省很多时间。
九、一个实用的选择建议
如果你的团队同时在用其中两三个，别都接上。
理由：接得越多，你要维护的凭证、要排查的链路就越多，而它们背后连的是同一台电脑——多接几个渠道并不会让它干得更多，只是多了几个入口。
建议：选你日常沟通最集中的那一个接上，用熟了再说。真的有多渠道需求（比如内部用 Slack、社区用 Discord），再加第二个。
小结
- 位置差异：这三家是 OpenClaw 的核心渠道（首页定位句就列了），在 WorkBuddy 侧是九平台之一、平级。
- Slack：走 Socket Mode，无需公网 Webhook；两个 Token 认前缀（
xapp-/xoxb-）；六个权限 + 两个事件；★最后要在私聊里发 gateway pairing code。 - Telegram：流程最短之一，一个 Token；用户名必须唯一且以
bot结尾；★必须先发/start；Token 可在 BotFather 里 Revoke 重置；/clear清会话。 - Discord：★ 三个 Intents 必开，其中 Message Content Intent 不开则 bot 在线但收不到消息；Bot Token 只完整显示一次（可 Reset）；分诊看在线状态。
- 三家**都没有「应用必须发布」**这一关（那是钉钉与飞书才有的）。
- 想快速验证：从 Telegram 开始。
- 共同三条：宿主得活着、频道里别人也能指挥它（私密任务走私聊）、凭证别带空格。
双方功能与文档表述均以各自官方为准，各平台侧规则以对应平台官方为准，核对日 2026-08-16。