英雄所见略同：Hermes v0.12.0 与 CN 版的三个巧合

求索实验室
63 阅读6分钟

上周刷公众号，看到两篇讲 Hermes Agent 的文章。

一篇讲 Hermes Curator——Agent 技能自动审查与进化引擎。另一篇讲 Hermes v0.12.0 的离线能力升级：LM Studio 正式升级为首等 Provider、Piper 本地 TTS 集成、Secret Redaction 默认关闭。

两篇都是关于 Hermes 官方 v0.12.0 新功能的解说。

巧的是，我维护的hermes-agent-cn 也在近期完成了类似的改造。 一个是官方主力版本，一个是面向中文社区的分支，在几乎同一时间，选择了同一个方向。

这是用户需求驱动下的殊途同归。

共识 1：Agent 需要自己能"整理房间"

Agent 用得越久，自动创建的 skills 越积越多。重复的、过时的、质量不高的，全混在一起。手动管理不现实，放任不管又影响效果。

Hermes 官方的解法是 Curator——一个内置的"技能管家"：

  • 频率追踪：记录每个 skill 的调用数据，高频标为核心，低频进入观察
  • 智能合并：功能相似的 skill 自动合并为更强版本
  • 自动归档：低价值 skill 自动归档，不占用上下文
  • Pin 保护：用户手动固定的 skill 永远不会被 Curator 动

CN 版的解法是 Skill 三层管理（Phase 8）：

  • Builtin 层：内置 skill，只读保护，不会被修改
  • Frequent 层：高频 skill，自动晋升到活跃上下文
  • Archived 层：归档 skill，零 token 成本

两者是互补的两个维度：

Curator（质量引擎）              三层管理（成本管控）
    │                                  │
    ├─ 合并相似技能 ──────────────→  ├─ 高频 skill 自动晋升
    ├─ 归档低价值技能                  ├─ 归档 skill 零 token 成本
    └─ 只动 Agent 自建的 skill         └─ 内置 skill 受保护

一个管质量（合并、优化、淘汰），一个管成本（谁进上下文、谁省 token）。方向一致，落地互补。

但有一个关键差异：Curator 是主动触发的自动化任务（默认每周日凌晨运行），而 CN 版的三层管理是实时响应的上下文调度。 这意味着 Curator 做周期性的"大扫除"，三层管理做每次对话的"精细分拣"。两个加在一起，才是完整的技能生命周期管理。

参考：尼克的AI笔记《AI Agent觉醒！Hermes Curator横空出世，竟会自我进化？》— 介绍 Hermes v0.12.0 Curator 功能

共识 2：本地优先，离线可用

这点在我的上一篇文章里重点写过。CN 版做了三层路由：

简单任务 → 嵌入式 CPU 推理（0 token 成本）
中等任务 → Ollama 本地服务
复杂任务 → 云端 API

Hermes 官方 v0.12.0 则走了另一条路：

  • LM Studio 升级为首等 Provider：不再是"自定义端点别名"，而是与 OpenAI、Anthropic 平级。hermes model 自动列出本地已下载的所有模型，hermes doctor 里有专门的检查项。
  • Piper TTS 集成：完全本地运行的开源语音合成，资源占用小，音频不出机器。
  • Secret Redaction 默认关闭：之前默认给密钥格式字符串打码的机制改为关，避免工具输出被静默篡改。
维度官方 v0.12.0Hermes-CN
本地推理LM Studio API（首等 Provider）嵌入式 llama-cpp-python + Ollama
本地 TTSPiper（开源 TTS）MOSS-TTS-Nano
离线部署手动配置 LM Studio一键装模型 setup --yes（1.58GB）
路由策略手动切换 Model自动三层路由（CPU/Ollama/Cloud）

量子智元那篇文章里有句话点得很透："核心推理链路（输入 → 模型思考 → 语音回复）已经可以实现数据全程不出用户机器。"

官方通过集成第三方工具实现，CN 版通过嵌入式推理实现。前者更开放（支持更多本地推理引擎），后者更省 token（CPU 推理不花一分钱）。路线不同，方向一致。

参考：量子智元《Hermes v0.12.0 彻底可以离线跑了》— 介绍 Hermes v0.12.0 离线能力增强

共识 3：配置体验应该趋近于零

CN 版的做法是 hermes quickstart——一句命令，自动检测环境变量、Ollama、本地模型，检测到什么用什么，用户不需要做选择。

官方 v0.12.0 也有类似的动作：LM Studio 升级后，hermes model 可自动列出本地已下载的所有模型，用户只需选择，无需手动配置路径。

两边的共同方向：

过去：                            现在：
hermes setup → 5 步手动配置    → 一句命令全自动 / 自动列表
手动下载模型 + 配置路径         → 自动检测 + 一键安装 / 自动列出
手动管理 API Key               → 扫描环境变量自动配置

选择是一种认知负担。 用户只想用工具，不想折腾配置。这个共识不只在 Hermes 生态——整个 AI 工具链都在朝这个方向走。

为什么会想到一起去？

不是因为代码共享，不是因为互相参考。纯粹是因为——用户的需求摆在那里。

  • 用户不想每次手动整理技能 → Curator / 三层管理
  • 用户不想每句对话都付 API 费 → LM Studio / 三层路由
  • 用户不想装个工具还要看 5 页文档 → 自动列表 / quickstart

当底层技术和用户需求同时成熟时，好的解决方案会在不同地方同时出现。这是行业进步的标志，不是巧合。

CN 版当前状态

如果你在用 Hermes-CN，以下功能已经就绪：

功能命令对应官方能力状态
Curator 技能自进化hermes curator runHermes v0.12.0 Curator✅ 完整保留，CLI 已汉化
技能三层管理自动运行Curator 互补方案✅ Phase 8 完成
一键装本地模型hermes local-models setup --yesLM Studio 支持✅ 自动下载 1.58GB
一键配置hermes quickstart自动列出模型✅ 零选择体验
首次启动引导hermes—✅ 中文菜单
LM Studio 支持hermes model 选择上游 v0.12.0 特性✅ 完整保留
中文回复内置—✅ Always reply in Chinese

尚未体验的朋友：git clone -b cn https://github.com/xyshanren/hermes-agent-cn.git && cd hermes-agent-cn && pip install -e . && hermes quickstart

后续：向官方提交 PR

文章写完当天，我把 CN 版的三层管理 + 自动调度核心模块重构为通用版本，提交了 Pull Request 👇

NousResearch/hermes-agent#20644 — Smart Skill Lifecycle Management: auto-tiering + auto-matching

这次提交包含 5 个 commit、6 个文件、+1018 行：

  • agent/skill_tier_manager.py — 根据使用频率自动升降级，省 token
  • agent/skill_matcher.py — 关键词/上下文/模糊匹配自动触发 Skill
  • agent/prompt_builder.py — System prompt 按三层分级注入
  • run_agent.py — 定期触发升降级评估
  • hermes_cli/main.py — hermes skills tier CLI 子命令
  • cli-config.yaml.example — 新增 skills.tier_management 配置节

CN 版的所有独有设计都通过这篇文章和这次 PR 回馈给上游。如果合并成功，每个 Hermes 用户都能享受自动分级的技能管理体验。

参考文章

求索实验室 · 2026-05-06

avatar
文章
阅读
粉丝