Curator 是 Hermes 自进化系统中最特殊的存在它不是用户调用的功能而是一个独立运行的后台进程。而 Background Review Fork 是它的手——一个拥有独立权限标记的 Agent 实例专门执行 curator 的决策。一、curator 不是功能是进程大多数 AI 助手的自动化意味着用户在某个菜单里点一下优化按钮。Hermes 的 curator 不需要用户点。它是一个独立进程有自己的状态文件.curator_state、调度周期、操作权限。它的存在对用户完全透明——没有 UI没有通知不打扰。用户只是某天发现Agent 自动创建的技能变少了重复的消失了过时的归档了。二、curator 做什么curator 的工作由tools/skill_usage.py中的状态转换逻辑驱动。每次运行时它执行以下步骤Step 1收集候选技能list_agent_created_skill_names()第 330 行枚举所有 curator 可以管理的技能def list_agent_created_skill_names() - List[str]: # 扫描 skills/ 下所有 SKILL.md # 排除 Hub 安装的 # 排除受保护的内置技能如 plan # 排除外部目录的 # 只返回 created_by agent 的Step 2检查使用频率对于每个候选技能读取.usage.json中的last_used_at和last_viewed_at。超过stale_after_days→ 标记STATE_STALE。超过archive_after_days→STATE_ARCHIVED→ 移到.archive/目录。这些阈值可以在config.yaml中配置curator: stale_after_days: 30 # 30 天未使用 → stale archive_after_days: 90 # 90 天未使用 → archived prune_builtins: false # 是否也管理内置技能默认 falseStep 3检测重复如果两个技能的 frontmatterdescription和内容高度相似curator 调用 LLM 做一次 consolidation pass——生成一个合并版本旧的两个归档。Step 4归档而非删除归档操作不是rm -rf。archive_skill()第 770 行将技能目录移到.archive/skill-timestamp/。用户可以通过hermes curator restore name恢复。三、is_curation_eligiblecurator 的边界检查curator 不会无差别操作。is_curation_eligible()第 447 行是每次操作前的硬检查def is_curation_eligible(skill_name: str) - bool: if is_hub_installed(skill_name): return False # 有外部上游 if is_bundled(skill_name): return _prune_builtins_enabled() if is_protected_builtin(skill_name): return False # 硬编码保护 ...特别值得注意的是PROTECTED_BUILTIN_SKILLS第 66 行PROTECTED_BUILTIN_SKILLS: Set[str] {plan,}plan是 Hermes 内置的/plan命令依赖的技能。如果 curator 不小心归档了它/plan就会变成 Unknown command。这个硬编码保护确保关键 UX 路径永远不会被 curator 破坏。_mutate()函数第 580 行在执行任何生命周期变更前都会检查这个条件。不是prompt 里提示 curator 别碰——是代码层面阻止了。四、Background Review Forkcurator 的执行器curator 决定应该做什么但实际修改技能文件需要一个 Agent。这就是 Background Review Fork。run_agent.py中的_spawn_background_review()创建一个独立的 Agent 实例——不是前台 Agent 的分身而是一个完整的、拥有自己工具调用上下文的进程。tools/skill_provenance.py定义了一个 ContextVar 来标记当前写入来源_write_origin: ContextVar[str] ContextVar(skill_write_origin, defaultforeground)Review fork 启动时这个 ContextVar 被设置为background_review。之后这个 fork 的所有工具调用都会携带这个标记。当 fork 中的 Agent 调用skill_manage(actioncreate)时# skill_manager_tool.py 第 1385-1389 行 if action create: if is_background_review(): # ← 检查 ContextVar mark_agent_created(name) # ← 标记为 agent 创建这是整个 provenance 链的关键环节。不是所有技能创建都标记——只有 Review fork 创建的才标记。此外Review fork 还有额外的安全限制只能修改它自己读过的技能——_background_review_read_before_write_guard()确保 fork 不能基于推断来修改技能外部技能目录写保护——_background_review_write_guard()检查技能是否在外部目录删除走 archive 而非硬删除——确保用户始终可以恢复五、curator_state 文件curator 的运行状态持久化在%LOCALAPPDATA%\hermes\skills\.curator_state{ last_run_at: 2026-07-05T10:34:0000:00, last_run_duration_seconds: null, last_run_summary: deferred first run, paused: false, run_count: 0 }安装后 curator 设置为deferred first run——等一个间隔周期后才首次执行。给用户时间自己创建技能curator 不会在探索阶段跳出来优化。用户可以通过 CLI 管理 curatorhermes curator status # 查看状态 hermes curator run --dry-run # 预览会做什么 hermes curator pause # 暂停 hermes curator resume # 恢复 hermes curator restore name # 恢复归档的技能六、为什么 Claude Code 做不到curator Background Review 这套机制对 Claude Code 来说在架构上就不可能。Claude Code 没有后台进程。它按需启动执行完退出。没有在用户不看的时候运行的概念。Claude Code 没有 ContextVar 权限标记。所有操作都在同一个上下文中——它无法区分用户让我做的和系统自动做的。Claude Code 没有 provenance。它不知道 CLAUDE.md 里哪些是你写的、哪些是它生成的。所以它不敢自动修改任何东西。这不是 Anthropic 做不出。这是产品定位。Claude Code 是一个按需工具。Hermes 是一个常驻系统。curator 只有在一个会持续运行的 Agent中才有意义。七、核心哲学curator 的设计回答了一个根本问题自治系统如何不越界答案不是让它更聪明——是让它在代码层面不可能越界ContextVar 在运行时标记操作来源is_curation_eligible在每次操作前做硬检查PROTECTED_BUILTIN_SKILLS硬编码保护关键功能外部目录写保护、只读技能只读归档而非删除、始终可恢复这就是 Hermes 的自治哲学在严格定义的边界内给你最大的自动化。边界之外一步都不多走。下一篇安全架构注入扫描、漂移检测与防死循环Hermes Agent 由 Nous Research 开发。本文基于 Hermes v0.18.0 源码分析。
Hermes Agent 自进化架构深度解析（四）：Curator 与 Background Review——后台自治的核心
Curator 是 Hermes 自进化系统中最特殊的存在它不是用户调用的功能而是一个独立运行的后台进程。而 Background Review Fork 是它的手——一个拥有独立权限标记的 Agent 实例专门执行 curator 的决策。一、curator 不是功能是进程大多数 AI 助手的自动化意味着用户在某个菜单里点一下优化按钮。Hermes 的 curator 不需要用户点。它是一个独立进程有自己的状态文件.curator_state、调度周期、操作权限。它的存在对用户完全透明——没有 UI没有通知不打扰。用户只是某天发现Agent 自动创建的技能变少了重复的消失了过时的归档了。二、curator 做什么curator 的工作由tools/skill_usage.py中的状态转换逻辑驱动。每次运行时它执行以下步骤Step 1收集候选技能list_agent_created_skill_names()第 330 行枚举所有 curator 可以管理的技能def list_agent_created_skill_names() - List[str]: # 扫描 skills/ 下所有 SKILL.md # 排除 Hub 安装的 # 排除受保护的内置技能如 plan # 排除外部目录的 # 只返回 created_by agent 的Step 2检查使用频率对于每个候选技能读取.usage.json中的last_used_at和last_viewed_at。超过stale_after_days→ 标记STATE_STALE。超过archive_after_days→STATE_ARCHIVED→ 移到.archive/目录。这些阈值可以在config.yaml中配置curator: stale_after_days: 30 # 30 天未使用 → stale archive_after_days: 90 # 90 天未使用 → archived prune_builtins: false # 是否也管理内置技能默认 falseStep 3检测重复如果两个技能的 frontmatterdescription和内容高度相似curator 调用 LLM 做一次 consolidation pass——生成一个合并版本旧的两个归档。Step 4归档而非删除归档操作不是rm -rf。archive_skill()第 770 行将技能目录移到.archive/skill-timestamp/。用户可以通过hermes curator restore name恢复。三、is_curation_eligiblecurator 的边界检查curator 不会无差别操作。is_curation_eligible()第 447 行是每次操作前的硬检查def is_curation_eligible(skill_name: str) - bool: if is_hub_installed(skill_name): return False # 有外部上游 if is_bundled(skill_name): return _prune_builtins_enabled() if is_protected_builtin(skill_name): return False # 硬编码保护 ...特别值得注意的是PROTECTED_BUILTIN_SKILLS第 66 行PROTECTED_BUILTIN_SKILLS: Set[str] {plan,}plan是 Hermes 内置的/plan命令依赖的技能。如果 curator 不小心归档了它/plan就会变成 Unknown command。这个硬编码保护确保关键 UX 路径永远不会被 curator 破坏。_mutate()函数第 580 行在执行任何生命周期变更前都会检查这个条件。不是prompt 里提示 curator 别碰——是代码层面阻止了。四、Background Review Forkcurator 的执行器curator 决定应该做什么但实际修改技能文件需要一个 Agent。这就是 Background Review Fork。run_agent.py中的_spawn_background_review()创建一个独立的 Agent 实例——不是前台 Agent 的分身而是一个完整的、拥有自己工具调用上下文的进程。tools/skill_provenance.py定义了一个 ContextVar 来标记当前写入来源_write_origin: ContextVar[str] ContextVar(skill_write_origin, defaultforeground)Review fork 启动时这个 ContextVar 被设置为background_review。之后这个 fork 的所有工具调用都会携带这个标记。当 fork 中的 Agent 调用skill_manage(actioncreate)时# skill_manager_tool.py 第 1385-1389 行 if action create: if is_background_review(): # ← 检查 ContextVar mark_agent_created(name) # ← 标记为 agent 创建这是整个 provenance 链的关键环节。不是所有技能创建都标记——只有 Review fork 创建的才标记。此外Review fork 还有额外的安全限制只能修改它自己读过的技能——_background_review_read_before_write_guard()确保 fork 不能基于推断来修改技能外部技能目录写保护——_background_review_write_guard()检查技能是否在外部目录删除走 archive 而非硬删除——确保用户始终可以恢复五、curator_state 文件curator 的运行状态持久化在%LOCALAPPDATA%\hermes\skills\.curator_state{ last_run_at: 2026-07-05T10:34:0000:00, last_run_duration_seconds: null, last_run_summary: deferred first run, paused: false, run_count: 0 }安装后 curator 设置为deferred first run——等一个间隔周期后才首次执行。给用户时间自己创建技能curator 不会在探索阶段跳出来优化。用户可以通过 CLI 管理 curatorhermes curator status # 查看状态 hermes curator run --dry-run # 预览会做什么 hermes curator pause # 暂停 hermes curator resume # 恢复 hermes curator restore name # 恢复归档的技能六、为什么 Claude Code 做不到curator Background Review 这套机制对 Claude Code 来说在架构上就不可能。Claude Code 没有后台进程。它按需启动执行完退出。没有在用户不看的时候运行的概念。Claude Code 没有 ContextVar 权限标记。所有操作都在同一个上下文中——它无法区分用户让我做的和系统自动做的。Claude Code 没有 provenance。它不知道 CLAUDE.md 里哪些是你写的、哪些是它生成的。所以它不敢自动修改任何东西。这不是 Anthropic 做不出。这是产品定位。Claude Code 是一个按需工具。Hermes 是一个常驻系统。curator 只有在一个会持续运行的 Agent中才有意义。七、核心哲学curator 的设计回答了一个根本问题自治系统如何不越界答案不是让它更聪明——是让它在代码层面不可能越界ContextVar 在运行时标记操作来源is_curation_eligible在每次操作前做硬检查PROTECTED_BUILTIN_SKILLS硬编码保护关键功能外部目录写保护、只读技能只读归档而非删除、始终可恢复这就是 Hermes 的自治哲学在严格定义的边界内给你最大的自动化。边界之外一步都不多走。下一篇安全架构注入扫描、漂移检测与防死循环Hermes Agent 由 Nous Research 开发。本文基于 Hermes v0.18.0 源码分析。
