Hermes Agent 技能治理实录：关掉自动审查，改用 git 审计 + 变更快照 + 每周自检三道防线（v0.20.4 实测）

📖 摘要：Hermes Agent 实测：background_review 是官方承认的错误假设来源，write_approval 耗人——关掉自动审查，改用 git 审计 + 变更快照 + 每周自检三道防线。

导读

目标读者：正在用 Agent 做自动化交付的开发者、担心 Agent 自主变更配置的独立用户。

环境版本：Hermes Agent v0.20.4 + deepseek-v4-flash（2026-08 实测）。

读完你将获得：① 两个官方机制的真实边界与取舍依据 ② 事前审批 vs 事后审计的完整决策链 ③ git 审计 + 变更快照 + 每周自检的落地命令。

如果你的 Agent 会趁你不注意改掉你的技能文件，你会怎么办？

这篇文章写给两类人：一类是正在用 Agent 做自动化交付、担心「我的 Agent 会不会自己改我的配置」的；另一类是已经发现 Agent 会自作主张更新技能、想找一个可落地的治理方案的。

我会完整还原一个决策链：Agent 悄悄改技能的事故 → 两个官方机制的剖析 → 第一轮治理（事前逐笔审批）的效果与代价 → 为什么最终关掉了后台自动审查 → 以及替代它的事后审计体系长什么样。所有配置命令真实可复现，所有结论都来自本机实测。

先说结论：治理的本质不是「堵住 Agent 的嘴」，而是「让每一次变更都可追溯、可回滚」。前者越堵越累，后者一次建好，长期省心。

关于实测环境多说一句：本文基于 Hermes Agent v0.20.4 + deepseek-v4-flash 实测。技能治理这类任务（看 diff、判断是否采纳）是低复杂度判断场景，模型选型不影响结论；长周期多步编排任务则另当别论，不在本文范围。

一、事故：Agent 悄悄改了技能

事情的起因是一个周末的例行检查。我在翻技能库的 git 状态时，发现多了几个文件——不是我创建的，也不是我让任何会话创建的。git log 一查，是并行会话里 Agent 自主 patch 进去的：它判断某个技能「过时了」，就自己改了一版。

这听起来像是 Agent 在「主动改进」，但问题在于：这几处改动的依据不充分。有的引用了它从未读过的文件内容，有的是基于会话推断的「应该这样」——不是实测验证过的结论。官方源码里对这类自动改动有一句非常直白的自我评价，原文是：

the source of the "wrong assumptions" users complained about

——「用户抱怨的错误假设的来源」。官方自己都知道这个机制会产出错误假设。

如果你也在用 Agent，第一反应可能是：加个审批不就行了？我当时也是这么想的。但走完一轮之后发现，问题比想象的多一层。

二、两个官方机制：background_review 与 write_approval

Hermes Agent 有两个机制和技能变更直接相关：

关键区别：background_review 是「自动提出」，write_approval 是「人工把关」。前者决定有没有噪声，后者决定噪声能不能落地。

三、第一轮治理：审批全开，可控了，但麻烦

事故之后我的第一反应是把 write_approval 打开——所有技能写入变成待审提案，我批准才生效。效果立竿见影：Agent 再也无法悄悄改技能了，每次改动都会出现在待审列表里，我可以看 diff 决定批准还是拒绝。

但这套方案跑了两天，我发现了三个问题：

3.1 维护负担真实存在

每天都要处理待审项。如果当天改动多，得逐个看 diff、批准、拒绝——这不是「偶尔看一眼」的节奏，是每天都要做的日常任务。

3.2 批量批准有盲区

待审列表里不仅有你当前会话产生的改动，还有之前积压的、后台自动审查产生的建议。我实测过一次「批准全部」——一次性放行了 19 项，其中有 15 项是之前积压的、我根本没看过的内容（待审记录在 <HERMES_HOME>/pending/skills/ 下逐项落盘，git 可查证）。「批准全部」这个操作，实际上把事前审批变成了事后才发现。

3.3 审批无法提升建议质量

write_approval 只能决定「接不接收」，不能决定「建议好不好」。后台自动审查每天还在产生建议，我只是每天在拒绝它——这是纯粹的噪声，占用了审批队列，却没有任何价值。

写到这，答案已经很明显了：问题的根源不是「写入没有把关」，而是「后台自动审查在持续产出低质量建议」。审批解决的是「接不接收」的问题，解决不了「噪声从哪来」的问题——只要自动审查还在跑，你就是在给一个产出错误假设的机器做安检，这是一场永远赢不了的消耗战。

四、关掉 background_review：为什么

于是我把后台自动审查直接关掉了：

hermes config set auxiliary.background_review.enabled false

理由有三条，每条都是实测：

1. 建议质量不可控：官方源码自己都说这是「错误假设的来源」——v0.20.4 源码 tools/write_approval.py 模块说明原文：background_review 是「the self-improvement review fork that runs after a turn and autonomously decides what to save (the source of the "wrong assumptions" users complained about)」。我实测收到的 4 条自动建议——3 条技能文档补充、1 条引用修正——全部拒绝了，没有一条达到「值得采纳」的标准。

2. 关闭产生源比拦截结果干净：与其每天在待审队列里拒绝自动建议，不如让它根本不产生。关掉之后，待审列表里只剩真正由用户发起的沉淀，一眼能看完。

3. 手动沉淀路径不受影响：这个开关只关「自动」审查。手动触发（/refine 或直接要求 Agent 沉淀某段经验）照常工作——需要沉淀的时候我随时可以发起，不需要的时候没有噪声。

这里有一个关键的认知转变：我不需要 Agent 替我「主动发现该沉淀什么」，我需要的是「我明确要求时它把经验沉淀好」。主动权在我，不在后台。

五、最终形态：事后审计三道防线

关掉 background_review 之后，技能写入的审批门我也一并关闭了：

hermes config set skills.write_approval false

理由很简单：剩下的技能写入来源只有「用户发起的沉淀」和「Agent 会话中明确提出的修正」——这些都是我知情的内容，逐笔审批变成了多余的一步。

但「放开」不等于「放任」。我建了三条事后防线，保证任何一次变更都可追溯、可回滚：

5.1 防线一：git 基线审计

技能目录做了 git 初始化，任何改动都能 diff、能回滚。每周检查时 git status 一看就知道这周谁改了什么；发现异常改动，git diff 就是取证工具，git checkout 就是回滚工具。

5.2 防线二：变更快照

工具的每次技能变更都会写入一个追加式快照（before/after 都有记录）。git 管「文件层面的改动」，快照管「谁在什么时候改了什么」——两层证据链互补。

5.3 防线三：每周技能自检

每周跑一次技能体检：体积健康线（单文件超过阈值要拆）、引用覆盖核对（技能引用的文档是否都在）、结构门禁（必填字段是否齐全）。膨胀的苗头在每周检查时就会被发现，而不是等到技能库变成一团乱麻。

5.4 行为约束：能自主的边界写进记忆

最后一条是行为约束，写进了记忆而不是配置：用户要求的沉淀直接做；Agent 自主发现的小修正（补坑、补引用）直接做；结构性大改（重构、新建、瘦身）先告知用户。把「什么能自主、什么要报备」划清楚，比任何开关都管用。

这三道防线和一条约束的协作关系，用一张图收束：

一句话总结两种治理模式的差别：事前审批是每天安检，事后审计是装监控加定期查录像——前者每天耗人，后者一次建好，长期省心。

六、适用边界：这套方案适合谁

事后审计这套方案成立，依赖三个前提：

一句话：自己用的东西，事后审计；给别人用的东西，事前审批。 治理强度跟着风险走，不跟着理念走。

七、配置速查表

# 关闭后台自动审查（自动建议不再产生，手动 /refine 保留）

hermes config set auxiliary.background_review.enabled false

# 关闭技能写入审批（写入自动落地，靠审计链兜底）

hermes config set skills.write_approval false

# 查看技能体检状态（curator 运行状态 / 周期 / 归档阈值）

hermes curator status

# 查看技能变更（每周自检第一步）

cd 技能目录 && git log --oneline

# 回滚异常变更（发现乱改时的取证与回滚）

cd 技能目录 && git diff && git checkout <commit> -- <文件>

FAQ：

Q1：关掉后台自动审查，会错过有价值的建议吗？

会，但概率极低——实测 4 条全拒，没有一条达到采纳标准。真需要沉淀时，手动触发（/refine 或直接要求 Agent 沉淀某段经验）照常工作。

Q2：技能写入直接落地，Agent 乱改怎么办？

git 审计 + 每周自检兜底：异常变更能 diff 取证、checkout 回滚；行为约束（大改先告知）从源头减少乱改。

Q3：git 基线审计和变更快照会重复吗？

不会，两层互补：git 管文件层面「谁在什么时候改了什么」，快照管工具层面的 before/after 记录——git 查不到工具上下文时（比如这次变更由哪个会话发起），快照补上。

Q4：这套方案和代码库 CI/CD 审计有什么区别？

本质同一条思路——把信任建立在可回滚的审计链上。差异在规模：技能库变更频率低、单人操作，轻量 git + 快照足够，不需要 CI 门禁那套自动化闸门。

Q5：这个开关其他 Agent 框架有吗？

不同框架机制不同，但「自动审查 vs 手动审批 vs 事后审计」的三段式治理思路通用——关键不是抄配置，是把「谁改的、能不能回滚」变成显式可查的。

治理 Agent 的技能库，和治理代码库没有本质区别：写代码不是问题，没有版本控制的写代码才是问题。把「信任」建立在可回滚的审计链上，而不是建立在「管住每一次写入」上——这是我这次治理实践的最终结论。

参考资料

• Hermes Agent 官方文档：https://hermes-agent.nousresearch.com/docs

• Hermes Agent 源码（write_approval / background_review 实现）：https://github.com/NousResearch/hermes-agent

• git 官方文档（审计与回滚）：https://git-scm.com/doc

本文基于 Hermes Agent v0.20.4 实测，配置命令在不同版本间可能变化，使用前请确认版本。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。