1. 从一次 QQ Bot 渠道接入说起OpenClaw 接入 QQ Bot 渠道这件事本质上是在给同一个 main agent 增加一个新的对话入口而不是新建一个独立的机器人。这个认知很关键因为很多排障思路跑偏都是因为把它当成了另一个 agent来处理。我这次的目标很明确在已有的 OpenClaw 环境里新增 QQ Bot 渠道让它承接天气预报定时推送、Sub2API 异常告警同时作为新的对话入口接入主 agent。环境特征先交代清楚OpenClaw 版本 2026.3.8原有主渠道是 Telegram新接入的是 QQ Bot。整个排障过程踩了几个坑从插件版本选择、渠道配置写入到消息抽象层的跨渠道限制最后定位到问题其实出在 OpenClaw 的消息抽象层而不是 QQ Bot 本身。这篇记录会把可复制的 config.toml 骨架、渠道连通性验证动作、以及常见报错的定位思路都梳理一遍适合正在做 OpenClaw 多渠道接入、或者卡在 QQ Bot 插件渠道配置上的同学参考。需要说明的是OpenClaw 的模型调用通道这里用的是 TaoToken 统一 Key 方案也就是把模型 API 走一个统一的入口这样在插件侧配置时只需要维护一套 Key 和 base_url不用为每个渠道单独管理凭证。这个设计在多渠道场景下省了不少事后面配置部分会具体展开。2. TaoToken 前置统一 Key 与 API 通道准备在动 OpenClaw 的渠道配置之前先把模型调用通道准备好。TaoToken 在这里扮演的角色是统一 Key 和 API 通道提供方OpenClaw 的 agent 在跑对话和定时任务时模型请求会走这个通道。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。你需要先在控制台创建一个 API Key这个 Key 后面会写进 OpenClaw 的配置里。创建入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建好之后先别急着填进 OpenClaw建议先用模型对话页面验证一下 Key 是否可用入口是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 随便发一条消息确认能正常返回这样能排除掉 Key 本身的问题后面排障时就不用怀疑这一层了。如果你后续要做长期编码或者 Agent 类的持续任务可以关注一下 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配置项和参数说明都在里面遇到不确定的字段可以先查文档。提示统一 Key 的核心价值在于多渠道共享同一套凭证。OpenClaw 里 Telegram 和 QQ Bot 两个渠道跑的是同一个 main agent模型调用走同一个通道所以 Key 只需要配一份不用按渠道拆分。3. 可复制配置插件安装与 config.toml 骨架3.1 插件版本选择最开始执行openclaw channels add --help检查内置 channel 列表时没有直接看到 qqbot。这说明当前 OpenClaw 主线不内置 QQ 渠道QQ Bot 需要通过插件方式扩展。验证下来确实如此qqbot 是通过插件tencent-connect/openclaw-qqbot提供的。第一次尝试安装 latest 版本openclaw plugins install tencent-connect/openclaw-qqbotlatest结果发现 latest 指向的是预发布版本 1.6.4-alpha.5而 OpenClaw 默认不会直接安装 prerelease所以需要显式指定稳定版本openclaw plugins install tencent-connect/openclaw-qqbot1.6.3安装成功后插件列表里会出现插件 IDopenclaw-qqbot版本 1.6.3。这一步的坑在于如果你不指定版本号安装会因为 prerelease 被拦截而失败报错信息通常不会直接告诉你这是预发布版本需要自己判断。3.2 config.toml 骨架确认插件可用后写入渠道配置。下面是可复制的 config.toml 骨架字段含义在注释里说明# OpenClaw 主配置片段 [channels.qqbot] enabled true appId 你的APP_ID clientSecret 你的CLIENT_SECRET [plugins.entries.openclaw-qqbot] enabled true # 模型调用通道TaoToken 统一 Key [model] provider openai-compatible baseUrl https://taotoken.net/api apiKey 你的TAOTOKEN_API_KEY如果你更习惯用命令行写入等价的操作是openclaw config set channels.qqbot.enabled true openclaw config set channels.qqbot.appId APP_ID openclaw config set channels.qqbot.clientSecret CLIENT_SECRET openclaw config set plugins.entries.openclaw-qqbot.enabled trueappId 和 clientSecret 来自 QQ 开放平台创建机器人时分配的凭证这两个值填错会直接导致渠道连不上。baseUrl 和 apiKey 是 TaoToken 统一 Key 的配置baseUrl 固定为https://taotoken.net/apiapiKey 用你在控制台创建的那一串。3.3 重启与生效配置写完后需要重启 gateway 让改动生效openclaw gateway restart重启后不要急着测消息先确认渠道状态。这一步是排障的关键分水岭渠道没起来的话后面所有消息测试都是白费。4. 验证请求渠道连通性与消息链路4.1 渠道状态检查重启 gateway 后用下面两条命令确认 QQ Bot 渠道状态openclaw channels list openclaw channels status --probe预期输出里 QQ Bot 这一行应该显示QQ Bot default: configured enabled running connected四个状态词分别对应已配置、已启用、进程运行中、连接已建立。如果卡在 configured 但没有 running通常是插件没启用或者 gateway 没重启如果 running 但没有 connected多半是 appId/clientSecret 有问题或者网络层面连不上 QQ 的接口。4.2 消息链路验证渠道连通后先做一次被动消息验证在 QQ 里给机器人发一条消息看 OpenClaw 侧是否收到并回复。这一步验证的是QQ 作为对话入口这条链路。如果这一步通了说明渠道本身没问题。接下来验证主动推送。这里会遇到一个限制直接通过 OpenClaw 的message(actionsend, channelqqbot, ...)去主动发 QQ 私聊时从 Telegram 对话上下文里直接跨发到 QQ 会被拦截即便切到子会话也可能触发 cross-context messaging 限制。这个限制不是 QQ Bot 故障而是 OpenClaw 当前消息抽象层对跨渠道主动发送的策略。为了确认问题到底出在 QQ 渠道还是 OpenClaw 的消息抽象层可以绕开 message 工具直接调用 QQ 官方接口发送私聊消息。发送分两步第一步获取 access tokencurl -X POST https://bots.qq.com/app/getAppAccessToken \ -H Content-Type: application/json \ -d {appId:APP_ID,clientSecret:CLIENT_SECRET}第二步向用户私聊接口发送消息curl -X POST https://api.sgroup.qq.com/v2/users/openid/messages \ -H Authorization: QQBot token \ -H X-Union-Appid: appid \ -H Content-Type: application/json \ -d {content:测试消息,msg_id:最近一次用户消息ID,msg_type:0}注意点有三个openid 要正确msg_id 用用户最近一次发来的消息 IDAuthorization 头格式是QQBot token而不是 Bearer。这一步返回 HTTP 200 并且 QQ 侧实际收到消息就说明 QQ 官方发送链路本身是正常的之前卡住的是 OpenClaw 消息抽象层的跨渠道限制。5. 本篇常见错排查5.1 插件安装报 prerelease 错误现象执行openclaw plugins install tencent-connect/openclaw-qqbotlatest失败提示不安装预发布版本。定位latest 标签指向了 alpha 版本。解决方式是显式指定稳定版本号比如1.6.3。如果你不确定有哪些稳定版本可以先查 npm 上的版本列表挑一个不带 alpha/beta/rc 后缀的。5.2 渠道状态卡在 configured现象openclaw channels status --probe显示 configured 但没有 running。定位先检查plugins.entries.openclaw-qqbot.enabled是否为 true再确认 gateway 是否真的重启了。有时候改了配置但 gateway 没重启状态不会更新。另外检查 config.toml 的语法TOML 对缩进和引号比较敏感字段名写错会静默忽略。5.3 running 但 connected 失败现象渠道进程起来了但连接建立不了。定位重点查 appId 和 clientSecret。这两个值如果填错QQ 侧会拒绝连接。另外确认服务器出网正常能访问bots.qq.com和api.sgroup.qq.com。如果用的是统一 Key 方案顺便确认 baseUrl 和 apiKey 没写错虽然模型通道和 QQ 渠道是两回事但配置混在一起时容易看串行。5.4 主动推送被拦截现象被动回复正常但主动发 QQ 私聊时被 cross-context messaging 限制拦截。定位这是 OpenClaw 消息抽象层的策略不是 QQ Bot 故障。验证方法是绕开 message 工具直接调 QQ 官方 API如果官方 API 能发出去就说明渠道本身没问题。后续如果要打通主动推送需要在 OpenClaw 侧调整消息上下文策略或者用独立的定时任务进程直接调官方 API。5.5 模型调用报 401现象agent 回复时报鉴权失败。定位检查 TaoToken 的 apiKey 是否填对baseUrl 是否为https://taotoken.net/api。可以先在模型对话页面用同一个 Key 发一条消息确认 Key 本身有效。如果那边正常这边报错就是 OpenClaw 配置里的字段写错了。6. 接入自检清单与后续动作把整个流程收一下给你一份可执行的自检清单。第一步确认插件装的是稳定版而不是 prerelease第二步确认 config.toml 里 channels.qqbot 和 plugins.entries.openclaw-qqbot 两个段都 enabled第三步重启 gateway 后用channels status --probe确认四个状态词齐全第四步被动消息验证通过后再用官方 API 验证主动发送链路第五步模型调用通道用 TaoToken 统一 KeybaseUrl 和 apiKey 填对。如果你在排障过程中遇到接入层面的报错优先看 API Keys 和接入文档入口分别是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 和 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果是验证模型是否正常用模型对话页面最快入口是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。长期跑编码或 Agent 任务的话Coding Plan 在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。最后说一个实际经验OpenClaw 多渠道接入时最容易出问题的不是渠道本身而是配置的生效链路。改完配置一定要重启 gateway重启后一定要用 probe 确认状态不要凭感觉认为配置已经生效。QQ Bot 这个渠道的坑主要集中在插件版本和消息抽象层的跨渠道限制上前者靠指定版本号解决后者靠官方 API 绕开验证。把这两点搞清楚整个接入过程会顺很多。
