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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole在 API Keys 页面点新建复制生成的 Key 保存好。第二步把 Key 和 Base URL 写进 OpenClaw 的 settings 配置。如果你用的是 Claude Code 类的编码场景TaoToken 也提供了对应的接入文档地址是https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc里面有各客户端的配置示例。这里要强调一个排查思路当飞书消息没回复时先确认模型通道是通的。你可以用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结尾不要多加/v1TaoToken 的接口路径已经内置。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 和飞书账号没写bindingsOpenClaw 会把所有消息路由给默认 Agent通常是main新 Agent 永远收不到消息。这就是「新增 Agent 后飞书无回复」最常见的原因之一。配置改完重启 Gateway 让 settings 生效openclaw gateway restart然后验证绑定是否生效openclaw agents list --bindings正常输出里每个 Agent 下面应该显示Routing rules: 1并列出对应的feishu accountIdxxx。如果新 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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentchat看返回是否正常。确认通道可用后再回到 OpenClaw 里配bindings。如果你打算长期跑多智能体、接编码类 Agent 或做自动化任务建议直接上 Coding Plan把 Key 和额度统一管理地址是https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan。这样每加一个 Agent不用再单独申请 Key直接复用同一条通道。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc里面有 Claude Code、Cline、Codex 等客户端的完整配置示例包括auth.json、MCP 配置、Base URL Key Model ID 三件套的写法。照着抄一遍比在飞书后台反复点按钮快得多。最后留一个实操建议每次新增 Agent按「先curl测通道 → 再配bindings→ 重启 Gateway → 开日志发消息」的顺序走一遍。这套流程跑顺了以后扩到五个、十个 Agent 都不会乱。
OpenClaw 多智能体实战：新增 Agent 后飞书 im.message.receive_v1 无回复，把 settings 改到 TaoToken 排查
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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole在 API Keys 页面点新建复制生成的 Key 保存好。第二步把 Key 和 Base URL 写进 OpenClaw 的 settings 配置。如果你用的是 Claude Code 类的编码场景TaoToken 也提供了对应的接入文档地址是https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc里面有各客户端的配置示例。这里要强调一个排查思路当飞书消息没回复时先确认模型通道是通的。你可以用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结尾不要多加/v1TaoToken 的接口路径已经内置。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 和飞书账号没写bindingsOpenClaw 会把所有消息路由给默认 Agent通常是main新 Agent 永远收不到消息。这就是「新增 Agent 后飞书无回复」最常见的原因之一。配置改完重启 Gateway 让 settings 生效openclaw gateway restart然后验证绑定是否生效openclaw agents list --bindings正常输出里每个 Agent 下面应该显示Routing rules: 1并列出对应的feishu accountIdxxx。如果新 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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-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_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentchat看返回是否正常。确认通道可用后再回到 OpenClaw 里配bindings。如果你打算长期跑多智能体、接编码类 Agent 或做自动化任务建议直接上 Coding Plan把 Key 和额度统一管理地址是https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan。这样每加一个 Agent不用再单独申请 Key直接复用同一条通道。接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc里面有 Claude Code、Cline、Codex 等客户端的完整配置示例包括auth.json、MCP 配置、Base URL Key Model ID 三件套的写法。照着抄一遍比在飞书后台反复点按钮快得多。最后留一个实操建议每次新增 Agent按「先curl测通道 → 再配bindings→ 重启 Gateway → 开日志发消息」的顺序走一遍。这套流程跑顺了以后扩到五个、十个 Agent 都不会乱。
