AIOps实战：Hermes如何管控AI的写操作

现阶段，我十分看好Hermes作为运维工具的价值。它具备自我进化与自动构建skill的亮点，确实很实用。不过，它也并非完美，安全方面的隐患必须重视。

虽然成熟的AIOps理应能自主解决故障，但现阶段我们仍不敢将所有操作，尤其是频繁的“写”操作，完全托付给AI。

因此，这两天我专门研究了Hermes的审批机制。即当其执行我们认为风险较高的操作时，必须先经过人工批准方可继续。

01 | Hermes 内置的审批机制

根据Hermes官方文档，执行命令前会检测危险模式，一旦触发即请求人工批准；安全模型中设有“Dangerous command approval”层，专门针对破坏性操作实施人机协同审批。

配置示例如下：

该配置的具体含义包括：

① 凡是触犯危险规则的指令，均需人工核准；② 若60秒内无人批准，则默认拒绝执行；③ 无人值守的定时任务若遇到危险指令，同样默认拒绝。

注意，设置approvals.mode: off会禁用安全提示，这仅适用于可信且隔离的环境。

Hermes 触发审批的常见操作涵盖：递归删除、mkfs/dd、SQL DROP TABLE、无WHERE条件的DELETE FROM、TRUNCATE TABLE、修改/etc/、systemctl stop/restart/disable/mask、远程脚本管道执行、强制结束进程等。

02 | 运维中的“写操作”不能仅靠命令规则，需构建工具层审批

核心问题在于：Hermes 内置审批主要针对Shell命令的危险模式。然而运维中的许多“写操作”未必表现为危险Shell命令，例如：

这些操作可能无法被Hermes的危险命令规则完全覆盖。因此更稳妥的做法是：将运维写操作封装为Hermes插件/MCP工具，并在工具调用前增加审批拦截。

在Hermes的工具执行流程中，模型发起tool_call后，会先触发pre_tool_call插件钩子，随后进入工具分发；终端命令还会经过危险命令审批检查。

其中，pre_tool_call可用于阻止工具调用，并强制对destructive write_file/patch等操作进行审批。

推荐的架构方案如下：

03 | 建议将工具划分为 read / plan / write 三种类型

运维Agent最好避免模型直接执行写操作，而是拆解为三个步骤：

① read：仅读取查询

② plan：生成变更方案、差异对比、风险说明

③ write：实际执行变更，必须经过审批

以Kubernetes场景为例：

其中的apply_k8s_change才是真正的写操作，必须审批。

可采用如下策略表：

04 | 审批内容必须清晰易懂

不要仅展示：

应当展示：

05 | 如何将审批流程接入飞书等即时通讯工具

基本思路是：开发一个Hermes插件，利用pre_tool_call钩子拦截写操作，随后通过飞书API发送交互卡片供用户审批。

插件结构如下：

handler.py 的具体内容

以上仅是我的一些初步构想，

后续还需要通过实践来进一步验证。

希望能起到抛砖引玉的作用。