1. 飞书里那四个按钮到底在批什么Hermes Agent 跑在飞书群里的时候最容易被忽略、又最容易出事的一环就是审批按钮。你让 Agent 执行一条命令它不会闷头就干而是先在飞书里弹一张卡片上面四个按钮Allow Once、Session、Always、Deny。很多人第一次看到会随手点 Always觉得省事结果后面 Agent 拿着永久授权在沙箱里跑rm -rf之类的命令你连它什么时候被放行的都不知道。这篇就聚焦feishu.py:1906-1909这一段按钮回调的实现逻辑把四个按钮从「点击」到「权限决策」的链路拆开讲清楚再给一份可以直接复制的config.toml/settings.json骨架配合 TaoToken 的统一 Key 接入让你在本地把整个审批流程复现出来亲眼确认四个按钮的行为差异。适合已经在用 Hermes Agent、或者正准备把它接进飞书工作流的人读完你能自己改回调、加审计日志、把 Always 关进笼子里。核心检索词先摆出来Hermes Agent 的飞书审批按钮、feishu.py回调实现、Allow Once / Session / Always / Deny 四级权限、TaoToken 统一 Key 配置。下面按「问题场景 → 前置准备 → 可复制配置 → 验证 → 排障 → 接入」的顺序走。2. 原问题与场景四个按钮的语义差异先把四个按钮的语义对齐不然后面看代码会懵。Allow Once 是「本次批」只放行当前这一条命令执行完授权即失效下一条危险命令还会再弹卡片。Session 是「本会话内都批」从点击那一刻起当前会话里同类命令不再询问会话结束授权回收。Always 是「永远批」写进持久化配置重启 Hermes 依然生效这也是最危险的一个。Deny 是「拒绝」命令不执行回调返回拒绝态。问题就出在 Always 上。feishu.py:1906-1909这段回调里四个按钮走的是同一个分发入口靠button_id区分分支。如果这段逻辑没有对always做二次确认用户一次误点就等于给 Agent 开了永久后门。我见过最典型的报错现象是群里有人点了 Always之后 Agent 连续执行了好几条带sudo的命令卡片再也没弹过直到有人发现日志里多了一堆越权操作。根因一句话概括危险命令触发审批卡片而按钮 callback 在feishu.py:1906-1909这类平台实现里对 Always 分支缺少拦截和审计。配置层其实有两个字段能大幅减少触发概率代码层则需要在 callback 里补审计日志和二次确认。下面先把前置环境准备好。3. TaoToken 前置统一 Key 与接入准备Hermes Agent 本身要调用模型飞书侧只是审批交互层。为了让本地复现时模型调用稳定、Key 管理不散落建议用 TaoToken 做统一入口。它的作用是给你一个兼容常见协议的统一 KeyHermes 的模型配置指向它就行不用在多个平台之间来回换 Key。你需要准备的东西不多一个 TaoToken 账号、一个 API Key、本地装好的 Hermes Agent v0.16.0、以及一个能收飞书卡片的测试群。Key 的获取在控制台的 API Keys 页面模型对话入口可以用来先验证 Key 是否可用接入文档里有各协议的 base_url 和鉴权头写法。注意TaoToken 的 API 地址是https://taotoken.net/api配置里不要带多余的路径后缀鉴权用标准的 Bearer 头。官网入口在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content需要看文档时从那里进。拿到 Key 之后先别急着配 Hermes用模型对话页面发一条最简单的消息确认 Key 有效、额度正常。这一步能帮你排除掉后面 80% 的「到底是 Key 问题还是回调问题」的扯皮。确认可用后再往下配 Hermes 的模型段。4. 可复制配置config.toml 与 settings.json 骨架Hermes 的配置分两层模型接入层和终端安全层。模型层指向 TaoToken安全层控制审批行为。下面这份骨架可以直接抄改掉 Key 和飞书凭证即可。# ~/.hermes/config.toml [model] provider openai-compatible base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model claude-sonnet-4-20250514 [terminal] backend docker # 危险命令跑在沙箱里影响面小 timeout_seconds 60 [security] tirith_enabled true # 自动拦截高危命令 require_confirm_always true # Always 按钮强制二次确认 audit_log_path ~/.hermes/audit/approval.log [security.exec_allowlist] commands [git status, ls, cat, pwd, git diff] [security.exec_denylist] commands [rm -rf, curl|sh, sudo, chmod 777] [feishu] app_id cli_你的AppID app_secret 你的AppSecret verification_token 你的VerificationToken对应的settings.json用于飞书侧卡片与回调注册字段和 toml 里的安全段呼应{ feishu: { card_callback_path: /hermes/feishu/callback, approval_buttons: [allow_once, session, always, deny], always_requires_admin: true, audit: { enabled: true, log_path: ~/.hermes/audit/approval.log, fields: [user_id, button_id, command, timestamp] } }, security: { tirith_enabled: true, exec_allowlist: [git status, ls, cat, pwd, git diff], exec_denylist: [rm -rf, curl|sh, sudo, chmod 777] } }两个文件里require_confirm_always和always_requires_admin是同一件事的两处开关前者管 Hermes 内核后者管飞书卡片回调建议都开。audit_log_path指向的目录要提前建好否则回调写日志时会静默失败你排查半天以为是按钮没触发。配置改完回到feishu.py:1906-1909这段回调理解它怎么读这些字段。这段代码的核心是拿到button_id后做分支allow_once直接放行当前命令session写入会话级缓存always先检查always_requires_admin为真则要求管理员二次确认deny直接返回拒绝。审计日志应该在分支之前统一写一条保证四个按钮都有记录。5. 验证请求跑一条危险命令看四个按钮配置就绪后启动 Hermes 并触发一次审批。用uv run python hermes启动然后在飞书群里发一条会触发审批的命令比如让 Agent 执行sudo ls /root。正常情况下卡片会弹出四个按钮。# 启动 Hermes uv run python hermes # 在飞书群发送触发审批的指令 # 例如帮我执行 sudo ls /root点击 Allow Once观察命令执行一次后再发一条同类命令卡片应该再次弹出说明授权没有持久化。点击 Session再发同类命令卡片不再弹但重启 Hermes 后授权失效。点击 Always如果always_requires_admin生效应该先弹一个管理员确认卡片确认后才写入持久化配置。点击 Deny命令不执行日志里能看到拒绝记录。验证审计日志是否落盘tail -f ~/.hermes/audit/approval.log # 期望看到类似 # {user_id:ou_xxx,button_id:always,command:sudo ls /root,timestamp:2025-...}四个按钮都点一遍日志里应该有四条对应记录button_id各不相同。如果 Always 那条没有二次确认卡片直接放行说明always_requires_admin没生效回去检查settings.json的字段名是否拼错或者飞书回调是否读的是旧配置。6. 本篇常见错排查第一个坑是回调路径对不上。飞书卡片的card_callback_path必须和 Hermes 实际注册的路由一致否则你点按钮飞书那边显示成功Hermes 这边根本没收到。排查方法是看 Hermes 启动日志里注册的路由列表和settings.json里的路径逐字比对。第二个坑是审计日志目录不存在。audit_log_path指向的父目录如果没建写日志会抛异常但很多实现会吞掉这个异常表现就是「按钮点了没反应」。先mkdir -p ~/.hermes/audit再启动。第三个坑是 Always 的二次确认没生效。常见原因是require_confirm_always和always_requires_admin只开了一个或者feishu.py:1906-1909这段回调读的是硬编码默认值而不是配置。改完配置记得重启 Hermes热加载不一定覆盖安全段。第四个坑是 allowlist 和 denylist 冲突。同一条命令同时出现在两个列表里时行为取决于实现顺序通常是 denylist 优先。别把git status这种安全命令放进 denylist也别指望 allowlist 能绕过 Always 的二次确认两者管的是不同层。第五个坑是 Key 配错导致模型调用失败误以为是审批问题。如果卡片弹不出来先确认模型层能正常返回用模型对话页面单独测一次 Key排除掉接入层问题再查回调。7. 语义一致 CTA把审批链路接稳审批按钮这条链路配置层和安全层要一起改才稳。如果你还在调 Key 和接入参数先去 API Keys 页面把统一 Key 建好再对照接入文档把base_url和鉴权头配准这两步是后面所有验证的前提。Key 没通按钮点得再对也看不到模型响应。模型验证通过后建议用模型对话页面把几个常用模型各发一条消息确认 TaoToken 侧的路由和额度都正常再回到 Hermes 里跑审批复现。如果你打算把 Hermes 长期挂在飞书群里做编码或 Agent 任务Coding Plan 更适合这种持续调用的场景Key 和额度管理会比按次调用省心。最后提醒一句Always 按钮能不用就不用require_confirm_always和always_requires_admin两个开关都打开审计日志定期翻一翻。审批链路的价值不在于按钮多好看而在于每一次放行都有记录、每一个永久授权都有人确认。