睡一觉起来看 New-API 后台，发现 Hermes 在我睡觉时调了 90 多次 deepseek-v4-flash。查完之后发现是个好东西，值得写一篇。
事情经过
端午节在家吃了睡睡了吃，下午睡起来，习惯性打开 New-API 后台看看消耗。好家伙：
15:49 ~ 16:08，87 次调用，总输入 ~26 万 token，总缓存 ~1337万，总输出 ~5万。
我第一反应是我的Key泄漏了？查了一下New-API日志细节，发现调用IP是我本地的。第二反应是 Hermes 出 BUG 了，或者有什么循环在疯狂刷 API。于是让 Hermes 自己查日志：
15点30到16点30调用了90多次大模型，查看日志这是干了啥？
30 秒后它告诉我：不是 BUG，是 Curator（技能策展人）在跑。
Curator 是什么？
Curator 是 Hermes Agent 内置的技能库自动维护系统。默认每周跑一次，负责对 ~/.hermes/skills/ 下的所有技能文件做整理、合并、清理。
简单说就是：AI 版本的家政阿姨，定期来给你的技能库做断舍离。
查日志过程
Hermes 的日志分两层：
| 日志 | 路径 | 用途 |
|---|---|---|
| Gateway 日志 | ~/.hermes/logs/gateway.log |
网络层、消息路由、会话管理 |
| Agent 日志 | ~/.hermes/logs/agent.log |
LLM 调用、工具执行、会话详情 |
先看 gateway.log 确认时间范围内的事件：
2026-06-19 15:49:13 curator snapshot created (pre-curator-run)
2026-06-19 16:08:13 curator: auto: no changes; llm: ## Consolidation Summary
抓住 session ID 20260619_154915_d9f7b2，切到 agent.log 看详细：
$ grep "20260619_154915_d9f7b2" agent.log | grep "API call" | wc -l
87
$ grep "20260619_154915_d9f7b2" agent.log | grep "Turn ended"
Turn ended: reason=text_response(finish_reason=stop)
api_calls=87/9999 tool_turns=36 response_len=4541
87 次调用，36 轮工具操作，19 分钟跑完。
Curator 执行完后会把完整报告写到一个独立目录：
~/.hermes/logs/curator/20260619-074912/
├── REPORT.md # 人类可读的总结报告
└── run.json # 机器可读的完整记录（含所有工具调用细节）
报告内容很详细——每一步做了什么工具调用、归档了哪些技能、合并了哪些、patch 了哪些文件，全部有记录。
这次执行具体做了什么
配置
来自 ~/.hermes/config.yaml：
curator:
enabled: true
interval_hours: 168 # 每周一次
min_idle_hours: 2 # 至少空闲 2 小时才跑
stale_after_days: 30 # 30 天未用标记为过期
archive_after_days: 90 # 90 天自动归档
backup:
enabled: true
keep: 5 # 保留最近 5 次备份
执行结果：72 → 53，净减 19
归档了 19 个技能
全部移到 ~/.hermes/skills/.archive/，可用 hermes curator restore <name> 恢复：
| 归档技能 | 原因 |
|---|---|
claude-code,codex,opencode |
AI Coding Agent，已经不再用 |
cocos-creator-performance,cocos-creator-resource-management |
项目迁移，不需要了 |
plan,spike,test-driven-development,requesting-code-review等 6 个 |
已被 development-workflows 伞技能覆盖 |
kanban-orchestrator,kanban-worker |
不再使用 |
heartmula,songsee,songwriting-and-ai-music |
实验性技能，不再维护 |
合并了 6 个技能到伞技能下
① xitter → xurl
xurl 的 SKILL.md 明确写着 "This skill replaces the older xitter skill"。Curator 把 xitter 的命令参考转为 xurl/references/xitter.md，xurl 里加一段迁移说明，原 xitter 目录归档。
② 4 个 Himalaya 相关技能 → himalaya 主技能
himalaya-email-cleanup-systematic→ 搜索语法和参数规则补入主 SKILL.mdhimalaya-multi-account-fix→ 降为references/multi-account-fix.mdhimalaya-installation（乱放在 productivity/ 下）→ 降为references/installation.mdemail-cleanup-systematic（与 himalaya 内容完全重复）→ 降为 reference
③ hermes-web-ui-auth-token-config → hermes-web-ui-management
两页的 AUTH_TOKEN 配置文档降为 references/auth-token-config.md。
保留了 10 个独立技能
评估后认为各自有独立价值，不合并：
api-integration-failure-handling、apikey-image-gen、custom_providers_env_config、dogfood、grok-image-to-video、hyperframes、remotion、markdown-viewer、ima-skill、yuanbao
为什么花了 87 次调用？
Curator 的 LLM 阶段流程是：读取技能 → LLM 分析内容 → 决定处理方式 → 执行（patch/skill_manage）→ 更新 todo 列表。每个技能少则 1 次、多则 3-4 次调用。
这次处理了 72 个技能（扫描）+ 6 个合并集群 + 19 个归档 + 多个 patch，66 次工具调用 + 87 次 API 调用，合理。
平均每个调用 ~10 秒延迟，一半有 cache hit（50%），实际消耗约 13 万 token/轮。
实用操作
# 查看 curator 调度配置
grep -A 8 "curator:" ~/.hermes/config.yaml
# 查看最近一次 curator 报告
cat ~/.hermes/logs/curator/$(ls -t ~/.hermes/logs/curator/ | head -1)/REPORT.md
# 恢复归档的技能
hermes curator restore <skill-name>
# 手动触发 curator 运行
# （需要重启 gateway 或等下次调度）
我的感受
好的地方
- 报告详细——REPORT.md + run.json 双份记录，每一步都有日志可查
- 合并逻辑合理——xitter→xurl、4 个 himalaya→1 个，确实应该整理
- 可恢复——归档进
.archive/不是真删，一条命令就回来 - 自动备份——跑之前先整库快照，不怕搞砸
槽点
- 87 次调用确实不少——一周一次可以接受，如果觉得贵可以把
interval_hours调成 336（两周一次）或者 720（一个月一次） - 中间有几次 skill_view 报错——比如
sketch重名（本地和 external_dir 各一个）、audiocraft-audio-generation找不到，这些小坑说明 curator 对目录结构敏感 - 如果是按量计费的 API，默认用的是 DeepSeek V4 Flash模型，这 19 分钟大概花几毛到一块钱。
总结
Curator 不是一个"可有可无"的功能。如果你的技能库超过 20 个，它确实能帮你保持整洁——把分散的小技能归入伞技能、清理过期技能、修复交叉引用。每周一次、一两毛钱，换来技能库不腐烂，值。
不过它也有局限：对技能目录结构敏感，重名或路径不对会报 warning 跳过。而且它只处理技能文件，不影响你正在运行的对话或 cron 任务，这一点设计得干净。
核心建议：默认配置就可以用。如果每周 80-90 次调用对你来说太多，把 interval_hours 改成 336 就行。技能归档后不占 token，恢复也很简单。
评论区