2026-06-22

不是 Hermes 变笨了，是它的"坟场"把你最好的工具收走了

早上我让 Hermes 帮我写一个新 skill，用来规范 API 测试流程。这个任务不复杂，之前我已经把 skill 写作规范整理过一轮，所以我预期它至少会照着现有规则走。

结果它交出来的 SKILL.md 很怪：frontmatter 里少了 license，description 只有一句话，目录结构也没按我刚定下来的规范走。

坟场

.archive/ 在 ~/.hermes/skills/ 下面，说白了就是 Hermes curator 的”坟场”。

我一直知道 curator 这个东西。v0.12 更新时，官方把它叫成后台维护管家，定期扫描 skill 库，把长期不用的 skill 归档掉。配置里也写得很清楚：30 天不用变 stale，90 天不用进 archive。

我一开始没当回事，像我这种重度用户，真重要的 skill 怎么可能 90 天不用？

现在回头看，这个判断太粗了。

更麻烦的是，curator 不只有”时间到了自动归档”这一条线。它还有一个 LLM review 阶段：每隔 7 天，curator 会 spawn 一个辅助 agent，扫一遍你的 skill 库，判断哪些该保留，哪些该合并，哪些该归档。这个判断不完全按时间来，它还会看”相关性”和”冗余度”。

我的 skill-creator 就死在这里。

我优化过的新版本，和之前那个英文版的 hermes-agent-skill-authoring，在 curator 眼里都是”写 skill 的工具”。它判断了一轮，把新的归档了，留下了旧的。而留下来的，正是那个不太行的版本。

隐蔽的崩塌

这事最坑的地方，不是它归档了 skill，而是它不会报错。

如果 skill 彻底没了，你马上能发现：加载失败，文件不存在，命令直接炸。但 skill-creator 不是消失了。它只是被换成了另一个名字相近、功能也相近、但规则落后的版本。

表面上看，Hermes 还在正常工作；实际上一些关键约束已经没了。你很容易顺着别的方向排查：是不是模型今天状态差？是不是 provider 的输出风格变了？是不是上下文压缩把规则压没了？是不是我自己记错了？

我就是这么绕进去的。半小时里，我重启 session、换 provider、查配置，最后才发现不是模型变笨，是我调好的 skill 被 curator 收走了。

更烦的是，这半小时里我还顺手写了三个不合格的 skill，全部得返工。

还有一个很讽刺的点：我优化过的 skill-creator 里面，明明写了”重要 skill 需要 pin 保护”。

我自己写的规则，我自己忘了执行。

怎么查、怎么救

先看坟场：

1	ls ~/.hermes/skills/.archive/

如果 skill 已经进去，先救回来：

1	hermes curator restore skill-creator

但这只是把它从坟场拖出来。下次 curator review，它仍然可能被判断成”可归档”。

真正要做的是 pin 住：

1	hermes curator pin skill-creator

然后验证一下：

1 2	cat ~/.hermes/skills/.usage.json \| python3 -c "import json,sys; d=json.load(sys.stdin); print(d['skill-creator'].get('pinned'))" # → true

这一步不要省，尤其是你自己调过的 skill。

restore 解决的是”现在能不能用”，pin 解决的是”下次会不会又被收走”。这两个动作不是一回事。

哪些必须 pin

我现在会优先 pin 这几类：

skill-creator：低频，但一旦失效，后面写出来的 skill 会断崖下跌
para：文档治理规范，丢了以后落盘路径会乱
cronjob-operations：定时任务总控，缺了它就容易把 cron 配错
hot-news：热点新闻规范，事实核查标准不能丢

我的判断标准很简单：只要一个 skill 是你花时间调过的，而且不是每天都会用，就应该 pin。

高频 skill 反而没那么危险，因为 curator 容易看到它被使用。真正危险的是那些”平时不用、用时必须准”的 skill。它们在系统里看起来最像可以被清理的冗余项，也最容易被清错。

这个标准不需要搞得太复杂。你可以先从两个问题开始：

这个 skill 我是不是亲手改过？
它失效之后，会不会污染后面一串输出？

如果两个答案都是”是”，就别等它出事。