夜雨聆风
OpenBuild 导读：
近期，Hermes Agent 在 AI Agent 开源社区彻底引爆讨论。自 2026 年 2 月发布以来，GitHub 星标两个月内突破 28K，日均新增上千星，Discord、Reddit、X 等平台持续刷屏，被视为 OpenClaw 之后最具颠覆性的自进化智能体方案。Hermes 以自学习闭环、持久化记忆、轻量化架构直击传统 Agent 痛点，尤其在长期记忆、技能自生成、跨会话稳定性上，被广泛讨论为对 OpenClaw 设计思路的重要修正与升级。
原标题：I Read Hermes Agent's Memory System, and It Fixes What OpenClaw Got Wrong
如果你读过我之前关于 ChatGPT、Claude 以及 OpenClaw 记忆机制的文章，就会发现我始终在追问同一个问题：这些智能体到底是怎么实现记忆的？
Hermes Agent 之所以让我格外感兴趣，是因为这一次我不必再通过行为反向推导原理 —— 它完全开源，代码仓库与文档全部公开。于是我没有再用提示词去试探黑盒，而是直接追踪了构建提示词状态、持久化会话、刷新记忆与查询历史对话的核心代码逻辑。
简单直接的结论是：Hermes 并非只有一套记忆系统，而是同时拥有四层。
存储在 MEMORY.md 和 USER.md 中的精简常驻提示词记忆
基于 SQLite、可搜索的历史会话归档（通过 session_search 调用）
由智能体自主管理、类似程序性记忆的技能库
可选接入的 Honcho 扩展层，用于更深度的用户建模
而把这一切串联起来的核心设计原则非常朴素：保持提示词结构稳定以支持缓存，其余所有内容都通过工具按需调取。
下面我们逐层拆解。
/ 01
Hermes 的上下文结构
想理解记忆，先要搞清楚 Hermes 到底给模型发送了什么。它的系统提示词大致按以下顺序组装：
[0] Default agent identity[1] Tool-aware behavior guidance[2] Honcho integration block(optional)[3] Optional system message[4] Frozen MEMORY.md snapshot[5] Frozen USER.md snapshot[6] Skills index[7] Context files(AGENTS.md, SOUL.md, .cursorrules, .cursor/rules/*.mdc)[8] Date/time + platform hints[9] Conversation history[10] Current user message
这一结构非常关键，因为 Hermes 专门为厂商侧提示词缓存做了优化。源码里明确体现了这一设计：稳定前缀要尽可能长期保持不变。正是这一个决策，决定了 Hermes 几乎全部的记忆架构。
如果某条信息需要每轮都可用 → 尽量精简，只注入一次
如果信息量大、属于历史、或仅偶尔需要 → 移出提示词，按需检索
/ 02
第一层：冻结式提示词常驻记忆
Hermes 内置的常驻记忆体积非常小。所有持久记忆存在 ~/.hermes/memories/ 下的两个文件中：
| File | Purpose | Limit ||------|---------|-------|| `MEMORY.md` | Agent notes about environment, conventions, tool quirks, lessons learned | 2,200 chars || `USER.md` | User profile: preferences, communication style, identity | 1,375 chars |
总量并不大，合计大约 1300 Token 左右。而这是刻意为之。
会话启动时，Hermes 加载这两个文件，渲染进提示词，然后冻结该快照，直到会话结束。会话中途对文件的修改会立即落盘，但不会改变已经生成的系统提示词，只会在新会话开始或触发压缩重建提示词时生效。
渲染后的格式大致如下：
══════════════════════════════════════════════MEMORY (your personal notes) [67% — 1,474/2,200 chars]══════════════════════════════════════════════User's project is a Rust web service at ~/code/myapi using Axum + SQLx§This machine runs Ubuntu 22.04, has Docker and Podman installed§User prefers concise responses, dislikes verbose explanations
我非常欣赏其中几个精巧的设计细节：
使用字符限制而非 Token 限制：让记忆逻辑与模型解耦，不需要针对特定模型做分词处理。
极简分隔符格式：使用 § 分割条目，无向量库、无自定义二进制存储，纯文本文件即可。
刻意保持系统提示词记忆极小：这是整个设计最重要的一点。Hermes 不会把全部历史塞进提示词，只保留最高价值的信息。
将记忆视为精炼状态，而非流水日记：这也是它与 OpenClaw 最大的区别之一。
OpenClaw 的日志更偏向追加式记录，而 Hermes 明确走向另一个极端。工具 Schema 与测试代码中写明：
保存用户偏好
保存环境事实
保存高频修正
保存稳定惯例
不保存任务进度
不保存会话结果
不保存临时待办状态
本质上，Hermes 希望 MEMORY.md 和 USER.md 保持高频访问、紧凑、缓存友好。
memory 工具
Hermes 通过一个统一的 memory 工具管理这两个文件，支持三种操作：
add
replace
remove
当前工具接口并没有独立的读取操作，因为记忆已经在会话开始时注入提示词。一个很人性化的细节是：replace 和 remove 支持子串匹配，不需要内部 ID，只要传入唯一片段即可。
示例：
memory(action="replace",target="memory",old_text="dark mode",content="User prefers light mode in VS Code, dark mode in terminal")
系统还会自动拒绝重复内容，并拦截危险内容，包括：
提示注入特征
凭证泄露字符串
SSH 后门特征
不可见 Unicode 字符
这很合理：任何写入记忆的内容，未来都会成为系统提示词的一部分。
/ 03
第二层：session_search 情景式记忆检索
如果说 MEMORY.md/USER.md 是热记忆，那 session_search 就是长尾历史召回系统。
所有历史会话存在 ~/.hermes/state.db，一个 SQLite 数据库，包含：
sessions 表
messages 表
FTS5 全文检索索引
通过 parent_session_id 建立的会话父子关联
当模型需要回忆之前的对话时，不会去搜 MEMORY.md，而是直接检索会话库。
执行流程：
对历史消息做 FTS5 检索
按会话分组
解析父子会话关联
加载最匹配的会话
在相关内容附近截断记录
用轻量模型对每个会话做摘要
返回精简摘要给主模型
这与那些试图对所有记忆做语义索引的系统完全不同。Hermes 的思路非常务实：
常驻提示词记忆保持极小
真实历史存在 SQLite
仅在需要时检索
返回前先做摘要
既省钱，又避免把冗长历史塞进每一轮提示词。
文档中对 session_search 的定位是回答这类问题：
“我们上周聊过这个吗？”
“关于 X 我们当时是怎么处理的？”
“就像我之前说过的……”
简单说：
MEMORY.md：存稳定事实
session_search：存情景回忆
/ 04
第三层：压缩与记忆刷新（Memory Flush）
Hermes 另一个精巧设计，体现在长对话压缩之前的处理。
随着会话增长，Hermes 会对中间部分做摘要，以控制在模型上下文窗口内。但摘要必然有信息损耗，重要内容可能丢失。于是 Hermes 会先执行一次 memory flush。
在压缩前，它会插入一条合成指令，大意是：
会话即将压缩。把所有值得记住的内容保存下来。优先保留用户偏好、修正内容、高频模式，而非任务细节。
然后单独调用一次模型，只开放 memory 工具。如果模型认为某些信息值得留存，就会在对话被摘要压缩前，写入 MEMORY.md 或 USER.md。
这是一个非常优秀的设计。它给了模型最后一次机会，在历史被折叠前提炼出持久信息。
更妙的是：压缩完成后，Hermes 会重建缓存的系统提示词，重新从磁盘加载记忆。这意味着压缩前刷新的内容，会直接进入下一份稳定提示词快照。
整体流程：长对话 → 刷新持久事实 → 压缩早期轮次 → 重建提示词 → 以更小上下文 + 更新记忆继续运行
正是这种设计，让 Hermes 看起来像一套真正的记忆架构，而不是简单外挂的笔记库。
/ 05
第四层：作为程序性记忆的 Skills
Hermes 的记忆不只是事实与对话，还包括技能。
技能存放在 ~/.hermes/skills/，相当于可复用的知识文档，官方文档直接将其定义为智能体的程序性记忆。
当 Hermes 学会一个复杂工作流、修复了一个棘手问题、或找到更优方案，就可以保存为技能，后续重复使用。
这一点非常重要。绝大多数记忆系统只关注语义召回：名称、偏好、事实、摘要。但智能体同样需要记住 “怎么做”，而不只是 “发生了什么”。
Hermes 通过分层解决了这一问题：
MEMORY.md/USER.md：紧凑、持久的事实记忆
session_search：情景式历史检索
skills：可复用工作流程
这里还有一个 Token 优化技巧：Hermes 不会把所有技能全部注入提示词，只注入一个精简索引，真正需要时才加载完整内容。既保证程序性记忆可用，又避免每轮都承担全额 Token 开销。
/ 06
第五层：Honcho 深度用户建模（可选）
最后是可选的 Honcho 扩展层。
如果说本地记忆是 Hermes 的精炼笔记本，Honcho 则是更完整的用户建模系统。默认以 hybrid 模式与内置记忆并行运行，额外提供：
跨会话用户建模
跨设备、跨平台 continuity
对用户上下文的语义搜索
由 LLM 生成的关于用户与智能体自身的辩证式回答
精妙之处在于，它的集成方式不会破坏提示词缓存：
第一轮：预取的 Honcho 上下文可以编入可缓存的系统提示
后续轮次：不修改稳定前缀，仅在 API 调用时将 Honcho 召回内容附加在当前用户消息后
结果就是：稳定前缀保持不变 → 提示词缓存继续生效第 N 轮可以使用第 N-1 轮后台预取的上下文
这是一个非常聪明的折中方案。Honcho 本身还会同时建模两个角色：
用户
AI 助手
也就是说，Hermes 不仅会记住你，还会逐渐构建一套对自身的表征。
/ 07
Hermes 与 OpenClaw 的核心差异
既然我最近刚分析过 OpenClaw，这里有必要做一个明确对比：
OpenClaw
记忆更偏向 Markdown 优先存储
以每日日志 + 长期记忆文件为主要事实来源
记忆召回依赖对存储笔记的混合检索
Hermes
提示词记忆严格限制体积
会话历史存在 SQLite，而非提示词文件
历史内容通过 session_search 召回
程序性记忆剥离到 skills 中
深度用户建模可选委托给 Honcho
核心区别：Hermes 对缓存的敏感度远高于 OpenClaw。OpenClaw 更偏向 “记忆即可检索知识库”；Hermes 更偏向 “记忆即高频工作集 + 多层冷存储”。
我个人认为这更接近生产级智能体的正确方向。不是所有信息都值得放进系统提示词。
/ 08
Hermes 做得最出色的三点
通读代码与文档后，我认为 Hermes 在三个核心问题上做到了位：
1. 严格区分热记忆与冷召回
这是架构上的核心胜利。少量常驻提示词记忆应对高频需求，检索系统处理长尾需求。
2. 将提示词稳定性作为一级设计目标
很多智能体系统只谈记忆，不谈缓存。Hermes 两者都重视。冻结快照、延迟更新、按轮注入 Honcho、压缩后重建，都指向同一个原则：想降低延迟与成本，就不要随意改动提示词。
3. 承认记忆是多层结构，而非单一存储
Hermes 没有假装用一套存储解决所有问题，而是清晰分层：
语义档案记忆
情景会话记忆
技能程序性记忆
可选高阶用户建模
这更贴近智能体真实的记忆需求。
/ 09
总结
Hermes 的记忆系统既不是巨型知识库，也不是包装精美的向量库，而是一套分层级的连续性架构。
核心是极小且精炼的提示词记忆：MEMORY.md + USER.md；外层是可检索的 SQLite 历史库，用于情景回忆；再外层是技能系统，用于复用工作流；如果开启 Honcho，则在最上层叠加深度用户建模。
而最让我欣赏的，是贯穿始终的设计理念：记忆应该让智能体更有用，同时不破坏提示词稳定性。
真正的技巧，不是记住更多，而是：在正确的层级，以合理的成本，记住正确的信息。
原文：https://x.com/manthanguptaa/status/2034849672985288957
作者：@manthanguptaa
（OpenBuild 翻译整理，原文有删减）
👇欢迎加入 OpenBuild 开发者交流群，第一时间获取技术干货、最新行业动态！
添加小助手或者后台回复“社群”
