飞书机器人无响应先别急着改事件订阅把 OpenClaw 模型通道切到 TaoToken 的排查记录飞书机器人发消息没反应很多人第一反应是去翻飞书开放平台的权限和事件订阅。但这次我遇到的场景有点不一样飞书侧的 App ID、App Secret、im.message.receive_v1事件订阅、应用发布状态全都核对过一遍openclaw gateway logs里却能看到事件已经进来了只是模型调用那一步卡住。也就是说问题不在飞书通道而在 OpenClaw 的模型通道没通。这篇就按这个排障视角记录一下把 OpenClaw 的模型 Base URL 改到 TaoToken官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 之后怎么用日志把「飞书事件订阅问题」和「模型通道问题」区分开。需要先明确一点TaoToken 在这个链路里只负责提供模型 Key 和 Base URL它不替代飞书 App Secret也不接管飞书的事件订阅。飞书那套凭证仍然从飞书开放平台拿TaoToken 解决的是 OpenClaw 调用模型这一段的连通性。搞清楚这个边界排查方向才不会跑偏。一、原问题与场景无响应到底卡在哪一层OpenClaw 接飞书机器人链路上其实有两段完全独立的认证第一段是飞书侧。OpenClaw 通过openclaw channels add配置飞书通道填的是 App ID 和 App Secret走的是飞书开放平台的事件订阅长连接或回调 URL。这一段决定「飞书的消息能不能进到 OpenClaw」。第二段是模型侧。OpenClaw 收到消息后要调用大模型生成回复这一段用的是模型服务的 Base URL 和 API Key。这一段决定「OpenClaw 能不能把回复吐出来」。飞书机器人无响应的常见排查顺序是App ID/App Secret → 权限 → 事件订阅 → gateway logs。这个顺序没错但它默认了「模型通道是通的」。实际排障中如果日志显示事件已接收、但没有任何模型请求发出或者模型请求直接报 401/404那问题就在第二段。我这次的判断依据就是日志飞书事件订阅正常消息进来了但 OpenClaw 在调用模型时失败导致机器人看起来「无响应」。所以先把模型通道切到 TaoToken 验证一遍再回头确认飞书侧。二、TaoToken 前置拿 Key 和 Base URL在改 OpenClaw 配置之前先把模型侧的两样东西准备好Base URLhttps://taotoken.net/apiAPI Key去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建创建 Key 的入口在控制台的 API Keys 页面登录后新建一个 Key复制出来备用。这个 Key 只用于 OpenClaw 调用模型和飞书的 App Secret 是两回事不要混在一起填。如果你后面还要做更细的验证比如确认某个模型 ID 是否可用可以到模型对话页面直接发一条测试请求如果是长期跑编码类 Agent可以考虑 Coding Plan。但本篇的核心是排障先把 Key 和 Base URL 拿到手就够了。三、可复制配置改 OpenClaw 的模型通道OpenClaw 的模型配置和飞书通道配置是分开的。飞书通道在~/.openclaw/openclaw.json的channels.feishu下模型配置则在模型相关字段里。不同版本的 OpenClaw 字段名可能略有差异但核心就是 Base URL 和 API Key 两项。先看一下当前配置文件的结构Linux/Maccat ~/.openclaw/openclaw.json找到模型配置部分把 Base URL 指向 TaoTokenKey 填你刚创建的{ models: { default: { baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY, model: 你的模型ID } } }Windows 下路径是%USERPROFILE%\.openclaw\openclaw.json结构一样。如果你用的是 CLI 方式配置模型也可以直接用命令行写入。TaoToken 提供了 CLI 工具安装方式npm i -g taotoken/taotoken然后用它来跑 Claude Code 类的编码场景taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m MODEL_ID注意这里的-u后面跟的是 API 地址https://taotoken.net/api不要加 UTM 参数UTM 只用于官网链接。改完配置后重启网关openclaw gateway restart飞书通道的配置不用动App ID、App Secret、domain、groupPolicy 保持原样。这一步只改模型通道目的是把「模型调用失败」这个变量单独隔离出来。四、验证请求与成功结果配置改完后分两步验证。第一步先确认模型通道本身是通的。可以直接用 curl 打一条请求curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { model: 你的模型ID, messages: [{role: user, content: ping}] }如果返回正常的 JSON 响应说明 Key 和 Base URL 没问题。如果返回 401检查 Key 是否复制完整返回 404检查 Base URL 是否写成了https://taotoken.net/api而不是别的路径。第二步回到飞书侧发消息同时盯日志openclaw gateway logs成功的情况下日志里应该能看到类似这样的顺序先出现飞书事件接收的记录紧接着出现模型请求发出的记录然后是模型响应返回最后是回复发送到飞书。如果只看到飞书事件接收、没有模型请求记录说明 OpenClaw 在收到消息后没有触发模型调用这时候要回去检查模型配置是否被正确加载比如字段名写错、JSON 格式错误导致整段配置没生效。如果模型请求记录出现了但报错错误信息会直接告诉你原因401 是 Key 问题404 是 URL 或模型 ID 问题超时是网络问题。这一步就能明确区分是飞书侧还是模型侧。五、本篇常见错排查围绕「飞书机器人无响应 模型通道切换」这个场景几个高频错误错误一把 TaoToken 的 Key 填到了飞书 App Secret 的位置。这两个是完全不同的凭证。飞书通道的appSecret必须从飞书开放平台拿TaoToken 的 Key 只填在模型配置里。填反了会导致飞书通道认证失败或者模型调用 401。错误二Base URL 写成了官网地址。模型请求的 Base URL 是https://taotoken.net/api不是https://taotoken.net。少写/api会导致 404。错误三改了配置没重启网关。OpenClaw 的配置是启动时加载的改完openclaw.json必须openclaw gateway restart否则还是用旧配置跑。错误四日志里看到飞书事件就以为模型也通了。飞书事件接收和模型调用是两条独立的日志。要专门找模型请求相关的记录没有这条记录就说明模型通道根本没被触发。错误五模型 ID 写错。不同模型 ID 对应的可用性不一样写一个不存在的 ID 会直接报错。可以先用模型对话页面确认 ID 可用再填进配置。错误六飞书长连接和模型通道同时出问题。如果日志里连飞书事件接收都没有那说明飞书侧的长连接或事件订阅有问题这时候要先解决飞书侧再回头看模型侧。两个问题叠在一起时先用日志确认事件有没有进来再确认模型有没有被调用。六、语义一致 CTA回到最初的问题飞书机器人无响应OpenClaw 模型通道改走 TaoToken 行不行行但前提是你要清楚它解决的是哪一段。TaoToken 提供模型 Key 和 Base URL让 OpenClaw 的模型调用这一段能通飞书的 App ID、App Secret、事件订阅仍然归飞书开放平台管。排障时先用openclaw gateway logs确认事件有没有进来再看模型请求有没有发出就能把两类问题分开。如果你现在正卡在模型通道这一步可以先去 https://taotoken.net/api-keys 创建一个 Key再到接入文档对照 OpenClaw 的配置字段填一遍。配通之后如果还想验证具体模型是否可用去模型对话页面发一条测试消息即可如果是长期跑编码类 Agent 的场景可以了解一下 Coding Plan。飞书那套凭证还是老老实实从飞书开放平台拿两边不要混。