你的 AI 智能体技能库正在失控？Hermes Curator 帮你自动”断舍离”

“

本文核心问题：当 AI 智能体不断创建新技能时，如何防止技能库膨胀成一堆无人维护的”技术债务”？

如果你正在使用 Hermes Agent，可能已经注意到一个现象：每次智能体解决一个新颖问题，它都会把解决方案打包成一个新的”技能”（skill），存进 ~/.hermes/skills/ 目录。起初这很美好——你的智能体越来越聪明，能复用过去的经验。但几个月后，你打开技能目录，可能会发现里面塞满了几十个 narrowly scoped、彼此重叠、甚至已经过时的技能文件。它们不仅占用空间，更麻烦的是：每次智能体加载技能目录时，这些冗余技能都会挤占宝贵的上下文窗口，浪费 token，拖慢响应速度。

这就是 Hermes Curator 诞生的原因。它不是一个花哨的新功能，而是一个务实的后台维护机制——专门负责给你的技能库做”定期体检”和”断舍离”。

---

一、Curator 到底是什么？它解决什么问题？

核心问题：为什么智能体需要自动化的技能维护机制？

想象你雇了一位非常勤奋的助理，这位助理每解决一个新问题，就会把解法写进一本笔记本。一年过去，笔记本堆成了山。有些解法已经过时，有些则只是同一问题的不同表述。当你需要这位助理处理新任务时，它不得不先翻阅这堆笔记——效率越来越低。

Hermes 智能体的技能系统正是如此。通过 self-improvement loop，智能体可以在对话中自动创建技能，保存为 SKILL.md 文件。没有维护机制的话，这些技能会无限累积，最终变成”技能债务”：目录臃肿、重复技能泛滥、有效技能被噪音淹没。

Curator 就是来解决这个问题的。它是一个后台维护进程，核心职责有三件：

1. 追踪使用数据：记录每个技能被查看、使用、修改的频率和时间。
2. 自动状态迁移：把长期不用的技能从 active 移到 stale，再移到 archived。
3. 智能审查建议：定期启动一个辅助模型，审视现有技能，提出合并、修补或归档建议。

“

作者反思：我第一次理解 Curator 的设计时，意识到它本质上是在解决一个被很多 AI 系统忽视的问题——”知识的保质期”。人类会遗忘、会整理笔记，但 AI 系统默认只会不断追加。Curator 给 Hermes 引入了一种类似人类”记忆整理”的机制，这不是锦上添花，而是大规模智能体系统的必要基础设施。

---

二、Curator 的运行机制：不是定时任务，而是”趁你不在时干活”

核心问题：Curator 什么时候运行？它会不会干扰我正在进行的对话？

Curator 的触发逻辑设计得很巧妙——它不是传统的 cron 定时任务，而是基于”空闲检测”。

具体来说，在以下两个时机，Hermes 会检查是否需要启动 Curator：

• CLI 会话启动时
• Gateway 的 cron-ticker 线程的周期性检查中

每次检查都需同时满足两个条件才会触发：

条件	默认值	说明
interval_hours	168 小时（7 天）	距离上次 Curator 运行是否已超过设定时间
min_idle_hours	2 小时	智能体是否已空闲足够长时间

为什么要这样设计？ 因为 Curator 的 LLM 审查阶段会消耗模型调用资源。如果在你正忙着和智能体对话时触发，既浪费资源又可能影响体验。所以 Curator 选择在你”离开键盘”的安静时段启动——就像一位尽职的夜班管理员。

一旦触发，Hermes 会 fork 出一个独立的 AIAgent 实例，这个实例：

• 运行在独立的 prompt cache 中
• 绝不触碰当前活跃对话
• 拥有完整的工具访问权限（包括 skill_view 和 skill_manage）

这意味着你可以完全放心：Curator 的后台审查不会打断你的工作，也不会意外修改你正在使用的技能。

---

三、两阶段审查流程：先自动化，再智能化

核心问题：Curator 具体如何审查和整理技能？

每次 Curator 运行分为两个阶段，一快一慢，一确定一智能。

阶段一：自动状态迁移（确定性，无 LLM 调用）

这是纯规则引擎阶段，Curator 根据硬编码的时间阈值，批量处理技能状态：

stale_after_days: 30      # 30 天未使用 → 标记为 stale
archive_after_days: 90    # 90 天未使用 → 移入 .archive/ 目录

状态流转路径：

active → stale → archived
   ↑              ↓
   └──────── restore ───────┘

被归档的技能会被移动到 ~/.hermes/skills/.archive/ 目录下。这不是删除——你随时可以通过 hermes curator restore <skill-name> 恢复。Curator 的设计哲学是”保守清理”：宁可多留一步恢复余地，也不做不可逆的删除。

阶段二：LLM 智能审查（单次辅助模型调用，最多 8 轮迭代）

这是 Curator 的”大脑”部分。Fork 出的辅助智能体会：

1. 浏览技能目录：通过 skill_view 读取技能内容
2. 识别问题技能：

   • 功能重叠的冗余技能（例如两个技能分别处理”读取 CSV”和”加载 CSV 文件”）
   • 内容漂移的技能（原始意图已被多次 patch 改得面目全非）
   • 过于狭窄、几乎不会被复用的技能
3. 提出处理建议：

   • 保留：技能仍然健康，无需动作
   • 修补：通过 skill_manage 更新技能内容
   • 合并：将多个重叠技能整合为一个更通用的技能
   • 归档：手动将技能移入存档（覆盖自动规则的决策）

“

作者反思：这个两阶段设计让我印象深刻。第一阶段是”低成本的例行公事”，用确定性规则处理 80% 的情况；第二阶段是”高价值的深度思考”，用 LLM 处理需要语义理解的复杂判断。这种”分层治理”的思路，其实在很多工程系统中都适用——先用规则过滤简单 case，再把复杂 case 交给更昂贵的智能层。

---

四、Curator 不碰什么？边界意识很重要

核心问题：Curator 会不会误删我重要的内置技能或从 Hub 安装的技能？

这是很多人第一次听说 Curator 时的第一反应。好消息是：Curator 有明确的边界意识，它只审查智能体自己创建的技能。

具体来说，Curator 永远不会触碰以下两类技能：

技能类型	标识文件	说明
Bundled skills	~/.hermes/skills/.bundled_manifest	Hermes 安装时自带的技能
Hub-installed skills	~/.hermes/skills/.hub/lock.json	通过 hermes skills install 从 agentskills.io 安装的技能

Curator 的审查范围仅限于 ~/.hermes/skills/ 下不属于上述两类清单的所有内容，包括：

• 智能体在对话中通过 skill_manage(action="create") 自动创建的技能
• 你手动编写的 SKILL.md 文件
• 通过外部技能目录映射进来的自定义技能

“

场景示例：假设你写了一个 deploy-to-aws 的手动技能，已经三个月没用了。Curator 会把它标记为 stale，甚至归档。但如果你从 Hub 安装了官方的 docker-compose 技能，即使一年不用，Curator 也绝不会碰它。

---

五、配置 Curator：按需调整维护节奏

核心问题：Curator 的默认配置适合我吗？如何自定义？

Curator 的所有配置都集中在 config.yaml 的 curator: 节点下，不走环境变量（因为这不是敏感信息）。默认配置如下：

curator:
  enabled: true
  interval_hours: 168          # 7 天
  min_idle_hours: 2
  stale_after_days: 30
  archive_after_days: 90
  auxiliary:
    provider: null             # null = 使用主辅助客户端
    model: null

配置项详解

配置项	默认值	用途
enabled	true	总开关，设为 false 完全禁用
interval_hours	168	两次 Curator 运行的最小间隔
min_idle_hours	2	触发前智能体必须空闲的时长
stale_after_days	30	技能变为 stale 的阈值
archive_after_days	90	技能被归档的阈值
auxiliary.provider	null	LLM 审查阶段的模型提供商
auxiliary.model	null	LLM 审查阶段的具体模型

实用场景：用更便宜的模型做审查

如果你的主模型是 GPT-4 或 Claude 3 Opus，每次 Curator 的 LLM 审查都可能消耗不少 token。你可以指定一个更便宜的辅助模型来降低成本：

curator:
  auxiliary:
    provider: openrouter
    model: google/gemini-3-flash-preview

这样，Curator 的自动状态迁移阶段零成本（纯规则），LLM 审查阶段则用低成本模型完成，整体开销可以控制得很低。

“

作者反思：这个配置设计体现了工程上的务实。很多系统会把”是否启用”和”用什么模型”混在一起，或者把配置分散到环境变量、配置文件、数据库多个地方。Curator 把所有配置收拢到一个 YAML 节点，并且明确区分了”调度策略”（interval、idle）和”执行策略”（auxiliary model），这让运维和调优都很直观。

---

六、命令行操作：你的 Curator 控制面板

核心问题：除了等它自动运行，我能手动控制 Curator 吗？

当然可以。Hermes 提供了一套完整的 CLI 命令来管理 Curator：

# 查看 Curator 状态：上次运行时间、技能统计、已固定技能、最近最少使用的 5 个技能
hermes curator status

# 立即触发一次审查（后台运行）
hermes curator run

# 立即触发一次审查，并阻塞直到 LLM 审查阶段完成
hermes curator run --sync

# 暂停 Curator（跨会话持久）
hermes curator pause

# 恢复 Curator
hermes curator resume

# 固定技能（防止自动迁移和智能体修改）
hermes curator pin <skill>

# 取消固定
hermes curator unpin <skill>

# 从归档中恢复技能
hermes curator restore <skill>

场景示例：排查技能目录膨胀

假设你感觉技能目录越来越慢，想手动检查：

$ hermes curator status
Last run: 2026-04-22 03:15:00
Active skills: 47
Stale skills: 12
Archived skills: 8
Pinned: deploy-to-aws, custom-logger

LRU Top 5:
  1. parse-json-legacy (last used: 2026-01-15)
  2. old-api-client (last used: 2026-02-03)
  3. temp-script-001 (last used: 2026-02-20)
  4. draft-skill-test (last used: 2026-03-01)
  5. backup-routine-v1 (last used: 2026-03-10)

从输出中，你一眼就能看出 parse-json-legacy 和 old-api-client 已经很久没用了，下次 Curator 运行它们很可能会被归档。如果你想保留某个技能，就可以立即执行 hermes curator pin <skill>。

“

场景示例：你正在准备一个重要的演示，担心 Curator 在后台运行可能意外归档你最近刚写但还没频繁使用的技能。这时你可以运行 hermes curator pause，演示结束后再 hermes curator resume。这种”手动闸门”在关键工作时段非常有用。

---

七、技能固定（Pinning）：给你的重要技能上把锁

核心问题：如何确保关键技能永远不会被 Curator 或智能体自己修改？

这是 Curator 最实用的功能之一。通过 pin 命令，你可以给特定技能加上一道”硬边界”。

Pinning 的双重保护

一旦技能被 pinned，它同时受到两方面的保护：

保护层面	具体行为
Curator 自动迁移	跳过该技能，不执行 active → stale → archived 的状态流转
Curator LLM 审查	审查指令明确要求 LLM 不要触碰该技能
智能体的 skill_manage 工具	拒绝所有写操作（edit、patch、delete、write_file、remove_file），并提示用户先 unpin

为什么需要阻止智能体自己修改？

这是一个关键设计。假设你写了一个精心调试的 production-deploy 技能， pinned 之后：

• 智能体在对话中不会意外重写这个技能
• 如果智能体认为需要修改，它会明确提示你：”请运行 hermes curator unpin production-deploy 后再进行修改”

这防止了”静默覆盖”——智能体在长篇对话的某个回合中，不知不觉把你辛苦写好的技能改坏了。

如何更新已固定的技能？

Pin 只保护”工具路径”，不保护”文件系统路径”。你可以直接编辑文件：

vim ~/.hermes/skills/<name>/SKILL.md

保存后，技能内容立即生效，pin 状态保持不变。

“

场景示例：你团队维护了一个内部的 company-standards 技能，规定了代码风格和审查流程。这个技能需要定期人工更新，但绝不能让智能体在对话中擅自修改。hermes curator pin company-standards 就是为此而生的。

限制：只能固定 agent-created 技能

尝试 pin 一个 bundled 或 hub-installed 技能会被拒绝，因为这两类技能本来就不在 Curator 的管辖范围内，无需额外保护。

---

八、使用数据追踪：Curator 的”记账本”

核心问题：Curator 如何判断一个技能是否”没人用”？它记录了哪些数据？

Curator 在 ~/.hermes/skills/.usage.json 中维护了一个”使用账本”，每个技能一条记录：

{
  "my-skill": {
    "use_count": 12,
    "view_count": 34,
    "last_used_at": "2026-04-24T18:12:03Z",
    "last_viewed_at": "2026-04-23T09:44:17Z",
    "patch_count": 3,
    "last_patched_at": "2026-04-20T22:01:55Z",
    "created_at": "2026-03-01T14:20:00Z",
    "state": "active",
    "pinned": false,
    "archived_at": null
  }
}

计数器含义

字段	触发条件
view_count	智能体调用 skill_view 查看技能内容
use_count	技能被加载进对话的 prompt 中实际使用
patch_count	通过 skill_manage 执行 patch/edit/write_file/remove_file

值得注意的是，bundled 和 hub-installed 技能明确排除在 telemetry 写入之外。这既是性能优化（减少不必要的 I/O），也是逻辑一致（Curator 不管理它们，所以也不追踪它们）。

“

作者反思：这个 telemetry 设计很”轻量”。它不是在做一个完整的审计日志系统，而是只收集 Curator 决策所需的最小数据集。view_count 和 use_count 的区分尤其精妙——一个技能可能经常被”查看”（智能体在检索时看到它），但很少被”使用”（实际加载进上下文）。高 view、低 use 的技能，往往是”标题党”——名字起得好，但内容不够实用。Curator 的 LLM 审查阶段可以借助这种信号，优先审视这些”华而不实”的技能。

---

九、运行报告：每次维护都留痕

核心问题：Curator 做了什么？我能在事后审计它的决策吗？

每次 Curator 运行都会生成一个带时间戳的目录：

~/.hermes/logs/curator/
└── 20260429-111512/
    ├── run.json      # 机器可读：完整数据、统计、LLM 输出
    └── REPORT.md     # 人类可读：摘要

REPORT.md 的内容通常包括：

• 哪些技能发生了状态迁移（active → stale → archived）
• LLM 审查阶段的发现和建议
• 哪些技能被修补或合并
• 运行耗时和 token 消耗

“

场景示例：你周一早上发现某个重要技能不见了。查看 REPORT.md，发现它在周末的 Curator 运行中被归档了。进一步查看 run.json 中的 LLM 输出，发现是因为该技能与另一个新创建的技能功能重叠，被建议合并。你可以立即 hermes curator restore <skill> 恢复，然后手动整合两个技能的内容。

这种”留痕”设计对于生产环境至关重要。它让 Curator 的自动决策变得可审计、可回溯、可纠正。

---

十、恢复已归档技能：一键”时光倒流”

核心问题：如果 Curator 归档了我还需要用的技能，怎么办？

恢复很简单：

hermes curator restore <skill-name>

这条命令会：

1. 将技能从 ~/.hermes/skills/.archive/ 移回主目录
2. 将其状态重置为 active
3. 更新 last_used_at 为当前时间

安全边界

恢复操作有一个保护机制：如果同名的 bundled 或 hub-installed 技能在归档后被安装了，恢复会被拒绝。这是为了防止”上游技能被用户技能 shadow”的潜在冲突。

“

场景示例：你三个月前写了一个 api-client 技能，后来被 Curator 归档。期间你从 Hub 安装了官方的 api-client 技能。此时执行 hermes curator restore api-client 会被拒绝，因为恢复后会与 Hub 版本冲突。你需要先重命名旧技能或卸载 Hub 版本。

---

十一、按环境禁用 Curator：灵活控制

核心问题：我能在特定环境或特定时段关闭 Curator 吗？

有三种方式可以控制 Curator 的启用状态：

方式	命令/配置	持久性	适用场景
完全禁用	config.yaml 中 curator.enabled: false	跨会话	不需要自动维护的轻量环境
临时暂停	hermes curator pause	跨会话，可恢复	关键工作时段防止干扰
自然抑制	保持智能体活跃	单次检查	活跃开发机器上，Curator 只在安静时运行

“

场景示例：你在 CI/CD 流水线中运行 Hermes，每次启动都是短暂的批处理任务，不需要 Curator 在后台运行。这时在配置中设置 curator.enabled: false 是最干净的方案。

---

十二、与 Hermes 其他系统的关联

核心问题：Curator 在 Hermes 的整体架构中处于什么位置？

Curator 不是孤立的功能，它与 Hermes 的其他子系统紧密配合：

相关系统	关系
Skills System	Curator 的治理对象。Skills 的自改进循环创建技能，Curator 负责维护。
Memory	与 Curator 平行的后台审查系统，负责长期记忆的维护。两者采用相同的 fork-agent 架构。
Bundled Skills	Curator 的”禁区”。这些技能由 Hermes 团队维护，通过版本更新迭代。
Hub (agentskills.io)	社区技能的分发平台。Hub 安装的技能也不在 Curator 管辖范围内。

“

作者反思：Curator 和 Memory 系统采用相同的”后台 fork 审查”模式，这让我看到 Hermes 架构的一个设计原则：把”维护性任务”和”交互性任务”彻底分离。主对话线程只负责响应用户，所有整理、审查、归档工作都交给独立的后台实例。这种分离保证了用户体验的稳定性，也让维护逻辑可以独立演进。

---

实用摘要 / 操作清单

如果你刚读完本文，想立即上手使用 Curator，以下是按优先级排序的行动清单：

• [ ] 检查当前状态：运行 hermes curator status，了解技能库健康度
• [ ] 识别关键技能：查看 LRU Top 5，判断是否有技能需要 pin 保护
• [ ] 固定重要技能：对团队标准、生产流程等关键技能执行 hermes curator pin
• [ ] 调整配置：根据团队节奏，修改 stale_after_days 和 archive_after_days
• [ ] 考虑成本优化：为 LLM 审查阶段指定更便宜的辅助模型
• [ ] 定期审计：养成查看 ~/.hermes/logs/curator/REPORT.md 的习惯
• [ ] 建立恢复流程：确保团队成员知道如何用 hermes curator restore 找回归档技能

---

一页速览（One-page Summary）

问题	答案
Curator 是什么？	Hermes Agent 的后台技能维护系统，防止技能库无限膨胀
它什么时候运行？	智能体空闲超过 2 小时且距离上次运行超过 7 天时触发
它会删除技能吗？	不会。最坏情况是归档到 .archive/ 目录，可随时恢复
它管理哪些技能？	仅智能体创建的技能，不碰 bundled 和 hub-installed 技能
如何保护关键技能？	hermes curator pin <skill>，阻止自动迁移和智能体修改
如何查看维护记录？	~/.hermes/logs/curator/<timestamp>/REPORT.md
如何恢复归档技能？	hermes curator restore <skill-name>
如何完全禁用？	config.yaml 中设置 curator.enabled: false
LLM 审查用哪个模型？	默认用主辅助模型，可通过 curator.auxiliary 指定更便宜的模型
配置在哪里？	~/.hermes/config.yaml 的 curator: 节点下

---

常见问题（FAQ）

Q1: Curator 会在我不注意的时候删除我的技能吗？

不会。Curator 从不自动删除任何技能。它的最终手段是将技能移动到 ~/.hermes/skills/.archive/ 目录，这是一个可逆操作。你可以随时用 hermes curator restore <skill> 恢复。

Q2: 我手动写的技能会被 Curator 处理吗？

会。只要你的手动技能不在 .bundled_manifest 或 .hub/lock.json 中，Curator 就会把它视为 agent-created 技能进行管理。如果你希望保护它，请使用 hermes curator pin <skill>。

Q3: Pin 一个技能后，我自己还能修改它吗？

可以。Pin 只阻止智能体通过 skill_manage 工具修改，不阻止你直接编辑文件系统中的 SKILL.md。你可以随时用编辑器手动更新。

Q4: Curator 的 LLM 审查会消耗很多 token 吗？

取决于你的技能库大小和配置的模型。默认使用主辅助模型，但建议为 Curator 指定一个更便宜的模型（如 Gemini Flash）来降低成本。审查是单次调用，最多 8 轮迭代。

Q5: 我能看到 Curator 每次具体做了什么决策吗？

可以。每次运行都会生成 ~/.hermes/logs/curator/<timestamp>/ 目录，包含机器可读的 run.json 和人类可读的 REPORT.md，完整记录状态迁移和 LLM 审查结果。

Q6: 如果 Curator 归档了一个技能，而后来又安装了同名的 Hub 技能，还能恢复吗？

不能。恢复操作会检查是否有同名 bundled 或 hub 技能存在，如果存在则拒绝恢复，防止命名冲突和 shadowing 问题。

Q7: Curator 和 Memory 系统有什么区别？

两者采用相同的 fork-agent 后台审查架构，但治理对象不同：Curator 管理技能（skills），Memory 系统管理长期记忆。它们独立运行，互不干扰。

Q8: 我的技能库很小，还需要启用 Curator 吗？

如果你的技能库只有几个技能，Curator 的自动迁移阶段几乎不会触发动作，LLM 审查阶段的开销也很低。建议保持启用，因为它会在技能库增长时自动发挥作用，无需你后续手动开启。如果确实不需要，可以设置 curator.enabled: false。