§10Curator：给自进化装刹车

Curator: Brakes for Self-Evolution

一个会自己造skill的agent，迟早会造出一堆垃圾。Hermes的答案不是「别造那么多」，而是请了一个会自己上班的清洁工——它永远不删东西，动手前先给你备份。

先想清楚一个问题

上一节讲到Hermes每轮对话后都会fork一个后台复盘，把这次学到的东西写成skill。听起来很美，但我第一反应是担心：它会不会越攒越多，最后攒出几十个长得差不多的小破skill？

这个担心是对的。你今天修了个bug，它存一个；明天换个项目又撞上类似的坑，它再存一个。一周下来，skill目录里躺着十几个名字不一样、内容八成重叠的文件。每次agent要选skill时，都得在这堆近重复里翻，既费token又容易选错。

这不是假想。后台复盘的prompt里有一句话，态度很激进：「大多数会话至少该产出一次skill更新，什么都不做是错过了学习机会，不是中性结果。」一个被要求「尽量多学」的系统，必然伴生「学太多」的副作用。

Curator就是为这个副作用存在的。它在v0.12.0才诞生，那一版官方直接起名叫「The Curator release」，副标题是一句很有底气的话：Hermes Agent now maintains itself，它开始自己维护自己了。

接着 §09 那个比喻说：background review 负责增殖，Curator 负责凋亡——而 Curator 正是这里要拆的那台「凋亡引擎」。Karpathy 也说过类似的话，对一个学习系统来说，遗忘和学习同样重要。

它怎么被叫醒

Curator不是个一直转的定时任务。源码里没有cron daemon，它靠「闲置触发」：CLI启动时、网关tick时顺便检查一下，距上次跑够久了，而且agent也闲够久了，才fork一个后台进程去干活。

默认两道闸门都得过：

距上次运行≥ 7天agent闲置≥ 2小时fork一次维护还有个我挺欣赏的细节：全新装好之后第一次tick不会立刻干活。它会把「上次运行时间」直接记成现在，逼自己等满一个完整的7天周期。注释里说得很实在：刚hermes update完就乱动你的skill库，体验太差。给你一整个星期去pin住你在乎的、opt-out掉你不想要的。

两段式：先用纯函数，再用LLM

Curator真正动手时分两步。第一步完全不调用大模型，是一段纯函数状态机，按「这个skill多久没被用过」机械地推进它的生命周期。

active活跃

14天没用→

stale陈旧

30天没用→

archived归档

这套状态机有意思的地方在于它是可逆的、确定性的。一个被标成stale的skill，只要再被用上一次，就自动弹回active。没有玄学，没有大模型的判断，纯靠时间戳算。被pin住的skill则完全跳过这一步，时间再久也不会被动；被任何一个定时任务引用着的skill也跳过；从来没用过的新skill有一段宽限期，至少要存在满14天才可能被归档。（6月写上一版时这两个阈值还是30天和90天，现在收紧了。）

为什么第一步刻意不用LLM？我猜是为了把「能用规则确定的事」和「需要判断的事」分开。归不归档纯看时间，这种事让模型来判断纯属浪费钱还不稳定。真正需要品味的活留给第二步。

第二步才fork一个用辅助模型跑的agent，让它巡视那些agent自己造的skill，逐个决定：保留、改一改、跟别的合并、还是归档。这一步是有「想法」的，下面这套想法是v0.16那一轮Curator最大的进化。

注意

从v0.17开始，这第二步默认是关的。Curator默认只跑第一步那个不花钱的状态机，官方的理由是省token。想要下面讲的「建伞式归并」，得自己在配置里打开curator.consolidate: true，或者临时跑一次hermes curator run --consolidate。很多教程还按「默认会合并」来讲，这一点要留心。

从「找重复删掉」到「建一把伞」

早期你会以为Curator干的是去重：找出两个像的，删掉一个。但v0.16.0的review prompt第一句就把这个理解否了：「这是一次建伞式的归并，不是被动审计，也不是找重复。」

差别在哪？去重的思路是「这俩像不像」，建伞的思路是「一个人类维护者会把它写成几个独立skill，还是写成一个带几个小节的skill」。prompt里甚至明确禁止用「每个skill触发词不同」当不合并的借口，触发词各异不是理由，该收进一把伞的就得收。

具体有三种手法：

这个转向其实很有产品味道。它把「一个好的知识库长什么样」这种很难量化的人类品味，编码进了一段自动维护逻辑。prompt里那句话我特别喜欢：「几百个各管一个session具体bug的窄skill，是这个库的失败，不是它的特性。」

刹车的四道设计

讲到这你可能跟我一样有个本能的不安：让一个AI自动改、自动归档我的skill库，万一它判断错了呢？万一它把我重要的东西归档了呢？

这正是§10的核心。Curator不是一脚油门踩到底的自动化，它的刹车做得很重，重到我觉得值得逐条讲。

第一道：永不删除，只归档源码文件头写了一条不变量：Never auto-deletes — only archives. Archive is recoverable. 所谓归档，就是把skill目录挪进~/.hermes/skills/.archive/ ，随时能restore回来。Curator自动跑的时候没有「删除」这个动作，顶多把东西搬到旁边的抽屉里。后来加了一条手动命令hermes curator purge ，可以清掉超过一定天数的归档，但那是你自己按的，不是它自动做的。

第二道：合并前先打快照每次要合并改写skill之前，Curator会先把整个skills目录打成一个tar.gz快照，连.archive/一起存进.curator_backups/ ，文件名是UTC时间戳。注意这只针对合并（consolidate）那一步，它是唯一会改skill内容的操作；v0.22默认合并是关的，只剪枝的那一轮不打快照，归档本身就是撤销的路径（hermes curator restore ）。

注意

打开合并之后，哪怕这一轮改错了一片，你一条hermes curator rollback就能把整轮撤销，包括它这次归档的、之前归档的，全救回来。快照连旧归档一起存，所以回滚是真的「时光倒流」，不是只撤销最近一步。现在还多了一本账：hermes curator ledger记着每一次改动，rollback 条目编号可以只撤销其中某一条（rollback --list列的是整库快照）。

第三道：dry-run预览不放心自动跑？hermes curator run --dry-run让它把这一轮想干的事全列出来，但一个字都不动你的库。

你审完报告，觉得OK再live run。

这一点对应Martin Fowler那个著名的框架：人和自动化系统的关系，是in the loop（事事亲为）、on the loop（在旁监督可干预）、还是out the loop（完全放手）。Hermes明确选了on the loop，你不必盯着它每一步，但报告随时可审，结果随时可回滚。它没把你踢出去。

第四道：provenance锁死破坏半径最优雅的一道在这。Curator凭什么知道哪些skill能动、哪些碰都不能碰？靠的是每个skill的「出身」标记。

实现上靠一个contextvar：后台复盘fork跑的时候，写入来源被标成background_review ，只有这种来源造出来的skill才被打上created_by: agent ，才进Curator的管辖。你手写的、装来的，永远安全。

这句话值得停一下：agent自我进化的破坏半径，被严格锁在它自己的自留地里。它能回收的，只有它自己长出来的东西。你的财产和它的财产之间，有一道源码层面的产权线。

核心建议

有个容易混淆的细节：pin一个skill，只挡删除、归档、合并，不挡内容改进。被pin的skill照样能被Curator改得更好，pin保护的是「它不会消失」，不是「它不会变」。

这把刹车回答了什么

「自进化会不会失控」是悬在所有这类系统头上的问题。很多产品的回答是含糊的，无非「我们有安全机制」

「会持续监控」。Hermes的回答是一组能指着源码念的具体设计。

我觉得这才是「装刹车」的正确姿势。刹车不是限制车跑多快，而是让你敢把车开快。正因为永不删、能回滚、动不了你的东西，那个「尽量多学」的激进复盘才敢真的激进。没有这套刹车，你根本不敢让一个AI自动改你的工具库。

下一节我们看这套自进化里最反直觉的一笔：在所有「该学什么」的规则之外，Hermes还专门写了一份「不该学什么」的黑名单。一个会自我进化的agent，真正的危险不是学不会，而是学错了之后拿错误的规则反复拒绝自己。