1. 从单平台到多平台OpenClaw 消息路由的真实痛点如果你已经在本地跑通了 OpenClaw 接单个 Discord 或 Telegram接下来大概率会撞上同一堵墙两个平台的 Bot Token 各管各的模型调用却要重复配一遍消息格式还互不兼容。我试过最笨的办法——给每个平台单独写一套转发脚本结果 Discord 的 embed 发到 Telegram 变成纯文本Telegram 的 MarkdownV2 转回 Discord 又满屏转义符维护成本直接翻倍。OpenClaw 的多平台集成能力本质上是把「平台适配」和「模型调用」拆成两层。平台层负责把 Discord、Telegram 的 Webhook 事件归一化成统一消息结构模型层则通过一个统一的 API 通道完成推理。这样你新增一个平台时只需要在openclaw.json的channels字段里加一段配置不用动核心路由逻辑。这篇文章聚焦 Discord 与 Telegram 的 Webhook 接入给出可复制的端点配置和统一 Key 接入示例并附上消息收发链路的验证动作。适合已经跑通单平台、想扩展到多平台消息路由的开发者。核心检索词就三个OpenClaw 多平台集成、Discord Webhook、Telegram Webhook。读完你能拿到一套能直接粘贴的配置以及一套排障时能对照的报错清单。先说清楚统一 Key 在这里解决什么问题。OpenClaw 本身不绑定任何模型供应商它通过 OpenAI 兼容的 API 通道调用模型。如果你给 Discord 配一个 Key、给 Telegram 配另一个 Key不仅管理麻烦跨平台会话状态也没法共享。用 TaoToken 的统一 Key 接入后两个平台走同一个 Base URL 和同一个 Key模型侧只认一个调用来源会话上下文和记忆系统才能真正跨平台复用。2. TaoToken 前置准备统一 Key 与 API 通道配置在动 Discord 和 Telegram 的 Webhook 之前先把模型调用通道打通。这一步不做后面两个平台的消息进来了也没有模型能回。TaoToken 提供 OpenAI 兼容的 API 接口Base URL 是https://taotoken.net/api注意这个地址不带任何查询参数。你需要先在控制台创建一个 API Key然后把它写进 OpenClaw 的模型配置里。OpenClaw 的模型配置和通道配置是分开的模型配置通常在openclaw.json的models或providers字段具体字段名取决于你的版本下面给的是通用写法。先拿 Key。访问控制台创建 API Key建议命名成openclaw-multi这种能一眼看出用途的名字方便后面轮换。创建后复制 Key它只会完整显示一次。拿到 Key 之后在 OpenClaw 的配置里加一个 provider 条目。这里的关键是baseURL必须指向https://taotoken.net/apiapiKey填你刚创建的 Keymodel填你要用的模型 ID。模型 ID 可以在模型对话页面确认不同模型的 ID 不一样别照抄。{ providers: { taotoken: { type: openai-compatible, baseURL: https://taotoken.net/api, apiKey: sk-your-taotoken-key-here, model: your-model-id, timeout: 60000 } }, defaultProvider: taotoken }这里有个容易踩的坑baseURL末尾不要加/v1。OpenClaw 的 OpenAI 兼容层会自己拼接路径你加了/v1就变成/v1/v1/chat/completions直接 404。我实测下来https://taotoken.net/api这个写法在 OpenClaw 里是能正常打通的。配置写完后先用一个最小请求验证通道是否通。不要急着配 Discord 和 Telegram先确认模型侧没问题。用 curl 发一个 chat completions 请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-your-taotoken-key-here \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [{role: user, content: ping}], max_tokens: 16 }如果返回里能看到choices数组和正常的content说明 Key 和通道都没问题。如果返回 401检查 Key 是否复制完整、有没有多余空格。如果返回model not found说明模型 ID 写错了回模型对话页面重新确认。这一步做完你手里就有了一个可用的统一 API 通道。接下来 Discord 和 Telegram 的 Webhook 都走这个通道不需要各自再配 Key。3. 可复制配置Discord 与 Telegram Webhook 端点接入现在进入正题把两个平台的 Webhook 接进来。OpenClaw 的通道配置集中在openclaw.json的channels字段Discord 和 Telegram 各占一个子对象。先看 Discord。Discord 的 Bot 接入需要botToken这个在 Discord Developer Portal 的 Bot 页面获取。Webhook 模式下OpenClaw 会启动一个 HTTP 服务接收 Discord 的事件推送所以还需要配port和path。注意 Discord 的 Webhook 需要公网可达本地开发可以用内网穿透工具把端口暴露出去但这里不展开讲穿透工具的具体选型。{ channels: { discord: { enabled: true, botToken: your-discord-bot-token, guildId: your-guild-id, channelIds: [your-channel-id], webhook: { enabled: true, port: 8080, path: /webhook/discord, publicKey: your-discord-public-key }, groupPolicy: open, prefix: / } } }Discord 的publicKey在 Developer Portal 的 General Information 页面用于验证 Webhook 请求签名。这个字段不填的话OpenClaw 会跳过签名校验本地测试可以生产环境必须填。再看 Telegram。Telegram 的 Webhook 配置和 Discord 略有不同它需要你先用 BotFather 拿到botToken然后通过setWebhook接口把回调地址注册到 Telegram 服务器。OpenClaw 的配置里写的是接收端参数{ channels: { telegram: { enabled: true, botToken: your-telegram-bot-token, webhook: { enabled: true, port: 8081, path: /webhook/telegram, secretToken: your-telegram-secret-token }, allowedChatIds: [123456789], groupPolicy: open } } }Telegram 的secretToken是你自己生成的随机字符串在调用setWebhook时作为secret_token参数传给 Telegram之后 Telegram 每次推送都会带上这个 token 的哈希OpenClaw 用它来校验请求来源。生成方式可以用openssl rand -hex 32。两个平台配好后完整的openclaw.json结构大致是这样注意providers和channels是平级的{ providers: { taotoken: { type: openai-compatible, baseURL: https://taotoken.net/api, apiKey: sk-your-taotoken-key-here, model: your-model-id } }, defaultProvider: taotoken, channels: { discord: { enabled: true, botToken: your-discord-bot-token, webhook: { enabled: true, port: 8080, path: /webhook/discord, publicKey: your-discord-public-key } }, telegram: { enabled: true, botToken: your-telegram-bot-token, webhook: { enabled: true, port: 8081, path: /webhook/telegram, secretToken: your-telegram-secret-token } } } }这里有个细节Discord 和 Telegram 用了不同的端口8080 和 8081。OpenClaw 支持在同一个进程里监听多个端口但如果你用反向代理统一入口也可以让两个通道共用一个端口通过path区分。共用端口时把port改成同一个值path保持不同即可。配置写完后启动 OpenClaw观察日志里有没有channel discord listening on :8080和channel telegram listening on :8081这样的输出。如果有说明两个 Webhook 端点都起来了。4. 验证请求消息收发链路与成功结果确认配置起来只是第一步真正要确认的是消息能不能从平台进来、模型能不能处理、回复能不能发回去。这一节给一套完整的验证动作。先验证 Discord 侧。在 Discord 的频道里 你的 Bot 发一条消息比如YourBot hello。OpenClaw 的日志里应该出现类似这样的记录[discord] received message from user#1234: hello [router] dispatching to provider taotoken [taotoken] request completed in 1.2s [discord] sent reply to channel your-channel-id如果日志停在received message没有后续说明消息路由没走到模型层检查defaultProvider是否指向了taotoken。如果日志出现taotoken request failed回上一节的 curl 测试确认通道是否还通。再验证 Telegram 侧。在 Telegram 里给 Bot 发一条私聊消息日志应该出现[telegram] received update from chat 123456789 [router] dispatching to provider taotoken [taotoken] request completed in 0.9s [telegram] sent reply to chat 123456789Telegram 的验证有个额外步骤确认 Webhook 注册成功。用浏览器访问https://api.telegram.org/botyour-bot-token/getWebhookInfo返回里url字段应该是你的回调地址pending_update_count为 0。如果last_error_message有内容说明 Telegram 推送失败检查你的回调地址是否公网可达、secret_token是否匹配。跨平台验证是重点。在 Discord 里发一条消息然后在 Telegram 里发一条确认两条消息都走了同一个 provider。你可以在 TaoToken 控制台的用量页面看到调用记录如果两个平台的请求都出现在同一个 Key 下说明统一 Key 接入生效了。再做一个会话状态验证。OpenClaw 的会话管理支持跨平台共享上下文配置里加session字段{ session: { dmScope: per-channel-peer, groupPolicy: open, shared: { context: true, memory: true } } }配好后在 Discord 里告诉 Bot 你的名字然后在 Telegram 里问它「我叫什么」如果它能答出来说明跨平台会话状态同步成功。这个验证能直接证明统一 Key 通道在跨平台场景下的价值。最后确认消息格式转换。Discord 的 embed 消息发到 Telegram 会转成纯文本加链接Telegram 的 Markdown 发到 Discord 会转成 embed 字段。你可以在两个平台各发一条带格式的消息观察对方平台收到的效果。如果格式错乱检查sync.messageFormat配置是否按平台分别设置了。5. 本篇常见错排查401、local proxy failed 与 choices 读取失败这一节按真实报错来。以下四个是我在配 OpenClaw 多平台时实际撞到过的按出现频率排序。401 Unauthorized。这个最常见出现在模型调用阶段。日志里通常是taotoken request failed: 401。原因有三个Key 复制时带了空格、Key 已过期或被删除、baseURL写成了https://taotoken.net/api/v1导致路径重复。排查顺序是先重新复制 Key再确认baseURL末尾没有/v1最后去控制台确认 Key 状态。注意 401 和 403 不同403 通常是权限问题401 就是认证失败。local proxy failed。这个报错出现在 Webhook 接收阶段日志里是local proxy failed: connection refused。原因是 OpenClaw 的 Webhook 端口没有真正监听或者反向代理配置指向了错误的端口。检查openclaw.json里 Discord 和 Telegram 的port是否和实际监听一致用netstat -tlnp | grep 808确认端口状态。如果你用了 Nginx 做反代检查proxy_pass是否指向了正确的本地端口。reading choices 失败。这个报错出现在模型响应解析阶段日志里是failed to read choices from response。原因是模型返回的 JSON 结构不符合 OpenAI 兼容格式或者返回了错误对象但被当成正常响应解析。先看原始响应内容在 OpenClaw 配置里把debug打开日志会打印原始响应体。如果响应里是{error: {...}}说明模型侧返回了错误按错误信息处理。如果响应里choices是空数组检查max_tokens是否设得太小导致模型没输出。OAuth 相关报错。如果你在 Discord 侧用了 OAuth2 而不是 Bot Token可能会遇到OAuth token exchange failed。Discord 的 Bot 接入推荐直接用botToken不要走 OAuth2 流程因为 Bot Token 是长期有效的OAuth2 的 access token 会过期需要额外实现刷新逻辑。如果你确实需要 OAuth2检查clientId、clientSecret、redirectUri三个参数是否和 Developer Portal 里一致。Telegram Webhook 注册失败。报错是setWebhook failed: 400 Bad Request。常见原因是回调地址不是 HTTPSTelegram 要求 Webhook 地址必须是 HTTPS。本地开发时用内网穿透工具提供的 HTTPS 地址不要用http://。另一个原因是secret_token包含非法字符Telegram 要求它只能是A-Za-z0-9_-这些字符。跨平台消息重复。这个不是报错是行为异常。Discord 和 Telegram 都收到了同一条消息的回复但你没配广播。原因是sync.rules里的autoForward被误开了。检查sync配置把autoForward.enabled设为false除非你确实需要跨平台广播。排障时有个通用技巧把 OpenClaw 的日志级别调到debug然后在配置里加logLevel: debug。这样每个请求的入参和出参都会打印定位问题快很多。但生产环境记得调回info不然日志量会很大。6. 统一 Key 通道下的多平台扩展与后续动作Discord 和 Telegram 跑通之后OpenClaw 的多平台集成其实还有更大的扩展空间。统一 Key 通道的价值在于你新增任何平台时模型侧都不用再动只需要在channels里加配置。如果你要接入飞书或企业微信配置结构和 Discord 类似只是认证方式从botToken换成appIdappSecret。飞书的 Webhook 回调需要配verificationToken和encryptKey企业微信需要配corpId、agentId、secret和encodingAesKey。这些字段在 OpenClaw 的通道配置里都有对应位置照着官方文档填即可。对于需要长期跑编码任务或 Agent 场景的建议把模型调用切到 Coding Plan 通道。Coding Plan 针对代码生成和长上下文做了优化在 OpenClaw 里只需要把 provider 的baseURL换成对应的端点Key 还是同一个。这样 Discord 和 Telegram 里的代码问答、文件处理任务都会走优化后的通道。验证模型能力时可以直接在模型对话页面测试你要用的模型 ID确认它在你的场景下表现符合预期再写进 OpenClaw 配置。这样避免配好了才发现模型不适合。接入文档里有各平台的完整配置字段说明和示例遇到字段不确定的可以直接查。API Keys 页面用来管理你的 Key建议给 OpenClaw 单独创建一个 Key方便后续按用途区分用量和轮换。最后给一个实用技巧把 Discord 和 Telegram 的 Webhook 路径统一成/webhook/{platform}的格式反向代理里用一条规则匹配/webhook/*转发到 OpenClaw 的监听端口。这样新增平台时只需要在 OpenClaw 配置里加通道反向代理不用改。我实测下来这个结构在接第三个、第四个平台时省了很多重复配置的功夫。