1. 新增 Agent 后飞书消息石沉大海：从 im.message.receive_v1 事件链路说起
你刚在 OpenClaw 里用openclaw agents add建好一个新智能体，工作空间、SOUL.md 人格文件都配齐了，飞书机器人也建了应用、发了版本，结果在群里 @ 它，消息发出去像掉进黑洞——没有任何回复。这种「新增 Agent 后飞书无响应」的问题，十有八九不是模型的问题，而是事件链路断在了某一环。
OpenClaw 的多智能体架构里，一条飞书消息要变成 Agent 的回复，需要经过一条完整的链路：飞书服务器推送im.message.receive_v1事件 → OpenClaw Gateway 通过长连接接收 → 根据bindings路由规则匹配到对应agentId→ Agent 调用模型生成回复 → 通过飞书账号accountId发回消息。这条链路上任何一环缺失，表现都是「发消息没反应」，但根因完全不同。
我见过最多的三种情况：一是飞书开放平台压根没订阅im.message.receive_v1事件，Gateway 收不到任何推送；二是订阅了但没配bindings，消息全被默认 Agent 吃掉，新 Agent 永远轮不到；三是配置顺序搞反，先配飞书后台再配 OpenClaw，导致长连接建立失败。这篇就按「事件订阅校验 → settings 配置 → 路由绑定 → 连通性验证」的顺序，把每一步都拆成可复制的操作，最后给出把 settings 统一改到 TaoToken 通道后的验证动作，帮你定位新增 Agent 未触发回复的真实原因。
适合正在用 OpenClaw 搭多智能体、被飞书事件订阅和 Agent 路由绕晕的开发者。下面所有命令和配置片段都可以直接抄。
2. TaoToken 前置：统一 Key 与 API 通道，让多 Agent 共用一条出口
在排查飞书事件之前，先把模型调用这一层理顺。多智能体场景下，每个 Agent 可能配不同的模型，如果每个 Agent 都单独维护一套 API Key 和 Base URL，排查问题时你根本分不清「没回复」是事件没进来，还是模型调用失败了。把 settings 统一改到 TaoToken 的 API 通道，好处是所有 Agent 走同一个出口，日志里一眼就能看出请求有没有发出去、返回了什么。
TaoToken 的 API 地址是https://taotoken.net/api，兼容 OpenAI 风格的接口格式。你需要在 OpenClaw 的 settings 里把模型的baseURL指向它，apiKey换成在控制台生成的 Key。这样无论是main还是新加的agile_marketing_write，模型请求都从同一条通道出去，排障时只需要看一个地方的日志。
具体操作分两步。第一步，去 TaoToken 控制台创建 API Key，地址是https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=console，在 API Keys 页面点新建，复制生成的 Key 保存好。第二步，把 Key 和 Base URL 写进 OpenClaw 的 settings 配置。如果你用的是 Claude Code 类的编码场景，TaoToken 也提供了对应的接入文档，地址是https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc，里面有各客户端的配置示例。
这里要强调一个排查思路：当飞书消息没回复时，先确认模型通道是通的。你可以用curl直接打一次 TaoToken 的接口，看返回是否正常。如果这一步就失败，那问题根本不在飞书，而在 Key 或网络配置。只有模型通道确认可用，再去查飞书事件订阅才有意义。很多人一上来就翻飞书后台，结果折腾半天发现是 API Key 过期了，白白浪费时间。
把 settings 改到 TaoToken 之后，OpenClaw 里所有 Agent 的模型请求都会经过这条通道。你可以在 Gateway 日志里看到每次请求的耗时和状态码，这对判断「消息进来了但模型没回」还是「消息压根没进来」非常关键。下面一节给出完整的 settings 配置片段。
3. 可复制 settings 配置：openclaw.json 里的模型、通道与 bindings 三件套
OpenClaw 的核心配置文件在~/.openclaw/openclaw.json。新增 Agent 后飞书无回复，绝大多数配置问题都出在这个文件里。下面给出一份完整可复制的 settings 片段，包含模型通道（指向 TaoToken）、飞书多账号、以及最关键的bindings路由三部分。
先看模型通道配置。把models或providers里的 baseURL 和 apiKey 改成 TaoToken 的：
{ "models": { "default": { "provider": "openai-compatible", "baseURL": "https://taotoken.net/api", "apiKey": "sk-你的TaoToken密钥", "model": "claude-sonnet-4-20250514" } } }注意baseURL结尾不要多加/v1，TaoToken 的接口路径已经内置。model字段填你在 TaoToken 控制台看到的模型 ID，不同 Agent 可以在这里覆盖成不同模型。
接着是飞书多账号配置。关键点是不要用openclaw config set channels.feishu.appId这种命令，它会覆盖整个飞书通道。正确做法是在channels.feishu.accounts下用对象管理多个账号：
{ "channels": { "feishu": { "enabled": true, "domain": "feishu", "groupPolicy": "open", "accounts": { "main": { "appId": "cli_a91be1951578dcca", "appSecret": "你的主应用Secret", "botName": "主助手" }, "agile_marketing_write": { "appId": "cli_a910c62c59b8dcb5", "appSecret": "你的新应用Secret", "botName": "文案红孩儿" } } } } }accounts的键名就是后面bindings里要引用的accountId，必须完全一致，大小写都不能错。
最后是bindings路由，这是新增 Agent 能不能收到消息的决定性配置：
{ "bindings": [ { "agentId": "main", "match": { "channel": "feishu", "accountId": "main" } }, { "agentId": "agile_marketing_write", "match": { "channel": "feishu", "accountId": "agile_marketing_write" } } ] }bindings不是自动生成的。如果你只建了 Agent 和飞书账号，没写bindings，OpenClaw 会把所有消息路由给默认 Agent（通常是main），新 Agent 永远收不到消息。这就是「新增 Agent 后飞书无回复」最常见的原因之一。
配置改完，重启 Gateway 让 settings 生效：
openclaw gateway restart然后验证绑定是否生效：
openclaw agents list --bindings正常输出里，每个 Agent 下面应该显示Routing rules: 1，并列出对应的feishu accountId=xxx。如果新 Agent 显示Routing rules: 0，说明bindings没匹配上，回去检查accountId拼写。
注意：
appSecret是敏感信息，配置文件权限建议设为600，不要提交到 Git 仓库。
4. 验证请求与成功结果：从飞书发消息到 Agent 回复的完整链路
配置写好后，怎么确认整条链路是通的？按下面四步走，每一步都有明确的成功标志。
第一步，确认 Gateway 在运行：
openclaw status输出里 Gateway 状态应该是running。如果没运行，先openclaw gateway start。
第二步，开日志跟踪，然后在飞书里给新机器人发一条消息：
openclaw logs --follow成功的情况下，你会看到类似这样的日志流：先是feishu event received: im.message.receive_v1，表示事件进来了；接着routing to agent: agile_marketing_write，表示路由匹配成功；然后model request via https://taotoken.net/api，表示模型调用发出；最后reply sent to feishu account: agile_marketing_write，表示回复已发出。
如果日志停在第一步之后没有routing，说明bindings没配好。如果停在routing之后没有model request，说明模型通道配置有问题，回去检查 TaoToken 的 Key 和 baseURL。如果model request出现但报错，看错误码，401 是 Key 无效，404 是模型 ID 写错。
第三步，用curl单独验证 TaoToken 通道：
curl 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": "ping"}] }'返回里有choices数组且内容正常，说明模型通道没问题。这一步能帮你把「飞书事件问题」和「模型调用问题」彻底分开。
第四步，回到飞书，确认机器人真的回复了。如果是首次私聊，机器人可能先回一个配对码，需要你在服务器上执行：
openclaw pairing approve feishu <配对码>配对通过后，再发消息就能收到正常回复。群聊场景下，确认机器人被 @ 了，且groupPolicy允许该群。
走完这四步，如果日志显示reply sent但飞书里没看到消息，检查飞书应用的im:message:send_as_bot权限是否开通，以及应用是否已发布上线。草稿状态的应用发不出消息。
5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth 对照
排障时最怕报错信息看不懂。下面把新增 Agent 后飞书无回复场景下最常撞到的几类报错列出来，对照着查。
401 Unauthorized：模型调用返回 401，说明 TaoToken 的 API Key 无效或没带上。检查openclaw.json里apiKey字段是否填了完整 Key，有没有多余空格。如果你在环境变量里也设了 Key，确认没有冲突。TaoToken 的 Key 在控制台 API Keys 页面可以重新生成，地址是https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys。
local proxy failed：这个报错通常出现在 Gateway 尝试连接模型通道时。如果你本地配了代理类工具，先关掉再试。OpenClaw 的模型请求应该直连 TaoToken 的 API 地址，不需要额外代理层。检查baseURL是否写成了https://taotoken.net/api，不要带尾部斜杠。
reading choices 相关报错：日志里出现error reading choices或choices is undefined，说明模型返回的 JSON 结构不符合预期。常见原因是model字段填了一个 TaoToken 不支持的模型 ID，或者请求体格式不对。用第 4 节的curl命令单独测一次，看返回结构。如果curl正常但 OpenClaw 报错，检查 OpenClaw 版本是否过旧，升级到最新版。
OAuth 相关报错：如果你在配置里用了 OAuth 方式的凭证而不是 API Key，可能出现OAuth token expired或invalid_grant。多智能体场景建议统一用 API Key 方式，简单可靠。把 settings 里的认证方式改成apiKey字段，去掉 OAuth 相关配置。
飞书侧报错「应用未建立长连接」：这是配置顺序问题。必须先在 OpenClaw 里配好appId和appSecret，重启 Gateway，再去飞书开放平台配置「使用长连接接收事件」。顺序反了就会报这个错。补救办法：在服务器上openclaw gateway restart，然后回飞书后台重新保存事件配置。
事件订阅里找不到 im.message.receive_v1：在飞书开放平台「事件配置」页面点「添加事件」，搜索「接收消息」，添加im.message.receive_v1。添加后按指引确认开通权限。注意订阅方式必须选「使用长连接接收事件」，不要选 Webhook。
权限不足导致消息发不出：飞书应用需要至少这些权限：im:message、im:message.p2p_msg:readonly、im:message.group_at_msg:readonly、im:message:send_as_bot、contact:user.base:readonly。在「权限管理」页面用批量导入功能一次性加上。
排查时记住一个原则：先看openclaw logs --follow的日志停在哪一步，再对照上面的报错定位。日志不会骗人，它比飞书后台的配置页面更能反映真实链路状态。
6. 语义一致 CTA：把通道固定下来，再扩 Agent 就不慌了
新增 Agent 后飞书无回复，本质是「事件订阅 + 路由绑定 + 模型通道」三件事里有一件没对齐。把 settings 统一改到 TaoToken 之后，模型这一层就固定了，以后再加新 Agent，你只需要关注飞书事件订阅和bindings两处，排查范围直接砍半。
如果你还在验证阶段，想先确认模型通道本身没问题，可以直接用模型对话页面发一条测试消息，地址是https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=chat，看返回是否正常。确认通道可用后，再回到 OpenClaw 里配bindings。
如果你打算长期跑多智能体、接编码类 Agent 或做自动化任务，建议直接上 Coding Plan，把 Key 和额度统一管理，地址是https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan。这样每加一个 Agent，不用再单独申请 Key，直接复用同一条通道。
接入文档在https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc，里面有 Claude Code、Cline、Codex 等客户端的完整配置示例，包括auth.json、MCP 配置、Base URL + Key + Model ID 三件套的写法。照着抄一遍，比在飞书后台反复点按钮快得多。
最后留一个实操建议：每次新增 Agent，按「先curl测通道 → 再配bindings→ 重启 Gateway → 开日志发消息」的顺序走一遍。这套流程跑顺了，以后扩到五个、十个 Agent 都不会乱。
