Hermes三款插件审计AI代理自我记忆

AI代理在长期运行中会写入自己的记忆和技能文件，但这个过程缺乏监督，可能导致重复循环、虚构用户决策、技能来源不明等问题。一位开发者为此构建了三款Hermes插件，分别针对这些失败模式进行审计，其中两款已并入上游目录，一款在审核中。

问题背景：代理自我写入的三种风险

运行AI代理时，它会不断将运行循环、决策和技能写入文件。本地模型或卡住的流容易陷入重复。Hermes本身会截断失控文本，但设计上允许供应商确认的工具调用通过，即使参数是重复内容。工具调用又是唯一能改变进程外部状态的操作——写文件、发帖、执行shell命令。因此，重复的工具调用可能造成实际损害。

另一类风险是代理记录用户从未做出的决策。“用户决定X”是代理能写下的最危险句子，因为下一个会话会相信它。此外，自改写技能需要追溯文本来源，否则无法信任。

Hermes 框架与插件机制：Hermes 是一个用于运行 AI 代理的开源框架，支持代理在长期会话中自主调用工具、写入记忆和技能文件。其插件系统允许开发者在关键生命周期节点（如 pre_tool_call、记忆写入前后）挂载钩子，以审计或干预代理行为。插件通过 hermes plugins validate 验证，并可提交至上游目录供他人安装。这种设计让第三方能在不修改核心代码的前提下，为代理增加安全护栏，这也是本文三款插件得以独立开发和分发的技术基础。

插件一：degeneracy-guard——拦截重复工具调用

hermes-degeneracy-guard挂在pre_tool_call阶段，在工具执行前对参数评分。当参数看起来像循环而非数据时，它将调用交给Hermes自己的审批门，而不是自行猜测。拒绝、审批门错误或超时都会拒绝调用，cron默认拒绝，因此无人值守运行会失败关闭，而非写入损坏文件。

证据：五个挂钩，均不编辑Hermes自带的文件；hermes plugins validate .在固定提交上通过。目录PR #141341已于2026-10-20合并。

pre_tool_call 钩子与审批门：pre_tool_call 是 Hermes 在工具执行前触发的插件钩子，允许插件检查甚至修改调用参数。审批门（approval gate）是 Hermes 内置的安全机制，通常用于需要人工确认的高风险操作。degeneracy-guard 将可疑的重复调用转交给审批门，而非直接放行或拒绝，这样既利用了现有的人工监督流程，又避免了插件自身误判。cron 场景下默认拒绝，是因为无人值守时无法完成人工确认，失败关闭（fail-closed）可防止损坏文件被静默写入。

插件二：provenance-gate——检测虚构用户决策

hermes-provenance-gate检查每次记忆和技能写入，寻找“用户决定X”这类构造，并核对用户原话：引文需在本会话用户输入中逐字出现、与声明共享关键词、且不丢失否定词。默认只记录未通过检查的写入；阻止模式会拒绝它们。

证据：在133行由另一个未见过插件代码的模型会话写入并标记的文本上（49条声明，84条非声明），精确率1.000（34/34），召回率0.694（34/49）。漏报与命中一起公布，两个独立模型会话的审查结果已转化为回归测试。目录PR #141935已于2026-10-20合并。

精确率与召回率：在二分类检测中，精确率（precision）指被判定为“虚构决策”的样本中真正虚构的比例，召回率（recall）指所有真实虚构决策中被成功检出的比例。provenance-gate 的精确率 1.000 意味着它标记的 34 条声明全部确属虚构，没有误报；召回率 0.694 意味着在 49 条真实虚构声明中检出了 34 条，漏报 15 条。高精确率保证不会误伤合法记忆写入，而召回率有限则表明部分虚构决策仍可能漏过，需结合其他审计手段。

插件三：skill-lineage——追踪技能文本来源

hermes-skill-lineage记录每次技能写入前后的内容指纹、同一会话中早先出现的来源、将来源与新增行关联的特征，以及条目上的seq → prev_hash → hash链。trace回答某个版本来自何处；descendants反向查找——给定一个页面或技能，返回内容最终嵌入的所有技能；report列出含有无法追溯来源行的版本；verify重新走链，head打印一个值供别处记录，以便后续运行区分截断与完整链。

证据：48个测试通过，一个模块在Python 3.11.16和3.14.7上跳过（需要Hermes自身可导入）；hermes plugins validate .在Hermes 0.22.0上无警告通过。隔离数据根中的手动端到端运行通过skill_manage创建技能，然后运行status/trace/descendants/report/verify/head——原始日志已提交至仓库。目录PR #142381处于开放状态。

未覆盖的流式路径与核心修复

Hermes新增了一个守卫，在流变成重复循环时立即切断。它已接入chat_completions和Anthropic Messages流；Bedrock Converse和Codex Responses流尚未使用，因此在这些流上，无上限端点可能将循环流式传输到输出限制。#141477是报告。#141479将现有守卫接入两者，复用相同的检测逻辑和回合结束交接，不新增检测逻辑。两者均处于开放状态。

开发者自述的未解难题

来源到行的链接基于共享shingle、锚点和会话顺序计算，并非因果证明。开发者希望找到更便宜的方法区分“此行来自该页面”与“它们恰好共享词语”。

键控哈希意味着第三方可以验证内部一致性，但无法从公开产物重新推导链接。发布无键摘要的明显替代方案会通过短字符串字典攻击泄露内容。开发者选择了隐私而非第三方可复现性，但不确定这个权衡是否正确。

三个插件的默认行为不一致：degeneracy-guard采取行动，将可疑调用交给审批门；provenance-gate观察，记录本应拒绝的内容为would_block，直到设置PROVENANCE_GATE_MODE=block才拒绝；skill-lineage只记录，从不阻止。开发者依据误阻止成本不同而设定——损坏文件难以察觉，拒绝记忆写入重试成本低，丢失指纹毫无成本——但三个兄弟工具三种默认是一种异味，他更愿意听到为什么错了，而不是为之辩护。

三款插件均为Apache-2.0许可，无付费层，无需账户。

披露：开发者在自己的工作流中使用AI代理，部分文字由AI辅助起草并经其编辑。以上测量均为可指认的运行；失败、跳过或未测量的地方已如实说明。

短字符串字典攻击与键控哈希：键控哈希（keyed hash）使用秘密密钥计算哈希值，第三方在没有密钥时无法验证或重新推导内容。若开发者发布无键摘要以允许公开验证，攻击者可能通过枚举常见短字符串（如“用户决定删除文件”）并计算其哈希，与公开摘要比对，从而反推出原始内容，这就是短字符串字典攻击。开发者选择键控哈希，牺牲了第三方可复现性，以换取内容隐私，这一权衡在需要公开审计又涉及敏感记忆的场景中尤为棘手。