3.2 Discord与Slack接入

生成模型：gpt-5.4 (openai/gpt-5.4) Token 消耗：输入 ~18k tokens，输出 ~4.5k tokens（本节）

---

如果说 Telegram 是“最容易迈出去的第一步”，那 Discord 和 Slack 更像“真正进入多人协作场景”。它们都很适合把 OpenClaw 放进团队讨论、值班频道、知识问答或者项目协作里，但接入思路和 Telegram 有几个明显区别。

最重要的一点是：Discord 和 Slack 都不是单纯“拿个 token 就完事”的平台。 你得先在平台后台创建应用，明确机器人身份，再把它邀请进服务器或工作区，最后还要处理权限、事件订阅、命令和线程这些细节。

这一节我们就做三件事：

1. 把 Discord Bot 从零建出来，接到 OpenClaw

2. 把 Slack App 的双 token 模式讲明白，并给出可跑配置

3. 顺带看一下 WhatsApp、Signal、iMessage 这些别的通道，大概是什么接法

3.2.1 先说 Discord：它为什么适合做 OpenClaw 通道

Discord 的优势不只是“年轻人常用”。从 AI 助手的角度看，它有几个很实在的优点：

• 服务器、频道、私信结构清楚

• Bot 能力成熟，权限粒度细

• Slash Commands 生态很适合做命令型交互

• 既能私聊，也能进群组频道，还能做线程化讨论

如果你是想做“团队里的 AI 助手”，Discord 基本是很自然的一站。

3.2.2 Discord 里几个你会反复见到的词

Application

在 Discord 里，Bot 不是凭空冒出来的。你得先在开发者后台创建一个应用。这个应用像个总壳，Bot 只是它下面的一个能力。

Bot Token

和 Telegram 类似，Discord Bot 也有 token。这个 token 就是 OpenClaw 登录 Discord 的关键凭证。

Guild

就是 Discord 的“服务器”。很多中文教程会直接说服务器，这样理解就够了。

Intent

可以理解成“你要告诉 Discord，Bot 打算关心哪些事件”。如果没开对应 Intent，某些消息即使真的发生了，Bot 也收不到。

尤其要注意 Message Content Intent。如果你希望 Bot 读到普通文本消息内容，这项往往很关键。

3.2.3 第一步：创建 Discord Application 和 Bot

操作路径基本是这样：

1. 打开 Discord Developer Portal

2. 点击 New Application

3. 给应用起一个名字，比如 OpenClaw Team Bot

4. 创建完成后，进入左侧 Bot

5. 点击 Add Bot

6. 确认创建

创建好以后，你会在 Bot 页面看到用户名、头像、Token 管理等信息。这里最重要的是生成并复制 Bot Token。

注意：Discord 现在通常不会一直明文展示旧 token。你需要在后台重新生成或点击显示后立刻保存。操作风格跟很多云服务 API Key 很像：给你一次看清楚的机会，后面就别指望平台替你记着了。

截图说明建议

• 图 3-8：Discord Developer Portal 新建 Application 界面

• 图 3-9：Bot 页面点击 Add Bot

• 图 3-10：生成 token 后的页面，token 需打码

3.2.4 第二步：开启必要的 Intent

这是 Discord 接入里最容易漏的一步。

进入 Bot 设置页面后，通常要检查这些项：

• MESSAGE CONTENT INTENT

• SERVER MEMBERS INTENT（如果你涉及成员信息）

• PRESENCE INTENT（如果你确实需要在线状态）

对于大多数 OpenClaw 聊天场景，重点是第一项：MESSAGE CONTENT INTENT。

不开它，Bot 往往就看不到你发的普通文本内容。结果就是：

• 机器人在线

• 权限也有

• 甚至能发消息

• 但就是像“听不懂人话”一样没反应

本质不是它不会回，而是它根本没读到正文。

3.2.5 第三步：邀请 Bot 进你的 Discord 服务器

Bot 在后台建好，还不等于它已经进到你的服务器里。你还得生成邀请链接，把它拉进去。

一般做法是：

1. 在 Developer Portal 里找到 OAuth2 / URL Generator

2. 勾选 bot

3. 如果你要用原生 Slash Commands，也勾选 applications.commands

4. 在权限里勾选最小必要集合

常见最小权限包括：

• View Channels

• Send Messages

• Read Message History

• Embed Links

• Add Reactions（如果你要做确认反馈）

复制生成的 URL，在浏览器打开，选择目标服务器，把它邀请进去。

截图说明建议

• 图 3-11：OAuth2 URL Generator 勾选 bot 和 applications.commands

• 图 3-12：浏览器中邀请 Bot 进服务器的确认界面

3.2.6 把 Discord token 写进 OpenClaw 配置

最小可跑的配置可以先这样写：

{
  channels: {
    discord: {
      enabled: true,
      token: "YOUR_DISCORD_BOT_TOKEN",
    },
  },
}

如果你希望命令体验更完整，可以再加一些和命令、群聊门控有关的项：

{
  channels: {
    discord: {
      enabled: true,
      token: "YOUR_DISCORD_BOT_TOKEN",

      commands: {
        native: true,
        prefix: "!",
      },

      mentionGating: true,

      allowlist: {
        guilds: ["123456789012345678"],
        channels: ["234567890123456789"],
        users: ["345678901234567890"],
      },

      maxLinesPerMessage: 30,
    },
  },
}

这里稍微解释一下。

commands.native

表示尽量利用 Discord 自己的原生命令体系，比如 Slash Commands。用户输入时会更像“平台原生功能”，而不是一个纯文本聊天机器人。

prefix

如果你还支持文本命令，这个前缀决定什么样的消息会被当成命令。比如 !ask、!reset。

maxLinesPerMessage

这是偏实用的限制项。因为 Discord 单条消息虽然不短，但 AI 回复经常一大坨，做一点分段更稳，不然可读性会很差。

3.2.7 Discord 里怎么做第一次验证

建议按这个顺序测：

先测私信

直接给 Bot 发私信，问一句简单的话：

帮我写一个今晚的读书计划。

私信环境变量最少，排查最干净。如果私信都不通，先别进服务器里折腾。

再测服务器频道

在你刚邀请进去的频道里发：

@BotName 帮我总结一下这个频道最近的任务重点。

如果你开了 mentionGating，那就必须明确提及它。没 @ 而不回，未必是问题。

最后测命令

如果你开了原生命令或文本命令，再试：

!reset

或者在 Slash Commands 菜单里看命令是否注册成功。

3.2.8 Discord 常见问题，九成不是 OpenClaw 主逻辑坏了

情况一：Bot 在线，但死活不回

优先查：

• token 对不对

• Bot 是否真的被邀请进服务器

• MESSAGE CONTENT INTENT 是否开启

• 当前频道权限是否允许它看和发

情况二：私信能用，服务器频道不行

优先查：

• 频道权限单独被限制了

• 你开了 mentionGating，但没有 @ 它

• 频道不在 allowlist 内

情况三：命令菜单没有出现

优先查：

• OAuth2 邀请时是否勾选 applications.commands

• 配置里是否启用了原生命令

• 平台同步有时有一点延迟，不一定是挂了

3.2.9 Slack 跟 Discord 最大的不同：它是 App 模式，不只是 Bot 模式

Slack 接入常常让新手更晕，因为它不是“注册个 Bot 就结束”。更准确地说，你是在创建一个 Slack App，然后这个 App 里包含 Bot 用户、事件订阅、Socket 连接、权限范围等一整套东西。

如果你只记一句话，那就是：Slack 不是单 token 世界，它经常是双 token 甚至多凭证协作。

3.2.10 先把 Slack 的两个核心 token 讲透

OpenClaw 接 Slack 时，常会提到两个 token：

Bot Token

通常长得像 xoxb-...，这是 Bot 身份调用 Slack API 的主要凭证。发消息、读频道、响应事件，很多动作都离不开它。

App Token

通常长得像 xapp-...，它更多用于 App 级连接，尤其是在 Socket Mode 里很常见。简单说，它让你的应用和 Slack 平台之间维持一条事件通信通道。

如果你看到“Bolt SDK + App Token + Bot Token”这组词，不要慌。它表达的其实是：

• 用 Slack 官方的 Bolt 框架接事件

• 用 App Token 建立应用级连接

• 用 Bot Token 执行具体聊天动作

3.2.11 第一步：创建 Slack App

基本步骤：

1. 打开 Slack API 后台

2. 点击 Create New App

3. 可以从零开始，也可以从 manifest 开始

4. 选择你的工作区

5. 创建后进入 App 配置页

然后你要做几件关键事：

• 打开 Socket Mode

• 生成 App Token

• 配置 OAuth & Permissions

• 安装 App 到目标工作区

• 生成 Bot User OAuth Token

截图说明建议

• 图 3-13：Slack API 后台创建新 App

• 图 3-14：Socket Mode 页面生成 xapp- token

• 图 3-15：OAuth & Permissions 页面生成 xoxb- token

3.2.12 Slack 需要哪些权限范围

Slack 里权限通常叫 scopes。你可以把它理解成“这个 App 允许做哪些事”。

常见聊天场景至少会涉及：

• app_mentions:read

• channels:history

• channels:read

• chat:write

• groups:history

• groups:read

• im:history

• im:read

• im:write

你不一定每项都需要，但如果你要同时覆盖公开频道、私有频道、私聊，那 scopes 不会太少。

这里和 Discord 的一个差别是：Discord 更像“勾权限 + 勾 Intent”，Slack 更像“配 scopes + 订阅事件 + App 安装”。

3.2.13 把 Slack 写进 OpenClaw 配置

下面是一个比较典型的 Slack 通道配置：

{
  channels: {
    slack: {
      enabled: true,
      appToken: "xapp-1-A0000000000-0000000000-abcdefghijklmnop",
      botToken: "你的-slack-bot-token",

      mentionGating: true,

      allowlist: {
        channels: ["C0123456789"],
        users: ["U0123456789"],
      },

      threads: {
        enabled: true,
      },
    },
  },
}

这里的 threads.enabled 很值得注意。Slack 的实际使用里，线程是非常常见的协作单位。很多团队不希望 Bot 每次都把回复刷在主频道，而是希望它顺着某条消息在线程里接着聊。这样更整洁，也更符合工作区习惯。

3.2.14 Slack 里怎么验证是否接通

验证建议也按“先简单、后复杂”的顺序：

测试 1：私聊 Bot

给 Bot 发一句：

请帮我整理一下今天的待办。

测试 2：频道中 @ 提及

在频道里发：

@OpenClaw 帮我总结刚才讨论的上线风险。

测试 3：线程延续

如果它在某条消息下开了线程，再追问一句，看看上下文是否能顺下来。

Slack 场景里，线程连续性比“会不会回第一句”更重要。因为团队协作的真实对话，往往不是一轮结束，而是在线程里来回追问。

3.2.15 Discord 和 Slack，到底谁更适合你

如果你是个人项目、兴趣社区、开发者群体，Discord 往往更顺手。它天然适合：

• 公开频道

• 社区问答

• 命令式交互

• 开发协作

如果你是公司内部协作、日常办公、项目跟踪，Slack 通常更自然。它天然适合：

• 团队工作流

• 线程讨论

• 内部通知和知识问答

• 与其他办公系统串联

不是说一个比另一个“高级”，而是使用环境不一样。你先看用户在哪，不要倒过来看技术炫不炫。

3.2.16 其他几个常被提到的通道，先知道门路就够了

这一章重点不是把所有通道都讲到可部署，但你至少得知道 OpenClaw 的多通道世界长什么样。

WhatsApp

常见接法会提到 Baileys。它不是 WhatsApp 官方 Bot 平台那一路，而是围绕 WhatsApp Web 协议的一套实现。优点是灵活，接近真人账号使用体验；缺点是运维和稳定性会更微妙，也更依赖协议变化。

Signal

常见方案会依赖 signal-cli 一类工具链。它更像“把命令行或桥接程序接到消息系统里”，不是那种纯网页后台点几下就完事的通道。

iMessage

这一类通常和宿主系统绑定很深。你会看到像 BlueBubbles、macOS 原生桥接之类方案。它的难点不在 token，而在运行环境、设备权限和系统耦合。

所以从上手顺序来说，最推荐还是：

1. Telegram

2. Discord

3. Slack

4. 再看 WhatsApp / Signal / iMessage

这个顺序的原因不是功能强弱，而是成功率和排错成本。

本节小结

1. Discord 接入的关键不只是 Bot Token，还包括 Application 创建、服务器邀请和 Intent 开启。

2. Message Content Intent 对很多 Discord 聊天场景是关键项，不开它，机器人可能根本读不到正文。

3. Slack 更像 App 集成而不是单纯 Bot 集成，常见是 App Token + Bot Token 一起使用。

4. Slack 的线程机制非常适合协作型对话，配置时最好把线程场景一起考虑进去。

5. WhatsApp、Signal、iMessage 也都能接，但它们更依赖桥接层或宿主环境，建议等前面两个主流通道跑顺以后再扩展。