Last updated on

Hermes v0.19 上线智能审批：手把手教你怎么设置 3 道闸门，附命令

Hermes Agent v0.19.0 把**智能审批（Smart Approvals）**设成了默认行为。过去，当 Agent 想执行一条被标记（flagged）的命令时，它会直接打断你，让你逐条确认。现在，一个独立的 LLM 审查员会先对命令做「安全 / 危险 / 不确定」三连判，只有不确定的才会推到你面前。

听起来很美好，但生产环境里「自动放行」一旦出错，代价可能是删库、改错配置、或者把敏感 token 发到不该发的地方。所以本文会把它拆成三道可以落地的闸门，让你既保留自动化的爽，也不让控制权溜走。文中的所有配置项都对照 v0.19.0 源码和官方文档核实过——网上流传的 smart_approvals: true、deny_rules: 带 pattern:/reason: 字段等写法并不存在，真实 schema 见下文。

如果你还想先了解这次 v0.19 的整体升级，可以先看我们写的v0.19.0 发布说明和v0.19 功能速览。

第一道闸门：LLM 预审——安全放行，危险拒绝，不确定才找你

v0.19 的默认机制就是这一道。Hermes 不再把每条命令都甩给你，而是让内部审查模型先判断一次。

决策逻辑：

  • 安全 → 自动通过，不打断
  • 危险 → 自动拒绝，并记录原因
  • 不确定 → 升级到人类确认

每条命令单独审查，前一条通过了，下一条同样模式的命令不会自动放行。它缓解了「审批疲劳」，但也带来一个新问题：审查模型的判断标准对你是个黑盒。所以你需要第二道闸门兜底。

顺带一提，评审用的模型是可以换的：真实配置在 auxiliary.approval（不是 approvals.review_model，那个键不存在），后面完整示例里会给出。

第二道闸门：approvals.deny 硬红线——yolo 模式也拦得住

v0.19 在 config.yaml 里给你的红线配置是 approvals.deny：一个 fnmatch glob 模式列表，命中就无条件拦截对应命令。它的优先级高于 --yolo、/yolo 和 mode: off——换句话说，它是 Hermes 内置硬编码黑名单（hardline blocklist）的用户可编辑对应物：「不管 Agent 多自信，这条命令就是不能跑」。

典型配置示例：

# ~/.hermes/config.yaml
approvals:
  mode: smart        # smart | manual | off（smart 是默认值）
  deny:              # 硬红线：无条件拦截的 glob 模式
    - "git push --force*"
    - "rm -rf /"
    - "*curl*|*sh*"
    - "kubectl delete namespace*"

使用建议：

  1. 先写出你绝对不希望自动执行的操作类别——强推共享分支、递归删除、删生产 namespace、通过 CLI 写密钥，等等。
  2. 模式是大小写不敏感的 fnmatch glob，不是正则。YAML 里记得加引号——以裸 * 开头的模式会解析报错。
  3. 命中后 Agent 会收到明确的 BLOCKED 消息，并被明确告知不要重试或改写这条命令。deny 列表没有 reason 字段；想记录原因，用 YAML 注释写在旁边即可。
  4. 注意：approvals.deny 匹配的是终端命令（匹配前会做归一化和反混淆处理，r\m、git st""atus 之类的改写绕不过去），不是工具调用字符串——browser_*、file_* 这类工具调用不在它的管辖范围。

第三道闸门：人工干预与可学习反馈——/deny 不只是拒绝

当 LLM 预审无法判断、命令被送到你面前时，你通常只有两个选择：同意或拒绝。v0.19 的拒绝还支持带理由：/deny <reason>（/deny all <reason> 一次拒绝全部待审批命令）。你拒绝的同时，理由会被转达给 Agent 写进上下文，下一次遇到类似场景时，它会调整方向而不是重试同一条命令。

CLI / TUI 示例：

# Hermes 想执行：docker system prune -a -f
# 你判断现在不是时候，附带理由拒绝
/deny 这会清理所有镜像，可能影响其他容器

# 理由会写进上下文，后续尝试会避开类似命令

如果你只是想临时阻止一次，不带理由的直接拒绝也行；但如果你想让 Agent 长期学习，建议养成带理由拒绝的习惯——带理由的拒绝是反馈，不带理由的拒绝是一堵墙。

另外，当 Hermes 正在执行一连串操作而你突然发现方向完全错了，可以立即用 /stop 终止当前运行，这是 v0.3 就有的老朋友，但在 v0.19 和审批流配合时尤其有用。

一个完整的三闸门配置示例

# ~/.hermes/config.yaml
approvals:
  mode: smart                   # smart | manual | off（smart 是默认值）
  timeout: 300                  # 等待你批准/拒绝的秒数，超时按拒绝处理
  cron_mode: deny               # deny | approve — cron 无人值守场景的策略
  deny:                         # 硬红线：无条件拦截，yolo 模式也生效
    - "rm -rf /"
    - "git push --force*"
    - "kubectl delete namespace*"
    - "*curl*|*sh*"
  denial_breaker_threshold: 3   # 连续拒绝 N 次后升级为硬停止（0 关闭）
  smart_policy: |               # 可选：给评审 LLM 追加自定义判断规则
    Always ESCALATE commands that modify anything under /etc.

# 评审模型（可选）：默认 auto 自动选择，建议指定一个又快又便宜的模型
auxiliary:
  approval:
    provider: auto              # auto | openrouter | nous | codex | custom
    model: ""                   # 留空用 provider 默认；如 gemini-flash、haiku 级别

几个容易被忽略的点：

  • denial_breaker_threshold（默认 3）：评审模型连续拒绝同一条命令的多个变体时，每次都还会再烧一次评审调用。连续拒绝达到阈值后，拒绝消息会升级成硬停止指令——Agent 必须停下来报告被拦截的操作，由你手动执行或 /approve。任何一次批准都会重置计数；设 0 关闭。
  • smart_policy：把自定义规则追加到评审 LLM 的 system prompt（可信通道，不会和不可信的命令文本混在一起），用来收紧或放松它对特定环境的判断，不用改代码。
  • 配置路径是 ~/.hermes/config.yaml（或当前 Profile 自己的 config.yaml），不是项目目录里的 .hermes/config.yaml。

保存后重启 Hermes 即可生效。验证是否加载成功：

hermes config get approvals.mode
hermes config get approvals.deny

什么时候三道闸门会同时生效？

场景 第一道：LLM 预审 第二道：approvals.deny 第三道：人工决策
ls -la 查看目录 自动通过 未命中 不打扰
rm -rf / 命中 deny 直接拒绝，yolo 也拦 无需人工
docker system prune -a 判断为不确定 未命中 升级问你
连续拒绝同一条命令的变体 触发熔断阈值 — 硬停止，等你手动执行

这套组合的关键在于：LLM 预审负责日常减负，approvals.deny 负责硬约束，人工决策负责灰色地带。三道闸门不是互相替代，而是互相补充。

进阶：按 Profile 区分审批强度

Hermes 的每个 Profile 都有自己独立的配置目录（默认 Profile 是 ~/.hermes/config.yaml，命名 Profile 是 ~/.hermes/profiles/<name>/config.yaml），所以按 Profile 区分审批强度不需要在配置里写嵌套的 profiles: 键——直接编辑对应 Profile 自己的配置文件即可。例如：工作 Profile 保持三道闸门全开；个人 Profile 用 mode: off 加 deny 兜底；CI/CD 用的 Profile 只留 deny 红线、关掉 LLM 预审。切换 Profile 时，Hermes 自动加载对应的那套规则。

常见坑与排错

  1. deny 规则不生效：检查路径——用户级配置是 ~/.hermes/config.yaml（或当前 Profile 的 config.yaml），不是项目目录里的 .hermes/config.yaml。另外，改完配置需要重启 Hermes/gateway 才会重新加载，没有 hermes config reload 这个命令。
  2. LLM 预审太慢：通过 auxiliary.approval.model 指定一个轻量模型（比如 gemini-flash、haiku 级别），而不是用默认的评审模型。
  3. yolo 模式下还是弹确认：命令被评审判定为「不确定」，且没有命中任何 approvals.deny 模式。把这类命令写进 deny，或用 smart_policy 收紧评审规则。
  4. YAML 解析报错：glob 以 * 开头时必须加引号（如 "*curl*|*sh*"），否则整个 approvals 段解析失败、配置被忽略。

总结

Hermes v0.19 的智能审批不是「把权力交给 LLM」，而是「让 LLM 先帮你筛一遍，最终决策权仍在人类手里」。把它拆成三道闸门：

  • 第一道：LLM 预审（approvals.mode: smart），自动处理日常命令
  • 第二道：approvals.deny 硬红线，yolo 模式也无效
  • 第三道：/deny <reason> 和人工确认，保留可学习的人类干预

配置好后，你的 Agent 既不会变成哑巴（什么都要问），也不会变成野马（什么都能做）。

# 修改 config.yaml 后重启 Hermes 即生效（没有 reload 命令）
hermes config get approvals.mode    # 验证模式
hermes config get approvals.deny    # 验证红线

想继续了解 Hermes 的安全与效率相关能力，可以查看我们之前的错误处理与恢复指南，以及长任务不卡死配置。想深入理解智能审批为什么是默认行为，推荐阅读审批疲劳：为什么你不再需要给每一步点头。