点击上方 前端Q关注公众号回复加群加入前端Q技术交流群我研究 Hermes Agent 的时候最让我哦~原来是这样的不是 Memory而是 Skill 系统。Memory 解决的是我记得这件事是这样。Skill 解决的是我知道这件事该怎么做。听起来差不多工程上完全是两个东西。前者偏知识查询后者偏过程复用。Hermes Agent 之所以能越用越快靠的不是 Memory 越来越多而是 Skill 越攒越准。这一篇就专门讲 Skill 系统。先把概念分清楚聊 Skill 之前先把它和 Memory 拉开距离。我看过太多人混着用最后越聊越糊。Memory 是陈述性记忆你知道什么。它回答的是事实型问题▸用户喜欢用 TypeScript▸数据库是 PostgreSQL▸项目用 monorepo 结构Memory 写出来更像便签是离散的事实。Skill 是过程性记忆你怎么做。它回答的是流程型问题▸怎么发布到 npm▸怎么排查内存泄漏▸怎么写 changelogSkill 写出来更像菜谱是带顺序的步骤。我自己学认知心理学时老师讲过一句话挺贴切会做事比知道事更值钱。人能写出一份菜谱跟人真的会炒菜是两回事。Skill 做的就是后者。为什么不能只用 Memory可能你会想那我把发布 npm 包的 5 个步骤也塞进 Memory不就行了短期看是行的但跑长了一定爆。我自己实验过主要踩三个坑。坑 1Memory 是给理解用的不是给执行用的Memory 的查询路径默认是先把所有相关 Memory 注入 Prompt让模型看完再说话。但执行型任务不是说话是动手。Agent 真正需要的是打开手册第 3 步、做完打勾、出错回到第 2 步。把流程塞 Memory 里模型很容易跳步、合并步、漏一步。我的经验是任何超过 3 步的事情都会出问题。坑 2Memory 没办法版本化发布流程会变。今天用 npm明天换 pnpm后天加上 changesets。Memory 是离散事实的合集没人知道上次的发布步骤和今天的发布步骤有什么差。一改要么全删要么全留没有中间态。Skill 是文件天然可以打版本号、做 patch、回滚到上一版。坑 3Memory 之间没有依赖关系复杂任务往往是多个流程互相调用。发布 npm 包里要先跑测试、写 changelog、打 tag。Memory 是平的没办法表达做 A 之前先做 B。Skill 不一样它本身就是带步骤的文档自然可以引用其他 Skill。Hermes 里很多 Skill 顶部都有depends_on: [run-tests, write-changelog]这种声明。这三个坑加起来就是一句话陈述性知识和过程性知识必须分开存。一个 SKILL.md 长什么样讲清楚边界再来看 Skill 的物理形态。Hermes 里 Skill 就是一个普通的 markdown 文件存在.hermes/skills/目录下。一个项目一个 Skill 库结构清爽text.hermes/skills/publish-to-npm.mddebug-memory-leak.mdwrite-changelog.mdrollback-deploy.md每个文件里大致 5 个区块。我把每一块的设计意图说一下因为这个结构不是随便定的每条都有讲究。第 1 块元信息yamlname: 发布 npm 包trigger: 用户说 发布 或 上线version: 1.2trigger是关键字段。Hermes 在用户提需求时会先扫所有 Skill 的 trigger看哪个匹配。为什么不用纯语义匹配因为太贵也太慢。先用 trigger 关键字粗筛 → 再用语义补一刀这是工程上的折中。第 2 块适用场景写明哪些场景能用、哪些场景不能用。很多人省略这块结果踩坑一个monorepo 发布脚本被用到了单仓库项目上命令全错。适用场景写清楚能省掉至少一半的误用。第 3 块步骤清单带数字编号的真正流程text1. 跑 lint 测试2. bump 版本号3. 写 changelog4. npm publish这部分越具体越好。能贴命令就贴命令能写参数就写参数。模糊的做相关检查基本等于没写。第 4 块容易踩的坑这是 Hermes 设计里最妙的一块。不是写正确做法而是写上次错在哪。比如忘记 build发到了错误的 tag。为什么这个有用因为模型在执行时会专门看这一段相当于一个反向的 checklist。它会主动避开你之前掉进去的坑。第 5 块校验方式每一步做完怎么验证或者整个流程跑完怎么知道成了textnpm view pkg version 是否更新没有校验就没办法判断这次跑得对不对。后面 Review Agent 给 Skill 打分时也要靠这个。Skill 是怎么被找到、用起来的写好了 Skill接下来才是有意思的Agent 怎么知道现在该用哪个 Skill这是检索问题。Hermes 的做法没那么玄4 步搞定。第 1 步用户提需求帮我把项目发布到 npm。这是自然语言模型还没开始动。第 2 步Skill 索引匹配Hermes 会读.hermes/skills/下所有文件的元信息不是全文省 token。匹配逻辑分两层▸关键字匹配用户说了发布命中所有带这个 trigger 的 Skill▸语义补充再用模型对剩下的做一轮语义打分我看过这块的实现trigger 关键字命中的会被加权语义打分只是 tie-breaker。这样既快又准。第 3 步命中候选 Skill通常会拿到 1~3 个候选。如果只有一个就直接用多个会让模型看一眼标题和适用场景做选择。我做实验时发现这一步偶尔会出错 ——比如同时有发布到 npm和发布到 GitHub Release模型会卡一下。这种时候就靠 trigger 写得够区分。第 4 步注入到 Prompt选定的 Skill 会被作为执行手册注入到当前任务的 system prompt。注意是注入完整的 Skill 文件不是摘要。因为执行时漏一步就崩必须给完整步骤。这一步也是为什么 Skill 文件要控制长度。一个 Skill 太长超过 2000 token就会挤掉其他上下文。Hermes 里有个隐形规则单个 Skill 控制在 800~1500 token太长就拆。金句找不到才创建找到就复用。这是整个 Skill 系统最朴素的哲学。Agent 不会一上来就生成新 Skill永远是先找现成的。Skill 不是只创建更重要的是修补很多人理解 Skill 系统时停留在AI 自己写 markdown。但 Hermes 真正聪明的地方是它不是只写一次而是会反复修补。举个例子。你第一次让 Hermes 发布 npm 包它跑出来的步骤可能是text1. 跑测试2. bump 版本3. npm publish跑成了写进 SKILL.md。第二次跑的时候发现包发了但 changelog 没更新。Review Agent 复盘后会做一件事修补这个 Skill。Skill 文件会变成text1. 跑测试2. bump 版本3. 写 changelog ← 新增步骤4. npm publish注意不是重新生成一个新 Skill是在原文件上 patch。这是关键区别。为什么是 patch 不是重写▸重写会丢历史经验之前的容易踩的坑段落▸重写没办法增量评估新版本相比老版本到底好了多少▸重写让版本号失去意义Hermes 里 Skill 的修改是带 diff 的。每次 patch 都会留下改了什么、为什么改的记录。这个机制在第四章 Skill Hub 里会变成更复杂的评估、灰度、回滚先记住这个原型。一个 Skill 的一生5 个阶段Skill 不是写完就完事它有完整生命周期。Hermes 里大致分 5 个阶段。Created新建第一次任务跑通后Review Agent 复盘出来的初版 Skill。这个时候它还很嫩没经过多次验证。Used被复用被检索到、被注入 prompt、被 Agent 执行。每一次复用都是一次实战检验。Patched修补执行中发现遗漏或错误复盘后增补步骤、修正坑位说明。版本号 1。Aged沉淀多次成功复用后这个 Skill 就成了成熟资产。Hermes 内部对成熟 Skill 会提升信任度比如允许跳过部分人工确认。Retired退役工具栈过时了比如从 npm 切到 jsr、流程不再适用了Skill 会被归档而不是删除。归档的 Skill 不参与匹配但还能查历史。为什么不是直接删除因为 Skill 携带了大量经验,哪怕过时了里面上次踩的坑依然有参考价值。整个生命周期就一句话越用越准过期就退。我自己用下来的几个建议写完 Skill 系统的源码导读后我总结了 5 条实操经验。建议 1Skill 写得越具体越好模糊的 Skill 等于没写。做相关检查模型自己脑补每次脑补都不一样。我现在写 Skill 的标准是步骤里能贴命令就贴命令能写参数就写参数能附校验就附校验。建议 2trigger 关键字要选区分度高的别用发布这种太通用的词。发布 npm 包发布 GitHub Release发布到生产环境每一个都该有自己专属的 trigger。不然检索阶段就会撞撞了模型就纠结。建议 3定期清理 .hermes/skills/我每个月会扫一次把那些半年没用过、明显过时的 Skill 归档。Skill 库膨胀的成本不是磁盘是检索时的噪音。10 个 Skill 模型能选对100 个就开始飘。建议 4Skill 写人能看懂的话很多人喜欢让 Skill 看起来机器味全是 yaml 和 schema。我的经验恰好相反Skill 是给人也是给 AI 看的。哪天你需要手动调写得越像菜谱越容易上手。建议 5别一上来追求自动 Skill很多人接 Hermes 第一天就想让它自动生成所有 Skill。我建议反过来前 5 个 Skill 自己手写。这样你能感受到一个好 Skill 长什么样后面让 Review Agent 写的时候也知道怎么挑、怎么改。我的看法我研究完 Skill 系统最大的感受是 ——Skill 才是自进化 Agent真正的资产层。Memory 解决的是懂背景但背景知识每个项目都要从头积累。Skill 解决的是会做事而做事的方式可以跨项目、跨团队、跨人复用。一个写好的发布流程 Skill新人入职那天就能用根本不用问老员工。这才是 Agent 真正能放进组织里的关键能力。它不再是某个开发者的私人助手而是能沉淀团队 know-how 的载体。这也解释了为什么后面第四章会重点讲企业级 Skill Hub。当 Skill 从个人 markdown升级成组织资产时就需要版本管理、质量评估、灰度发布、回滚机制 —— 这些都是工程系统该解决的事不能靠人手 git。Hermes 在单机版本里已经把骨架搭好了版本号、patch、生命周期。剩下的是把它放大到组织层面那是后面 16~25 篇要解决的事。下一篇我们聊 Nudge Engine ——Hermes 是怎么主动触发学习时刻的因为 Skill 不会自己冒出来得有人按下该复盘了那个按钮。往期推荐Multi-Agent Teams让多个专家 Agent 像团队一样协作AI Agent 是怎么想一步做一步的拆解 ReAct 模式从零开始用 LangChain.js 构建你的第一个 Tool-Calling Agent最后点个在看支持我吧
