<!-- Source: https://hermesbible.com/docs/user-guide/features/curator -->

Section: Core Features · URL: https://hermesbible.com/docs/user-guide/features/curator

Curator（策展人）是用於代理建立的技能的背景維護機制。它追蹤每個技能的檢視、使用和修補頻率，將長時間未使用的技能依序推進 active → stale → archived 狀態，並定期啟動一個短期的輔助模型審查，提出合併或修補偏移的建議。

它的存在是為了避免透過 self-improvement loop 建立的技能無限堆疊。每次代理解決了一個新問題並儲存技能，該技能就會進入 ~/.hermes/skills/。如果不加以維護，最終會累積數十個狹窄且近乎重複的技能，污染目錄並浪費 token。

預設情況下（prune_builtins: true），Curator 可以在 archive_after_days 天未使用後，歸檔未使用的內建技能（隨 repo 一起發佈），與它主要管理的代理建立技能一併處理。從 agentskills.io 安裝的 Hub 技能永遠不會被觸碰。設定 curator.prune_builtins: false 可恢復舊有的「僅管理代理建立技能」行為，即內建技能永遠不受影響。Curator 也永遠不會自動刪除——最糟的情況是歸檔至 ~/.hermes/skills/.archive/，且可隨時還原。

追蹤 issue #7816。

運作方式

Curator 由閒置檢查觸發，而非 cron 常駐程式。在 CLI 工作階段啟動時，以及閘道器 cron-ticker 線程的週期性 tick 中，Hermes 會檢查：

1. 距離上次 Curator 執行是否已過足夠時間（interval_hours，預設 7 天），以及
2. 代理是否已閒置足夠時間（min_idle_hours，預設 2 小時）。

若兩者皆為 true，它會產生一個 AIAgent 的背景分叉——與記憶/技能自我改進提示使用的模式相同。該分叉在自己的 prompt cache 中運行，不會觸及活跃的對話。

INFO — 首次運行行為

在全新安裝（或是 pre-curator 版本在 hermes update 後首次 tick）時，Curator 不會立即運行。首次觀察會將 last_run_at 設為「now」，並將真正的首次執行推延一個完整的 interval_hours。這讓你有整個間隔時間來審視你的技能資料庫、釘選重要的技能，或完全退出，然後 Curator 才會開始運作。

如果你想在 Curator 真正運行前看看它會做什麼，執行 hermes curator run --dry-run——它會產生相同的審查報告，但不會修改資料庫。

一次運行包含兩個階段：

1. 自動狀態轉換（確定性，無 LLM）。未使用 stale_after_days（30）天的技能變為 stale；未使用 archive_after_days（90）天的技能被移至 ~/.hermes/skills/.archive/。
2. LLM 審查（單次輔助模型運行，max_iterations=8）。分叉的代理會檢視代理建立的技能，可以透過 skill_view 讀取任何技能，並逐個決定是否保留、修補（透過 skill_manage）、合併重疊的技能，或透過終端工具歸檔。合併將技能視為完整的套件：如果技能包含 references/、templates/、scripts/、assets/ 或指向這些路徑的相對連結，Curator 必須將其保留為獨立套件、重新安置必要的支援檔案並重寫路徑，或完整歸檔整個套件——不能僅將 SKILL.md 扁平化地塞進另一個技能的 references/ 檔案中。

釘選的技能不受 Curator 的自動狀態轉換和代理自身的 skill_manage 工具影響。參見下方釘選技能。

設定

所有設定位於 config.yaml 的 curator: 下（不是 .env——這不是機密）。預設值：

curator:
  enabled: true
  interval_hours: 168          # 7 天
  min_idle_hours: 2
  stale_after_days: 30
  archive_after_days: 90
  prune_builtins: true         # 也歸檔未使用的內建技能（Hub 技能永遠豁免）

要完全停用，設定 curator.enabled: false。

使用較便宜的輔助模型運行審查

Curator 的 LLM 審查階段是一般的輔助任務槽位——auxiliary.curator——與 Vision、Compression、Session Search 等並列。"Auto" 表示「使用我的主要聊天模型」；你可以覆蓋此槽位，指定特定的供應商 + 模型來執行審查。

最簡單——hermes model：

hermes model                   # → "Auxiliary models — side-task routing"
                               # → 選擇 "Curator" → 選擇供應商 → 選擇模型

相同的選擇器也可在 Web 儀表板的 Models 分頁中使用。

直接修改 config.yaml（等效方式）：

auxiliary:
  curator:
    provider: openrouter
    model: google/gemini-3-flash-preview
    timeout: 600               # 寬鬆設定——審查可能需要數分鐘

保留 provider: auto（預設值）會將審查階段導向你的主要聊天模型，與其他所有輔助任務的行為一致。

NOTE — 舊版設定

早期版本使用了一次性的 curator.auxiliary.{provider,model} 區塊。該方式仍然有效，但會輸出棄用日誌——請遷移至上方的 auxiliary.curator，讓 Curator 與其他輔助任務共用相同的管線（hermes model、儀表板 Models 分頁、base_url、api_key、timeout、extra_body）。

CLI

hermes curator status         # 上次運行、計數、釘選清單、LRU 前 5 名
hermes curator run            # 立即觸發審查（阻塞至 LLM 階段完成）
hermes curator run --background  # 背景執行：在背景線程中啟動 LLM 階段
hermes curator run --dry-run  # 僅預覽——產生報告但不進行任何修改
hermes curator backup         # 手動快照 ~/.hermes/skills/
hermes curator rollback       # 從最新的快照還原
hermes curator rollback --list     # 列出所有可用快照
hermes curator rollback --id <ts>  # 還原特定快照
hermes curator rollback -y         # 跳過確認提示
hermes curator pause          # 暫停運行，直到 resume
hermes curator resume
hermes curator pin <skill>    # 永遠不自動轉換此技能
hermes curator unpin <skill>
hermes curator restore <skill>  # 將已歸檔的技能移回 active
hermes curator list-archived    # 列出目前在 ~/.hermes/skills/.archive/ 中的技能
hermes curator archive <skill>  # 手動立即歸檔單一技能
hermes curator prune [--days N] # 批量歸檔閒置 >= N 天的代理建立技能（預設 90）

備份與還原

在每次真正的 Curator 運行之前，Hermes 會在 ~/.hermes/skills/.curator_backups/<utc-iso>/skills.tar.gz 建立 ~/.hermes/skills/ 的 tar.gz 快照。如果某次運行歸檔或合併了你不想動的東西，你可以用一行指令撤銷整個運行：

hermes curator rollback        # 還原最新快照（含確認提示）
hermes curator rollback -y     # 跳過確認提示
hermes curator rollback --list # 查看所有快照及其原因和大小

還原本身也是可逆的：在替換技能目錄之前，Hermes 會建立另一個標記為 pre-rollback to <target-id> 的快照，因此錯誤的還原可以透過 --id 還原到該快照來撤銷。

你也可以隨時使用 hermes curator backup --reason "before-refactor" 建立手動快照。--reason 字串會記錄在快照的 manifest.json 中，並在 --list 中顯示。

快照會修剪至 curator.backup.keep（預設 5）以限制磁碟用量：

curator:
  backup:
    enabled: true
    keep: 5

設定 curator.backup.enabled: false 以停用自動快照。手動 hermes curator backup 指令在備份停用時仍然有效，但前提是你要先設定 enabled: true——此旗標對兩種路徑對稱地進行把關，以避免在修改性運行中意外跳過運行前快照。

hermes curator status 也會列出最近最少使用的五個技能——快速查看哪些技能可能即將變為 stale。

這些子指令也可在運行中的工作階段（CLI 或閘道器平台）以 /curator 斜線指令使用。

「代理建立」的含義

Curator 只管理在 ~/.hermes/skills/.usage.json 中明確標記為代理建立的技能。技能需要同時滿足以下所有條件才算合格：

1. 其名稱不在 ~/.hermes/skills/.bundled_manifest 中（隨 repo 發佈的內建技能）。
2. 其名稱不在 ~/.hermes/skills/.hub/lock.json 中（Hub 安裝的技能）。
3. 其 .usage.json 項目具有 "created_by": "agent" 或 "agent_created": true。

目前只有背景自我改進審查分叉會設定此標記——當它在週期性審查階段（約每 10 個代理回合一次）中建立新的綜合技能時。背景分叉以寫入來源 "background_review"（透過 tools/skill_provenance.py）運行，這是唯一會觸發 skill_manage 中 mark_agent_created() 命叫的路徑。

前景代理在對話期間透過 skill_manage(action="create") 建立的技能不會標記為代理建立——它們被視為使用者主導的，Curator 會刻意不觸碰它們。

WARNING — 你手寫的技能不會被 Curator 管理

如果你手動建立了 SKILL.md 或將 Hermes 指向外部技能目錄，該技能的 .usage.json 項目會有 created_by: null（或該欄位不存在）。Curator 不會碰它。同樣地，前景代理在你的要求下建立的技能也是如此。

要查看 Curator 實際管理哪些技能，執行 hermes curator status。如果代理建立的數量為 0，表示目前沒有任何技能在 Curator 的管轄範圍內——LLM 審查階段會被跳過，報告會顯示 Model: (not resolved) via (not resolved) 以及 Duration: 0s。

被認定為代理建立的技能遵循完整的生命週期：

• active →（30 天未使用）stale →（90 天未使用）archived
• 釘選的技能跳過所有自動轉換
• 歸檔可透過 hermes curator restore <name> 還原

如果你想要保護特定技能永遠不被觸碰——例如你依賴的手寫技能——使用 hermes curator pin <name>。參見下一節。

釘選技能

釘選可以保護技能不被刪除——無論是 Curator 的自動歸檔階段還是代理的 skill_manage(action="delete") 工具呼叫。一旦技能被釘選：

• Curator 在自動轉換（active → stale → archived）時會跳過它，且其 LLM 審查階段的指示會要求不動它。
• 代理的 skill_manage 工具會拒絕對其執行 delete，並引導使用者執行 hermes curator unpin <name>。修補和編輯仍然可以進行，因此代理可以在遇到問題時改進釘選技能的內容，而無需進行釘選/取消釘選/重新釘選的繁瑣操作。

使用以下指令釘選和取消釘選：

hermes curator pin <skill>
hermes curator unpin <skill>

此旗標以 "pinned": true 儲存在技能在 ~/.hermes/skills/.usage.json 中的條目上，因此可以跨工作階段保留。

只有代理建立的技能可以被釘選——hermes curator pin 對內建技能和 Hub 安裝的技能會拒絕並輸出說明訊息。Hub 安裝的技能永遠不會受到 Curator 修改的影響。內建技能只有在 curator.prune_builtins: true（預設值）時才會被觸碰，且即便如此也僅在 archive_after_days 天未使用後才會被歸檔——永遠不會被修補、合併或刪除。設定 curator.prune_builtins: false 可讓內建技能完全豁免。

一小組受保護的內建技能被硬編碼為永遠不可歸檔、永遠不可合併，無論 curator.prune_builtins、釘選狀態或 LLM 判斷如何。這些技能支撐著關鍵的使用者體驗——例如 plan 驅動了 /plan 斜線指令流程——因此靜悄悄地歸檔會將其斜線指令變成「Unknown command」錯誤，且不會向你發出任何訊號。受保護的內建技能會從 Curator 的候選名單中完全過濾掉，因此合併階段永遠不會看到它們。

如果你想要比「不刪除」更強的保證——例如在代理仍然讀取技能時完全凍結其內容——直接用你的編輯器編輯 ~/.hermes/skills/<name>/SKILL.md。釘選保護的是工具驅動的刪除，而非你自己的檔案系統存取。

使用遙測

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 在該技能上執行。

內建技能和 Hub 安裝的技能會明確排除在遙測寫入之外。

每次運行的報告

每次 Curator 運行都會在 ~/.hermes/logs/curator/ 下寫入一個帶時間戳的目錄：

~/.hermes/logs/curator/
└── 20260429-111512/
    ├── run.json      # 機器可讀：完整保真度、統計、LLM 輸出
    └── REPORT.md     # 人類可讀的摘要

REPORT.md 是快速查看某次運行做了什麼的好方法——哪些技能發生了狀態轉換、LLM 審查器說了什麼、它修補了哪些技能。適合在不需要 grep agent.log 的情況下進行審計。

NOTE — 沒有候選者？報告顯示 (not resolved)

當 Curator 沒有代理建立的技能可以審查時，LLM 審查階段會完全跳過。報告標題會顯示 Model: (not resolved) via (not resolved) 以及 Duration: 0s——這不代表設定錯誤或模型解析失敗。它只是表示沒有候選者，因此從未呼叫任何模型。自動轉換階段仍然會正常運行並報告其計數。

摘要中的重新命名對應

如果一次運行將多個技能合併到一個綜合技能下（或合併了近乎重複的技能），運行結束時顯示的使用者可見摘要會包含一個明確的重新命名對應，列出 Curator 套用的所有 old-name → new-name 還對。這是在各技能狀態轉換行之外的補充，因此當一波重新命名發生時，你可以一眼看出，而無需比對 JSON 報告。此提示也會在 hermes curator pin 下顯示，因此如果你想要鎖定新的標籤名稱，可以立即釘選綜合技能的名稱。

還原已歸檔的技能

如果 Curator 歸檔了你仍然想要的技能：

hermes curator restore <skill-name>

這會將技能從 ~/.hermes/skills/.archive/ 移回活跃的目錄結構，並重置其狀態為 active。如果同名的內建技能或 Hub 安裝的技能已被安裝，還原會被拒絕（會遮蔽上游）。

按環境停用

Curator 預設啟用。要關閉：

• 僅針對一個設定檔： 編輯 ~/.hermes/config.yaml（或作用中設定檔的設定）並設定 curator.enabled: false。
• 僅針對一次運行： hermes curator pause——暫停會跨工作階段持續；使用 resume 重新啟用。

Curator 也會在 min_idle_hours 尚未過去時拒絕運行，因此在活跃的開發機器上，它自然只會在安靜時段運行。

參見

• Skills System——技能的一般運作方式及建立它們的自我改進循環
• Memory——維護長期記憶的平行背景審查
• Bundled Skills Catalog
• Issue #7816——原始提案與設計討論

---

---

Persistent Memory