高风险操作拦截失败？Hermes Agent 异步审批机制的 4 级人工介入配置实践
1. 高风险操作拦截失败？不是模型不听话，是审批链路没“断电”
上周三下午，我们线上服务的数据库备份脚本被一个新接入的 Hermes Agent 自动触发了全量重建——它把生产库的 schema 导出后，又顺手执行了DROP TABLE IF EXISTS。所幸没走--force参数，但告警钉钉群里弹出的那句dangerous command requires approval: DROP TABLE已经晚了：审批弹窗在开发者的 Slack 里静默了 17 分钟，没人点“确认”，而 agent 默认超时策略是“跳过并继续”。
这不是模型幻觉，也不是 prompt 写得不够狠。这是 Hermes Agent 的异步审批机制在真实场景中暴露的结构性缺陷：它默认把“人工介入”当成一个可选的、带超时的 HTTP 回调，而不是一条必须物理阻断执行流的电路开关。
我翻了 v0.13.0 到 v0.14.2 的 release note 和 GitHub issues，发现至少有 12 个团队报告过类似问题——不是审批没触发，而是触发了却“不生效”。根本原因在于：Hermes 的approval_required标签只控制是否弹窗，不控制是否暂停；timeout_seconds只决定弹窗消失时间，不决定任务是否终止；而fallback_action的默认值continue更是埋雷。
我们最终在三个项目上落地了「4 级人工介入配置」，把审批从“提醒”变成“闸门”。这套方案不依赖任何