---
title: "深度拆解 Hermes Agent 的记忆系统：它如何修正 OpenClaw 的误区"
source_name: "宝玉的分享"
original_url: "https://baoyu.io/blog/2026-04-29/manthanguptaa-2034849672985288957"
canonical_url: "https://www.traeai.com/articles/6aa026e2-b889-4f4c-aa4f-c7ef9efc064a"
content_type: "article"
language: "中文"
score: 9
tags: ["AI","机器学习","自然语言处理"]
published_at: "2026-04-29T00:00:00+00:00"
created_at: "2026-04-30T02:15:47.660096+00:00"
---

# 深度拆解 Hermes Agent 的记忆系统：它如何修正 OpenClaw 的误区

Canonical URL: https://www.traeai.com/articles/6aa026e2-b889-4f4c-aa4f-c7ef9efc064a
Original source: https://baoyu.io/blog/2026-04-29/manthanguptaa-2034849672985288957

## Summary

文章深入解析了Hermes Agent的记忆系统，揭示其通过四层记忆结构优化提示词缓存，与OpenClaw相比更注重效率和实用性。

## Key Takeaways

- Hermes Agent采用四层记忆系统以优化提示词缓存。
- 核心逻辑是保持提示词稳定，将繁杂信息交给工具处理。
- Hermes与OpenClaw的主要区别在于对缓存效率的关注。

## Content

Title: 深度拆解 Hermes Agent 的记忆系统：它如何修正 OpenClaw 的误区

URL Source: http://baoyu.io/blog/2026-04-29/manthanguptaa-2034849672985288957

Markdown Content:
## 深度拆解 Hermes Agent 的记忆系统：它如何修正 OpenClaw 的误区

作者：Manthan Gupta

 原文：[I Read Hermes Agent's Memory System, and It Fixes What OpenClaw Got Wrong](https://x.com/manthanguptaa/status/2034849672985288957)

如果你读过我之前关于 ChatGPT、Claude 以及 Clawdbot 记忆系统的文章，你就会知道我一直在钻研同一个问题：这些 AI 智能体（AI Agent）到底是怎么记事的？

Hermes Agent 对我来说格外有趣，因为这次我不需要只靠观察它的行为来搞“逆向工程”。Hermes 是开源的，它的代码库和文档都是公开的。所以，我没有通过提示词（Prompt）去盲测这个黑盒，而是直接翻看了它的代码路径——从它如何构建提示词状态、持久化会话，到如何清理记忆和查询历史对话。

**简而言之：Hermes 拥有的不是一套记忆系统，而是四套。**

1.   存储在 `MEMORY.md` 和 `USER.md` 中、经过高度浓缩的**提示词记忆**。
2.   通过 `session_search` 调用的 **SQLite 历史会话存档**（可搜索）。
3.   像**程序记忆**（Procedural Memory）一样运作的**智能体技能管理**。
4.   可选的 **Honcho** 层，用于更深层的**用户建模**（User Modeling）。

把这些设计联系在一起的核心逻辑非常简单：**保持提示词稳定以便利用缓存（Caching），其他一切繁杂信息都交给工具。**

![Image 1: Hermes 四层记忆系统总览](https://s.baoyu.io/imgs/2026-04-29/manthanguptaa-2034849672985288957/01-infographic-memory-layers.png)

让我们深入聊聊。

![Image 2](https://s.baoyu.io/imgs/2026-04-29/manthanguptaa-2034849672985288957/info.png)

* * *

## Hermes 的上下文结构

在理解记忆之前，我们先看看 Hermes 到底给模型发送了什么。

系统提示词（System Prompt）大致是按以下顺序组装的：

```
[0] 默认智能体身份
[1] 工具使用行为指南
[2] Honcho 集成模块（可选）
[3] 可选系统消息
[4] 固化的 MEMORY.md 快照
[5] 固化的 USER.md 快照
[6] 技能索引
[7] 上下文文件（AGENTS.md, SOUL.md 等规则文件）
[8] 日期/时间 + 平台信息
[9] 对话历史
[10] 当前用户消息
```

这非常关键，因为 Hermes 正在针对大模型供应商的**提示词缓存（Prompt Caching）**机制进行优化。代码显示，提示词构建器的目标非常明确：**让稳定的前缀部分尽可能长时间地保持不变。**

这一个决定就解释了 Hermes 大部分的记忆架构。

如果某条信息每一轮对话都要用到，Hermes 会尽量把它缩得很小并注入进去；如果信息量很大、属于历史旧账或者偶尔才有用，Hermes 就会把它踢出提示词，改用“按需检索”的方式。

![Image 3: Hermes 的提示词缓存结构](https://s.baoyu.io/imgs/2026-04-29/manthanguptaa-2034849672985288957/02-infographic-prompt-cache.png)

## 第一层：固化的提示词记忆

其内置的记忆系统小得令人惊讶。

Hermes 将持久记忆存储在 `~/.hermes/memories/` 下的两个文件中：

| 文件 | 用途 | 限制 |
| --- | --- | --- |
| `MEMORY.md` | 智能体笔记：环境、规范、工具怪癖、教训 | 2,200 字符 |
| `USER.md` | 用户画像：偏好、沟通风格、身份信息 | 1,375 字符 |

这容量真不大。加起来大约只有 1,300 个 **Token（模型理解文本的最小单位）**。

**而这正是刻意为之。**

在会话开始时，Hermes 加载这两个文件，把它们渲染进提示词区块，然后**在整个会话期间固化这个快照**。会话中途写入的记忆会立即存入硬盘，但不会改变已经生成的系统提示词。这些改动只有在开启新会话，或者触发了“压缩（Compression）”导致的提示词重建时才会生效。

渲染后的格式如下：

```
══════════════════════════════════════════════
MEMORY (你的个人笔记) [67% — 1,474/2,200 字符]
══════════════════════════════════════════════
用户的项目是一个位于 ~/code/myapi 的 Rust Web 服务，使用 Axum + SQLx
§
这台机器运行 Ubuntu 22.04，安装了 Docker 和 Podman
§
用户喜欢简洁的回复，讨厌冗长的解释
```

这里有几个我非常欣赏的细节设计：

1.   **使用字符限制而非 Token 限制**：这让记忆逻辑与模型无关。Hermes 不需要调用特定模型的计算工具就能判断记忆是否存满。
2.   **简单的分隔符文件格式**：条目之间用 `§` 分隔。没有复杂的向量数据库（Vector DB），没有自定义二进制存储，就是纯文本。
3.   **刻意保持极小的系统提示词空间**：这是整个设计的重中之重。Hermes 不想把所有历史都塞进提示词，它只想要最有价值的事实。
4.   **记忆是“精选状态”，而不是“日记”**：这是 Hermes 与 OpenClaw 最大的区别。

OpenClaw 的日志更像是“流水账”。而 Hermes 则反其道而行。它的工具架构和测试逻辑强调：

*   保存用户偏好。
*   保存环境事实。
*   保存反复出现的错误修正。
*   保存稳定的规范。
*   **不保存**任务进度。
*   **不保存**会话结果。
*   **不保存**临时的待办事项（TODO）。

**真相是：Hermes 希望 `MEMORY.md` 和 `USER.md` 保持精简、高频且对缓存友好。**

![Image 4: 冷热分离的小记忆与大历史检索](https://s.baoyu.io/imgs/2026-04-29/manthanguptaa-2034849672985288957/03-comparison-hot-cold-memory.png)

## `memory` 工具

Hermes 通过一个拥有三种操作的 `memory` 工具来管理这些文件：`add`（添加）、`replace`（替换）、`remove`（移除）。

一个好用的细节是：`replace` 和 `remove` 使用**子字符串匹配**。你不需要记住条目的内部 ID，只需要传入现有条目中一段唯一的文字即可。

此外，系统会拒绝完全重复的内容，并拦截危险信息。源代码会扫描记忆条目，防止**提示词注入（Prompt Injection，即通过输入恶意指令误导 AI）**、凭证泄露或隐藏的 Unicode 字符。

* * *

## 第二层：用于情景回溯的 `session_search`

如果说 `MEMORY.md` 是 Hermes 的“短期热记忆”，那么 `session_search` 就是它的“长尾回溯系统”。

所有过去的会话都存储在 SQLite 数据库中，拥有完整的索引和搜索功能。当模型需要想起以前聊过的内容时，它不去翻 `MEMORY.md`，而是搜索这个会话数据库。

其工作流程是：

1.   在过去的消息中进行全文搜索。
2.   按会话分组结果。
3.   加载匹配度最高的会话。
4.   **使用一个便宜的辅助模型对这些会话进行摘要总结。**
5.   将精炼后的回顾内容返回给主模型。

这是一种非常务实的设计。它比盲目地把长篇累牍的历史塞进每一个提示词要便宜且高效得多。

* * *

## 第三层：压缩与记忆冲刷（Memory Flush）

Hermes 另一个聪明之处在于它处理长对话“压缩”的方式。

当会话变得太长，Hermes 会压缩对话中间的部分以节省空间。但摘要是有损的，重要事实可能会丢失。

**于是，Hermes 会先进行一次“记忆冲刷”。**

在压缩之前，它会发送一条指令告诉模型：

> “会话即将压缩，请保存任何值得记住的东西。优先保存用户偏好、修正建议和重复模式，而非具体的任务细节。”

然后它运行一次额外的模型调用，只开启 `memory` 工具。如果模型觉得有什么东西该留下来，就会在对话被“洗掉”之前把它写入 `MEMORY.md`。

![Image 5: 长对话压缩前的记忆冲刷流程](https://s.baoyu.io/imgs/2026-04-29/manthanguptaa-2034849672985288957/04-flowchart-search-flush.png)

* * *

## 第四层：作为程序记忆的技能（Skills）

Hermes 不仅能记住事实，还能记住**技能**。

技能（Skills）存储在 `~/.hermes/skills/` 下。当 Hermes 发现了一个复杂的流程、修复了一个棘手的问题或学会了更好的方法时，它可以将其保存为“技能”。

大多数记忆系统只关注“语义回溯”（名字、偏好、事实），但智能体还需要记住**如何做事**。

为了效率，Hermes 不会把所有技能都塞进提示词，而是只放一个**技能索引**，只有在需要时才加载具体的技能内容。

* * *

## 第五层：用于深层建模的 Honcho

最后是可选的 Honcho 层。如果说本地记忆是 Hermes 的笔记本，Honcho 就是它尝试构建的复杂用户模型。它能实现跨设备、跨平台的记忆连续性。

最精妙的是它如何在不破坏提示词缓存的前提下实现集成：

*   在会话的第一轮，Honcho 的上下文会被织入系统提示词。
*   在之后的对话中，为了保持提示词稳定，Honcho 的回溯内容会附加在**当前用户的提问**后面，而不是修改系统提示词。

**这确保了缓存依然有效，同时 AI 依然能读到最新的背景信息。**

* * *

## Hermes 与 OpenClaw 的区别

*   **OpenClaw**：记忆更接近“以 Markdown 为中心的存储”，日志和长效文件是主要事实来源。
*   **Hermes**：提示词记忆被严格限制，历史记录存在 SQLite 里，只有需要时才搜索。

**Hermes 更加关注缓存效率。** 它认为：不是所有东西都配住在“系统提示词”这个黄金地段。

![Image 6: Hermes 与 OpenClaw 的记忆系统差异](https://s.baoyu.io/imgs/2026-04-29/manthanguptaa-2034849672985288957/05-comparison-hermes-openclaw.png)

* * *

## 总结：Hermes 做对了什么？

1.   **冷热分离**：小规模提示词记忆负责常驻信息，搜索负责偶尔用到的信息。
2.   **缓存优先**：它意识到频繁改动提示词会导致延迟增加和成本上升。
3.   **记忆的多样性**：它承认记忆是分层的——包括个人画像、情景回溯、操作技能和深层建模。

Hermes 的核心设计原则最令我折服：**记忆应该让智能体变得更好用，而不是通过摧毁提示词的稳定性来换取博闻强识。**

真正的诀窍不是记住更多，而是在正确的层级、以正确的成本，记住正确的事情。