1. 飞书群里那只“装死虾”到底卡在哪一步OpenClaw 接入飞书机器人这件事说穿了就是把三样东西串起来一个能收消息的 webhook 入口、一份能跑通鉴权的 API Key 配置、一套能让飞书正确渲染的 Markdown 消息体。听起来简单但真正动手的时候报错往往不是“配置错了”这么直白而是机器人已读不回、消息发出去变成一坨纯文本、或者干脆在日志里甩一句 401 让你自己猜。我最近帮朋友调了一套 OpenClaw 的飞书接入链路场景很典型机器人能进群它也有反应但推送的消息要么格式全乱要么隔三差五鉴权失败。排查下来发现问题基本集中在两个地方——config.toml 里的 Key 和 Base URL 没对齐以及飞书消息体里 Markdown 的字段用错了类型。这篇就把这两个坑拆开讲给你一份可以直接复制的配置骨架再配一套验证动作让你一次性把消息推送链路跑通。适合谁看正在调试 OpenClaw 飞书集成的开发者尤其是遇到鉴权失败、Markdown 渲染异常、webhook 验证不通过这几类报错的人。下面所有配置和命令都可以直接拿去改不需要你从零搭环境。2. 先把 Key 和通道理顺TaoToken 在链路里的位置OpenClaw 本身是个调度框架它不生产模型能力只负责把你的指令转发给背后的模型服务。所以当你在飞书里 机器人、它却回你“鉴权失败”的时候问题大概率不在飞书而在 OpenClaw 调用模型服务这一层。我试过把模型调用统一收口到 TaoToken 的 API 通道上好处是 Key 只需要维护一份Base URL 固定排查鉴权问题时不用在多个服务商之间来回切换。TaoToken 的 API 地址是https://taotoken.net/api模型对话、Coding Plan、API Keys 管理都在同一个控制台里配置的时候少一层心智负担。具体来说OpenClaw 的 config.toml 里需要填两个关键字段一个是api_key一个是base_url。很多人踩的坑是 base_url 填了官网首页地址而不是 API 端点结果请求发出去直接被重定向日志里看到的就是一堆 301 和 401 混在一起。正确的做法是 base_url 只填到/api这一层剩下的路径由 OpenClaw 自己拼接。如果你还没拿到 Key可以去 TaoToken 控制台生成一个地址是https://taotoken.net/api-keys。生成之后先别急着往配置里塞用 curl 单独验一次确认 Key 本身是通的再往下走。这一步能帮你把“Key 无效”和“配置写错”两类问题分开。3. 可复制的 config.toml 骨架与飞书 webhook 配置下面这份 config.toml 是我实测能跑通的骨架字段名按 OpenClaw 的约定来你把自己的 Key 和飞书 webhook 地址替换进去就能用。注意[model]段里的base_url结尾不要带斜杠api_key用你刚生成的那串。[server] host 0.0.0.0 port 8080 log_level debug [model] provider openai-compatible base_url https://taotoken.net/api api_key sk-你的TaoToken密钥 model_name claude-sonnet-4-20250514 timeout_seconds 60 max_retries 2 [feishu] enabled true webhook_url https://open.feishu.cn/open-apis/bot/v2/hook/你的webhook-id verify_token 你的verification-token encrypt_key 你的encrypt-key msg_type interactive markdown_enabled true [feishu.card] title OpenClaw 助手 template blue几个容易写错的地方单独说一下。provider填openai-compatible是因为 TaoToken 的 API 走的是兼容 OpenAI 的协议格式OpenClaw 里选这个 provider 就能直接对接。model_name按你实际要用的模型填别照抄。timeout_seconds建议给到 60飞书那边对机器人响应有时间限制模型推理慢的时候容易触发超时重试重试次数给 2 次比较稳。飞书侧的 webhook 配置重点在verify_token和encrypt_key这两个字段。它们不是可选项飞书在事件订阅里会拿这两个值做签名校验填错的话表现就是 webhook 验证一直不通过飞书后台显示“请求地址校验失败”。这两个值在飞书开放平台的应用详情页里能找到复制的时候注意别把前后空格带进去。配置写完之后先别启动 OpenClaw用下面这条命令单独验一下 webhook 地址是否可达curl -X POST https://open.feishu.cn/open-apis/bot/v2/hook/你的webhook-id \ -H Content-Type: application/json \ -d { msg_type: text, content: {text: webhook 连通性测试} }如果飞书群里能收到这条纯文本消息说明 webhook 本身没问题接下来再排查 OpenClaw 到模型服务这一段。如果收不到先检查 webhook 地址有没有复制错或者机器人是不是被移出群了。4. 验证请求从 curl 到飞书消息落地配置就绪之后分两步验证。第一步验模型通道第二步验飞书消息渲染。先验模型通道用 curl 直接打 TaoToken 的 API确认 Key 和 base_url 都对curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 回复两个字通了}], max_tokens: 20 }返回里能看到choices字段并且内容正常说明模型通道没问题。如果这里报 401那就是 Key 的问题去控制台重新生成一个如果报 404检查 base_url 是不是多写了或者少写了路径。模型通道通了之后启动 OpenClaw在飞书群里 机器人发一条指令比如“帮我总结一下今天的待办”。这时候重点看两件事机器人有没有回复以及回复的 Markdown 有没有正确渲染。飞书的消息类型里interactive卡片对 Markdown 的支持最好但字段结构比纯文本复杂。如果你在 config.toml 里把msg_type设成了text那 Markdown 语法不会被解析发出来就是带星号和井号的纯文本。这就是很多人遇到的“格式全乱”问题的根源——不是 Markdown 写错了是消息类型选错了。正确的做法是msg_type用interactive消息体里用elements数组承载 Markdown 内容。下面是一个最小可用的飞书卡片消息体示例你可以直接塞进 OpenClaw 的发送逻辑里做对照{ msg_type: interactive, card: { header: { title: {tag: plain_text, content: OpenClaw 回复}, template: blue }, elements: [ { tag: div, text: { tag: lark_md, content: **待办总结**\n- 上午接口联调\n- 下午写周报 } } ] } }注意text.tag必须是lark_md不是plain_text也不是markdown。飞书对 Markdown 的字段名有自己的约定写错了不会报错但渲染出来就是纯文本。这个坑我踩过日志里一切正常就是格式不对查了半天才发现是 tag 写错了。5. 本篇常见错排查把调试过程中遇到的高频报错整理成一张表方便你对照日志定位。报错现象可能原因排查动作飞书后台提示“请求地址校验失败”verify_token 或 encrypt_key 填错重新复制飞书应用详情页里的值检查前后空格机器人已读不回日志无请求记录webhook 地址不可达或机器人被移出群用 curl 单独测 webhook确认群成员列表返回 401 UnauthorizedTaoToken Key 无效或过期去控制台重新生成 Key用 curl 验一次返回 404 Not Foundbase_url 路径写错确认 base_url 为https://taotoken.net/api不带多余路径消息发出但格式全乱msg_type 用了 text 而非 interactive改 msg_type 为 interactivetext.tag 用 lark_md机器人响应超时后重复发送timeout 太短触发重试把 timeout_seconds 调到 60max_retries 设为 2换了新会话后机器人“失忆”对话状态没写入持久化配置检查 OpenClaw 的 session 存储路径和权限其中“失忆”这个问题值得多说一句。OpenClaw 默认的对话记忆是会话级的新会话开启后不会自动继承上一轮的上下文。如果你希望机器人记住固定的格式要求或者权限配置得把这些写进 config.toml 或者单独的持久化文件里不能只靠对话里教它。这一点在飞书场景下特别明显因为飞书的会话 ID 会变机器人每次都可能当成新对话处理。还有一个隐蔽的坑飞书 webhook 对请求体大小有限制如果你让机器人一次性推送很长的 Markdown 内容可能会被截断或者直接拒收。解决办法是把长内容拆成多条卡片消息或者用飞书文档链接代替大段文本。6. 跑通之后把 Key 和通道固定下来链路跑通之后建议做一件事把 TaoToken 的 Key 和 base_url 固定成环境变量不要硬编码在 config.toml 里。这样换 Key 或者切模型的时候不用改配置文件重启服务就行。export TAOTOKEN_API_KEYsk-你的TaoToken密钥 export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在 config.toml 里用${TAOTOKEN_API_KEY}这种占位符引用。OpenClaw 支持环境变量注入具体写法看你的版本大部分情况下把值写成${VAR_NAME}就能识别。如果你后面要长期跑编码类任务或者 Agent 流程可以了解一下 TaoToken 的 Coding Plan它把模型调用和额度管理放在一起适合需要持续跑量的场景。模型对话的入口在https://taotoken.net/chat接入文档在https://taotoken.net/docAPI Keys 管理在https://taotoken.net/api-keys。这几个地址按你的实际需求选排障阶段优先看文档和 API Keys验证模型效果就去对话页面试。最后留一个实用技巧飞书机器人的日志级别开到 debug把每次请求的 request_id 和响应状态都打出来。这样出问题的时候不用猜直接拿 request_id 去飞书开放平台的日志查询里搜能省掉大量来回试错的时间。