1. 飞书不回的第一反应先分清渠道断了还是模型断了飞书群里 了 OpenClaw 机器人消息显示已读机器人却像没听见——一句话都不回。这种「飞书不回」的场面多数时候不是机器人挂了而是链路中间某一环断了飞书事件有没有进到 OpenClawOpenClaw 有没有把消息发出去问模型模型回复有没有被发回飞书。TaoToken 负责的是中间那一环也就是模型请求的 Key 与兼容通道来源。先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key把 OpenClaw 的模型通道 Base URL 指向 https://taotoken.net/api再回头翻飞书那一侧的日志顺序会清楚很多。很多人第一次遇到这个现象第一反应是重装机器人或者重扫一遍授权。这么做有时候确实能蒙对但代价是把原本正常的渠道状态、配对记录一起弄乱下次再出问题就完全没有参照物了。排障最怕的不是问题难而是每次都在动不同的地方。1.1 一条 消息在 OpenClaw 里要过三道关第一关是飞书到 OpenClaw机器人订阅了群消息、被 的事件推到本地进程、渠道连接处于健康状态。第二关是 OpenClaw 到模型消息被拼成一次模型请求带上 provider、Base URL、API Key、模型 ID 发出去等回包。第三关是 OpenClaw 回飞书拿到模型返回的文本后调飞书发消息接口把回复落到群里。三关任意一关断群里看到的现象都是「没反应」但它们对应的排查命令完全不同。渠道断了要看channels系列命令模型断了要看models系列命令回复发不出去又要回头看渠道的 outbound 记录。把它们混在一起查就会陷入「改了半天还是不回」的循环。还有一个容易忽略的细节这三关的耗时差别很大。第一关和第三关通常是毫秒到百毫秒级别第二关取决于模型响应速度慢的时候几秒到几十秒都正常。所以看到日志里隔了几秒才出现下一步不要立刻判定卡死先看那一步到底有没有落笔。1.2 两条 status 命令把排查范围砍一半openclaw channels status openclaw models status第一条看飞书渠道的在线状态和最近一次收发时间第二条看模型 provider 是否可用、Key 有没有被拒。两条命令连着跑基本能把问题压到「飞书侧」或「模型侧」其中一边。如果只有一边不对劲就别去动另一边这是省时间的关键。如果两边都显示正常说明问题更可能藏在「事件进来了但没触发模型调用」这种中间态那就必须上日志。下面先把这两条 status 命令的输出讲清楚再讲channels logs怎么看。2. openclaw channels status飞书这一侧到底通没通openclaw channels status是最省事的一条命令用不着翻日志几秒钟就能给出飞书渠道的当前状态。它的输出大致长这样不同版本字段名可能略有差异但结构差不多Channels feishu online modelong-conn accountcli_xxxxx slack disabled Pending events: 0 Last inbound: 12s ago Last outbound: 41s ago看到这段输出你要提取的信息其实只有三样渠道是不是 online、Pending events 是不是在涨、Last inbound 和 Last outbound 的时间差有多久。2.1 输出里三块信息各自代表什么online / offline表示飞书渠道的长连接有没有建立。offline 的话群里发什么都不可能进来先解决连接问题别往下查了。Pending events是已经收到但还没处理完的事件数。这个数字长期停在非零值说明事件进来了但处理卡住了通常是模型调用在阻塞或者正在重试。Last inbound / Last outbound是最有信息量的一对。inbound 是最近一次收到飞书消息的时间outbound 是最近一次成功发回消息的时间。如果 inbound 一直在往前滚outbound 死死停在一个很早的时间点那就说明「收得到、发不出」断点在模型那一段或者回复处理那一段。2.2 三种「看着正常其实不正常」的状态第一种是 online 但Last outbound时间是几小时前。渠道自己觉得连接没问题实际上已经很久没有成功回消息了这种最容易被忽略。第二种是 Pending events 缓慢增长。每分钟涨一两个看起来不多但说明处理速度跟不上最后会堆到超时。第三种是 online 但account字段为空或者是一串明显不对的值。这通常发生在换过机器人应用之后配置里还留着旧的凭据。这三种状态都指向一个结论飞书这一侧的连接是活的但业务链路是断的。接下来就该看日志而不是继续盯着 status 发呆。3. openclaw channels logs --channel feishu --lines 40 把一次收发摊开status 告诉你「通不通」logs 告诉你「哪一步断了」。排障时最常用的一条命令是openclaw channels logs --channel feishu --lines 40--channel feishu限定只看飞书渠道--lines 40取最近 40 行。40 行这个量是刻意选的够覆盖一次完整的消息往返又不会把更早的噪音拉进来。如果一次都没抓到把行数加到 100 再看。3.1 40 行日志里的三段结构正常的日志是有节奏的按时间顺序读下来大致分三段。第一段是 inbound事件类型、群 ID、发送者、消息文本。这一段的末尾通常会有一行「已入队」或者类似标记说明消息被接住了。第二段是 modelprovider 名字、目标 Base URL、模型 ID、耗时、状态码。这一段是判断模型通道好坏的唯一依据。状态码是 200 就说明模型回了是 401 就说明 Key 没被认是超时就是请求发出去了但没等到回包。第三段是 outbound调用飞书发消息接口、返回的消息 ID、耗时。这一段有记录说明回复已经发出去了没记录说明流程在第二段之后就没往下走。3.2 inbound 有、outbound 没有断点在模型通道这是最常见的组合。飞书消息进来了日志第一段齐全第二段要么根本没出现要么出现了但带着错误码第三段直接缺失。群里当然没反应。反过来如果第二段显示 200第三段也有调用记录但群里就是看不到消息那问题在飞书侧的发消息权限或者群白名单跟模型没关系。这两种情况的处理动作完全不同所以一定要把日志读到第三段再动手。日志里还有一种情况值得单独说第二段出现了两次。第一次是失败重试前的请求第二次是重试。如果两次都失败且错误码一致那就是配置错了重试再多也没用得回去改 provider。4. 模型通道的 Key 从 TaoToken 拿Base URL 填 https://taotoken.net/api确认断点在模型这一段之后剩下的就是三件事拿到一把能用的 Key、把 Base URL 指向统一接入地址、确认模型 ID 写对了。这三件事都能在一个地方完成。4.1 注册并创建 API Key打开 TaoToken 注册登录在控制台里创建一把 API Key。创建完之后先复制到本地一个安全的地方页面上一般不会重复完整展示。Key 在对话里一律用占位符表示本文里统一写成YOUR_API_KEY不要把你自己的真实 Key 贴进任何截图或者聊天记录。顺手在模型广场里确认一下模型 ID 的写法。不同通道对同一个模型的命名规则不一样有的带前缀有的不带直接抄文档里的字符串最稳不要凭印象拼。4.2 OpenClaw 配置文件里改 providerOpenClaw 的配置一般放在用户目录下的配置目录里字段名会随版本略有变化改之前先确认一下自己的版本号。provider 那一段的示例结构如下{ providers: { taotoken: { type: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: YOUR_API_KEY, model: YOUR_MODEL_ID } }, defaultProvider: taotoken }三个地方要盯住。baseUrl写https://taotoken.net/api结尾不要顺手补/v1补上之后请求路径会多一层回包直接 404。apiKey填从上面那个页面创建出来的 Key。model填模型广场里看到的 ID别自己编日期后缀。改完保存重启一次 OpenClaw 进程让配置生效。如果你的 OpenClaw 是通过环境变量注入 provider 的那就把同样的三个值放到环境变量里baseUrl这一项还是https://taotoken.net/api不要把落地页的完整地址填进去——那个地址是给人点的不是给程序请求的。4.3 改完必须再跑一次 models statusopenclaw models status期望看到的是 provider 显示可用、Base URL 是你刚填的那个、最近一次调用没有错误码。如果这里显示 401九成是 Key 复制时多了空格或者少了字符显示连接超时先确认本机网络能访问这个地址显示模型不存在那就是模型 ID 写错了回模型广场重新对一遍。这一步过了再看飞书不要跳过去直接去群里 机器人。models status 没过的情况下群里 一百次也不会有回复只会让你误以为是渠道问题。5. openclaw pairing list feishu渠道通了也可能卡在配对模型通道修好之后有一部分人的飞书还是没反应。这时候要看的就是配对状态因为 OpenClaw 对飞书群和用户通常会做一层授权没配对上的会话会被静默丢弃日志里只留一行很不起眼的记录。5.1 pairing list feishu 的输出怎么读openclaw pairing list feishu输出里要关注三列对象标识群或者用户、配对状态、到期时间。状态显示已授权、到期时间在未来才算真正可用。如果是 pending说明配对请求发起了但没确认需要重新走一次确认流程如果是 expired说明之前能用但现在过期了要续期或者重新配。这一步和模型通道是两回事不要混着查。很多人看到 pairing 列表是空的就以为是配 Key 的问题回头又把 Key 换了一遍白白折腾。5.2 配对正常却还是不回回到模型通道配对列表一切正常日志第一段也齐全那问题必然在模型那一段回到上一节去跑models status和看日志第二段。排障最忌讳的就是在同一个位置上反复换动作正确做法是每次只验证一个假设验证完再决定下一步。还有一种少见但确实存在的情况配对列表里同一个群出现了两条记录一条有效一条过期。这种时候 OpenClaw 有可能匹配到过期的那条表现就是消息进来了但不处理。把过期记录清掉再试一次。6. 回到飞书再 一次验证与分层排障配置改完、配对确认完就该回到飞书里做一次真实验证。 机器人发一句简单的话然后立刻看三处群里的回复、channels status的 outbound 时间、channels logs的第二段状态码。6.1 一条消息的链路核对表观察点正常表现异常指向channels statusLast inbound刚刚刷新飞书事件没进来channels logs第一段有事件、有消息文本渠道或权限问题channels logs第二段状态码 200、有耗时Key、Base URL、模型 IDchannels statusLast outbound刚刚刷新飞书发消息权限群里出现回复到此才算真的通了这张表建议照着顺序看不要跳着看。跳着看最容易出现的误判是看到群里没回复就去改配置实际上模型那一段早就 200 了问题在发消息权限上。6.2 三个容易反复踩的细节第一个是 Base URL 结尾多写了/v1。改的时候顺手加上不影响阅读但会让请求路径错位。正确的写法就是https://taotoken.net/api保持原样。第二个是改完配置没有重启进程。有些配置是启动时读一次运行中不会热加载不重启就一直是旧值。现象很有迷惑性明明改了文件行为跟没改一样。第三个是 Key 复制时带上了行尾的换行或者空格。这类问题不会报很明显的错有时表现为认证失败有时表现为请求被截断。复制之后在配置里扫一眼引号内的内容是不是干净的。7. 稳定跑起来之后Key、模型 ID 和日志留存飞书能回消息只是第一步接下来要做的是让它稳定跑下去出问题的时候能快速定位而不是每次都从头查一遍。7.1 把模型 ID 和 Key 当成配置项管理模型 ID 会变通道列出来的可用模型也会调整所以不要把模型名字硬编码到一堆脚本里。统一放在配置文件的一个位置改的时候只改一处。Key 也一样换 Key 的时候应该只动一个地方而不是去每个命令里翻。建议给自己留一份「配置快照」provider 名字、Base URL、模型 ID、Key 的来源页面写在一份不提交到代码仓库的本地笔记里。出问题的时候对一眼就知道哪里被动过。Key 本身不要写进笔记只写「从哪里创建的」就够了。顺手把日志留存打开。默认的--lines 40是给实时排障用的事后复盘往往需要更长的历史。把渠道日志和模型调用的状态码落盘下次再遇到飞书不回翻出来的就是证据而不是猜测。7.2 下一步把这次调用和后面的用量对上模型通道配通之后建议先去 TaoToken 模型对话 用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 都没写错——这一步比在飞书里反复 机器人快得多。如果 OpenClaw 要长期挂着跑可以看看 Coding Plan 的额度是否够用Key 的创建和轮换都在 控制台 API Keys 里完成换完之后记得回到 OpenClaw 的配置文件里同步一次再跑一遍openclaw models status确认没有 401。最后提醒一句channels logs看的是飞书收发models status看的是模型通道这两个视角不要互相替代。飞书不回的时候先用前者确认消息进出再用后者确认模型请求两条线都对了群里自然就有回复了。