飞书审批按钮报 200340？Hermes Agent 远程执行卡片回调的配置排查指南

很多团队把 Hermes Agent 接到飞书 / Lark 之后，会遇到一个很“像代码 bug”的问题：平时聊天、发送消息都正常，但一到危险命令审批，点击 Allow Once / Session / Always / Deny 按钮就弹出：

出了错了，请稍后重试 code: 200340

从表面看，这是 Hermes 的 command approval 卡片坏了；但从官方修复结论看，它更像是一个 飞书应用控制台配置问题：消息卡片能发出去，不代表卡片点击回调已经配置完整。

这篇文章基于 NousResearch/hermes-agent 中一个已关闭并标记 completed 的高讨论度问题，整理 Feishu / Lark 网关审批失败的排查路径。重点不是复述 issue，而是给正在搜索这些关键词的人一个可执行答案：

Feishu 200340 approval button
Lark card action callback not configured
Hermes Agent 飞书审批失败
Command Approval Required card 200340
card.action.trigger 飞书机器人配置

结论先说：200340 多半不是模型 API 问题

Hermes Agent 的飞书网关里，危险命令审批依赖“交互式消息卡片”。流程大致是：

1. Agent 准备执行敏感命令，例如删除文件、修改受保护路径； 2. Hermes 发送一张 Command Approval Required 卡片； 3. 用户点击 Allow Once、Session、Always 或 Deny； 4. 飞书把按钮点击事件回调到 Hermes Gateway； 5. Hermes 根据回调结果继续或拒绝执行。

如果第 4 步没有配置好，现象就会变成：

卡片能显示；
按钮也能点；
但点击后飞书提示 200340；
Agent 侧可能卡在 Still working...；
CLI / TUI 本地审批却正常。

这说明问题不在模型生成、不在 DeepAI / OpenAI Compatible API，也不一定在 Hermes 的审批逻辑本身，而在 飞书卡片 action callback 没有被应用正确接收。

典型症状：聊天正常，审批卡片一点击就失败

这个问题最容易误判，是因为飞书机器人本身看起来已经“接通”了：

现象	容易误判	更可能的真实原因
Bot 能发消息	网关配置都没问题	只能证明发送权限正常
审批卡片能出现	交互卡片功能正常	只能证明卡片发送成功
点击按钮报 200340	Hermes 代码处理失败	飞书未把 card action 回调发给应用
CLI/TUI 审批正常	飞书适配层 bug	本地审批绕开了 Feishu callback
重新发布后不报错但没反馈	修了一半	callback 可能到了，但卡片更新/反馈仍需检查

这类问题最关键的判断标准是：

> 能发送卡片，不等于能接收卡片按钮回调。

飞书的消息发送权限和交互卡片回调能力是两套配置，很多人只开了前者。

根因：飞书应用缺少 card action callback 配置

官方在对应修复 PR 中给出的根因很明确：

> Error 200340 means card action callback is not configured for this application。

也就是说，Hermes 的 Feishu 实现并不是核心问题；真正缺失的是文档里没有把飞书开发者控制台必须开启的步骤讲完整。

最终修复不是改审批算法，而是补充 Feishu 文档，要求用户完成三项配置：

1. 订阅 card.action.trigger 事件； 2. 在机器人能力里开启 Interactive Card； 3. Webhook 模式下配置 Message Card Request URL。

这也解释了为什么评论区里有人说“加了卡片回调还不行”，后来又有人补充“加了之后要重新发布版本”。飞书应用配置变更后，如果没有重新发布 / 生效，线上机器人仍然可能拿不到新的事件能力。

正确排查顺序：先查 Feishu Console，再查 Hermes 日志

遇到 200340 时，不建议先去换模型、换 base URL 或改 prompt。更稳的顺序是：

1. 确认是否订阅 `card.action.trigger`

进入飞书开发者后台，在事件订阅里确认是否加入：

card.action.trigger

这是卡片按钮点击事件。没有它，用户点击审批按钮后，Hermes 根本收不到“允许 / 拒绝”的决定。

2. 确认 Bot 开启了 Interactive Card 能力

在飞书应用的 Bot / App Features 区域，检查是否开启交互式卡片能力。

注意：im:message:send 这类权限只能让 Bot 发消息，不能自动代表它能处理卡片按钮点击。

3. Webhook 模式配置 Card Request URL

如果你的 Feishu Gateway 使用 webhook 模式，需要把 Message Card Request URL 指到 Hermes 的飞书 webhook endpoint，例如：

https://your-domain.example.com/feishu/webhook

具体域名和路径以你的 Hermes Gateway 暴露地址为准。核心原则是：卡片点击回调要打到和事件 webhook 一致的 Hermes 接收端。

4. 重新发布飞书应用版本

这是很多人漏掉的一步。

飞书开发者后台改完能力、事件、回调 URL 后，通常需要重新发布版本或让配置生效。否则你在后台看到“已配置”，线上机器人仍可能按旧版本运行。

5. 再看 Hermes Gateway 日志

完成上面配置后，再看 Hermes Gateway 日志是否收到 card action 事件。如果日志里完全没有按钮点击事件，继续查飞书侧；如果 Hermes 收到了事件但处理失败，再看 Hermes 的审批逻辑、token、route、会话状态。

为什么关掉 approve.model 不一定能解决？

有些用户会尝试把审批相关配置调低，例如关闭某些 model approval 或改成 smart approval。这样可能减少弹窗次数，但不等于修复卡片回调。

原因很简单：

approvals.mode = smart：可能让低风险命令自动审批，减少人工点击；
approve.model = off：只影响某类模型辅助判断或审批策略；
高风险命令：仍可能触发人工审批卡片；
飞书 callback 没配置：只要还需要点按钮，仍会撞上 200340。

所以这类配置只能作为临时降噪，不是根治。

如果你的 Hermes 跑在隔离容器里，临时降低审批强度可能方便开发；但如果它能访问真实主机文件、生产密钥或重要目录，不建议为了绕过 200340 直接放宽安全策略。

CLI/TUI 正常，飞书失败，说明什么？

这是一个很有价值的定位信号。

如果同一个危险命令：

在 Hermes CLI / TUI 里审批成功；
在 Telegram 或其他网关里审批成功；
只有 Feishu / Lark 卡片按钮失败；

那就优先判断为 Feishu Gateway 的交互事件链路问题，而不是 agent core、模型供应商或 shell 执行器的问题。

换句话说，排查边界应该这样切：

用户点击按钮
  ↓
飞书 card.action.trigger
  ↓
Feishu callback / webhook / websocket
  ↓
Hermes Gateway
  ↓
approval service
  ↓
命令继续执行或拒绝

200340 发生在前半段：飞书应用没有正确把卡片按钮事件交给你的服务。

和 DeepAI API 中转站有什么关系？要分层看

这类飞书审批问题本身不属于模型 API 层，所以不能说换成 DeepAI API 中转站就能修复 200340。如果卡片点击事件没有进入 Hermes Gateway，任何模型服务都还没机会参与。

但在 Hermes 这类 agent 系统里，排错时建议把链路分成两层：

1. 消息 / 网关层：飞书、Matrix、Discord、Telegram、Webhook、callback、权限、事件订阅； 2. 模型调用层：OpenAI Compatible API、Base URL、API Key、模型名、上下文、temperature、tool calling。

DeepAI API 中转站更适合解决第二层问题，例如：

想统一管理多个 OpenAI-compatible 模型；
想给 Cherry Studio、Cline、Dify、Open WebUI 等工具配置统一 Base URL；
想减少不同供应商 API Key 分散管理；
想在模型选择、账单、调用稳定性上做集中控制。

如果你的问题是 invalid_api_key、model not found、rate limit、context length exceeded、OpenAI Compatible endpoint 不一致，这时再看 DeepAI API 中转站会更合适。

但如果是飞书 card.action.trigger 没配，先修 Feishu Console。

FAQ

Feishu 200340 是 Hermes Agent bug 吗？

在这个已关闭问题的官方结论里，200340 被归因为飞书开发者控制台缺少 card action callback 配置。Hermes 代码本身不是主要根因，修复重点是补文档和配置步骤。

为什么卡片能发出来，但按钮不能用？

因为发送卡片和接收按钮回调是两件事。发送只需要消息发送相关权限；按钮点击需要 card.action.trigger、Interactive Card 能力和 Card Request URL 等配置。

配了 `card.action.trigger` 还是不行怎么办？

继续检查 Interactive Card 是否开启、Webhook 模式下 Card Request URL 是否配置、应用是否重新发布。很多人只做了第一步，没有完成三项配置。

WebSocket 模式也要配置 Card Request URL 吗？

官方修复说明里提到，Webhook 模式需要配置 Card Request URL；WebSocket 模式通常由 SDK 处理。实际仍建议以你当前 Hermes / Feishu 网关文档版本为准。

可以临时关闭审批绕过吗？

不建议在真实主机或生产环境这么做。你可以用隔离容器、测试目录、低权限用户降低风险，但不要为了绕过一个回调配置问题而长期放宽危险命令审批。

小结

飞书 / Lark 中 Hermes Agent 审批按钮报 200340，最重要的结论是：

> 先查飞书交互卡片回调配置，不要先怀疑模型 API。

完整修复通常包括：订阅 card.action.trigger、开启 Interactive Card、配置 Card Request URL，并重新发布应用版本。

如果你同时在做 Hermes Agent 的模型接入、OpenAI Compatible API 统一配置、Cherry Studio / Cline / Dify / Open WebUI 多工具管理，可以再把模型层统一到 DeepAI API 中转站；但飞书审批按钮这类问题，必须先把消息回调链路打通。