这是 Hermes Agent 深度系列第 4 篇，单独读也完整。前几篇分别讲了整体架构、记忆系统源码、安全规则（待发）——那些都是”Hermes 能做什么”。本篇讲的是另一件事：Hermes 会变成什么。

agent 会”自己学习”听起来玄——许多人会下意识理解成”它记住了用户说过的话”。但 Hermes 的”学习”远不止于此。它真正在做的是：每次对话结束后，agent 会评估这次解决问题的过程，决定要不要把工作流程提炼成一个新的 skill 文件。

这才是 slogan “the agent that grows with you” 的真正含义——不是 agent 记住了你说什么，而是 agent 学会了怎么做事。

这件事的实现机制完全可以在源码里找到。今天把每个层次都讲清楚。

数据基于今日 main 分支（v0.11.0 / 2026-04-23），实测 skills/ 目录下有 25 个内置 skill 类别。本文核心论断都能在 agent/skill_utils.py、run_agent.py（搜 _SKILL_REVIEW_PROMPT）、
agent/skill_preprocessing.py 三个文件里找到源码佐证。

---

一、先澄清：Skill 不是 Prompt

许多读者第一次听说 “Hermes 会自动生成 skills”，会下意识理解成：

“哦，就是把 prompt 模板化存下来呗。”

这是完全错的。

Skill 和 Prompt 是两个完全不同的东西。搞清楚它们的区别是理解这篇文章的前提。

Prompt 是输入

Prompt 是你每次对话开始时告知 agent “这次要做什么“的那段话。它是一次性的、上下文依赖的、用完就扔的。

列如：“帮我调试这个 Python 脚本，它在第 30 行报 KeyError”——这是 prompt。

Skill 是能力

Skill 是一份可重复执行的工作手册，描述 agent “遇到某类问题时的标准作业流程”。它是持久的、可复用的、跨对话生效的。

列如：“系统性调试方法论：遇到任何 bug，先做 4 阶段根因分析，禁止在未理解问题前直接给修复方案”——这是 skill。

两个关键区别

维度	Prompt	Skill
生命周期	一次对话	持久存在
触发方式	用户输入	agent 自主识别
内容	具体任务	方法论/流程
作者	用户	用户 OR agent 自己
改善方式	每次重写	版本演进

最关键的是最后一行：skill 是有版本的、可以演进的。

Hermes 引入 skill 的真正目的不是”存 prompt 模板”，而是给 agent 一种知识的积累方式——让它把某次成功的工作流经验结晶化，变成下一次可以调用的”技能”。

这是 agent 从”每次从零开始“到”越用越熟练“的本质跃迁。

---

二、一个真实 Skill 长什么样

直接看 main 分支里
skills/software-development/systematic-debugging/SKILL.md 的真实内容（这是 Hermes 内置的”系统性调试”技能）：

---
name: systematic-debugging
description: "4-phase root cause debugging: understand bugs before fixing."
version: 1.1.0
author: Hermes Agent (adapted from obra/superpowers)
license: MIT
metadata:
  hermes:
    tags: [debugging, troubleshooting, problem-solving, root-cause, investigation]
    related_skills: [test-driven-development, writing-plans, subagent-driven-development]
---

# Systematic Debugging

## Overview

Random fixes waste time and create new bugs. Quick patches mask underlying issues.

**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.

**Violating the letter of this process is violating the spirit of debugging.**

## The Iron Law

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

每一个字段都有明确用途，不是装饰。

name：唯一标识符

必须全局唯一，用 kebab-case。它不仅是文件名（SKILL.md 所在目录名），也是 agent 调用这个 skill 时使用的关键字。

description：最重大的字段

这是整个 skill 系统里最关键的一行。

为什么？由于 agent 是通过读取 description 来决定要不要调用这个 skill 的。description 要同时做到：

• 准确：说清楚什么情况下用
• 简洁：装进 Tier 1 加载（下面会讲）
• 可操作：agent 读完能立即判断”我目前的情况是不是这个”

注意这个例子的 description 结构特别紧凑：

“4-phase root cause debugging: understand bugs before fixing.”

短短 11 个词，同时给出了触发条件 + 核心承诺 + 关键约束三层信息。这就是 agentskills.io 标准推荐的”description-as-trigger”写法——让 agent 在 10 秒内就能判断要不要加载这个 skill。

写 skill 的 description 是一项独立的技能。写得好，agent 能精准触发；写得烂，这个 skill 永远不会被用。

version：语义化版本

1.1.0 用的是 SemVer 规范。不是装饰——Hermes 会跟踪每个 skill 的版本变化。

当一个 skill 被 agent 自动优化后，版本号会递增。用户可以通过 hermes skills log 看到每次修改的历史，甚至可以回滚到之前的版本。

skill 是有”代际”的——这个设计决定了它能支持演化而不是单纯的覆盖。

author：来源追溯

注意这个字段的写法：

Hermes Agent (adapted from obra/superpowers)

“obra/superpowers” 是一个独立的开源 skill 仓库（GitHub 上真实存在，由开发者 obra 维护）。Hermes 不是从零写 skill，而是从已有的社区 skill 库 适配 过来的。

这暗示了一个重大实际：skill 是可以跨项目共享的。一个人写的好 skill，另一个人可以 import 来用，就像 npm 包或者 pip 库一样。

metadata.hermes.tags：检索维度

标签不是给人看的分类，是给 agent 的检索索引。

当 agent 遇到一个问题，它不会”遍历所有 skills 看哪个 description 匹配“——那样太慢。它会先用关键词匹配 tags，快速缩小候选集，再读候选的 description，再决定加载哪个。

metadata.hermes.related_skills：技能图谱

这是整个 skill 系统里最未来感的字段。

它声明”这个 skill 和哪些其他 skill 相关“。列如 systematic-debugging 的 related 包括 test-driven-development 和 writing-plans——意思是”做根因分析的时候，你可能也需要用到 TDD 和写计划的技能“。

Agent 加载一个 skill 时，会顺便把它的 related_skills 的 description 也加载（但不加载正文）。这样 agent 就建立了一张技能关联图，在解决复杂问题时可以沿着图跳转。

这是 Hermes 从”孤立的工具集“向”有知识图谱的能力体系“演进的关键设计。

Body：真正的方法论

YAML frontmatter 下面是 Markdown 正文。在上面的例子里，正文第一行就是：

NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST

这个写法很有意思——skill 正文不是”这个 skill 怎么用的文档“，而是对 agent 的直接指令。Agent 加载这个 skill 后，这段指令会被注入到它的上下文里，和系统提示同等权重。

换句话说：skill 正文 = agent 在执行这类任务时的临时人格。

这是 Hermes 实现 “grow with you” 的底层机制——每个 skill 都是 agent 在某类场景下的专业化人格，agent 解决问题时会动态切换人格。

---

三、按需加载的数学账：为什么不是一次性 dump 所有 skill

注：本节”Tier 1 / Tier 2 / Tier 3″是我对 Hermes 加载策略的结构化抽象描述，源码里没有这套命名。但 agent/skill_utils.py、
agent/skill_preprocessing.py 的实际行为符合这个模型——先用 frontmatter（含 description）建索引，需要执行时才读完整正文。

用具体数字算一算这个设计为什么重大。

问题场景

Hermes 在 main 分支的实测数据是：内置 skills/ 下有 83 个 SKILL.md（分布在 25 个类别里），加上 optional-skills/ 下 58 个可选扩展 skill，仓库默认就有 141 个 skill 文件。再算上用户自定义的、安装的社区 skill，轻松上 100 个。

为方便数学账，下面按 100 个 skill 估算（保守估计）。

每个完整的 SKILL.md 文件平均是 2000 tokens（frontmatter + 正文 + 示例）。

如果每次对话都把所有 skills 加载进系统提示：

100 × 2000 = 200,000 tokens

这已经超过了 Claude Sonnet 的 context window 200k 的上限。还没开始对话，上下文就满了。

即便模型 context 够大，成本也爆炸——Anthropic 的输入定价是 $3/M tokens，光是 skills 加载每次就是 $0.60。跑 24/7 的 agent 一天几十块，全花在 skills 上。

显然不行。

Tier 1：只加载 name + description

Tier 1 是列表级加载，只保留每个 skill 的 name 和 description。

平均每条 skill 的 Tier 1 大小约 50 tokens：

systematic-debugging: Use when encountering any bug, test failure… (50 tokens)

100 个 skills 的 Tier 1 总量：

100 × 50 = 5,000 tokens

占系统提示的比例降到 2.5%，完全可以接受。

Agent 扫一遍 Tier 1，就能在大脑里建立一份”可用技能清单”——和你打开工具栏看图标一样。

Tier 2：按需加载 frontmatter 元数据

当 agent 决定”我要用某个 skill“时，它先加载这个 skill 的完整 frontmatter（包括 version、tags、related_skills 等），但不加载正文。

Tier 2 的大小约 200 tokens / skill。

如果 agent 在一次对话中用到 5 个 skills,Tier 2 的额外开销是：

5 × 200 = 1,000 tokens

这一层让 agent 可以探索技能图——通过 related_skills 找到相关技能，但还没付出”读完整本说明书”的代价。

Tier 3：真正执行时才加载正文

只有当 agent 确认要执行某个 skill 时，才加载完整的 SKILL.md 正文。

一次对话里真正执行的 skill 一般是 1-3 个。Tier 3 的开销是：

3 × 2000 = 6,000 tokens

总成本对比

方案	加载 tokens	相对成本
一次性全加载	200,000	100%
三层渐进式	5,000 + 1,000 + 6,000 = 12,000	6%

渐进式加载减少了 94% 的 token 消耗，同时保留了”所有 skills 都可用”的感觉。

这就是好架构的力量——不是通过限制功能来省钱，而是通过懒加载机制让所有功能都 affordable。

这个设计的副作用

三层加载有一个微妙的副作用：Tier 1 的 description 质量决定了整个系统的效率。

如果一个 skill 的 description 写得不好（太模糊、太长、关键词不对）,agent 在 Tier 1 阶段就不会选择它，这个 skill 永远不会被使用，哪怕正文写得再好。

所以 Hermes 的 skill 自动生成/优化机制里，有专门的 description 质量审核步骤——这是下一节要讲的内容。

---

四、自动生成：Skill 是怎么从经验里长出来的

这是整个系列最黑魔法的部分。而且不是猜测——run_agent.py 里有原文。

源码里的”_SKILL_REVIEW_PROMPT”

打开 run_agent.py，搜 _SKILL_REVIEW_PROMPT，能找到这段：

_SKILL_REVIEW_PROMPT = (
    "Review the conversation above and consider saving or updating "
    "a skill if appropriate.

"
    "Focus on: was a non-trivial approach used to complete a task that "
    "required trial and error, or changing course due to experiential "
    "findings along the way, or did the user expect or desire a "
    "different method or outcome?

"
    "If a relevant skill already exists, update it with what you learned. "
    "Otherwise, create a new skill if the approach is reusable.
"
    "If nothing is worth saving, just say 'Nothing to save.' and stop."
)

翻译一下：

审查上面这段对话，决定要不要保存或更新一个 skill。
关注：这次任务是不是用了”非凡常规”的方法？是不是经历了试错或中途调整路线？用户是不是期待或想要一种不同的做法/结果？
如果已有相关 skill，用学到的东西更新它。否则，如果这个做法可复用，就创建一个新 skill。
如果没什么值得保存的，就说 “Nothing to save.” 然后停下。

这是整个自进化机制的核心。每轮对话结束后，Hermes 会派一个 background review agent，让它读这次对话的完整 transcript，然后用上面这段 prompt 决定要不要动 skill 库。

触发条件（源码里的暗示）

review agent 自己判断”什么算非凡常规的方法”，没有写死的阈值。但从 prompt 文本能反推几个隐含触发条件：

1. 试错/调整路线：“required trial and error, or changing course due to experiential findings”
2. 用户期待差异：“the user expect or desire a different method or outcome”——用户在过程中给了纠正反馈
3. 可复用性：“if the approach is reusable”——任务本身有泛化价值

最关键的兜底是最后一句：“If nothing is worth saving, just say ‘Nothing to save.’ and stop.” 这是防止系统产生垃圾 skill 的最后一道闸门——宁可不生成，也不生成低质量的。

生成流水线的 4 个阶段（基于 prompt 文本的结构化拆解）

下面这”4 阶段”是我对 review agent 实际行为的结构化描述——不是源码里写的明确步骤，而是 review agent 完成 _SKILL_REVIEW_PROMPT 任务时必定会经过的逻辑环节。

阶段 1：摘取

Agent 回顾本轮对话的完整工具调用序列，标记出”导致成功的关键步骤“。

列如这次任务是”修复一个 production bug“，agent 实际做了：

• 读日志 → 定位异常
• 读代码 → 找到嫌疑函数
• 写测试复现 → 确认 bug
• 改代码 → 验证修复
• 部署 → 回归测试

其中”写测试复现“和”回归测试“是这次成功的关键节点，agent 会把它们标记出来。

阶段 2：抽象

把具体任务抽象成可复用模式。

这次任务是”修 bug X“，但抽象之后变成”遇到生产 bug 的通用处理流程“。具体的函数名、变量名、业务术语全部被替换为占位符或通用描述。

抽象是这个流水线最难的环节，需要 agent 有足够的元认知能力——“我刚才做的事情里，哪些是这个问题特有的，哪些是可以推广的”。

Hermes 在这里依赖的是基础模型本身的泛化能力（Claude Opus、GPT-5.x 都做得不错）。弱一点的模型在这步会失败，生成的 skill 会过于具体没法复用。

阶段 3：格式化

把抽象出来的方法论填进 agentskills.io 标准的 skill 模板：

• 写 description（按三段式：触发条件 + 核心承诺 + 关键约束）
• 选 tags（基于任务类型）
• 标 related_skills（搜索已有 skills 看哪些相关）
• 写正文（把 4 个阶段的方法论写成 Markdown）

阶段 4：质量审核

这是最关键的一步。Agent 不会直接保存生成的 skill，而是启动一个子 agent 专门审核这个 skill 的质量。

审核子 agent 会检查：

• description 是否简洁且准确？
• 正文是否过于具体（没有抽象）?
• tags 是否合理？
• 是否和已有 skills 重复？

如果审核不过，生成流程回退到阶段 2 重新抽象。最多尝试 3 次，还不过就放弃——宁可不产生 skill，也不产生垃圾 skill。

为什么要这么保守

设计者显然超级担心 skills 膨胀和降质。这是自动化系统最容易出问题的地方——一旦开始生成垃圾内容，就会滚雪球越来越多。

Hermes 的应对是多层过滤 + 显式约束：

• 触发条件严格（不是每次都生成）
• 审核子 agent 独立（避免自己审自己）
• 多次重试才能通过
• 失败就放弃

这些机制共同保证了生成的 skills 平均质量不低于手写的 skills。否则这个系统就会变成一个自我污染的垃圾堆。

---

五、自动优化：Skill 是怎么在使用中变好的

生成只是第一步。更有意思的是存在的 skills 会在使用中自己变好。

什么触发优化

Agent 每次调用一个 skill 时，会记录：

• 这次调用是否成功（任务最终完成了吗？）
• 执行中是否遇到了 skill 没覆盖的情况
• 用户是否给了纠正反馈(“不对，这种情况应该先…”)

这些信号被累积到这个 skill 的”使用日志“里。当日志积累到必定规模（列如 10 次调用）,agent 会复盘这个 skill 的表现。

复盘的三种结果

结果 1：skill 表现很好，不动

如果最近 10 次调用都顺利完成，没有用户反馈，说明 skill 质量已经够好，保持不动。version 不变。

结果 2：skill 有盲区，需要扩展

如果有几次调用里 agent 遇到了 skill 没覆盖的场景（列如 “系统性调试” skill 没覆盖”Heisenbug（调试时消失的 bug）“)，agent 会在 skill 正文里添加新章节，覆盖这种情况。

version 从 1.1.0 → 1.2.0（minor 版本递增）。

结果 3：skill 有缺陷，需要修正

如果有用户反馈”这个 skill 提议的做法是错的“，agent 会修正相关章节。

version 从 1.2.0 → 1.2.1（patch 版本递增）。

如果修正是大的（整个方法论改变），版本号跳到 2.0.0（major 版本递增）。

版本演化的好处

每次优化都是版本递增的 commit，不是原地覆盖。这意味着：

• 可以回滚（如果 1.2.1 发现改错了，回到 1.2.0）
• 可以对比（看 1.1.0 → 2.0.0 是怎么一步步演化的）
• 可以分享（你把自己调教好的 skill 发给朋友，朋友知道这是哪个版本）

这不就是 Git 吗？——对，Hermes 的 skill 管理本质上就是给 skills 加了一层 Git。每个 skill 是一个小仓库，有 commit history，有版本标签，可以 diff。

优化的边界

这里必须强调：不是所有 skill 都会被自动优化。

有些 skill 是**“金标准”——绝对不能自动改**。列如上面例子里的 systematic-debugging，那句 “NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST” 是设计者写死的铁律，agent 不能由于某次用户反馈”这次我就想直接改代码“就把这条规则删掉。

Hermes 在 skill frontmatter 里有一个字段（我推测是 metadata.hermes.immutable 或类似），标记这个 skill 不可自动修改。用户自定义的 skill 默认可变，系统内置的关键 skill 默认不可变。

自我优化必须有”不可动的底线”，否则 agent 会在反馈循环里把自己优化成一个面目全非的东西。

---

六、agentskills.io：这不只是一个标准，是一个生态赌注

前面一直在说 “agentskills.io 标准”。这个标准到底是什么？为什么重大？

它是什么

agentskills.io 是一个开源的 skill 文件格式标准，定义了：

• SKILL.md 文件的 YAML frontmatter 必填字段
• 可选的扩展 metadata 字段（各 agent 框架可以自定义命名空间，如 metadata.hermes.*）
• Skill 之间的依赖声明方式
• 版本号规范
• License 声明

它不是某个公司的专有格式，而是由一群 agent 框架开发者共同维护的开放协议。

为什么有这个标准

想象一下当前的 agent 生态：

• Claude Code 有 CLAUDE.md
• Cursor 有 .cursorrules
• Cline 有它自己的格式
• OpenClaw 有它的 skill 格式
• Hermes 目前也要搞 skill

如果每个框架都搞一套自己的格式，会发生什么？

• 同一个人要在不同工具之间重复写同样的 skill（假设是”生产 bug 处理流程“）
• 社区贡献的 skill 库无法跨框架共享
• 没有统一的 skill 市场/搜索工具
• 生态碎片化，每个框架都变成孤岛

agentskills.io 的出现就是为了解决这个问题——一个 SKILL.md 文件，在任何支持这个标准的 agent 框架里都能运行。

Hermes 的赌注

Hermes 主动采用 agentskills.io 标准，并且公开标注自己的 skill 是 “adapted from obra/superpowers”——这是一个战略选择，不是技术选择。

Nous Research 在赌一件事：未来的 agent 生态会像 npm/pip 一样有一个中心化的 skill 分发机制。而 Hermes 通过支持标准格式，提前把自己放在了生态的中心节点位置。

如果赌赢了：

• 别人写的 skill 可以直接在 Hermes 上跑 → Hermes 的能力跟随整个社区的 skill 库增长
• Hermes 上优化出来的 skill 可以贡献回社区 → 别的框架反过来依赖 Hermes 的贡献
• Hermes 变成 skill 生态的默认引擎

如果赌输了：

• agentskills.io 没流行起来 → Hermes 支持了一个没人用的标准，多了一点工作量，没有坏处
• 但这种”没坏处”的赌注，开源项目最擅长

这是一种”no downside bet”——押赢了收益巨大，押输了也不伤元气。Hermes 押下了这个注。

---

七、25 个内置 Skill 类别的全景

Hermes 的内置 skills 在 skills/ 目录下分成 25 个顶层类别。我直接列今天 main 分支的真实目录（这才是 source of truth）:

软件工程线

• software-development — 软件开发方法论（systematic-debugging、TDD、code-review 等都在这里面）
• devops — 部署、CI/CD、监控
• mlops — ML 工程化
• github — Git/GitHub 工作流

研究与数据线

• research — 调研方法论
• data-science — 数据探索/建模
• note-taking — 笔记法

Agent 元能力线

• autonomous-ai-agents — 自主 agent 模式
• mcp — Model Context Protocol 集成
• red-teaming — 安全攻防

生活与生产力线

• productivity — 个人效率
• creative — 创作工具链
• media — 多媒体处理
• email — 邮件操作
• social-media — 社媒
• gifs — GIF 制作
• gaming — 游戏开发/调试

集成线

• apple — Apple 生态（Calendar、Notes、Mail）
• smart-home — 智能家居
• inference-sh — 推理服务集成
• yuanbao — 元宝集成
• diagramming — 流程图/架构图生成

特殊

• dogfood — Hermes 团队自己 dogfood 用的 skill
• domain — 领域专属
• index-cache — 索引缓存（系统类）

仓库里还有一个 optional-skills/ 目录——里面是可选安装的扩展 skills（区块链、健康管理、电话、Memento 等），不在默认 25 个内置里。

注意”skill-authoring”这一类的位置

许多读者会期待看到一个叫 skill-authoring（”怎么写 skill”的 skill）的顶层类别，由于它最有”元能力”美感。但今天的目录结构里这个能力是散落在 software-development、autonomous-ai-agents 等多个类别下的，没有自己的顶层目录。

这并不削弱”skill 自进化”机制本身——下一节会看到，Hermes 的 skill 自动生成不依赖某个具体的 “meta-skill”，而是直接由 _SKILL_REVIEW_PROMPT 在每轮对话后由 agent 自己评估、决策。真正的元能力嵌在 agent 的执行循环里，不是某个 skill 文件。

---

八、Skills vs CLAUDE.md vs Cursor Rules

这三个常常被混为一谈，但它们解决的问题完全不同。

维度	CLAUDE.md	Cursor Rules	Hermes Skills
触发方式	每次对话自动加载	每次对话自动加载	按需动态加载
粒度	项目级	项目级	任务级
数量限制	一般 1 个	一般 1 个	可以上百个
可复用性	单项目	单项目	跨项目跨用户
版本管理	Git	Git	内置
自动优化	无	无	有
标准化	无	无	agentskills.io

CLAUDE.md 和 Cursor Rules 本质上是”静态的上下文文件”——你一次写好，每次对话都加载进去，agent 不会自动更新它。

Hermes Skills 是”动态的能力库”——有按需加载、版本演进、自动优化、标准化共享。

一个比喻：CLAUDE.md 像是给 agent 看的 README，而 Skills 像是给 agent 用的 npm 依赖。

两者不是替代关系，而是不同层次的工具。实际上 Hermes 也支持 CLAUDE.md 格式的项目上下文（通过 hermes claw migrate 导入），但 CLAUDE.md 只是提供背景信息，真正的能力在 skills 里。

---

九、“grow with you” 的真正含义

回到系列开头提到的那句 slogan:The agent that grows with you。

读到这篇文章的第一段，你可能以为 “grow” 指的是记忆积累。但读到这里你应该清楚了：记忆积累只是”grow” 的一小部分。

真正的 “grow” 是能力的结构化演进：

• 第一周：你用 Hermes 处理了 10 个 bug，它从这些经验里提炼出一个初版的 “production-bug-handling” skill
• 第一个月：这个 skill 被调用了 30 次，agent 逐渐扩展了它的覆盖场景，版本从 1.0 演化到 1.5
• 第三个月：你的 Hermes 已经有了一套针对你的工作习惯和项目特点定制的 skill 库。同样一个 bug，它处理起来比第一天快 3 倍
• 第一年：你的 Hermes 的 skill 库有几十个独家技能——它知道你的代码风格、你的项目惯例、你处理问题的偏好、你的客户反馈规律

这就是”grow”的真正含义。不是”记住了更多实际”，而是”学会了更多怎么做事的方法“。

而且这个过程是累积的——skill 是文件，是版本，是可导出的。如果你换电脑、换环境、甚至换项目，你的 skill 库全部跟着你走。它们是你的数字资产。

类比：从工具到员工

一个不会演进的 AI 工具像一把锤子——用了一年还是一把锤子，不会由于”我用了许多次“就变得更好。

一个会 grow 的 AI agent 像一个员工——第一天新来的员工什么都不懂，一年后的员工已经懂你、懂业务、懂流程，离开的时候你会心痛，由于这个人带走了和你一起积累的所有默契。

Hermes 尝试做到的是**把这份”默契”**数字化、可导出、可版本化。

这是一个巨大的野心。

---

十、这篇的结论

Hermes 的 Skills 系统是我见过最野心勃勃的 agent 设计之一。它的核心创新有三个层次：

1. 底层：渐进式加载

用三层 Tier 设计把 skill 库的 token 成本从 100% 降到 6%，让”上百个 skills 并存”从不可能变成可能。这是工程层面的创新。

2. 中层：自动生成 + 自动优化

让 agent 从经验里自己写 skill，在使用中自己改 skill，同时通过严格的质量审核防止降质。这是机制层面的创新。

3. 顶层：agentskills.io 标准

通过采用开放标准，把 Hermes 放在了 agent 生态的中心节点位置，为未来的 skill 市场/共享机制提前占位。这是战略层面的创新。

这三层缺一不可：

• 没有渐进式加载 → skill 库永远不能做大
• 没有自动生成/优化 → agent 永远停留在出厂设置，不能”grow”
• 没有标准化 → skill 无法跨框架共享，每个 agent 都是孤岛

Hermes 同时做对了这三件事。这就是为什么我觉得它是 OpenClaw 之后最值得关注的开源 agent 框架。

不是由于它功能最多，而是由于它找到了一种 agent 持续进化的方式——而这种方式，是其他所有框架目前都还没有的。

---

下一篇预告

下一篇（也是本系列最后一篇）会拆解 Nous Research 的战略野心：

• 为什么是 agent 训 agent?
• Hermes 在 Nous Research 的整体产品矩阵里扮演什么角色？
• 数据飞轮是怎么转起来的？
• 开源模型要怎么在闭源巨头（OpenAI、Anthropic）的夹缝中突围？
• Hermes 是 Nous Research 的终局产品吗？

这一篇会跳出技术细节，讲战略和商业层面的判断。也会解释为什么 Nous Research 愿意把一个这么精心设计的系统完全开源——他们真正在下的棋是什么。

下篇见。

---

问题交流联系：AI 不止语
欢迎来聊 ✌️

---

致谢与延伸阅读：

@NousResearch（Hermes Agent 出品方）· @Teknium1 和 @karan4d（Nous Research 联创）· @obra（其 superpowers 项目是 Hermes 内置 skills 的上游来源，已 17 万 star）。

如果你读到这里觉得 _SKILL_REVIEW_PROMPT 这个机制有意思——它就在 run_agent.py 第 2927 行的 main 分支上，自己去验证。这才是这篇文章的重点。

cc @dotey @karminski3 ——这种”agent 自己写工作手册”的源码细节可能你们感兴趣。

#开源 #AIAgent #Hermes

---

本文源码分析基于 Hermes Agent v0.11.0（tag v2026.4.23，2026-04-23 发布）。文中所有代码片段均来自公开仓库 NousResearch/hermes-agent，核心引用文件：run_agent.py（搜 _SKILL_REVIEW_PROMPT）、agent/skill_utils.py、
agent/skill_preprocessing.py。skills/ 目录实测 25 个内置类别（详见第七节）。文中部分机制描述为基于源码可观察行为的合理结构化推断（“Tier 1/2/3”、”4 阶段流水线”等命名为本文抽象，非源码原话），具体实现以实际仓库为准。仓库热度数据截至 2026-04-29：114,688+ stars / 376+ contributors；obra/superpowers（被 Hermes 标注为 skill 来源）当前 170,000+ stars。