Hermes 记忆系统深度分析：5 层记忆架构 vs OpenClaw——"不是记更多，是记对的东西"

> 来源: X/Twitter 原文

> 作者: Manthan Gupta (@manthanguptaa)，AI Research Engineer

> 互动: 546 赞 / 1,092 收藏 / 133K 浏览

> 之前的 Hermes 报告: Hermes Agent 深度研究

> 研究时间: 2026-03-21

🎯 一句话版本

一位 AI 研究工程师通读了 Hermes Agent 的源码，发现它有 5 层记忆系统（热记忆+冷搜索+压缩刷盘+技能+用户模型），核心设计哲学是"prompt 稳定性优先"——不是记更多，是在正确的层、以正确的成本记正确的东西。

📝 背景

Manthan Gupta 之前写过 ChatGPT、Claude、OpenClaw 的记忆系统分析，这次是 Hermes Agent。不同之处：Hermes 开源，所以他直接读源码，不是黑盒逆向工程。

这篇文章在 X 上获得了 1,092 收藏——说明 Agent 记忆架构是当前开发者社区最关注的话题之一。

🧠 Hermes 的 5 层记忆架构

Layer 1: Frozen Prompt Memory（热记忆）

合计 ~1,300 tokens。故意很小。

关键设计：

• 会话开始时加载 → 冻结，会话中修改写入磁盘但不改当前 prompt
• 用字符限制而非 token 限制（模型无关）
• § 分隔符，纯文本，无向量库
• 是 curated state（策展状态），不是 diary（日记）
• 不保存：任务进度、会话结果、临时 TODO
• 安全扫描：防注入、防凭证泄露、防后门

超过限制怎么办？ 写入工具会直接拒绝。源码有容量检查，超了返回错误，逼模型先 replace 或 remove 旧内容腾位置。这才是核心——不是"记不下就扩容"，而是逼模型做优先级排序。就像只有一张 A4 纸写备忘录，写满了就得擦掉不重要的才能写新的。

三个改进一起构成第一层的设计：

1. 硬字符限制 — 控制 prompt 大小

2. 冻结快照 — 会话中改了也不立即生效，保护 prompt cache

3. 策展式管理 — 只存高价值事实，拒绝临时内容

Layer 2: session_search（情节回忆）

所有历史会话存在 SQLite (state.db)：

• sessions 表 + messages 表 + FTS5 全文索引
• 支持 parent/child 会话链

检索流程：

FTS5 搜索 → 按 session 分组 → 解析父子关系
→ 截取相关片段 → 用便宜模型摘要 → 返回精炼结果

哲学：热记忆保持小，真实历史在 SQLite，按需检索，返回前先摘要。

为什么不用向量数据库？

FTS5（Full-Text Search 5）是 SQLite 内置的全文搜索引擎，用倒排索引实现毫秒级关键词检索。Agent 历史会话有明确关键词，FTS5 够用，且零依赖、零成本。搜到结果后用便宜模型摘要，补足语义短板。

FTS5 的中文问题

FTS5 默认用空格分词，英文没问题，但中文"部署脚本写好了"会被当成一整个 token。解决方案：

• 预分词入库（最实用）：写入前用 jieba 分词，空格连接后存入
• trigram 模式：3 字符滑窗切分，索引大 3-5 倍但零配置
• 外接分词器：编译 C 扩展，最准但部署麻烦

Hermes 主要面向英文，用默认 unicode61。中文场景需额外处理。

Layer 3: Compression Memory Flush（压缩前刷盘）

这是最精妙的设计——当对话太长需要压缩时：

长对话 → 注入"保存值得记住的"指令
→ 用只有 memory 工具的额外模型调用
→ flush 持久事实到 MEMORY.md/USER.md
→ 压缩旧轮次 → 重建 prompt（含新记忆）→ 继续

给模型"最后一次机会"在对话被压缩前提取关键信息。 压缩后重建 prompt snapshot，刷新后的记忆立即生效。

Layer 4: Skills（程序记忆）

• 技能存在 ~/.hermes/skills/
• 只注入 skills index（紧凑索引），按需加载完整内容
• Agent 发现复杂工作流/修复棘手问题后可保存为 skill
• 大多数记忆系统只关注语义回忆（名字、偏好、事实），Hermes 还记住怎么做事

Layer 5: Honcho（可选用户模型）

前四层都是本地的（文件/SQLite/Skills 都在 ~/.hermes/）。Honcho 解决的问题是：换台电脑，记忆全没了。

双 Peer 建模

不只是记住你，还记住"我自己是什么样的"。换一个 Agent 接手时，新 Agent 能知道"上一个 Agent 是怎么跟这个用户互动的"——对多 Agent 协作很有价值。

不破坏 prompt cache 的秘诀

• 第 1 轮：Honcho 上下文 bake 进 system prompt（冷启动）
• 第 2 轮起：后台异步预取，attach 到 user turn 级别，不改 system prompt

Dialectic Reasoning（辩证推理）

Honcho 不只存键值对，它用 LLM 生成"关于用户的推理"：

> "这个用户倾向于先看架构全局再看细节，给他解释时应该 top-down"

这种推理比"用户喜欢简洁回复"更深一层，是行为模式级别的理解。支持 5 级推理深度（minimal → low → medium → high → max）。

跨平台同步

在笔记本上用 Hermes 聊了一周，回家换台式机——Honcho 把偏好、沟通风格、项目上下文同步过来，不用重新"教"它。支持 per-session、per-directory、per-repo、global 四种会话策略。

代价

依赖云服务（app.honcho.dev），需要 API key。不像前四层完全本地。这也是为什么设计成可选的。

🆚 Hermes vs OpenClaw 记忆对比

作者的判断：Hermes 更 cache-aware。OpenClaw 是"记忆=可搜索知识"，Hermes 是"热工作集+冷检索层"。

> "I actually think this is the right direction for production agents. Not everything deserves to live in the system prompt."

💡 作者总结的三个关键洞察

1. 分离热记忆和冷召回

小 prompt memory 放永远重要的。搜索给偶尔需要的。

2. Prompt 稳定性是一等约束

冻结快照、延迟 prompt 更新、轮级 Honcho 注入、压缩后重建——所有设计都指向同一原则：不要随便改 prompt，否则缓存失效、延迟上升、成本飙升。

3. 记忆是复数的

一个存储解决不了所有问题：

• 语义记忆（MEMORY.md/USER.md）
• 情节记忆（session_search）
• 程序记忆（Skills）
• 用户模型（Honcho）

💡 与我们的关联

1. 我们的 MEMORY.md 问题被精准点名

作者说 OpenClaw "append-only flavor to daily logs"——这正是我们面临的问题。MEMORY.md 越来越大，每次全量注入，token 成本线性增长。

2. 压缩前刷盘值得立即采用

Hermes 的 compression flush 模式（压缩前给模型一次"保存重要内容"的机会）非常聪明。我们可以要求 OpenClaw 在压缩前执行类似操作。

3. 与 OpenViking 形成互补

今天调研的 OpenViking 也是分层加载（L0/L1/L2），和 Hermes 的"热+冷"理念一致。两者可以结合：

• Hermes 式：prompt memory 严格限制 + 冻结
• OpenViking 式：冷数据走目录检索 + 分层加载

4. 字符限制 vs Token 限制

Hermes 用字符限制（2,200 chars）而非 token 限制，因为不同模型 tokenizer 不同。这是一个简单但实用的设计决策。

5. 安全扫描记忆内容

写入 MEMORY.md 的内容实际上成为未来 system prompt 的一部分。Hermes 扫描注入/凭证/后门——我们也应该做。

6. 实施路线

短期：

• 给 MEMORY.md 加字符限制（比如 3,000 chars）
• 压缩前增加 flush 步骤
• 不保存临时 TODO/任务进度到 MEMORY.md

中期：

• 试用 OpenViking 做冷检索层
• Skills 索引化（只注入目录，按需加载）

长期：

• 完整的热+冷+程序三层架构

📊 评分

报告由深度研究助手自动生成 | 2026-03-21

来源: X/Twitter 原文