Agent 自己写 Skills：拆解 hermes 的技能自学习闭环

上一节你学会了手写 SKILL.md。手写有个天花板:你能写出来的技能,上限是你想得到、肯坐下来写的那些。可有些"套路"是 Agent 在干活过程中才摸出来的——它连着三次成功修好同一类报错,那套修法你压根没意识到要写下来,Agent 自己倒是门儿清。

于是有了 Skills 的最高形态:Agent 自己生产 Skills。它干完一类复杂任务,自动把那套做法抽象成一个 SKILL.md 存进技能库;下次遇到同类活,直接 /<技能名> 调出来用。经验不再随会话结束而蒸发,而是沉淀成可复用的资产——越用越强。 这一节我们拆解开源项目 hermes-agent 的这套自学习闭环,再教你把同样的思路搬到自己的 Agent 上。

这篇适合谁:已经会手写技能、想让 Agent 自己积累技能的人。读完你会有一套"完成任务 → 提炼步骤 → 写成 SKILL.md → 入库 → 下次自动调用"的可落地闭环,以及一份关于"自动写的技能靠不靠谱"的清醒判断。

---

钩子:为什么"自己写技能"是质变

设想两个 Agent。

第一个,每次你让它部署服务,它都从零摸索一遍:哪个脚本、什么顺序、踩哪些坑。第十次和第一次一样笨。

第二个,第三次成功部署后,它默默把这套流程写成了一个技能 deploy-service 存进库里。第四次你只说"部署一下",它直接调出那套已验证的流程,稳、准、快。

差别不在模型聪不聪明,在于第二个 Agent 会"沉淀经验"。这正是 hermes 设计里最让人眼前一亮的地方——它把"做过的事"变成"会做的本事"。

---

拆解 hermes 的技能自学习闭环

在 文件即记忆那一节 我们讲过 hermes 的记忆是三层叠加。技能是其中的第二层:介于"永远在场的核心记忆"和"按需翻的海量历史"之间,存的是"会做某类活的本事"。

它的运作是这样的(细节以 hermes 官方文档为准):

• 存哪儿:每个技能一个文件夹,放在 ~/.hermes/skills/ 下,里面是一个 SKILL.md,描述"何时用、怎么做"——和你上一节手写的那个,结构完全一样。
• 谁来写:不是你,是 Agent 自己。当它几次成功完成同一类任务之后,会把那套做法自动抽象成一个 SKILL.md 沉淀下来。
• 怎么调:下次遇到同类任务,它自动调用对应技能(在 hermes 里也能用 /<skill-name> 显式点名调起)。

把这条链路接起来,就是一个经验 → 可复用技能的闭环:

干完一类复杂任务
      │
      ▼
识别"这是一类会重复的活"
      │
      ▼
把刚才的做法抽象成步骤
      │
      ▼
写成 SKILL.md(name/description/正文)→ 存进技能库
      │
      ▼
下次同类任务命中 description → 自动调用 → 又快又稳
      │
      └──────────► 用多了还能回头精炼这个技能（越用越准）

注意闭环里那条回流的虚线:技能不是写一次就定死,用过几轮、发现哪步不对,还能回头改。这才叫"越用越强"——不只是"积累得多",而是"积累得越来越准"。

---

这套闭环怎么设计:四个关键决策

想自己复刻,得想清楚四件事。hermes 的取舍可以直接抄:

1. 什么时候触发"写技能"? 不是干一次就写——干一次还看不出是不是"一类会重复的活"。hermes 的做法是几次成功完成同类任务后才沉淀。这个门槛很关键:太低了会写一堆用一次就废的垃圾技能,太高了又错过沉淀时机。

2. 抽象到什么粒度? 写技能不是把那次对话原样存下来(那是记忆第三层 FTS5 干的事)。要抽掉一次性的细节(这次的具体文件名、具体数值),留下可复用的方法骨架(步骤顺序、判断条件、易踩的坑)。粒度对了,技能才能套到下次不同的输入上。

3. 怎么保证下次能被想起来? 全靠那行 description——和你上一节手写时一样,它决定技能何时触发。Agent 自己写 description 时,最容易写糊,这是后面避坑的重点。

4. 写完放哪、怎么调? 入库到技能目录(hermes 是 ~/.hermes/skills/),靠渐进式披露——元数据常驻、命中才加载正文。所以自动攒一堆技能也不撑爆上下文,这点和手写技能完全共用同一套机制。

---

把这套思路用到你自己的 Agent

你不一定要用 hermes,这套闭环自己几十行就能搭出最小版本。核心就一个"反思 → 写技能"的步骤,挂在任务完成之后。

from pathlib import Path

SKILLS_DIR = Path.home() / ".myagent" / "skills"
SKILLS_DIR.mkdir(parents=True, exist_ok=True)

REFLECT_PROMPT = """刚才这个任务你完成了。判断:这是不是一类"以后还会重复"的活?
- 如果是一次性的、不会再遇到的,只回复 NO。
- 如果是会重复的,把做法抽象成可复用的技能,抽掉本次的具体细节,
  按下面格式输出一个 SKILL.md(name 用小写连字符;description 写清"何时用";
  正文写可执行步骤):
---
name: ...
description: 当用户……时使用。……
---
# ...
## 步骤
1. ...
"""

def maybe_distill_skill(task_transcript: str, llm) -> str | None:
    """任务完成后调一次:让模型判断要不要沉淀技能,并产出 SKILL.md"""
    out = llm(REFLECT_PROMPT + "\n\n[本次任务记录]\n" + task_transcript).strip()
    if out == "NO" or not out.startswith("---"):
        return None
    name = extract_name(out)          # 从 frontmatter 解析 name
    skill_dir = SKILLS_DIR / name
    if skill_dir.exists():
        return None                   # 已存在就不重复写(避免技能堆积重复)
    skill_dir.mkdir()
    (skill_dir / "SKILL.md").write_text(out, encoding="utf-8")
    return name

# 用法:一个任务跑完后
new_skill = maybe_distill_skill(transcript, llm)
if new_skill:
    print(f"沉淀出新技能:{new_skill},下次同类任务可自动调用")

下次开会话时,照 手写 SKILL.md 那一节 讲的渐进式披露,把技能目录里每个 SKILL.md 的 name+description 读进元数据层,命中再加载正文——自动攒的技能,和手写的走的是同一条加载链路。

想做得更像 hermes,可以加一个"成功计数器":同类任务成功 N 次才触发 maybe_distill_skill,而不是每次都写。再加一个去重/合并步骤,避免攒出十个名字不同、内容雷同的技能。

---

避坑:自动写的技能,质量靠不靠谱?

这是最该泼的冷水。让 Agent 自己写技能很性感,但自动产出的东西,质量天然参差。下面这些坑,几乎人人会踩:

• 写出一堆用一次就废的"垃圾技能"。如果触发门槛太低,Agent 会把每件做过的事都沉淀成技能,库里很快塞满"只在那一次的特定场景下成立"的伪技能。破法:提高触发门槛(成功 N 次才写),并定期清理用了一两次就再没命中的。
• 技能重复、互相打架。Agent 这次写了 deploy,下次又写了 deploy-service,两个内容八成重叠,触发时还抢。破法:写之前先查库里有没有近义技能,有就走"精炼旧的"而不是"新建一个"。
• 自动写的 description 写糊,该触发不触发。这是手写时就最容易出错的地方,交给 Agent 自动写更难保证。破法:在反思 prompt 里专门强调 description 要写"何时用"+ 同义说法,并把它当作重点抽审项。
• 抽象粒度不对,套不到下次。Agent 容易把这次的具体细节(文件名、数值)硬写进技能,导致下次输入一变就失效。破法:反思 prompt 里明确要求"抽掉一次性细节,只留方法骨架"。
• 越攒越多,没人管。自动沉淀最大的风险是无人治理——半年后库里几百个技能,一半是垃圾。破法:把技能库当代码库管,有"准入"也有"淘汰"。

那要不要人工审? 务实的答案:自动沉淀 + 人工抽审。让 Agent 自动产出(省你手写的力气),但新技能进库后,你定期抽几个看一眼——尤其看 description 准不准、步骤是不是真可复用。把"全自动信任"和"全手写"之间那条中间路走稳,才是当下最靠谱的做法。

---

避坑表

坑	后果	怎么破
干一次就写技能	库里全是用一次就废的伪技能	设触发门槛:同类任务成功 N 次才沉淀
不查重就新建	攒出多个雷同、互相抢触发的技能	写前先搜近义技能,有则精炼旧的
自动写的 description 太泛	该触发不触发,技能白攒	反思 prompt 强调"写何时用+同义说法",并抽审
抽象粒度太细,写死本次细节	下次输入一变就失效	要求"抽掉一次性细节,只留方法骨架"
自动沉淀但无人治理	半年后一库垃圾,信噪比崩塌	当代码库管:自动产出 + 人工抽审 + 定期淘汰
以为全自动就能撒手	质量参差还没人发现	走中间路:自动沉淀 + 人工抽审 description 与可复用性

---

动手挑战

1. 给你现有的 Agent 加一个"任务完成后反思"的步骤:跑完一个任务,让模型判断"这是不是会重复的活",是就吐出一个 SKILL.md。先只打印不入库,看它抽象得对不对。
2. 加上入库逻辑和查重(已存在同名就不写),让它真能自动沉淀技能。连续做三遍同类任务,看它第几次开始沉淀、沉淀出来的技能质量如何。
3. 进阶:加一个"成功计数器",同类任务成功 3 次才触发沉淀;再加一个"精炼"路径——发现近义技能就改旧的而不是新建,亲手把"越用越准"那条回流虚线接上。
4. 反思题:把自动写出的三个技能,逐个用上一节的"好 description 清单"打分。你会发现 Agent 自动写的 description 普遍偏泛——这就是为什么需要人工抽审。

---

小结 · 你现在掌握了什么

• 你看懂了 Skills 的最高形态:Agent 自己把成功经验抽象成 SKILL.md 存进技能库,下次同类任务自动调用,越用越强。
• 你拆解了 hermes 的自学习闭环:几次成功后沉淀、存 ~/.hermes/skills/、靠 description 触发、用 /<skill-name> 也能显式调——技能是它"文件即记忆"三层里的中间层。
• 你拿到了一份最小实现思路:任务完成后反思 → 判断是否可复用 → 抽象成 SKILL.md → 查重入库 → 下次自动调用,和手写技能共用渐进式披露的加载链路。
• 你清醒地知道自动写的技能质量参差,该走"自动沉淀 + 人工抽审"的中间路,而不是全自动撒手。

hermes 的字段、目录与触发细节以官方文档为准;但"经验沉淀成可复用技能"这条思路,是任何 Agent 都能借鉴的方向。

下一步:你已经走完了技能这条线——从分清 Skills 与 MCP、手写 SKILL.md,到让 Agent 自己产出技能。再往后是多 Agent 协作与编排。看 AI Agent 智能体阶梯 的后段;想看整条路的位置就对照 三支柱路线图。

👉 看看 AI 数字员工落地指南,或了解 数字员工搭建实战课。需要为企业落地方案,欢迎找我们聊 企业服务。