Hermes Agent 的自改进，不是训练而是四层记忆闭环

很多 agent 产品会把“自改进”说得很像在线学习，仿佛模型会在使用过程中不断训练自己。但真正看代码时，事情通常没有这么神秘。

最近我整理了一份对 Hermes Agent 的源码分析，最有意思的一点不是它“会自己训练自己”，而是它把“过去交互如何变成未来优势”这件事做成了一套非常工程化的闭环。

我的结论先放前面：Hermes Agent 的自改进不是参数级学习，也不是在线微调，而是应用层闭环学习。

它真正更新的不是模型权重，而是：

未来会再次注入 prompt 的上下文
持久化文件里的长期知识
可复用的技能工作流
会话检索和外部 memory provider 中的用户表征

如果只用一句话概括，可以这样说：

Hermes Agent 不是越用越会“训练自己”，而是越用越知道用户是谁、以前做过什么、哪些方法值得复用。

先定义问题：这里的“自改进”到底指什么

从实现看，Hermes 所说的自改进，主要是下面几件事的组合：

把稳定事实写入长期记忆，减少用户重复纠正
把可复用方法写成技能，供未来任务直接复用
把历史会话存档并可召回，弥补单次上下文窗口的遗忘
在外部 memory provider 中形成更深层的用户建模
在复杂任务后做后台复盘，尝试自动沉淀 memory 或 skill

这和传统意义上的“模型训练”完全不同。Hermes 不会在运行时更新模型参数，它更新的是一组会在未来推理中重新进入系统的持久状态。

所以更准确的定义应该是：

它是一个带持久状态、检索机制和复盘通道的 agent runtime。

整体结构：它不是一个 memory，而是四层记忆协作

Hermes 的设计里，最值得肯定的一点是它没有把所有“记忆”都塞进一个桶里，而是分成了四层：

语义记忆
程序性记忆
情节记忆
外部反思型记忆

这四层分别对应不同问题：

哪些稳定事实以后还要记得
哪些做事方法以后还要复用
哪次任务里发生过什么
用户到底是什么样的人，或者有哪些更深层模式

这种分层非常重要。因为如果所有信息都堆进一个长期 memory，系统很快就会出现两个问题：

有价值信息被噪音稀释
prompt 和存储都会不断膨胀

Hermes 的做法更像是在说：不同类型的经验，应该落到不同层次的持久状态里。

第一层：语义记忆，保存“稳定事实”而不是所有经历

这一层最直接，也最容易理解。Hermes 会把一部分长期稳定事实写进两个文件：

MEMORY.md
USER.md

它们分别更像：

agent 自己的工作笔记
用户的长期画像

这层机制的重点不是“能写文件”这么简单，而是它有很明确的约束：

持久化，跨 session 保留
有字符预算上限
会去重
支持替换和删除
原子写入和文件锁
对注入和外带数据做防护

这说明 Hermes 的内置 memory 不是日志，也不是无限膨胀的 notes，而是一个受预算约束的精选知识层。

更重要的是，它并不追求“写完立刻影响当前 session”。从实现意图看，memory 会落盘，但通常要到下一个 session 才重新进入 system prompt。这是一个非常典型的工程取舍：

牺牲一点即时性
换取 prompt cache 稳定和成本可控

所以这一层的核心价值是：把长期稳定事实从对话噪音里剥离出来。

第二层：程序性记忆，把经验沉淀成 Skill

如果说 memory 记录的是“事实”，那 skill 记录的就是“做事方法”。

这一层我觉得 Hermes 做得非常成熟。因为复杂工作流其实不适合塞进长期 memory，它更适合被沉淀成一个带结构的可复用技能包。

从设计上看，skill 的闭环大概是这样的：

system prompt 先注入技能索引
模型看到相关技能时，按需读取全文
执行中如果发现 skill 过时或有遗漏，就 patch
复杂任务结束后，可以沉淀出新的 skill，供未来复用

这套机制本质上是在做 程序性记忆。

它的优势非常明显：

比 memory 更适合保存复杂 workflow
支持 patch，而不是每次整篇重写
本质还是文件系统，便于审阅、版本管理和回滚
可以附带 references、templates、scripts、assets，不局限于单一 markdown

这也是为什么我觉得 Hermes 的“自改进”并不只是记住用户偏好，而是真的在把成功做法逐步外化成可复用 procedure。

当然，这一层也有边界：很多自动化依然是 prompt 驱动的，而不是纯规则引擎。系统可以鼓励模型创建和修补 skill，但是否真的沉淀，仍然受模型判断影响。

第三层：情节记忆，记住“哪次任务里发生过什么”

如果只有 memory 和 skill，这个系统仍然会丢掉很多很有价值但不适合永久保存的信息。

比如：

某次调试里试过哪些失败路径
某个问题上次在哪个 session 被修过
用户曾经提到过、但不值得写进长期记忆的背景

这些内容更适合放在情节记忆层。

Hermes 在这层的做法是：

用 SQLite 保存 session 元信息和消息历史
用 FTS5 建全文索引
需要时通过 session_search 检索相关历史
再用辅助模型做 focused summary

这一步特别值得注意，因为它不是 raw transcript 回放，而是摘要化的 episodic recall。

这会带来几个很重要的好处：

把长期事实和一次性情节分开
不需要把大量“脏历史”写进 memory
真需要时再召回，主上下文保持干净
还能处理 parent/child session lineage，避免把当前对话碎片又重新搜回来

所以这一层不是“记忆事实”，而是在回答：我们以前到底做过什么。

第四层：外部 memory provider，负责更深的用户建模

如果说前面三层已经足够构成一个不错的闭环，那么外部 memory provider 才是 Hermes 真正更有野心的部分。

这一层的设计最关键的地方在于：它不是简单加一个“外部搜索工具”，而是把 provider 抽象成一组生命周期接口，可以进入：

每 turn 的 recall
每 turn 的 write-back
session 结束时的 flush
压缩前的提炼
delegation 完成后的观察

这说明 Hermes 在这里的设计哲学非常清楚：

内置层提供稳定、克制、可审计的基础能力
更复杂、更昂贵、更实验性的记忆和建模能力放到 provider 层

像 Honcho 这种 provider，已经不只是做事实检索，而是在持续形成更丰富的用户模型，例如：

user / AI 的 representation
session summary
多轮 reasoning 补充
semantic search / profile / context / conclusion

而 Hindsight 这类 provider，则更偏长期知识仓库和知识图谱方向。

这意味着 Hermes 的“自改进”并不是一条单一路径，而是把：

稳定事实
procedure
情节检索
深层用户建模

拆成不同层次去做。

还有两个很关键但容易忽略的补丁机制

除了四层记忆本身，我觉得 Hermes 还有两个设计特别聪明。

1. delegation 结果也能被学习

子代理在设计上并不能直接写共享 memory，这是一条非常重要的边界控制。否则子代理很容易污染主代理的长期状态。

但 Hermes 并没有因此浪费掉 delegation 过程里的经验。更准确地说，它做的是：

子代理本身不直接学习
父代理或外部 provider 可以把“任务 + 结果”当成观察素材

这是一个很稳的平衡：

防止子代理乱写 memory
又不丢掉子任务带来的经验价值

2. 上下文压缩前先补做学习

Hermes 明确知道一件事：上下文压缩一定会丢信息。

所以它在压缩前会先做一次补救：

给模型一次额外保存 memory 的机会
让外部 provider 提取将被压缩掉的重要信息

这一点非常关键。因为它把“上下文压缩”从单纯的 token 管理，变成了闭环学习里的一个 checkpoint。

也就是说，压缩不是简单遗忘，而是先尝试把可持续的信息提炼出来。

这套体系真正强在哪

看完之后，我觉得 Hermes 的强项不是某一个神奇 memory，而是整体工程判断比较成熟。

1. 分层明确

它没有把所有经验都塞进一个长期存储里，而是分成：

事实
procedure
情节
深层画像 / 外部语义记忆

这会让每层都更可控。

2. 成本意识很强

很多设计都在明显控制长期运行成本：

memory 小而精
skill 先注入索引，全文按需加载
session search 先检索再摘要
provider 有 cadence、frequency、budget
背景 review 异步执行，不抢主任务

这说明它不是在无脑堆能力，而是在认真思考一个 agent 如何长期跑下去。

3. 可审计、可编辑、可回滚

很多“学到的东西”最终会落在可见文件里：

memories/MEMORY.md
memories/USER.md
skills/**/SKILL.md

这一点非常重要。因为它让用户和开发者都更容易回答一个关键问题：这个 agent 到底学到了什么。

它的边界和短板也很明确

这套系统虽然成熟，但也不能被误解。

1. 它不是权重级学习

Hermes 不会在线微调，不会做 RLHF，也不会在使用过程中更新模型参数。它做的是：

prompt / context 更新
文件化知识积累
检索式回忆
外部系统建模

这已经很强，但和“模型自己训练自己”不是一回事。

2. 很多自动化仍然是 prompt-mediated

很多关键行为虽然“会自动发生”，但仍然是模型在 prompt 驱动下去做：

什么时候该记 memory
什么时候该沉淀 skill
某个 skill 是否该 patch
某次任务值不值得写进长期状态

这意味着它不是纯规则系统，自治质量仍然受模型能力影响。

3. 内置 memory 的即时性有限

由于 prompt cache 和上下文稳定性的考虑，新增 memory 通常不会立刻影响同一 session 的 system prompt。这对长期体验是好事，但对“同一轮立刻变聪明”的帮助有限。

4. 技能创建的“确认”更像行为规范，不是硬闸门

从设计意图看，系统鼓励在创建或删除 skill 前和用户确认，但这更多是 schema 和 prompt 级约束，不是绝对技术闸门。

所以它是一个受控的自我更新系统，但不是完全不会越界的自治体。

最终判断

如果把“自改进”定义为“系统能否把过去经验转化成未来表现上的结构性优势”，那 Hermes Agent 的答案是：可以，而且做得很系统。

但它的方式不是训练式，而是：

记忆式
检索式
技能式
复盘式

我对它的判断可以浓缩成三句话：

它不是会自己训练自己的 agent
它是一个把长期记忆、程序性记忆和历史检索组合得很成熟的 agent runtime
它最强的价值在跨 session 累积和复用经验，而不是单次任务里的即时“变聪明”

如果只看 marketing 文案，很容易把这类系统理解成“会自己升级模型”；但从工程上看，Hermes 更真实、也更有价值的地方在于：

它把“过去交互如何变成未来优势”这件事做成了一套可持续运行的系统。