从一次任务到一次进化：完整拆解 Skill 创建、复用、修补链路

点击上方 前端Q关注公众号回复加群加入前端Q技术交流群写到这一篇第二章的拼图终于齐了。前面四篇我把 Hermes 的自学习系统拆成了 4 个零件Memory记知识、Skill记做法、Nudge Engine按下学习开关、Review Agent决定记什么。每个零件单独看都讲得清楚。但一个问题始终在心里 ——它们到底是怎么协同的一次任务从开始到结束再到下次任务时变得更聪明整个链路是怎么跑通的这一篇就把这个完整闭环串起来让你看到一次任务 一次进化到底是怎么发生的。完整闭环6 个阶段一气跑完我把 Hermes 一次任务的完整链路拆成 6 个阶段。每个阶段对应前面几篇讲过的某个零件。阶段 1接收任务用户提一个需求比如帮我把项目发布到 npm。这是闭环的起点。Agent 拿到需求但不会立刻动手 —— 它要先去看我之前是不是干过类似的事。阶段 2检索 Memory SkillAgent 先扫两个地方▸Memory当前项目和全局有哪些相关事实比如这个项目用 yarn 不用 npm▸Skill有没有现成的 SKILL.md 能直接照着做比如publish-to-npm.md如果命中了 Skill整个执行节奏会快很多 —— 模型不用从 0 推导步骤按手册执行就行。如果没命中模型就得自己一步步摸索。摸索出来的过程就是后面创建 Skill 的素材。阶段 3执行任务调工具、跑命令、多轮对话、拿结果。这一阶段是 Agent Loop 的本职工作。中间可能会走到一半失败、可能会问用户、可能会被用户打断纠正。所有这些事件都被记录下来组成任务轨迹session trace。阶段 4Nudge 触发任务结束时无论成功还是失败Nudge Engine 开始工作。它扫这一轮发生了什么▸任务成功了→ 中优先级触发▸任务失败了→ 高优先级触发▸用户中途纠正过→ 立刻触发▸已经是连续第 3 次相似任务→ 触发提炼 Skill满足条件的事件被打包成 Review 任务丢进后台队列。阶段 5Review 复盘后台异步跑的 Review Agent 拿到任务包过 4 步流程收集素材分类信息事实/偏好/流程/教训用 3 把尺子独有/重复/通用筛选决定写到 Memory 还是 Skill、新建还是 patch阶段 6写入 / Patch最后一步是真正落盘。新建 Memory 条目、新建 Skill 文件或者在已有的上面 patch 一段。版本号 1写入时间戳留下变更记录。到这里一次完整闭环就跑完了。金句闭环跑一次整个系统就稍微变强一点。下次类似任务再来的时候阶段 2 就不再是空跑—— 它会命中刚刚写入的 Memory 或 Skill直接复用。这就是进化具体发生的瞬间。一个真实例子同一个任务跑 3 次光看流程图还是抽象我用一个真实案例展开看。我自己在跑 Hermes 时连续做过 3 次类似的发布 npm 包任务。这 3 次的轨迹特别清楚地展示了自进化是什么。第 1 次首次发包12 步失败这是 Agent 第一次接到这个项目的发布任务。它没有任何 Skill 可用从 0 开始看 package.json看有没有 lint跑测试问我用什么版本号策略bump 版本号问我要不要写 changelog写 changelog... 一直到第 12 步 npm publish最后还是失败了 —— 它忘了在 publish 前 build。包发了但里面是空的。这一次最大的产出Review Agent 写了一个 Skill 0.1把这 12 步整理成了publish-to-npm.md并在踩坑笔记里强调了一定要先 build。第 2 次第二次发包9 步成功但有遗漏第二次任务来的时候Agent 命中了 Skill 0.1。它不再问我要不要 lint用什么版本策略这些事 —— 这些都在 Skill 里写清楚了。直接按手册执行跑 lint 测试buildbump 版本... 9 步搞定npm publish 成功但有个小遗漏 —— changelog 没写。Skill 0.1 里的 changelog 步骤写得太抽象模型不确定该不该跳过结果就跳过了。这一次最大的产出Review Agent 发现changelog 漏了是个明显的问题对 Skill 做了 patch升级到 0.2把 changelog 步骤具体化明确写出用 changesets 工具新增 minor 版本变更条目。第 3 次第三次发包6 步一次成功第三次任务Agent 命中了 Skill 0.2按手册一次跑通lint 测试buildbump 版本写 changeloggit tagnpm publish6 步没有任何中途确认没有任何遗漏。这一次最大的产出Skill 升级到 1.0稳定版本代表已经过 3 次以上完整验证。Review Agent 这一次没做大改动只是更新了成功复用次数计数。12 → 9 → 6。这就是自进化在数字层面最直观的体现。每一次任务Skill 都比上一次更准每一次复用Agent 的执行路径都比上一次更短。这不是模型变聪明了是系统积累的经验在帮模型省路径。数据是怎么在闭环里流转的讲完业务流程我再补一张工程视角的图 —— 数据在整个闭环里是怎么流转的。整个闭环里有 4 个数据容器每个容器有明确的写入方和读取方。容器 1Session Trace写入方Agent Loop执行型 Agent内容本次任务从开始到结束的所有事件这个 trace 是结构化的事件流不是纯文本。它至少记录▸用户的原始需求▸每一次工具调用的输入输出▸模型每一轮的回复▸用户的中途打断/纠正▸最终结果成功/失败/部分完成任务结束时这个 trace 被完整地交给下一个容器。容器 2Review Input写入方Nudge Engine内容Trace 用户反馈 触发原因Nudge Engine 不会把整个 Trace 原封不动地丢出去它会做一层打包▸标注本次触发的原因任务完成 / 失败 / 用户纠正 / 周期性▸附加用户的显式反馈如果有▸标注优先级高/中/低打包好之后丢进 Review 队列。容器 3Review Output写入方Review Agent内容要写哪些 / 写到哪 / 是 patch 还是新建Review Agent 不直接写文件它先输出一个结构化的写入计划yaml- target: memory.projectaction: appendcontent: 数据库是 PostgreSQL- target: skill.publish-to-npmaction: patchdiff: 在 step 3 后插入写 changelog这种先出计划再执行的设计有个好处 ——可以在写入前过一道安全检查。Hermes 里有个简单的 linter会检查这个写入计划有没有违反基本规则比如不要往全局 USER.md 里写项目特定信息。容器 4Memory Skill 文件写入方Memory Store内容MEMORY.md / SKILL.md / USER.md最后一步是真正的落盘。Memory Store 拿到 Review Output按计划修改文件▸append追加新条目▸patch修改已有内容▸new创建新文件写入时还会做几件事▸自动加时间戳和来源标注▸自动版本 1▸写入变更日志让你以后能看到这条是什么时候、因为什么写进来的到这里整个数据流跑完。下一次任务从 Memory Skill 文件出发再次跑完整个闭环。金句数据有节制地流系统才不会膨胀。每个容器都做了过滤、打包、转换的工作。如果中间任何一层全量直通整个系统很快就会被噪音淹没。这个分层节流的设计是 Hermes 在工程上最值钱的一处。怎么判断你的 Agent 真的在进化闭环跑起来之后你可能会问怎么知道它真的在变强我自己跑了一段时间总结了 5 个观察指标可以帮你判断闭环是不是在健康运转。指标 1Skill 命中率新任务里能命中已有 Skill 的比例。健康值 40%低于 40% 说明你的 Skill 库太薄绝大多数任务还是从 0 摸索高于 70% 也要警惕可能是过度抽象命中了但没准头。指标 2任务平均步数同类任务的平均执行步数。健康趋势随时间下降像前面那个发包例子12 → 9 → 6。如果你跑了一个月发现平均步数没变闭环大概率是断的要么 Skill 没写、要么 Skill 没被命中。指标 3失败重复率同一类失败连续出现的次数。健康值不超过 3 次任何一类失败最多踩 3 次坑就该被记进 Skill 的踩坑笔记。如果第 4 次还在重复说明 Review Agent 没识别出来或者 Skill 写完了但没被命中。指标 4用户纠正频率同样的事用户被迫反复纠正的次数。健康趋势随时间下降如果你已经跟 Agent 说过 5 次路径用绝对路径它还是用相对路径要么 USER.md 没写进去要么写进去了但 prompt 里没读出来。这是闭环里最容易断的一环。指标 5Skill 写入率每周新增 Skill 的数量。健康趋势前期上升后期趋于平稳patch 多于新建如果一个项目跑了 3 个月每周还在新增大量 Skill说明系统没收敛 —— 要么是 Review Agent 抽象做得不够要么是任务种类还在大量扩张。5 个指标都向好 真的在进化。任何一个长期不动 闭环某一节断了。我自己用下来的几个观察跑完整个闭环一段时间我对自进化这件事有几个不一样的体感。观察 1进化不是线性的是阶段性跃迁我以为 Agent 会每天进步一点点实际不是。更多时候是跑了 5 天没什么明显变化第 6 天突然发现诶它今天怎么这么顺。这种跃迁通常是因为某个高频 Skill 终于稳定下来让一类任务从每次摸索变成了一键执行。观察 2失败信号驱动的进化最明显复盘成功任务写出来的 Skill 大多是优化省 1~2 步。复盘失败任务写出来的 Skill 往往是质变避开整类陷阱。所以别怕 Agent 失败怕的是它失败了你没让它复盘。观察 3闭环里最弱的环节是检索写入做得再好如果检索阶段命不中那一切白搭。Skill 写出来了但用户提需求的措辞稍微变一点Skill 就被漏过 —— 然后 Agent 又从 0 摸索一遍。我现在调闭环时第一个看的就是 Skill 的 trigger 设计是不是足够覆盖各种说法。观察 4每周抽 10 分钟人工 review完全自动化的闭环最大的问题是你不知道它学歪了。我每周固定花 10 分钟扫一遍.hermes/memory/和.hermes/skills/▸删掉拟人化的偏好▸删掉过度抽象的 Skill▸把太啰嗦的条目精简▸把没用过的 Skill 归档这 10 分钟人工反馈是闭环长期健康的关键。完全无人值守的自进化系统目前还做不到更现实的是高度自动 极少人工的协同模式。我的看法写完这一章我对自进化 Agent这个词有了更立体的认识。它不是一个魔法概念是一套有节制的工程闭环。每一个零件单看都不复杂▸Memory 是个 markdown 文件▸Skill 是个带步骤的菜谱▸Nudge 是个事件总线▸Review 是个独立的判断 Agent但把它们按接收 → 检索 → 执行 → 触发 → 复盘 → 写入这个顺序串起来再加上层层过滤和节流就形成了一个能持续学习的系统。我觉得这套设计最值钱的地方有 3 点分层解耦每个零件只关心自己的事不互相耦合多重过滤Nudge 过一次、Review 过一次、Linter 过一次让噪音很难钻进 Memory / Skill可观测5 个指标随时能告诉你闭环健不健康这 3 点恰好也是个人玩具 Agent和组织级 Agent的分水岭。第二章我们讲的还是个人 Agent 的自进化。但当你想把这套机制放进团队、放进公司、放进多人协作的研发流程时会冒出一系列新问题▸多人共用一个 Skill 库谁的写入算数▸Skill 改坏了怎么回滚▸怎么在不同环境之间灰度发布 Skill▸一个 Skill 上线之前要不要先评估这些就是第四章要回答的问题 ——从个人 Agent 到企业级 Skill Hub 的工程化跨越。第三章我们会先继续深挖 Hermes 的源码架构把 Agent Loop、Prompt Assembly、MemoryStore、Skill Manager 这些底层细节一一打开。读完之后再去看第四章的企业级设计会有完全不一样的体感。下一篇见。往期推荐Multi-Agent Teams让多个专家 Agent 像团队一样协作AI Agent 是怎么想一步做一步的拆解 ReAct 模式从零开始用 LangChain.js 构建你的第一个 Tool-Calling Agent最后点个在看支持我吧