Hermes 智能审批：每步操作不用再点头了
重度使用 Hermes Agent 的人都有一个共同的体验：看着 Agent 干活，一切顺利，然后——砰——弹出一个审批提示。你真的仔细读了吗？说实话。一天里第五十次看到 rm 相关的确认框时，大多数人就是闭着眼点「批准」。这就是审批疲劳，它是一件披着便利外衣的安全漏洞：你盖章越多，每一次盖章就越不值钱。
Hermes v0.19.0（Quicksilver 版本）从根上解决了这个问题。智能审批现在已经是默认开启的：Hermes 不再把每一条被标记的命令都丢给你审批，而是让一个独立的 LLM 评审逐条评估——低风险自动放行、真正危险的自动拒绝、只有拿不准的才会升级到你手上。打断变少了，但人工否决权一点没丢，甚至更强了，因为你的注意力只花在真正需要的地方。
这篇文章是一份实操指南：新的审批流程到底怎么运转、config.yaml 里真实存在的配置项（对照 v0.19 源码验证过的，不是网上流传的版本）、以及如何设置连 yolo 模式都越不过去的硬红线。
问题本质：审批疲劳本身就是安全漏洞
Agent 一次会话只跑几条命令的时候，手动审批还行得通。现在的 Agent 一次跑几十上百条。每一条提示都是一次上下文切换，每一次切换都在消耗你的注意力，被消耗的注意力会批准它本不该批准的东西。安全研究里这叫习惯化——你唯一该认真读的那条命令，恰恰就这么溜过去了。
旧流程还有第二个问题：你是那个风险分类器。Hermes 标记一条命令，你判断，结束。判断质量完全取决于你那一刻有多清醒——这恰恰是安全机制最糟糕的设计。
智能审批同时解决这两点：把日常分类交给一个永远不会累的模型，同时把最终决定权留在你手里。
智能审批怎么工作：三种结论，每条命令单独评审
当 Hermes 想运行一条命中危险模式列表的命令时，流程不再是「问人」，而是：
- 一个独立的辅助 LLM 评估这条命令——不是主 Agent 自己，而是单独的评审模型。
- 评审返回三种结论之一：
- 安全 → 自动放行，不打断你。
- 危险 → 自动拒绝，并记录原因。
- 拿不准 → 升级给你，手动批准/拒绝。
发布说明里有个容易被忽略的细节：每条评审结论只覆盖那一条具体的命令。之后即使有命令命中同样的模式，也会重新评审。不存在「这类命令之前批过，这次也批了」的捷径。评审模型不会被模式麻痹，你也不会——因为你只会看到真正模棱两可的案例。
你：「部署预发布服务器，并跑数据库迁移」
Hermes: [kubectl apply --dry-run ...] → 智能评审：安全，自动放行
[kubectl rollout restart ...] → 智能评审：安全，自动放行
[kubectl delete namespace prod] → 智能评审：危险，自动拒绝
[psql -c "DROP TABLE users;"] → 评审拿不准 → 升级给你这就是终结「点头时代」的流程。
真实配置：是 approvals.mode，不是网上传的野键
如果你看过一些讲 v0.19 审批的旧文章，可能会见到 smart_approvals: true、deny_rules: 带 pattern:/reason: 字段之类的写法。这些键根本不存在。 config.yaml 里真实的 schema 是：
# ~/.hermes/config.yaml
approvals:
mode: smart # smart | manual | off （smart 是默认值）
timeout: 300 # 等待你批准/拒绝的秒数，超时按拒绝处理
cron_mode: deny # deny | approve — cron 任务命中危险命令时的处理方式
deny: [] # 你自己的红线：无条件拦截的 glob 模式列表| 配置项 | 默认值 | 作用 |
|---|---|---|
mode |
smart |
被标记 shell 命令的审批策略 |
timeout |
300 |
等不到你的回复，多少秒后按拒绝处理 |
cron_mode |
deny |
无人值守场景：deny 拦截 cron 里的危险命令，approve 自动执行 |
deny |
[] |
无条件拦截命令的 glob 模式——yolo 模式也拦得住 |
随时可以查看当前配置：
hermes config | grep -A 4 approvals三种模式用大白话说：
smart（默认）——LLM 评审过滤日常命令；危险的直接拒绝；拿不准的才到你手上。manual——每条被标记的命令都提示你，和 v0.19 之前一样。off——完全没有审批提示；等同于--yolo/HERMES_YOLO_MODE=1。只用于可信的沙箱环境。
硬红线：approvals.deny 连 yolo 都拦得住
下面这部分是让你敢放松用智能模式的关键。deny 列表是一组 无条件拦截匹配命令的 glob 模式——在任何 yolo 绕过之前、/yolo 之前、mode: off 之前就生效。它是 Hermes 内置硬编码黑名单的用户可编辑对应物，也是你能配置的最重要的一道防线：
approvals:
mode: smart
deny:
- "git push --force*"
- "rm -rf /"
- "*curl*|*sh*"
- "kubectl delete namespace*"模式是不区分大小写的 fnmatch glob。YAML 里记得加引号——裸的开头 * 会解析报错。命中模式的命令会直接拦截并记录原因，没有商量余地，yolo 模式也一样。这就是你的「不管 Agent 多自信，这事儿就是不能发生」清单，里面应该放那几条一旦出错就无法接受的操作：往共享分支强推、递归删除、删生产 namespace、通过 CLI 写密钥。
如果确实需要一次性执行呢？配置里没有后门——这正是设计意图。真要强推，就移除模式、跑命令、再把它加回去。这点摩擦是故意的，而且成本极低。
/deny <reason>：让拒绝变成一次教学
智能审批不只是减少提示——它让你真正回答的那些提示变得更有价值。当评审把一条命令升级给你、你拒绝时，现在可以告诉 Agent 为什么：
Hermes 想运行: docker system prune -a -f
> /deny 太激进了——其他容器共享同一个镜像缓存理由会被写回上下文，Agent 会据此调整方向——它会去找一条更精准的命令，而不是重试同一条然后赌你心软。带理由的拒绝是反馈；不带理由的拒绝是一堵墙。养成给一句话理由的习惯，Agent 的下一次尝试会明显更好。
另外：如果 Agent 整个方向都跑偏了，/stop 依然可以瞬间终止当前运行。审批流程和停止按钮是互补的——一个过滤单条命令，一个切断整条序列。
Cron 任务：无人值守时谁来点头
智能审批在交互会话里很出彩，那无人值守的场景呢？定时 cron 任务命中危险命令时，没有用户可升级。默认的 cron_mode: deny 保守处理：命令被拦截，Agent 必须另想办法。如果你对某个任务很有信心（比如合法的夜间备份需要清理旧文件），可以单独放开它的策略：
approvals:
cron_mode: approve # cron 上下文里自动放行被标记的命令开启前请三思。deny 模式下 Agent 找到替代路径就零成本；approve 则把 cron 里每一次审批提示都变成静默自动执行。对大多数任务来说，deny 加上一条窄化的 approvals.deny 例外清单，才是正确的形态。
你该用哪种模式？
| 场景 | 推荐 |
|---|---|
| 日常交互开发 | smart（默认）——保留否决权，去掉噪音 |
| 动仓库 / 破坏性操作 | smart + deny 规则——不可逆操作画红线 |
| 完全可信的沙箱 / CI 容器 | off 或 --yolo，但保留 deny 规则兜底 |
| 怀旧 | manual——如果你真的想要每一条提示都回来 |
对大多数人来说答案就是：保持 mode: smart，花十分钟写 deny 规则，每次拒绝都用 /deny <reason>。这就是全部升级内容。
审批之外：纵深防御
智能审批只是 Hermes 纵深防御模型里的一层，不是全部。其他值得了解的层：checkpoints 会在破坏性文件操作前自动做文件系统快照（出错是回滚，不是灾难）、密钥脱敏会在工具输出进入上下文或日志前擦除长得像 API key 的字符串、容器隔离（Docker/Singularity/Modal 后端）可以把终端工具整个关进沙箱。审批决定命令跑不跑；checkpoints 决定命令跑完之后会怎样。两者是组合关系。
总结
Hermes v0.19 智能审批不是「Agent 现在啥都能干了」。恰恰相反：一个疲惫到闭眼盖章的人类，被一个永不疲倦的评审取代——它过滤日常、拦截危险、只把模棱两可的浮上来。真实配置只有三个键加一个习惯：
approvals.mode: smart—— 终结审批疲劳的默认值。approvals.deny: [...]—— 你的硬红线，yolo 模式也强制生效。approvals.cron_mode: deny—— 无人值守任务默认保持保守。- 那个习惯：
/deny <reason>—— 每一次拒绝都是一次教学。
Agent 获得更多自主权，你保留每一分控制权。不用再点头了。
想看更多 Hermes 安全和工作流指南？这里有 v0.19.0 发布深度解读、三道安全门：智能审批配置实战、yolo 模式全解析，还有错误处理与恢复指南。刚接触 Hermes？从安装指南开始。