📚 系列导航：上一篇 Hermes Agent Curator 使用指南 已经讲清“Curator 使用与 Skill 维护指南”；本篇聚焦 Hermes Agent 自改进边界；下一篇 Hermes Agent 记忆系统教程 继续学习“记忆系统教程：会话、持久记忆与 Skills”。
先给结论：自改进最危险的不是没学会，而是把一次性的失败学成永久规则。 Hermes 用“不该学”黑名单做事前过滤，再用来源追踪（provenance）和 Curator 控制出错后的影响范围。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
临时故障如何变成长期错误规则
设想这么个场景。某天你让 Hermes 帮你抓个网页，恰好那一刻浏览器工具因为环境没配好报了个错。Agent 试了一下，失败了。
到这里都还正常。问题在于，它有一套学习循环（见§04），每轮对话后会 fork 一个后台复盘的子 agent，问自己一句：这次学到了什么，要不要写进 skill？
如果没有约束，它很可能会得出一个看似合理的结论：「浏览器工具用不了。」然后郑重其事地把这条写进自己的某个 skill 文件里。
麻烦从这一刻开始。环境很快被修好了，浏览器工具完全正常，但那条规则还躺在 skill 里。于是接下来好几个月，每次你让它上网，它都会引用自己写的那句话，告诉你：浏览器工具不行，做不了。
Hermes 源码注释里把这个现象描述得很到位，我直接引一句（出自 agent/background_review.py ）：
原文：Negative claims about tools or features (‘browser tools do not work’, ‘X tool is broken’). These harden into refusals the agent cites against itself for months after the actual problem was fixed.
「硬化成它用来反对自己的拒绝。」这个措辞我觉得相当清醒。一个本该越用越聪明的系统，反而因为学习能力，给自己挖了个长期的坑。
自改进 Agent 为什么会学错经验
这事得和前面连起来看。§04 讲过，那段后台复盘的 prompt 态度相当激进，默认就该多写规则—「什么都不做不是中性结果，是错过了一次学习机会」。
也就是说，Hermes 默认就该学，倾向于多写规则而不是少写。这个倾向本身是对的，它对应着 MitchelHashimoto 那个著名习惯：Agent 每犯一个错，就往 CLAUDE.md 里加一条规则。但把「每次犯错都加规则自动化之后，一个新问题暴露了出来。
人类犯错和环境出错，长得几乎一模一样。都是「我试了，它失败了」。可这两者的正确反应天差地别。
| 推荐我把命令参数写错了→这是我的错,该学,下次别再写错 | 不推荐这台机器恰好没装那个二进制文件→这是环境的临时状态,不该学成永久规则 |
|---|
一个只会「从失败中学习」的 Agent，分不清这两者。它会把第二种也当成第一种，把临时的环境故障，老老实实学成永久的自我设限。这才是自改进真正的二阶风险，它不在学习能力本身，而在于它缺乏对「这次失败配不配被记住」的判断力。
Hermes Agent 不该学习的内容
Hermes 的对策不复杂，但很实在：在那段 review prompt 里，专门写了一份「不要学」的清单（同样出自 background_review.py ）。复盘的子 agent 在决定写不写 skill 之前，必须先对照这份黑名单过一遍。
| 黑名单类别 | 典型例子 | 为什么不能学 |
|---|---|---|
| 环境依赖型失败 | 缺二进制文件、command not found、凭证没配 | 是这台机器此刻的状态,不是任务的普遍规律 |
| 对工具的否定论断 | 「浏览器工具用不了」「X 工具坏了」 | 会硬化成 Agent 反复引用、长期拒绝自己的借口 |
| 一次性的任务残片 | 某个 PR 编号、某串报错文本、今天临时的 codename | 只对今天这一件事有意义,明天就是噪音 |
这份黑名单背后有个朴素的判断标准，我把它翻成一句人话：如果一条规则只在今天这个具体情境下成立，那它就不该被写成永久规则。
区分「真知识」和「临时状态」，靠的就是这个。命令参数写错是普遍规律，值得学；某台机器没装某个包是临时状态，不值得学。Agent 在动笔写 skill 之前，先得问自己：这条规则换个环境、换台机器，还成立吗？不成立的，黑名单直接拦下。
这条认知是旧书完全没有的。两个月前 Hermes 还只是个「会写记忆、会建 skill」的理念，那时候没人意识到，自改进的真正难点不是「怎么让它学」，而是「怎么拦住它别乱学」。黑名单是这两个月长出来的最成熟的一笔。
使用 provenance 限制错误 Skill 的影响
黑名单是事前预防。可再清醒的规则也拦不住所有误判，总有漏网的坏 skill 被写进去。Hermes 在这层之外还有一道事后兜底：把任何一个出错 skill 能造成的破坏范围，从一开始就锁死。
靠的是 §05 讲过的那套 provenance（出身追踪）：每个 skill 都带着「是谁造的」标签—出厂自带、社区装的、你亲手写的、Agent 自己 fork 出来造的。这里只需记住那条产权线在「不要学」这件事上意味着什么：只有 Agent 自己造的 skill，才会被 Agent 自己回收。
所以哪怕黑名单百密一疏、某条坏规则漏网写进了某个 agent-created 的 skill，它能污染的也只是 Agent 那块自留地。你出厂就带的、从社区 Hub 装的、自己亲手写的，全都安全—源码注释那句话很直接：用户让前台 agent 写的 skill 属于用户，Curator 永远不许碰。
破坏半径：一个 Agent 自学时写歪的 skill，最坏也只会污染它自己的那块自留地。它碰不到你精心维护的配置，碰不到社区那些经过安全扫描的可信 skill。自改进的代价被严格圈在一个可控的小圈子里。
这层设计我觉得才是真正见功力的地方。前面 §05 讲过 Curator 永不删除、只归档、跑前还打 tar.gz 快照可以整轮回滚。provenance 又往前加了一道：它根本不让自改进的影响溢出到 agent 自留地之外。事前有黑名单拦着别乱学，事后有 provenance 圈着破坏半径，一前一后，把「自我进化」这件听上去有点危险的事，关进了一个不会失控的笼子。
Hermes Agent 自改进的克制原则
回到这一节的标题。我们总在期待 Agent 学得更多、改得更勤、进化得更快。但 Hermes 这套机制告诉我一件反直觉的事：对一个能自我修改的系统来说，「不该学什么」这条边界，比「能学多少」更决定它的下限。
学得越快的系统，犯错时的反噬也越深。一个不会学习的工具，最多这次失败；一个会学习但不会克制的工具，会把这次失败固化成一条规则，让自己在往后每一次都失败。能力和风险是同一枚硬币的两面。
所以 Hermes 在「让它学」这件事上花了很多力气，又同样认真地在「拦住它别乱学」上设了三道闸：黑名单管事前、provenance 管边界、Curator 管回收。这种清醒，比任何「越用越聪明」的宣传都更让我信任它。一个敢于明确告诉自己「这些东西不许学」的 Agent，才配谈得上真正的自我进化。
下一章我们往下挖一层，看支撑这一切的地基：三层记忆系统。如果学习循环是引擎，记忆就是它的燃料和油箱。
常见问题
哪些内容不应该写进 Hermes Skill？
临时缺少依赖、凭证未配置、偶发工具故障和只对单次任务有意义的编号或报错，不适合固化成永久规则。先判断换一台机器或换个时间是否仍然成立。
Hermes Agent 学错了怎么办？
先定位规则来自哪个 Skill，再根据来源决定修改、归档或恢复。Curator 和快照可以降低影响，但用户仍需审查重要的长期规则。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。