§11最该学的是「不要学」
The Most Important Lesson Is What Not to Learn
一个会自我进化的 Agent,真正的危险从来不是学不会。是学错了之后,它会拿着错误的规则,一连几个月反复拒绝自己。Hermes 的 review prompt 里,专门有一段黑名单在防这件事。
先讲一个会反噬几个月的 bug
设想这么个场景。某天你让 Hermes 帮你抓个网页,恰好那一刻浏览器工具因为环境没配好报了个错。Agent试了一下,失败了。
到这里都还正常。问题在于,它有一套学习循环(见 §09),每轮对话后会 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 特别容易栽这一跤
这事得和前面连起来看。§09 讲过,那段后台复盘的 prompt 态度相当激进,默认就该多写规则——「什么都不做不是中性结果,是错过了一次学习机会」。
也就是说,Hermes 默认就该学,倾向于多写规则而不是少写。这个倾向本身是对的,它对应着 Mitchell Hashimoto 那个著名习惯:Agent 每犯一个错,就往 CLAUDE.md 里加一条规则。但把「每次犯错都加规则」
自动化之后,一个新问题暴露了出来。
人类犯错和环境出错,长得几乎一模一样。都是「我试了,它失败了」。可这两者的正确反应天差地别。
| 推荐 | 不推荐 |
|---|---|
| 我把命令参数写错了→这是我的错,该学,下次别再 | 这台机器恰好没装那个二进制文件→这是环境的临时 |
| 写错 | 状态,不该学成永久规则 |
一个只会「从失败中学习」的 Agent,分不清这两者。它会把第二种也当成第一种,把临时的环境故障,老老实实学成永久的自我设限。这才是自改进真正的二阶风险,它不在学习能力本身,而在于它缺乏对「这次失败配不配被记住」的判断力。
黑名单:明确列出哪些东西不许学
Hermes 的对策不复杂,但很实在:在那段 review prompt 里,专门写了一份「不要学」的清单(同样出自background_review.py )。复盘的子 agent 在决定写不写 skill 之前,必须先对照这份黑名单过一遍。
| 黑名单类别 | 典型例子 | 为什么不能学 |
|---|---|---|
| 环境依赖型失败 | 缺二进制文件、command not found、凭证没配 | 是这台机器此刻的状态,不是任务的普遍规 |
| 律 | ||
| 对工具的否定论 | 「浏览器工具用不了」「X 工具坏了」 | 会硬化成 Agent 反复引用、长期拒绝自己的 |
| 断 | 借口 | |
| 一次性的任务残 | 某个 PR 编号、某串报错文本、今天临时的 | 只对今天这一件事有意义,明天就是噪音 |
| 片 | codename |
这份黑名单背后有个朴素的判断标准,我把它翻成一句人话:如果一条规则只在今天这个具体情境下成立,那它就不该被写成永久规则。
区分「真知识」和「临时状态」,靠的就是这个。命令参数写错是普遍规律,值得学;某台机器没装某个包是临时状态,不值得学。Agent 在动笔写 skill 之前,先得问自己:这条规则换个环境、换台机器,还成立吗?不成立的,黑名单直接拦下。
注意
这条认知是第一版书完全没有的。4月的 Hermes 还只是个「会写记忆、会建 skill」的理念,那时候没人意识到,自改进的真正难点不是「怎么让它学」,而是「怎么拦住它别乱学」。黑名单是后来长出来的最成熟的一笔,到v0.22.2还原样留在源码里。
万一还是学错了,provenance 锁住破坏半径
黑名单是事前预防。可再清醒的规则也拦不住所有误判,总有漏网的坏 skill 被写进去。Hermes 在这层之外还有一道事后兜底:把任何一个出错 skill 能造成的破坏范围,从一开始就锁死。
靠的是 §10 讲过的那套 provenance(出身追踪):每个 skill 都带着「是谁造的」标签——出厂自带、社区装的、你亲手写的、Agent 自己 fork 出来造的。这里只需记住那条产权线在「不要学」这件事上意味着什么:只有 Agent 自己造的 skill,才会被 Agent 自己回收。
所以哪怕黑名单百密一疏、某条坏规则漏网写进了某个 agent-created 的 skill,它能污染的也只是 Agent 那块自留地。你出厂就带的、从社区 Hub 装的、自己亲手写的,全都安全——源码注释那句话很直接:用户让前台agent 写的 skill 属于用户,Curator 永远不许碰。
破坏半径:一个 Agent 自学时写歪的 skill,最坏也只会污染它自己的那块自留地。它碰不到你精心维护的配置,碰不到社区那些经过安全扫描的可信 skill。自改进的代价被严格圈在一个可控的小圈子里。
这层设计我觉得才是真正见功力的地方。前面 §10 讲过 Curator 永不删除、只归档、合并前还打 tar.gz 快照可以整轮回滚。provenance 又往前加了一道:它根本不让自改进的影响溢出到 agent 自留地之外。事前有黑名单拦着别乱学,事后有 provenance 圈着破坏半径,一前一后,把「自我进化」这件听上去有点危险的事,关进了一个不会失控的笼子。
这一版又多了两道「人在环上」的闸
6月到10月之间,这个思路又往前走了两步,都是给「它学什么」加一道人可以介入的关口。
第一道是记忆写入审批。配置里的memory.write_approval打开之后,前台对话里它想写记忆会先弹确认;后台复盘想写的,先暂存起来,等你用/memory pending看、/memory approve或/memory reject处理。默认是关的,§05里它自己记下我的偏好,就是没开这个开关的结果。
第二道是agent自建skill的安全扫描(skills.guard_agent_created )。它自己写出来的skill,和从社区市场装的skill一样,要过一遍扫描器,判为dangerous的会被拦下来问你。
两道闸默认都比较松,这是产品上的取舍:全开的话,它每学一样东西都要打扰你一次,「会自己长」的体验就没了。我的建议是刚开始用、还不信任它的时候,把记忆审批打开一两周,看看它都想记些什么,心里有数了再关。
一个会自学的系统,最该学会的是克制
回到这一节的标题。我们总在期待 Agent 学得更多、改得更勤、进化得更快。但 Hermes 这套机制告诉我一件反直觉的事:对一个能自我修改的系统来说,「不该学什么」这条边界,比「能学多少」更决定它的下限。
学得越快的系统,犯错时的反噬也越深。一个不会学习的工具,最多这次失败;一个会学习但不会克制的工具,会把这次失败固化成一条规则,让自己在往后每一次都失败。能力和风险是同一枚硬币的两面。
所以 Hermes 在「让它学」这件事上花了很多力气,又同样认真地在「拦住它别乱学」上设了几道闸:黑名单管事前、provenance 管边界、Curator 管回收,再加上可选的人工审批。这种清醒,比任何「越用越聪明」的宣传都更让我信任它。一个敢于明确告诉自己「这些东西不许学」的 Agent,才配谈得上真正的自我进化。
下一章我们往下挖一层,看支撑这一切的地基:三层记忆系统。如果学习循环是引擎,记忆就是它的燃料和油箱。