拆解 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 场景里我更愿意先保细节再优化检索。因为细节一旦被压掉后面再聪明的路由器也找不回来。GEPAPrompt 优化不一定需要梯度诊断文本也能当优化信号Hermes 讨论的是系统怎样积累经验。GEPA 解决的是另一个问题Prompt 本身怎样进化。传统 Prompt 优化很容易走向打分驱动跑一组样本得到一个标量分数然后搜索更好的版本。问题是标量分数太瘦了。它只告诉你这版不行没告诉你为什么不行更不会指出是哪一步推理跳过了前提哪个工具调用误读了约束。GEPA 的做法更像工程复盘。它让强模型读取完整执行轨迹输出自然语言诊断。这个诊断被称为 ASI也就是可操作辅助信息。它的作用类似优化里的梯度指出当前候选 Prompt 往哪里改、为什么改、改动应该影响哪类样本。GEPA 的进化过程可以拆成三步操作做什么价值反射式突变基于失败诊断改写当前 Prompt让修改有明确原因谱系累积保留祖先版本的教训避免反复踩同一个坑帕累托选择保留在不同样本上表现最好的候选集合防止过早收敛到单一策略帕累托前沿是这里的关键。它不只保留当前总分第一的 Prompt而是保留那些至少在某些评估实例上做到最好的候选。复杂任务往往不是一把尺子能量完的。一个候选可能擅长工具规划另一个更擅长错误恢复第三个更适合长上下文。把这些候选都留下后续合并和突变才有材料。公开评测里GEPA 相比 GRPO、MIPROv2 更省评测调用。大致数据可以这样理解方法评测调用量级相对 GEPA 表现GRPO5,000 到 25,000低约 6% 到 20%MIPROv2500 到 2,000低约 10%GEPA100 到 500基准真正值得借鉴的不是某个具体数字而是这条思路完整轨迹里的自然语言诊断比单个分数包含更多可迁移的优化信息。四个反模式自进化系统最容易在这些地方坏掉自进化听起来很诱人但工程上并不浪漫。系统会生成垃圾技能会修坏旧文件会检索错相似任务还会相信自己的错误验证。最常见的坑有四个。第一技能围绕工具写而不是围绕工作流写。这样的技能短期好写长期难复用。Agent 需要的是完成目标的流程不是某个工具的参数说明。第二没有衰减机制。技能不会因为过期自动消失旧流程会继续被检索出来。如果接口已经改了Agent 还在用旧技能执行就会把错误经验当成权威。第三语义相似度路由误判。两个任务都叫发布可能一个是排版一个是上线文本相似度很高工具链却完全不同。只靠 embedding 相似度很容易把 Agent 引到错误流程里。第四缺少独立验证。生成器和验证器如果都是同类 LLM很多错误会一起漏掉。这就是所谓的幻觉壁垒模型自己编出来的东西另一个相似模型也可能觉得合理。解决方向并不复杂但执行成本不低技能变更要有测试或基准门控整理器要和执行器隔离关键任务要引入非同构验证比如真实编译、真实 API 响应、端到端回归而不是只让模型读一遍说看起来没问题。图技能变更、检索路由与真实验证构成治理门控结语Hermes 这类系统给 Agent 工程提供了一个更实际的答案让 Agent 变强不一定要等模型训练更新。更快的路径是把经验放到模型外面用运行时机制管理它。技能生成负责把复杂流程写下来自我修复负责让流程跟上真实环境Curator 负责防止技能库发霉记忆分层负责把临时上下文、跨会话经历、结构化知识和程序性技能分开。GEPA 又补上了 Prompt 层的进化方法用完整轨迹和自然语言诊断替代贫瘠的标量奖励。我更愿意把这类 Agent 看成带学习型外骨骼的执行系统。模型本身未必变聪明但它能调用的经验资产变厚了任务路由更准了错误修复更快了。第 50 次任务能不能比第 1 次做得好取决于系统有没有把前 49 次真正留下来。没有这套机制Agent 只是会说话的执行循环。有了这套机制它才开始像一个能积累手艺的工程系统。
