让 AI 整理 Agent Skills：为什么正确结果可能是零删除

自动维护 Skill 库的目标不是每轮都删除文件，而是对每个“保留、合并、归档”的决定给出足够证据，并确保错误决定可以恢复。

2026 年 8 月 8 日，Hermes 服务器上的 Curator 完成了第 43 次运行。运行前有 73 个活跃 Skills、65 个已归档 Skills；这一轮检查了 19 个由 Agent 创建的候选项，其中 5 个受固定规则保护，剩余 14 个逐一完整读取。

最终结果是：零合并、零归档、零状态变化。

如果目标是“每周至少清掉 10 个”，这显然是失败。如果目标是维持一个可用、可审计、可恢复的 Skill 库，这反而可能是正确答案。14 个候选项已经是职责清楚的 umbrella skill；为了满足配额强行合并，只会把触发条件、脚本和参考材料重新缠在一起。

文件数量不是 Curator 的目标函数

Skill 库会自然增长。任务中产生的技巧先成为候选，稳定模式可能进入正式 Skill，长期不用或被更好模块覆盖的内容再进入归档。

危险在于把“增长”直接解释成“膨胀”。文件多不等于重复，文件少也不等于边界清楚。一个 Curator 至少要回答四个问题：

两个 Skills 是否解决同一个用户意图，而不只是共享关键词？
一个 Skill 是否已经是多个小能力的稳定入口？
它引用的脚本、模板和例子能否随合并一起保持完整？
归档后，历史任务或其他 Skills 是否还依赖原路径？

因此我没有给 Curator 设置“必须删除几个”的奖励。它可以提出合并或归档，但零变化也是合法输出。真正需要惩罚的是没有阅读、没有证据、破坏包完整性，或者不可恢复的写入。

一轮维护怎样保持可恢复

每次 Curator 开始前，系统先创建一个运行前备份。8 月 8 日最近一次 manifest 记录了 73 个 Skill 文件和 44 个 cron job，压缩包约 4.13 MB，原因明确标为 pre-curator-run。

这个顺序很重要：先冻结可恢复状态，再允许模型提出改变。维护流程可以简化成：

盘点活跃与归档
  → 创建运行前备份与 manifest
  → 排除 pinned Skills
  → 完整读取候选包
  → 判断保留 / 合并 / 归档
  → 校验引用与包完整性
  → 写入报告和状态
  → 保留 restore 路径

归档也不是删除。文件进入独立 archive 后仍能通过 restore 命令或受控移动回到活跃目录。这样，Curator 可以做可逆的整理，而不是一次判断就永久抹掉知识。

备份本身同样需要边界。只保存 SKILL.md 不够；一个 Skill 可能依赖脚本、参考文件、模板和 cron。相反，把整台服务器无差别打包又会把密钥、日志和无关用户内容带入恢复材料。当前 manifest 记录被治理的文件和任务定义，但公开文章只保留聚合数量，不暴露服务器路径、任务 ID 或配置内容。

pinned 是硬边界，不是评分加分项

这一轮 19 个候选中有 5 个 pinned Skills。它们没有进入“模型觉得是否重要”的排序，而是在判断前直接排除。

这是我刻意保留的控制面：

pinned 表示运维或架构上的明确保留决定；
Curator 可以报告疑问，但不能绕过保护执行归档；
解除 pin 是另一项需要人或上层策略确认的变更。

如果 pin 只是一项较高分数，模型仍可能在“整体优化”时牺牲它。硬边界把权限问题留在模型之外，也让报告更容易审计：5 个跳过是规则结果，14 个保留是阅读后的判断，两类证据不能混在一起。

为什么这一轮选择了零变化

最新报告对 14 个未固定候选进行了完整读取，并记录了 17 次工具调用：14 次查看 Skill、1 次盘点、2 次只读终端检查。检查后没有发现能在不损失边界的情况下合并的重复项，也没有找到足够证据把某个候选归档。

这里的关键不是“模型说它们都很好”，而是报告给出了可以复查的理由：候选已经是 umbrella skills，各自负责一类稳定任务；继续合并会把不同触发条件和配套资源塞进更大的入口。当前系统因此保留 19 个 Agent 创建的 Skills，不把零变化伪装成一次优化成果。

这也说明 Curator 需要停止条件。完整阅读后如果没有满足归档或合并门槛的对象，就应结束运行。提示词里暗示“归档少于某个数字可能代表提前停止”，最多只能触发复核，不能变成强制配额。

自动生成不等于自动晋升

Hermes 还会从不同 Agent 的轨迹中产生草稿。最近重复出现的候选包括 Pi、Bridge 和 task-profile 相关草稿。它们不会因为“被生成”就自动进入活跃 Skill 库。

这条边界避免了另一种膨胀：生成器不断把一次性做法包装成正式能力。草稿需要先回答它是否跨任务复用、是否有明确触发、是否与现有 umbrella skill 重叠，以及依赖是否可携带。只有经过验证和策展，才有资格晋升。

如果你想了解从轨迹中提取候选的上游链路，可以继续阅读Agent 自进化的 Trajectory Mining 实践和SkillOpt 与 Hermes 的集成边界。本文只讨论候选产生之后的生命周期治理。

这套实践还没有证明什么

这是一台服务器在 2026 年 8 月 8 日的运行快照，不是通用 benchmark。73 个活跃、65 个归档和 43 次运行描述的是当时的库存与历史，不证明下游任务质量提高，也不证明模型永远能识别重复。

服务器实现也领先于公开材料。旧的 hermes-skill-evolution 仓库已经归档，其 README 指向的 controller-harness 子模块目前并不存在于公开树中。因此，我不会把本文写成“全部代码已经开源”。公开的 Agent Workspace Reference Architecture 可以参考 Git-native 规则、handover 和恢复边界，但它不是这套服务器 Curator 的代码发布。

下一步更值得测量的不是“又删了多少”，而是：错误归档的恢复时间、重复 Skill 的触发冲突、包完整性失败、候选晋升后的真实任务结果，以及人类推翻 Curator 决定的比例。

一个值得信任的 Skill Curator，应该允许自己在完整检查后什么都不做。自动化的价值不在于持续制造 diff，而在于把改变的权限、证据和恢复路径固定下来。