Hermes Agent 技能治理实录关掉自动审查改用 git 审计 变更快照 每周自检三道防线Hermes Agent 技能治理实录 · 独立篇 | 基于 Hermes Agent v0.20.4 实测2026-08deepseek-v4-flash 摘要Hermes Agent v0.20.4 实测background_review 是官方承认的错误假设来源write_approval 审批每天耗人、批量批准有盲区——关掉自动审查改用 git 审计 变更快照 每周自检三道防线附全部配置命令。导读目标读者正在用 Agent 做自动化交付的开发者、担心 Agent 自主变更配置的独立用户。环境版本Hermes Agent v0.20.4 deepseek-v4-flash2026-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_approvalHermes Agent 有两个机制和技能变更直接相关机制作用触发方式background_review后台自动审查会话结束后自动对技能/记忆提改进建议每次会话自动触发无需用户操作write_approval技能写入审批门所有技能写入创建/修改/删除变成待审提案人工批准后才落地配置开启后对所有写入来源生效关键区别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 configsetauxiliary.background_review.enabledfalse理由有三条每条都是实测建议质量不可控官方源码自己都说这是「错误假设的来源」——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 条引用修正——全部拒绝了没有一条达到「值得采纳」的标准。关闭产生源比拦截结果干净与其每天在待审队列里拒绝自动建议不如让它根本不产生。关掉之后待审列表里只剩真正由用户发起的沉淀一眼能看完。手动沉淀路径不受影响这个开关只关「自动」审查。手动触发/refine 或直接要求 Agent 沉淀某段经验照常工作——需要沉淀的时候我随时可以发起不需要的时候没有噪声。这里有一个关键的认知转变我不需要 Agent 替我「主动发现该沉淀什么」我需要的是「我明确要求时它把经验沉淀好」。主动权在我不在后台。五、最终形态事后审计三道防线关掉 background_review 之后技能写入的审批门我也一并关闭了hermes configsetskills.write_approvalfalse理由很简单剩下的技能写入来源只有「用户发起的沉淀」和「Agent 会话中明确提出的修正」——这些都是我知情的内容逐笔审批变成了多余的一步。但「放开」不等于「放任」。我建了三条事后防线保证任何一次变更都可追溯、可回滚阶段一无控制阶段二事前逐笔审批阶段三事后审计兜底Agent 自主改动直接落地无感知写入变待审提案可控但每天要审自动噪声关源写入自动落地三道防线5.1 防线一git 基线审计技能目录做了 git 初始化任何改动都能 diff、能回滚。每周检查时git status一看就知道这周谁改了什么发现异常改动git diff就是取证工具git checkout就是回滚工具。5.2 防线二变更快照工具的每次技能变更都会写入一个追加式快照before/after 都有记录。git 管「文件层面的改动」快照管「谁在什么时候改了什么」——两层证据链互补。5.3 防线三每周技能自检每周跑一次技能体检体积健康线单文件超过阈值要拆、引用覆盖核对技能引用的文档是否都在、结构门禁必填字段是否齐全。膨胀的苗头在每周检查时就会被发现而不是等到技能库变成一团乱麻。5.4 行为约束能自主的边界写进记忆最后一条是行为约束写进了记忆而不是配置用户要求的沉淀直接做Agent 自主发现的小修正补坑、补引用直接做结构性大改重构、新建、瘦身先告知用户。把「什么能自主、什么要报备」划清楚比任何开关都管用。这三道防线和一条约束的协作关系用一张图收束diff 取证与 checkout 回滚体检门禁技能库防线一git 基线审计防线二变更快照防线三每周技能自检发现问题 → 修复或回滚一句话总结两种治理模式的差别事前审批是每天安检事后审计是装监控加定期查录像——前者每天耗人后者一次建好长期省心。六、适用边界这套方案适合谁事后审计这套方案成立依赖三个前提前提不满足时怎么办单人使用技能库是自己的资产多人协作时仍然需要事前审批——你不一定知道同事让 Agent 改了什么技能目录有 git 可回滚没有版本控制的共享环境回滚无从谈起必须退回审批制技能用于个人工作流交付给客户的技能包客户对变更敏感事前审批更稳妥无外部合规要求客户或组织要求审计合规时即使单人也要退回事前审批——合规是硬要求不是理念问题一句话自己用的东西事后审计给别人用的东西事前审批。治理强度跟着风险走不跟着理念走。七、配置速查表# 关闭后台自动审查自动建议不再产生手动 /refine 保留hermes configsetauxiliary.background_review.enabledfalse# 关闭技能写入审批写入自动落地靠审计链兜底hermes configsetskills.write_approvalfalse# 查看技能体检状态curator 运行状态 / 周期 / 归档阈值hermes curator status# 查看技能变更每周自检第一步cd技能目录gitlog--oneline# 回滚异常变更发现乱改时的取证与回滚cd技能目录gitdiffgitcheckoutcommit--文件FAQQ1关掉后台自动审查会错过有价值的建议吗会但概率极低——实测 4 条全拒没有一条达到采纳标准。真需要沉淀时手动触发/refine 或直接要求 Agent 沉淀某段经验照常工作。Q2技能写入直接落地Agent 乱改怎么办git 审计 每周自检兜底异常变更能 diff 取证、checkout 回滚行为约束大改先告知从源头减少乱改。Q3git 基线审计和变更快照会重复吗不会两层互补git 管文件层面「谁在什么时候改了什么」快照管工具层面的 before/after 记录——git 查不到工具上下文时比如这次变更由哪个会话发起快照补上。Q4这套方案和代码库 CI/CD 审计有什么区别本质同一条思路——把信任建立在可回滚的审计链上。差异在规模技能库变更频率低、单人操作轻量 git 快照足够不需要 CI 门禁那套自动化闸门。Q5这个开关其他 Agent 框架有吗不同框架机制不同但「自动审查 vs 手动审批 vs 事后审计」的三段式治理思路通用——关键不是抄配置是把「谁改的、能不能回滚」变成显式可查的。治理 Agent 的技能库和治理代码库没有本质区别写代码不是问题没有版本控制的写代码才是问题。把「信任」建立在可回滚的审计链上而不是建立在「管住每一次写入」上——这是我这次治理实践的最终结论。参考资料Hermes Agent 官方文档https://hermes-agent.nousresearch.com/docsHermes Agent 源码write_approval / background_review 实现https://github.com/NousResearch/hermes-agentgit 官方文档审计与回滚https://git-scm.com/doc 你遇到过 Agent 自作主张改配置或改文件的情况吗欢迎在评论区聊聊你的处理方式。本文基于 Hermes Agent v0.20.4 实测配置命令在不同版本间可能变化使用前请确认版本。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。