当一个 AI 能自己创建技能时最大的问题不是它能不能写好——是它写的和别人写的怎么区分谁能改谁能删。Hermes 用 Provenance 追溯回答了谁能管用两段式 Curator 回答了怎么减——而且它默认只归档不删除。一、技能不是存一个 prompt大多数 AI 助手的技能或自定义指令功能本质上是文件管理器用户写一个 prompt 模板存起来下次加载。如果模板过时——用户手动改。如果存了十个模板其中三个重复——用户手动清理。Hermes 的技能系统不一样。它在四个层面实现了自动化创建时Provenance 追溯——记录谁创建的决定谁能管理使用时Auto-Patch——发现过时立刻修复不需要等闲置时生命周期管理——active → stale → archivedCurator 自动过渡冗余时LLM 合并——umbrella-building将分散的窄技能合并为类级技能需手动开启四者通过一套共享的信号系统created_by字段 ContextVar lifecycle state互相触发。二、技能的文件结构所有技能存放在%LOCALAPPDATA%\hermes\skills\下。每个技能是一个目录包含必需的SKILL.md和可选的支持文件skills/ ├── cover-image-generation/ ← 技能目录 │ ├── SKILL.md ← 必需YAML frontmatter Markdown 指令 │ ├── references/ ← 可选参考文档 │ ├── templates/ ← 可选输出模板 │ └── scripts/ ← 可选可执行脚本 ├── .usage.json ← 使用情况侧车文件关键 ├── .curator_state ← Curator 调度状态 ├── .curator_suppressed ← 已裁剪内置技能名单 ├── .archive/ ← 归档技能可恢复 └── .hub/ ← Hub 安装锁文件SKILL.md的 frontmatter 格式遵循 agentskills.io 标准--- name: cover-image-generation description: 用 HTML 浏览器截图生成封面不用 Pillow 直接画 version: 1.0.0 ---但最关键的不是 SKILL.md——是.usage.json。三、.usage.json技能的档案袋tools/skill_usage.py维护一个 JSON 侧车文件记录每个技能的元数据。空记录的默认值第 484-497 行def _empty_record() - Dict[str, Any]: return { created_by: None, # 谁创建的null用户agentAgent 自动 use_count: 0, # 被使用次数skill_view 加载时递增 view_count: 0, # 被查看次数 last_used_at: None, # 最后使用时间ISO 时间戳 last_viewed_at: None, # 最后查看时间 patch_count: 0, # 被修补次数 last_patched_at: None, # 最后修补时间 created_at: _now_iso(), # 创建时间首次写入时生成 state: active, # 生命周期状态active / stale / archived pinned: False, # 是否锁定锁定后永不自动归档 archived_at: None, # 归档时间 }每一个字段都在为 Curator 的决策提供信号。patch_count高 → 这个技能可能需要重构。last_used_at太久远 → 可能该归档了。pinned→ 跳过所有自动操作。关键设计侧车文件不是 frontmatter 内嵌。把运维遥测数据放在SKILL.md外面避免污染用户编写的内容也避免与 bundled/hub skill 的 YAML 产生冲突。所有计数器更新都是 best-effort——侧车损坏绝不影响底层工具调用。四、Provenance谁创建的就归谁管这是整个技能系统最根本的设计决策。如果 AI 能自己创建技能、自己删技能——那它和用户手动写的怎么区分答案在created_by字段。但不是所有技能创建都会打上agent标记——关键在于运行时 ContextVar 判断。tools/skill_manager_tool.py第 1385-1389 行if action create: if is_background_review(): # 只有 Background Review fork mark_agent_created(name) # 才标记为 agent 创建tools/skill_provenance.py定义了一个 ContextVar_write_origin: ContextVar[str] ContextVar(skill_write_origin, defaultforeground)三种值及其含义值含义created_byCurator 可管foreground用户在 CLI 对话中让 Agent 创建null用户所有❌ 永不触碰background_reviewCurator fork 创建agentCurator 可管✅ 可合并/归档bundled随 Hermes 仓库发布无 usage 记录⚠️ 仅prune_builtins: true时hub-installed从 Skills Hub 安装Hub 锁文件记录❌ 永不触碰前台对话中用户让 Agent 创建的技能 →created_by null→ Curator永不触碰。后台 Review fork 自动创建的技能 →created_by agent→ Curator可以管理。is_curation_eligible()tools/skill_usage.py第 447 行在执行任何 Curator 操作前都会做四重检查def is_curation_eligible(skill_name: str) - bool: if is_protected_builtin(skill_name): return False # 内置关键技能 if is_hub_installed(skill_name): return False # Hub 安装的 if is_bundled(skill_name): return _prune_builtins_enabled() # agent-created → 检查 usage 记录中的 created_by agentHub 安装的技能有外部上游、内置关键技能如plan被硬编码保护——Curator 在任何路径上都跳不过这些检查。Claude Code没有 provenance 的概念。CLAUDE.md 是你写的——但系统不知道这是用户写的还是AI 生成的。所以它不敢自动动任何东西。五、Auto-Patch使用中发现错误立刻修复Hermes 系统提示词中有一条硬性指令如果你加载了一个 Skill 来指导当前任务执行中发现它过时、不完整、或错误——立刻 patch 它。不要等被要求。每次 patch 都被记录tools/skill_usage.py第 635-643 行def bump_patch(skill_name: str) - None: def _apply(rec): rec[patch_count] int(rec.get(patch_count) or 0) 1 rec[last_patched_at] _now_iso() _mutate(skill_name, _apply)patch_count不只是统计。Curator 后续审查时优先关注频繁被修补的技能——它们是设计需要重构的信号。一次 patch 修 bug三次 patch 说明思路有问题Curator 会合并或重写。六、Curator 的两段式减法机制这是本文的重点。Curator 不是一个后台进程定期做一件事。它是两个独立 pass由curator.enabled共同控门由curator.consolidate区分是否执行 LLM 段。源码入口agent/curator.py:1513-1582——run_curator_pass()。6.1 默认配置hermes_cli/config.py第 2283-2320 行的默认值curator: enabled: true # Curator 总开关 interval_hours: 168 # 7 天运行一次 min_idle_hours: 2 # Agent 需空闲 2 小时以上才触发 stale_after_days: 30 # 30 天未使用 → 标记 stale archive_after_days: 90 # 90 天未使用 → 归档到 .archive/ consolidate: false # LLM 合并 pass默认关闭 prune_builtins: true # 允许裁剪内置技能 backup: enabled: true keep: 56.2 Pass 1确定性生命周期转换始终运行零 LLM 成本函数agent/curator.py:291-369——apply_automatic_transitions()这是纯逻辑判断不需要 LLM。每次 Curator 触发时必然执行def apply_automatic_transitions(nowNone): stale_cutoff now - timedelta(daysget_stale_after_days()) # 30 天 archive_cutoff now - timedelta(daysget_archive_after_days()) # 90 天 for row in agent_created_report(): if row.get(pinned): continue # 锁定的技能跳过 if name in cron_referenced: continue # 被 cron 引用的跳过 anchor last_activity or created_at # 以最后活跃时间为锚点 current row.get(state, active) # 从未使用过的技能有额外宽限期第 349-355 行 # use_count 0 不代表陈旧——可能只是还没遇到触发条件 if never_used and anchor stale_cutoff: continue # 至少等 30 天才开始计时 if anchor archive_cutoff: archive_skill(name) # → 移到 .archive/ elif anchor stale_cutoff: set_state(name, stale) # → 标记 stale elif anchor stale_cutoff and current stale: set_state(name, active) # → 又用了重新激活关键保护pinned技能在所有路径上被跳过被 cron job 引用的技能等同于 pinned第 326 行——即使 cron 是暂停状态use_count 0的技能不会被立刻归档至少等stale_after_days30 天才开始计时绝不硬删除最坏情况是mv到.archive/可恢复6.3 Pass 2LLM 驱动的 umbrella-building 合并默认关闭需手动开启函数agent/curator.py:1569-1582——_llm_pass()这是关键——consolidate默认false。当consolidate false时# agent/curator.py:1578-1582 if not consolidate: final_summary ( f{prefix}{auto_summary}; llm: skipped (consolidation off) ) # ← 直接返回不 spawn LLM fork不花钱 return只有当consolidate: true时Curator 才会 spawn 一个 aux-model fork执行 umbrella-building扫描所有created_by agent的技能识别 prefix 聚类如hermes-config-*、pr-*、codex-*将同类窄技能合并为一个 umbrella skill合并后的旧技能归档不是删除Cron job 的技能引用自动跟随迁移Curator prompt 的硬约束agent/curator.py:403-481DO NOT delete any skill. Archiving is the maximum destructive action. Archives are recoverable; deletion is not.6.4 手动删除 vs Curator 归档skill_manage(actiondelete)的行为取决于调用者tools/skill_manager_tool.py:1085-1098调用者行为可恢复前台 Agent用户对话shutil.rmtree()硬删除❌后台 Curator fork强制路由到archive_skill()✅Curator fork 永远不会硬删除——代码直接if curator_pass: archive_skill()绕过了rmtree。6.5 为什么技能只增不减基于以上机制现在可以完整回答这个问题原因细节时间窗口长30 天 stale 90 天 archive刚建的技能在安全区内Curator 间隔长默认 7 天触发一次且需空闲 2 小时LLM 合并默认关闭consolidate: false不会主动合并冗余use0 有额外宽限从未用过的技能至少等 30 天才开始计时用户创建的永不触碰created_by: null的技能不在 Curator 管理范围内Pin 锁定保护锁定后跳过所有自动操作永不硬删除最坏结果是归档可恢复这不是 bug——是刻意设计。Hermes 的选择是宁可堆积也不误删因为 archive 是可逆的但 delete 不是。七、Pin 机制用户对自动化的否决权tools/skill_usage.py第 254-278 行def _pinned_guard(name: str) - Optional[str]: rec skill_usage.get_record(name) if rec.get(pinned): return fSkill {name} is pinned and cannot be deleted... return NonePin 的保护范围操作Pin 阻止archive自动归档✅ 阻止delete手动删除✅ 阻止patch/edit❌ 不阻止内容演化仍允许Background review 的所有写入✅ 阻止_background_review_write_guard第 300-318 行这意味着你可以在hermes curator pin name锁定一个技能后仍然手动更新它的内容——只是 Curator 永远不会动它。八、curator_state不打扰你的后台进程Curator 的运行状态记录在skills/.curator_state文件中{ last_run_at: 2026-07-05T10:34:0000:00, last_run_duration_seconds: 45.2, last_run_summary: auto: 1 archived, 2 marked stale; llm: skipped (consolidation off), paused: false, run_count: 3 }安装后 Curator 不会立刻运行——它配置了一个延迟等一个间隔周期7 天后才首次执行。这是故意的给用户时间自己创建一些技能Curator 不会在探索阶段就跳出来优化。用户可以hermes curator run --dry-run—— 预览会做什么不实际执行hermes curator run --consolidate --dry-run—— 预览 LLM 合并会做什么hermes curator run --consolidate—— 手动触发 LLM 合并hermes curator pause / resume—— 暂停 / 恢复hermes curator pin name—— 锁定技能hermes curator restore name—— 从 .archive/ 恢复九、与 Claude Code 的差异总结HermesClaude Code技能格式SKILL.md YAML frontmatter 支持文件CLAUDE.md 纯 Markdown来源追溯created_by ContextVar 运行时刻断无自动修复使用时发现过时 → auto-patch无生命周期active → stale → archived pinned 锁定存在 / 不存在减法机制确定性转换30d/90d LLM 合并需手动开启无管理边界is_curation_eligible()四重检查无后台管理Curator 独立进程aux-model 驱动无硬删除保护Curator 只归档不删除pin 锁定无十、核心哲学技能自进化的本质不是AI 更聪明了。是系统设计让正确的事自动发生同时让危险的事无法发生created_byis_background_review()→ 创建时就决定了管理权限_empty_record()的侧车设计 → 遥测数据不污染 SKILL.md 内容bump_patch→ 每次修复自动记录高频 patch 触发 Curator 关注apply_automatic_transitions()→ 30 天 stale / 90 天 archive无需用户手动清理consolidate: false默认→ 不收 aux-model 费用除非你主动开启_curator_consolidation_delete_guard→ Curator 永远不能硬删除只能归档_pinned_guard→ 你锁定的技能Curator 一步都进不来用户只管用——用得越多技能越精准、越精简。减法不会在你不注意时发生——它只在你允许的范围内、在你设定的节奏下、以可逆的方式发生。Hermes Agent 由 Nous Research 开发。本文基于 Hermes v0.18.0 源码分析。关键源文件tools/skill_usage.py947 行、tools/skill_manager_tool.py1542 行、agent/curator.py1976 行、hermes_cli/config.py2283-2320 行 curator 默认配置。
