Hermes Agent Skill Runtime 架构拆解：让 AI Agent 不再从零开始
拆解 Hermes 如何把执行轨迹沉淀为技能、记忆和自修复闭环，让 Agent 真正积累经验。
原文链接：AI 小老六
导语
很多 Agent 产品有一个尴尬的问题：它们看起来每天都在工作，实际上每天都从零开始。
用户让它处理第 1 个复杂任务时，它会试错；第 20 次遇到类似任务时，它还在试错；到了第 50 次，最多只是这次上下文里显得熟练一些。对话一结束，经验就跟着蒸发。所谓"我记住了"，经常只是当前 session 里的礼貌回应。
这不是单纯换一个更强模型就能解决的问题。模型权重不会因为一次工具调用失败而更新，普通上下文也没有跨任务的经验沉淀能力。Agent 真正缺的是一套运行时机制：能把执行轨迹留下来，把反复出现的步骤写成技能，把错误修进工作流，再定期清理已经过期的知识。
Hermes Agent Runtime值得关注，原因就在这里。它不是把 Agent 包装成一个更会聊天的壳，而是把"经验如何进入系统"这件事做成了运行时能力。它通过模型无关的执行框架接入不同 LLM，同时在外部维护技能库、记忆层和整理流程。换句话说，模型还是那个模型，但系统会在任务中留下可复用的工程痕迹。
下面不谈概念口号，直接拆它的几个关键设计：技能如何长出来，运行时如何修补，记忆为什么要分层，Prompt 为什么能靠自然语言诊断进化，以及这些机制在工程上最容易坏在哪里。
图：Agent 从一次性执行走向可复用经验资产
Agent 不会自然变聪明，除非经验能落盘
一个 Agent 要想在第 50 次任务后比第 1 次更可靠，至少要满足三个条件。
第一，系统要知道一次任务到底发生了什么。只保存最终回答没有用，工具调用顺序、错误消息、中间状态、用户反馈都要能被还原。
第二，系统要能判断这次经历是不是可复用。一次偶然的绕路不该被固化成规则；反复出现的流程、错误和约束才值得沉淀。
第三，沉淀出来的东西必须能被下次任务检索到，并以足够具体的形式指导行动。泛泛一句"以后注意参数校验"没有执行力，写清楚触发条件、检查步骤和失败回退才有用。
Hermes 的自进化闭环大致围绕这三件事展开：
图：任务轨迹经过筛选、技能化、执行反馈与空闲整理形成闭环
这条链路里最重要的不是"会生成文档"，而是经验从一次性的上下文变成了外部资产。Agent 的能力增长不发生在模型权重里，而发生在运行时周边的知识系统里。
技能生成：只沉淀复杂工作流，不把每次操作都写进手册
Hermes 会在复杂任务完成后自动提炼技能。一个典型门槛是任务中发生了 5 次以上工具调用。这个阈值看起来朴素，但很有工程意味：单步查询、简单改字、一次 API 调用，没必要变成技能；真正值得留下的是多步骤、可复现、容易踩坑的工作流。
生成出来的技能不是一句摘要，而是一个可执行的SKILL.md。它通常包含适用场景、前置条件、操作步骤、常见错误和校验方式。这样的文件会进入~/.hermes/skills/，以后再遇到相近任务时由路由逻辑检索出来。
这里有个容易被忽略的点：技能应该围绕目标组织，而不是围绕工具组织。
如果一个技能写成"如何使用某个 CLI"，它的复用范围很窄，工具一换就失效。更好的写法是"如何完成某类发布流程"、“如何处理某类数据迁移”、“如何给某类文档做结构化改写”。工具只是流程的一部分，不应该成为技能的中心。
| 技能组织方式 | 看起来像什么 | 长期问题 |
|---|---|---|
| 工具中心 | 如何使用工具 X 的 A/B/C 参数 | 工具变化后大面积失效 |
| 任务中心 | 如何完成一次端到端交付 | 更容易迁移到新工具 |
| 约束中心 | 在权限、格式、验收条件下如何执行 | 能减少重复踩坑 |
| 证据中心 | 每一步如何验证结果 | 方便后续自修复 |
Hermes 后续的Curator整理也会处理这类问题：太窄、太像工具说明的技能会被合并、降级或归档。一个健康的技能库不应该像命令手册，更应该像一组被验证过的工作流。
运行时自修复：技能不是只读文档，而是会被执行结果反向修改
很多系统也会保存经验，但它们把经验当成静态材料。Hermes 更激进的地方是：技能在使用中可以被修。
当 Agent 按某个SKILL.md执行任务时，如果发现步骤描述和真实环境不一致，比如参数名变了、API 返回结构调整了、某个前置检查不充分，它会尝试定位技能文件里的相关段落，再做局部修补。这里用的是模糊查找替换，而不是必须精确命中原字符串。原因很现实：技能文件可能已经被多次编辑，文本不一定还能和旧版本完全对齐。
这种设计解决了一个问题，也制造了一个风险。
解决的问题是，技能库可以跟着真实执行环境走。工具升级、接口变更、流程补丁，不必全部等人工统一维护。
风险是，技能可能在多次小修小补后变形。一个本来清晰的工作流，被局部修复打上太多补丁，最后会变成只有当前场景能跑的脆弱脚本。
所以 Hermes 需要第三个角色：Curator。它不在任务执行时抢上下文，而是在空闲期整理技能库。
Curator：把"使用中增长"和"空闲时整理"分开
自动生成技能和运行时修补都发生在任务现场。它们追求的是立即有用。Curator 的目标不一样，它处理的是长期健康。
Hermes 的整理逻辑通常在 Agent 空闲时触发，比如一段时间无人使用后 fork 出一个独立进程巡检技能库。它要做的不是再执行一个用户任务，而是检查技能之间的关系：哪些技能过窄，哪些内容重复，哪些已经很久没人用，哪些看起来像同一类任务的多个变体。
可以把三类机制放在同一张图里看：
图：任务中增长技能，空闲时治理技能库拓扑
这个节奏很关键。任务中做增长，空闲时做治理。否则两件事会互相干扰：执行任务时忙着整理历史，浪费上下文；长期不整理，又会让技能库越来越臃肿。
Hermes 里还有类似 Nudge 的后台机制：定期从近期对话里蒸馏记忆，定期评估技能是否出现腐化信号。它们不直接改变模型，但会改变模型下次能看到什么材料。
三阶段循环：收集轨迹、做对比反思、把更新部署出去
把 Hermes 放到更大的 Agent 研究脉络里看，它和 Reflexion、Voyager、Memento-Skills 这类系统共享一个基本循环：
图：经验收集、反思提炼与更新部署构成持续迭代循环
经验收集不是随便记日志。要记录的是有行为含义的结构：输入是什么，工具怎么调，哪里报错，模型中间做了什么判断，最终结果有没有通过验证。没有结构的日志只是存储成本，不是经验。
反思提炼也不应该只是让模型总结"我学到了什么"。更有效的是对比反思：把成功轨迹和失败轨迹放在一起，让模型解释为什么 A 跑通、B 失败。单看失败很容易得到空泛教训，对比之后才容易定位到真正的差异变量。
更新部署则必须走门控。Hermes 的技能写入、模糊替换、整理归档都不应该绕过审查直接进入主线。成熟一点的做法是走 Git 分支和 PR，让自动演化产物留下可回滚记录。自进化不是让系统随便改自己，而是让系统提出变更，并接受独立验证。
这个循环还发生在不同时间尺度上：
| 层级 | 时间尺度 | 处理的问题 | 典型动作 |
|---|---|---|---|
| 战术层 | 秒到分钟 | 当前任务失败了怎么办 | 诊断错误，修补技能步骤 |
| 行为层 | 小时到天 | 最近反复出现什么模式 | 从多轮对话蒸馏记忆 |
| 拓扑层 | 天到周 | 技能库结构是否健康 | 合并、归档、重命名、拆分 |
这三层不能混在一起。当前 bug 要快修，行为模式要攒够证据再提炼，技能拓扑更需要后见之明。
记忆分层：上下文、经历、知识和技能不是一类东西
很多 Agent 系统一谈记忆就容易混成一坨：聊天记录是记忆，用户偏好是记忆，工具调用也是记忆，技能文件还是记忆。结果就是检索噪声大、更新边界乱、过期信息很难清理。
Hermes 更接近一种分层做法。不同记忆的生命周期、访问方式和晋升条件都不同。
| 层级 | 放什么 | 生命周期 | 主要用途 |
|---|---|---|---|
| L1 工作记忆 | 当前对话、工具调用、中间结果 | 单次 session | 支撑当前任务推理 |
| L2 情节记忆 | 跨会话经历、失败案例、用户反馈 | 多次 session | 让 Agent 想起过去发生过什么 |
| L3 结构化知识 | 经验证的规则、偏好、项目约束 | 中长期 | 给任务提供稳定背景 |
| L4 程序性技能 | SKILL.md、脚本、workflow runbook | 长期但需衰减 | 指导可重复工作流执行 |
分层的价值在于控制晋升。一次临时想法可以先放在局部记忆里；多次验证后再写成结构化知识；相同任务重复出现，才值得提升为技能；如果技能本身可以被自动化，再沉淀成脚本或工作流。
图：上下文、经历、结构化知识与程序性技能的分层关系
这个过程可以写得很简单：
临时观察 -> 被复用并验证 结构化知识 -> 同类任务多次出现 程序性技能 -> 步骤稳定且值得自动执行 脚本 / workflow这里最重要的工程直觉是：不要因为一次成功或一次失败就立刻固化。Agent 很容易把偶然路径写成规则，后续再被这条规则误导。
信息保存优先：为什么短摘要经常不如长技能文件有用
自进化系统里有一个反常识现象：更短的经验总结，不一定更容易被 Agent 用对。
ACE 等研究里提到过类似的经验忠实度问题：Agent 往往更忠实地使用原始执行轨迹，比如具体代码、命令、工具参数、错误输出；但对"下次注意某某"这类凝练教训反而容易忽略或误读。
这对工程实现的影响很直接。与其把经验压成一句漂亮摘要，不如保留更多可检索、可执行、可验证的条目。多花几百 token 读一个写清楚的SKILL.md，通常比读一句抽象建议更可靠。
当然，信息不能无限增长。技能库到几百个文件后，检索精度会变成新瓶颈。Hermes 这类混合路线比较务实：内容本身尽量不做有损压缩，路由和检索层负责把相关材料找出来。Memento-Skills 这类方案则进一步训练路由器，用对比学习区分"词很像但流程不同"的任务。
这里没有完美答案。但在目前的 Agent 场景里，我更愿意先保细节，再优化检索。因为细节一旦被压掉，后面再聪明的路由器也找不回来。
GEPA：Prompt 优化不一定需要梯度，诊断文本也能当优化信号
Hermes 讨论的是系统怎样积累经验。GEPA 解决的是另一个问题：Prompt 本身怎样进化。
传统 Prompt 优化很容易走向打分驱动：跑一组样本，得到一个标量分数，然后搜索更好的版本。问题是标量分数太瘦了。它只告诉你这版不行，没告诉你为什么不行，更不会指出是哪一步推理跳过了前提，哪个工具调用误读了约束。
GEPA 的做法更像工程复盘。它让强模型读取完整执行轨迹，输出自然语言诊断。这个诊断被称为 ASI，也就是可操作辅助信息。它的作用类似优化里的梯度：指出当前候选 Prompt 往哪里改、为什么改、改动应该影响哪类样本。
GEPA 的进化过程可以拆成三步：
| 操作 | 做什么 | 价值 |
|---|---|---|
| 反射式突变 | 基于失败诊断改写当前 Prompt | 让修改有明确原因 |
| 谱系累积 | 保留祖先版本的教训 | 避免反复踩同一个坑 |
| 帕累托选择 | 保留在不同样本上表现最好的候选集合 | 防止过早收敛到单一策略 |
帕累托前沿是这里的关键。它不只保留当前总分第一的 Prompt，而是保留那些至少在某些评估实例上做到最好的候选。复杂任务往往不是一把尺子能量完的。一个候选可能擅长工具规划，另一个更擅长错误恢复，第三个更适合长上下文。把这些候选都留下，后续合并和突变才有材料。
公开评测里，GEPA 相比 GRPO、MIPROv2 更省评测调用。大致数据可以这样理解：
| 方法 | 评测调用量级 | 相对 GEPA 表现 |
|---|---|---|
| GRPO | 5,000 到 25,000+ | 低约 6% 到 20% |
| MIPROv2 | 500 到 2,000+ | 低约 10% |
| GEPA | 100 到 500 | 基准 |
真正值得借鉴的不是某个具体数字，而是这条思路：完整轨迹里的自然语言诊断，比单个分数包含更多可迁移的优化信息。
四个反模式：自进化系统最容易在这些地方坏掉
自进化听起来很诱人，但工程上并不浪漫。系统会生成垃圾技能，会修坏旧文件，会检索错相似任务，还会相信自己的错误验证。
最常见的坑有四个。
第一，技能围绕工具写，而不是围绕工作流写。这样的技能短期好写，长期难复用。Agent 需要的是完成目标的流程，不是某个工具的参数说明。
第二，没有衰减机制。技能不会因为过期自动消失，旧流程会继续被检索出来。如果接口已经改了，Agent 还在用旧技能执行，就会把错误经验当成权威。
第三，语义相似度路由误判。两个任务都叫"发布"，可能一个是排版，一个是上线；文本相似度很高，工具链却完全不同。只靠 embedding 相似度，很容易把 Agent 引到错误流程里。
第四，缺少独立验证。生成器和验证器如果都是同类 LLM，很多错误会一起漏掉。这就是所谓的幻觉壁垒：模型自己编出来的东西，另一个相似模型也可能觉得合理。
解决方向并不复杂，但执行成本不低：技能变更要有测试或基准门控；整理器要和执行器隔离；关键任务要引入非同构验证，比如真实编译、真实 API 响应、端到端回归，而不是只让模型读一遍说"看起来没问题"。
图：技能变更、检索路由与真实验证构成治理门控
结语
Hermes 这类系统给 Agent 工程提供了一个更实际的答案：让 Agent 变强，不一定要等模型训练更新。更快的路径是把经验放到模型外面，用运行时机制管理它。
技能生成负责把复杂流程写下来，自我修复负责让流程跟上真实环境，Curator 负责防止技能库发霉，记忆分层负责把临时上下文、跨会话经历、结构化知识和程序性技能分开。GEPA 又补上了 Prompt 层的进化方法：用完整轨迹和自然语言诊断替代贫瘠的标量奖励。
我更愿意把这类 Agent 看成"带学习型外骨骼的执行系统"。模型本身未必变聪明，但它能调用的经验资产变厚了，任务路由更准了，错误修复更快了。第 50 次任务能不能比第 1 次做得好，取决于系统有没有把前 49 次真正留下来。
没有这套机制，Agent 只是会说话的执行循环。有了这套机制，它才开始像一个能积累手艺的工程系统。