Hermes Agent Skill 系统深度解析¶

Ch01.298 Hermes Agent Skill 系统深度解析¶

📊 Level ⭐⭐ | 12.4KB | entities/hermes-skill-system.md

核心定位¶

Skill = 过程性知识 = 菜谱 ≠ 便签 Hermes Agent 的 Skill 系统与 Memory 系统解决的是完全不同的问题： | | Memory | Skill | |--|--------|-------| | 本质 | 陈述性记忆（你知道什么） | 过程性记忆（你会做什么） | | 回答 | 事实型问题 | 流程型问题 | | 形态 | 离散的便签 | 带顺序的菜谱 | | 超过3步 | 跳步/合并/遗漏 | 天然有序、可声明依赖 | "会做事比知道事更值钱" ——认知心理学视角下，Skill 沉淀的是可复用的操作能力，不是知道这件事存在。

三个不能单用 Memory 的坑¶

坑 1：执行 vs 理解¶

Memory 的查询路径是"看完再说"，但执行型任务需要"打开手册第 3 步→做完打勾→出错回到第 2 步"。任何超过 3 步的流程塞进 Memory 都会出问题。

坑 2：版本化需求¶

发布流程会变（npm → pnpm → changesets）。Memory 是离散事实合集，改了要么全删要么全留。Skill 是文件，天然支持版本号/patch/回滚。

坑 3：依赖关系¶

复杂任务需要"做 A 之前先做 B"，Memory 是平的。Skill 可声明 `depends_on: [run-tests, write-changelog]`。¶

SKILL.md 五区块设计¶

区块	内容	关键设计意图
元信息	`trigger` 字段	trigger 关键字粗筛 → 语义 tie-breaker，工程折中
适用场景	明确边界	省掉一半误用
步骤清单	带编号的真正流程	能贴命令就贴，能写参数就写参数
坑位记录	"上次错在哪"	反向 checklist，模型主动避坑
校验方式	每步/全流程验证	无校验无法判断对错
---

Skill 检索匹配四步¶

用户提需求（自然语言）
trigger 关键字粗筛 → 语义打分 tie-breaker（省 token）
命中 1~3 个候选 → 看标题适用场景做选择
注入完整 Skill 文件到 system prompt（不是摘要，漏一步就崩） 金句：找不到才创建，找到就复用。

修补哲学：patch 不是重写¶

Skill 会反复修补（Review Agent 复盘后执行）。关键区别：

不是重写：带 diff，每次留下"改了什么、为什么改"
是 patch：在原文件上增量修改，版本可追溯这个机制在企业级 Skill Hub 里演化为：版本管理 + 质量评估 + 灰度发布 + 回滚。

生命周期五阶段¶

Created → Used → Patched → Aged → Retired
  ↓        ↓        ↓        ↓        ↓
初版验证  实战检验  版本+1   提升信任度  归档保留

Aged（沉淀）：多次成功复用后 Hermes 提升信任度，可跳过部分人工确认
Retired（退役）：工具栈过时了→归档不删除，"上次踩的坑"仍有参考价值

实操建议（winty 总结）¶

越具体越好：能贴命令贴命令，能附校验附校验
trigger 区分度高："发布 npm 包"而非泛用词"发布"
定期清理：Skill 库膨胀的成本是检索噪音，不是磁盘
写人能看懂：越像菜谱越容易手动调整
前 5 个手写：感受好 Skill 长什么样，后面让 AI 写才知道怎么挑

深度分析¶

1. 过程性知识 vs 陈述性知识的认知科学分野¶

Skill 系统的根基不是工程偏好，而是认知心理学的经典分野：陈述性记忆（Declarative Memory） 和 程序性记忆（Procedural Memory）。

陈述性记忆 回答"你知道什么"——事实、地点、人名，可被显性表达和直接查询
程序性记忆 回答"你会做什么"——骑自行车、写代码，是身体化和情境化的能力 winty 引用认知心理学老师的金句"会做事比知道事更值钱"，点出了 Skill 系统的核心假设：能写菜谱和真的会炒菜是两回事。Hermes Agent 的 Skill 沉淀的是后者——可复用的操作能力，而非关于某事的背景知识。这意味着 Skill 的评估维度不是"描述准确"，而是"执行成功"。

2. SKILL.md 五区块设计的工程意图¶

五区块设计不是随意划分的，每块都对应一个具体的工程问题： | 区块 | 解决的工程问题 | |------|--------------| | 元信息（trigger） | 检索阶段的关键字匹配 + 语义 tie-breaker | | 适用场景 | 减少误用，尤其是跨场景复用导致的命令错误 | | 步骤清单 | 让模型有顺序地执行，而非脑补顺序 | | 坑位记录 | 反向 checklist，让模型主动避开已知坑点 | | 校验方式 | 每步/全流程验证，解决"跑完了不知道对不对" | 坑位记录 是设计里最巧妙的一环：它不写"正确做法"，而写"上次错在哪"。这利用了模型的 attention 机制——模型在执行时会对"坑点"段落格外注意，产生主动避坑行为。

3. 双层检索匹配：工程折中与信息检索原理¶

Skill 检索采用 trigger 关键字粗筛 → 语义打分 tie-breaker 的双层架构，这不是偷懒，而是信息检索的经典折中：

trigger 关键字 解决召回率问题：所有含"发布"的 Skill 先被召回
语义打分 解决精确率问题：在候选集内做排序 winty 指出，单用语义匹配"太贵也太慢"——对每个 Skill 做 embedding 检索在大规模 Skill 库下成本不可接受。trigger 关键字是工程上的必要粗糙，但保证了基本召回；语义打分只在候选集小于 3 时触发，属于轻量 tie-breaker。

4. Patch 增量修补的版本化哲学¶

Skill 的"修补"机制是整个自进化系统的微观原型。关键洞察：patch 不是重写，而是带历史的增量修改。重写的代价是三重的： 1. 历史经验丢失（"容易踩的坑"段落被覆盖） 2. 无法增量评估（新版本相比老版本好了多少不可知） 3. 版本号失去意义（版本应该对应 diff，而非全新内容） Hermes 的 patch 机制保留了完整的历史轨迹，这为后续 Skill Hub 的版本管理 + 质量评估 + 灰度发布 + 回滚 提供了原子基础。winty 明确指出，这个机制在企业级场景下会演化为完整的 CI/CD 式 Skill 发布管道。

5. 生命周期五阶段与组织知识沉淀¶

五阶段生命周期设计反映了一个核心思想：Skill 是组织级知识资产，而非个人笔记。

Created：初版验证，单次成功即生成，未经验证
Used：实战检验，每次复用都是盲测
Patched：增量改进，版本号 +1
Aged：信任度提升，可跳过部分人工确认（意味着它已沉淀为高可靠资产）
Retired：归档不删除（因为"上次踩的坑"仍有参考价值） Retired 不删除 这一点体现了经验主义的知识观：过时 Skill 的步骤可能不再适用，但踩坑记录永远不会过时。这个设计为 Skill Hub 的"历史知识检索"提供了存在依据。

实践启示¶

1. 为 Skill 设计高区分度的 trigger 关键字¶

trigger 是检索的第一道门槛，设计时分两种场景：

通用动作 + 明确对象："发布 npm 包"、"发布 GitHub Release"、"发布到生产环境"——每个对象一个独立 trigger
避免泛化："发布"太宽，会导致多 Skill 撞车，模型在候选阶段就纠结 trigger 区分度直接影响候选集大小。理想情况下触发后候选不超过 3 个，否则语义打分阶段容易选错。

2. 控制单个 Skill 粒度在 800-1500 token¶

Skill 文件注入 prompt 时会占用上下文配额。winty 给出了隐性规则：单个 Skill 超过 2000 token 会挤掉其他上下文。实践建议：

步骤清单控制在 8-10 步以内
超过这个规模就拆分成多个 Skill，用 depends_on 声明依赖
坑位记录和校验方式尽量简洁，不要写成故障排查报告

3. 建立坑位记录的积累机制¶

坑位记录是 Skill 系统的"反向经验资产"，需要主动积累而非被动等待：

每次执行出错，复盘后必须写入/更新对应 Skill 的坑位段落
格式参考："上次错在漏了 build 步骤"、"忘记在发布前跑 lint"
原则：坑位记录越具体越好，"命令参数错误"这种模糊描述等于没写 Review Agent 的复盘质量直接决定了坑位记录的有效性。

4. 利用 Aged 阶段降低人工确认成本¶

成熟 Skill（多次成功复用后）会获得 Hermes 的信任度提升，可跳过部分人工确认。实践中应该：

定期审计 Aged Skill：确认其校验方式仍然有效（工具链可能变）
对 Aged Skill 建立监控：某次执行失败应及时触发 Patched，而非绕过
信任度有条件：只在场景完全匹配时跳过确认，场景偏移仍需人工审核

5. 退役归档时保留坑位与依赖声明¶

Skill 退役时切忌直接删除——工具栈过时不代表经验过时。归档时必须保留：

坑位记录："上次踩的坑"对新工具链仍有避坑参考价值
依赖声明：depends_on 片段可作为新 Skill 设计的参照
版本历史：patch 记录下来的版本演进轨迹是组织 know-how 的直接体现建议在 .hermes/skills/retired/ 目录下归档，并在 Skill Hub 中保留历史查询入口。

Hermes Agent Skill 系统深度解析¶

Ch01.298 Hermes Agent Skill 系统深度解析¶

核心定位¶

三个不能单用 Memory 的坑¶

坑 1：执行 vs 理解¶

坑 2：版本化需求¶

坑 3：依赖关系¶

复杂任务需要"做 A 之前先做 B"，Memory 是平的。Skill 可声明 `depends_on: [run-tests, write-changelog]`。¶

SKILL.md 五区块设计¶

Skill 检索匹配四步¶

修补哲学：patch 不是重写¶

生命周期五阶段¶

实操建议（winty 总结）¶

深度分析¶

1. 过程性知识 vs 陈述性知识的认知科学分野¶

2. SKILL.md 五区块设计的工程意图¶

3. 双层检索匹配：工程折中与信息检索原理¶

4. Patch 增量修补的版本化哲学¶

5. 生命周期五阶段与组织知识沉淀¶

实践启示¶

1. 为 Skill 设计高区分度的 trigger 关键字¶

2. 控制单个 Skill 粒度在 800-1500 token¶

3. 建立坑位记录的积累机制¶

4. 利用 Aged 阶段降低人工确认成本¶

5. 退役归档时保留坑位与依赖声明¶

相关页面¶

相关实体¶

Hermes Agent Skill 系统深度解析¶

Ch01.298 Hermes Agent Skill 系统深度解析¶

核心定位¶

三个不能单用 Memory 的坑¶

坑 1：执行 vs 理解¶

坑 2：版本化需求¶

坑 3：依赖关系¶

复杂任务需要"做 A 之前先做 B"，Memory 是平的。Skill 可声明 depends_on: [run-tests, write-changelog]。¶

SKILL.md 五区块设计¶

Skill 检索匹配四步¶

修补哲学：patch 不是重写¶

生命周期五阶段¶

实操建议（winty 总结）¶

深度分析¶

1. 过程性知识 vs 陈述性知识的认知科学分野¶

2. SKILL.md 五区块设计的工程意图¶

3. 双层检索匹配：工程折中与信息检索原理¶

4. Patch 增量修补的版本化哲学¶

5. 生命周期五阶段与组织知识沉淀¶

实践启示¶

1. 为 Skill 设计高区分度的 trigger 关键字¶

2. 控制单个 Skill 粒度在 800-1500 token¶

3. 建立坑位记录的积累机制¶

4. 利用 Aged 阶段降低人工确认成本¶

5. 退役归档时保留坑位与依赖声明¶

相关页面¶

相关实体¶

复杂任务需要"做 A 之前先做 B"，Memory 是平的。Skill 可声明 `depends_on: [run-tests, write-changelog]`。¶