1. 更新后飞书通道失效先别急着重装OpenClaw 每次版本更新都会带来不少配置结构上的调整尤其是 26.3.31 这个版本很多人在升级完之后发现飞书通道突然发不出消息了。你可能会看到日志里刷出一堆报错或者干脆连通道都起不来。这个问题其实不复杂核心原因就藏在openclaw.json的agents配置里。OpenClaw 是一个开源的 AI Agent 编排框架支持多通道接入飞书、Slack、Discord 等通过openclaw.json统一管理 Agent 的行为、工具权限和通道绑定。飞书通道则是通过larksuite/openclaw-lark插件实现的插件版本和 OpenClaw 主版本之间有兼容性要求。适合谁看如果你正在用 OpenClaw 接飞书做团队机器人、审批流或者消息推送升级后遇到通道异常这篇就是写给你的。我自己在升级到 26.3.31 之后飞书通道直接静默失效——没有崩溃但消息就是发不出去。翻日志才发现是agents.list里某个 Agent 的tools字段同时写了allow和alsoAllow新版本不再允许这种写法。下面我把完整的排查和修复过程拆开讲你可以直接跟着操作。2. 用 doctor 诊断 openclaw.json 配置冲突OpenClaw 自带一个doctor命令专门用来做配置体检和自动修复。升级之后第一件事不是手动翻 JSON而是先跑一遍诊断。这个命令会扫描openclaw.json里的字段合法性、版本兼容性、插件依赖等把问题直接列出来。执行方式很简单openclaw doctor如果你希望它自动修复能修的问题加上--fixopenclaw doctor --fix我实测下来doctor对大部分配置结构问题都能识别但allow和alsoAllow冲突这种语义级问题它会给提示但不一定自动改需要你手动处理。诊断输出里会明确告诉你哪个 Agent、哪个字段出了问题比如agents.list.6.tools: agent tools cannot set both allow and alsoAllow in the same scope这条报错的意思是第 7 个 Agent索引从 0 开始的tools配置里同一个作用域下同时出现了allow和alsoAllow。新版本要求你二选一或者把alsoAllow的内容合并进allow。为什么这个会导致飞书发不出消息因为飞书通道的消息发送依赖 Agent 的工具权限配置。如果tools解析失败Agent 初始化就会中断通道自然不可用。所以表面上是飞书的问题根子在openclaw.json。注意跑doctor --fix之前建议先备份openclaw.json虽然大部分修复是安全的但配置这种东西留个后路总没错。3. 可复制的 openclaw.json 修复配置定位到问题之后修复其实就一步把冲突的字段改掉。下面是一个典型的出错配置和修复后的对照。出错的样子agents.list中某个 Agent{ agents: { list: [ { name: feishu-bot, tools: { allow: [shell, http], alsoAllow: [file-read, file-write] } } ] } }修复方式有两种。第一种把alsoAllow合并进allow{ agents: { list: [ { name: feishu-bot, tools: { allow: [shell, http, file-read, file-write] } } ] } }第二种删掉allow改用profilealsoAllow的组合{ agents: { list: [ { name: feishu-bot, tools: { profile: default, alsoAllow: [file-read, file-write] } } ] } }两种方式都行看你团队的习惯。我一般推荐第一种因为字段少、直观不容易再出歧义。改完之后飞书插件也要同步升级。OpenClaw 主版本更新后飞书插件如果还是旧版通道注册会失败。升级命令npx -y larksuite/openclaw-lark2026.4.1 update这里注意版本号要和你当前 OpenClaw 版本匹配。26.3.31 对应的飞书插件是2026.4.1如果你用的是其他版本去官方文档查一下对应关系。如果你用的是 Claude Code 或者 Cline 这类工具来管理 OpenClaw 配置建议把 Base URL、API Key、Model ID 三件套都显式写清楚避免因为环境变量缺失导致通道初始化失败。TaoToken 的 API 地址是https://taotoken.net/api模型对话入口在 模型对话配置文档在 接入文档。4. 验证飞书通道是否恢复配置改完、插件升级完别急着庆祝先验证。验证分三步配置合法性、通道注册、实际发消息。第一步再跑一次doctor确认没有残留报错openclaw doctor如果输出里没有agents.list.*.tools相关的错误说明配置结构已经合法。第二步检查飞书通道是否注册成功。启动 OpenClaw 后看日志里有没有类似这样的输出[channel] feishu channel registered successfully [plugin] larksuite/openclaw-lark2026.4.1 loaded如果看到channel registered和插件版本号说明通道已经挂上了。第三步实际发一条消息测试。你可以用 OpenClaw 的 CLI 直接触发openclaw send --channel feishu --to 你的飞书用户ID --message 通道恢复测试如果飞书那边能收到消息说明整条链路通了。如果还是发不出去回到日志里看具体报错常见的有401 unauthorizedAPI Key 问题、local proxy failed网络配置问题、reading choices模型返回格式问题。我踩过的坑是改完openclaw.json之后忘了重启 OpenClaw 服务配置没加载白白排查了半小时。所以改完配置一定要重启。5. 常见报错对照与排查升级后飞书通道失效报错不止一种。下面把我遇到的和社区里常见的几类列出来对照着排查。报错信息原因修复动作agent tools cannot set both allow and alsoAllowopenclaw.json中tools字段冲突合并alsoAllow进allow或删掉allow改用profile401 unauthorizedAPI Key 无效或未配置检查openclaw.json中的apiKey字段或环境变量OPENCLAW_API_KEYlocal proxy failed网络代理配置异常检查proxy字段确认地址和端口正确reading choices模型返回格式不符合预期检查 Model ID 是否正确确认模型服务可用OAuth token expired飞书 OAuth 令牌过期重新执行飞书授权流程更新feishu.tokenplugin version mismatch飞书插件版本与主版本不兼容升级插件到对应版本如larksuite/openclaw-lark2026.4.1重点说几个容易搞混的。401 unauthorized不一定是 Key 错了也可能是 Key 没加载——比如你写在.env里但 OpenClaw 没读到。local proxy failed通常是代理地址写错或者代理服务没起来检查openclaw.json里的proxy配置。reading choices这个报错比较隐蔽一般是模型返回的 JSON 结构不对可能是 Model ID 写错了或者模型服务本身有问题。如果你用的是 Codex 的auth.json来管理凭证升级后要确认auth.json里的字段和新版本兼容。有些版本会改字段名比如api_key改成apiKey这种细节不注意就会报 401。提示排查的时候按「配置 → 插件 → 网络 → 凭证」的顺序来从内到外别一上来就怀疑网络。6. 长期维护与工具推荐飞书通道修好之后怎么避免下次更新又出问题我的经验是每次升级 OpenClaw 之前先跑一遍doctor记录当前状态升级完再跑一遍对比。这样出了问题能快速定位是哪个字段变了。另外把openclaw.json纳入版本管理Git每次改动都有记录回滚也方便。飞书插件的版本号建议和 OpenClaw 主版本一起记在 README 里升级时对照着来。如果你经常需要调试 Agent 的工具权限配置可以用 API Keys 管理多套凭证避免不同环境混用。长期跑编码类 Agent 的话Coding Plan 会更省心配置一次就能持续用。Claude Code 的接入配置可以参考 ClaudeCodeAnthropic里面有完整的 Base URL 和 Model ID 写法。最后说一个实用技巧openclaw doctor --fix虽然方便但别完全依赖它。有些配置冲突它只能提示不能自动改尤其是涉及业务逻辑的字段。养成改完配置先doctor再重启的习惯能省掉很多莫名其妙的通道故障。