# I Read Hermes Agent's Memory System, and It Fixes What OpenClaw Got Wrong
**作者**: Manthan Gupta
**日期**: 2026-03-20T04:29:02.000Z
**来源**: [https://x.com/manthanguptaa/status/2034849672985288957](https://x.com/manthanguptaa/status/2034849672985288957)
---
If you've read my previous posts on ChatGPT memory, Claude memory, and OpenClaw memory, you already know I keep coming back to the same question: how do these agents actually remember?
Hermes Agent was particularly interesting to me because this time, I did not have to reverse engineer everything from behavior alone. Hermes is open source, and both the repo and the docs are public. So instead of poking a black box with prompts, I went straight to the code paths that build prompt state, persist sessions, flush memories, and query past conversations.
The short version is this: Hermes does not have one memory system. It has four.
1. A very small, curated prompt memory stored in `MEMORY.md` and `USER.md`.
2. A searchable SQLite archive of past sessions exposed through `session_search`.
3. Agent-managed skills that act like procedural memory
4. An optional Honcho layer for deeper user modeling
And the key design choice tying all of this together is simple: keep the prompt stable for caching, and push everything else to tools.
Let's dive right in.
# Hermes's Context Structure
Before understanding memory, it helps to understand what Hermes is actually sending to the model.
The system prompt is assembled roughly like this:
```
[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
```
This matters because Hermes is optimizing for provider-side prompt caching. The prompt builder is very explicit about this in the source: the stable prefix should stay stable for as long as possible.
That one decision explains most of Hermes's memory architecture.
If a piece of information should be available on every turn, Hermes tries to keep it tiny and inject it once. If it is large, historical, or only occasionally useful, Hermes pushes it out of the prompt and retrieves it on demand.
## Layer 1: Frozen Prompt Memory
The built-in memory system is surprisingly small.
Hermes stores durable memory in two files under `~/.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 |
```
That is not much. Roughly 1,300 tokens combined.
And that is deliberate.
At session start, Hermes loads both files, renders them into a prompt block, and then freezes that snapshot for the rest of the session. Mid-session writes are persisted to disk immediately, but they do not mutate the already-built system prompt. Those changes only show up when a new session starts, or after a compression-triggered prompt rebuild.
The rendered format looks like this:
```
══════════════════════════════════════════════
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
```
There are a few subtle design choices here that I like:
1. It uses character limits, not token limits
This keeps the memory logic model-agnostic. Hermes does not need model-specific tokenization just to decide whether memory is full.
2. It uses a simple delimiter based file format
Entries are separated with `§`. No vector DB. No custom binary store. Just plain text files.
3. It keeps system-prompt memory intentionally tiny
This is probably the most important point in the entire design. Hermes is not trying to stuff its entire history into prompt memory. It wants only the highest-value facts there.
4. It treats memory as a curated state, not a diary
This is where Hermes is very different from OpenClaw.
OpenClaw had an append-only flavor to its daily logs. Hermes explicitly pushes in the opposite direction. The tool schema and tests say:
- Save user preferences
- Save the environment facts
- Save recurring corrections
- Save stable conventions
- Do not save task progress
- Do not save session outcomes
- Do not save the temporary TODO state
The truth is that Hermes wants `MEMORY.md` and `USER.md` to stay hot, compact, and cache-friendly.
## The `memory` Tool
Hermes manages these files through a single `memory` tool with three actions:
- `add`
- `replace`
- `remove`
There is no real read action in the current tool surface because the memory is already injected into the prompt at session start.
One nice usability detail is that `replace` and `remove` use substring matching. You do not need an internal ID. You just pass a unique substring from the existing entry.
Example:
```
memory(
action="replace",
target="memory",
old_text="dark mode",
content="User prefers light mode in VS Code, dark mode in terminal"
)
```
The system also rejects exact duplicates and blocks dangerous content before it ever enters prompt memory. The source scans memory entries for prompt-injection patterns, credential exfiltration strings, SSH backdoor hints, and invisible Unicode characters.
That makes sense. Anything written to memory is effectively becoming part of the future system prompt.
## Layer 2: `session_search` for Episodic Recall
If `MEMORY.md` and `USER.md` are Hermes's hot memory, then `session_search` is its long-tail recall system.
All past sessions are stored in `~/.hermes/state.db`, a SQLite database with:
- A `sessions` table
- A `messages` table
- An FTS5 full-text search index
- Lineage links through `parent_session_id`
When the model needs to recall something from a previous conversation, Hermes does not search `MEMORY.md`. It searches the session database.
The pipeline looks like this:
```
FTS5 search over past messages
-> group results by session
-> resolve parent/child lineage
-> load top matching sessions
-> truncate transcript around relevant matches
-> summarize each session with a cheap auxiliary model
-> return focused recaps to the main model
```
This is a very different philosophy from systems that try to semantically index every memory note.
Hermes is basically saying:
- Keep the always-injected memory tiny
- Store the real history in SQLite
- Search that history only when needed
- Summarize the results before handing them back
That is a pragmatic design.
It is also cheaper than blindly stuffing long histories into every prompt.
The docs describe `session_search` as a way to answer questions like:
- "Did we discuss this last week?"
- "What did we do about X?"
- "As I mentioned before..."
In other words, `MEMORY.md` is for durable facts, while `session_search` is for episodic recall.
## Layer 3: Compression and the Memory Flush
Another clever part of Hermes is what happens before it compresses a long conversation.
As sessions grow, Hermes eventually summarizes the middle portion of the conversation to stay within the model's context window. But summarization is lossy. Important facts can disappear.
So Hermes does a memory flush first.
Before compression, it injects a synthetic system/user instruction that basically says:
```
The session is being compressed.
Save anything worth remembering.
Prioritize user preferences, corrections, and recurring patterns over task-specific details.
```
Then it runs one extra model call with only the `memory` tool available.
If the model decides something should survive compression, it writes it to `MEMORY.md` or `USER.md` before the conversation gets summarized away.
That is a genuinely good pattern.
It gives the model one last chance to distill the durable bits before the middle of the conversation is collapsed.
Even better, after compression, Hermes invalidates and rebuilds the cached system prompt, reloading memory from disk. That means anything flushed right before compression becomes part of the next stable prompt snapshot.
So the flow is:
```
Long conversation
→ flush durable facts to memory
→ compress old turns
→ rebuild prompt
→ continue with smaller context and updated memory
```
This is the kind of thing that makes Hermes feel like an actual memory architecture instead of a bolt-on note store.
## Layer 4: Skills as Procedural Memory
Hermes's memory story is not just facts and transcripts.
It also has skills.
Skills live under `~/.hermes/skills/` and act like reusable knowledge documents. The docs explicitly describe them as the agent's procedural memory.
When Hermes discovers a non-trivial workflow, fixes a tricky issue, or learns a better way to do something, it can save that as a skill and reuse it later.
This is a big deal.
Most memory systems focus only on semantic recall: names, preferences, facts, and summaries. But agents also need to remember how to do things, not just what happened.
Hermes handles that by separating procedural knowledge from prompt memory:
- `MEMORY.md` / `USER.md` for compact, durable facts
- `session_search` for episodic recall
- `skills` for reusable workflows
There is also a nice token-efficiency trick here. Hermes does not blindly inject every skill into the prompt. It injects a compact skills index and only loads full skill content when needed.
That keeps procedural memory available without paying the full token cost on every turn.
## Layer 5: Honcho for Deeper User Modeling
Then there is the optional Honcho layer.
If local memory is Hermes's curated notebook, Honcho is its attempt at a richer user model.
Honcho runs alongside the built-in memory system in `hybrid` mode by default. It adds:
- Cross-session user modeling
- Cross-machine and cross-platform continuity
- Semantic search over user context
- Dialectic, LLM-generated answers about the user or the AI peer
The interesting part is how Hermes integrates it without wrecking prompt caching.
First turn vs later turns
On the first turn of a session, prefetched Honcho context can be baked into the cached system prompt.
On later turns, Hermes avoids mutating that stable system prompt. Instead, it attaches Honcho recall to the current user's turn at API-call time only. That means:
- The stable prefix stays stable
- Prompt caching still works
- Turn N can consume context prefetched in the background after turn N-1
This is a very smart compromise.
Honcho itself also models two peers:
- The user
- The AI assistant
So Hermes is not just trying to remember you. It can also build a representation of itself over time.
That is both cool and slightly wild.
# How Hermes Differs from OpenClaw
Since I wrote about OpenClaw recently, this comparison is worth making explicit.
## OpenClaw
- Memory is much closer to Markdown-first storage
- Daily logs and long-term memory files act as the primary source of truth
- Memory recall leans on hybrid search over stored notes
## Hermes
- Prompt memory is aggressively bounded
- Session history lives in SQLite, not in prompt memory files
- Past work is recalled through `session_search`
- Procedural memory is pushed into skills
- Deeper user modeling is optionally delegated to Honcho
The key insight here is that Hermes is more cache-aware than OpenClaw.
OpenClaw leans harder into "memory as searchable stored knowledge." Hermes leans harder into "memory as a hot working set plus cold retrieval layers."
I actually think this is the right direction for production agents.
Not everything deserves to live in the system prompt.
# What Hermes Gets Right
After going through the repo and docs, I think Hermes gets three big things right.
## 1. It separates hot memory from cold recall
This is the core architectural win.
Small prompt memory for what always matters. Search for what only sometimes matters.
## 2. It treats prompt stability as a first-class constraint
A lot of agent systems talk about memory without talking about caching. Hermes clearly cares about both.
Frozen snapshots, delayed prompt updates, turn-level Honcho injection, and compressed-session rebuilds all point to the same design principle: don't casually mutate your prompt if you want good latency and cost.
## 3. It acknowledges that memory is plural
Hermes does not pretend that one store solves everything.
It has:
- Semantic profile memory
- Episodic session recall
- Procedural memory through skills
- Optional higher-order user modeling through Honcho
That is a much more realistic view of what agents actually need.
# Conclusion
Hermes's memory system is not a giant knowledge base, and it is not a glorified vector store. It is a layered continuity architecture.
At the center is a tiny curated prompt memory: `MEMORY.md` and `USER.md`. Around that sits a searchable SQLite history for episodic recall. Beyond that sits a skills system for procedural reuse. And if you enable Honcho, Hermes adds a deeper user model on top of everything else.
The design principle underneath all of it is what impressed me the most: memory should help the agent stay useful without destroying prompt stability.
That is the real trick.
Not remembering more. Remembering the right things, in the right layer, at the right cost.
# References
- Hermes Agent GitHub Repository
- Hermes Persistent Memory Docs
- Hermes Prompt Assembly Docs
- Hermes Session Storage Docs
- Hermes Skills Docs
- Hermes Honcho Docs
This post is based on reading the Hermes source code and documentation directly, not black-box reverse engineering, so if the implementation changes upstream, parts of this analysis may age. If you found this interesting, I'd love to hear your thoughts. Share it on X/ Twitter, LinkedIn, or reach out at guptaamanthan01[at]gmail[dot]com.
## 相关链接
- [Manthan Gupta](https://x.com/manthanguptaa)
- [@manthanguptaa](https://x.com/manthanguptaa)
- [377K](https://x.com/manthanguptaa/status/2034849672985288957/analytics)
- [ChatGPT memory](https://manthanguptaa.in/posts/chatgpt_memory)
- [Claude memory](https://manthanguptaa.in/posts/claude_memory)
- [OpenClaw memory](https://manthanguptaa.in/posts/clawdbot_memory)
- [repo](https://github.com/NousResearch/hermes-agent)
- [docs](https://hermes-agent.nousresearch.com/docs/getting-started/quickstart)
- [Honcho](https://hermes-agent.nousresearch.com/docs/user-guide/features/honcho)
- [Hermes Agent GitHub Repository](https://github.com/NousResearch/hermes-agent)
- [Hermes Persistent Memory Docs](https://hermes-agent.nousresearch.com/docs/user-guide/features/memory)
- [Hermes Prompt Assembly Docs](https://hermes-agent.nousresearch.com/docs/developer-guide/prompt-assembly)
- [Hermes Session Storage Docs](https://hermes-agent.nousresearch.com/docs/developer-guide/session-storage)
- [Hermes Skills Docs](https://hermes-agent.nousresearch.com/docs/user-guide/features/skills)
- [Hermes Honcho Docs](https://hermes-agent.nousresearch.com/docs/user-guide/features/honcho)
- [X/ Twitter](https://twitter.com/manthanguptaa)
- [LinkedIn](https://www.linkedin.com/in/manthanguptaa/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:29 PM · Mar 20, 2026](https://x.com/manthanguptaa/status/2034849672985288957)
- [377.6K Views](https://x.com/manthanguptaa/status/2034849672985288957/analytics)
- [View quotes](https://x.com/manthanguptaa/status/2034849672985288957/quotes)
---
*导出时间: 2026/4/30 09:23:03*
---
## 中文翻译
# 深入 Hermes Agent 的记忆系统：它如何修正 OpenClaw 的缺陷
**作者**: Manthan Gupta
**日期**: 2026-03-20T04:29:02.000Z
**来源**: [https://x.com/manthanguptaa/status/2034849672985288957](https://x.com/manthanguptaa/status/2034849672985288957)
---
如果你读过我之前关于 ChatGPT 记忆、Claude 记忆和 OpenClaw 记忆的文章，你应该知道我一直在反复探讨同一个问题：这些 Agent 到底是如何记住东西的？
Hermes Agent 对我来说特别有意思，因为这一次，我不需要完全通过逆向工程行为来推测原理。Hermes 是开源的，代码库和文档都是公开的。所以，我没有用提示词去试探黑盒，而是直接去研究了构建提示状态、持久化会话、刷新记忆和查询历史对话的代码路径。
简单来说：Hermes 并没有单一的“记忆系统”。它有四个。
1. 一个极小的、经过筛选的存储在 `MEMORY.md` 和 `USER.md` 中的提示记忆。
2. 一个可通过 `session_search` 搜索的 SQLite 会话归档。
3. 像程序性记忆一样起作用的 Agent 管理技能。
4. 用于更深层用户建模的可选 Honcho 层。
将这一切联系在一起的关键设计决策很简单：保持提示稳定以利用缓存，并将其他所有内容推给工具。
让我们深入了解。
# Hermes 的上下文结构
在理解记忆之前，有必要先了解一下 Hermes 到底向模型发送了什么。
系统提示的组装大致如下：
```
[0] 默认 Agent 身份
[1] 工具感知的行为引导
[2] Honcho 集成块（可选）
[3] 可选系统消息
[4] 冻结的 MEMORY.md 快照
[5] 冻结的 USER.md 快照
[6] 技能索引
[7] 上下文文件 (AGENTS.md, SOUL.md, .cursorrules, .cursor/rules/*.mdc)
[8] 日期/时间 + 平台提示
[9] 对话历史
[10] 当前用户消息
```
这很重要，因为 Hermes 正在针对提供商端的提示缓存进行优化。提示构建器在源码中对此非常明确：稳定的前缀应尽可能长时间保持稳定。
这一个决定解释了 Hermes 大部分的记忆架构。
如果一条信息需要在每一轮对话中都可用，Hermes 会尝试让它保持极小并只注入一次。如果它很大、是历史性的，或者只是偶尔有用，Hermes 会将其推出提示词，并在需要时检索。
## 第 1 层：冻结的提示记忆
内置的记忆系统小得惊人。
Hermes 将持久化记忆存储在 `~/.hermes/memories/` 下的两个文件中：
```
| 文件 | 用途 | 限制 |
|------|---------|-------|
| `MEMORY.md` | 关于环境、约定、工具怪癖、经验教训的 Agent 笔记 | 2,200 字符 |
| `USER.md` | 用户档案：偏好、沟通风格、身份 | 1,375 字符 |
```
这并不多。总共大约 1,300 个 Token。
这是有意为之。
在会话开始时，Hermes 加载这两个文件，将它们渲染成一个提示块，然后冻结该快照，直到会话结束。会话中间的写入会立即持久化到磁盘，但它们不会改变已经构建好的系统提示。这些更改只有在启动新会话时，或者在触发压缩后的提示重建时才会出现。
渲染后的格式如下所示：
```
══════════════════════════════════════════════
MEMORY (你的个人笔记) [67% — 1,474/2,200 字符]
══════════════════════════════════════════════
用户的项目是一个位于 ~/code/myapi 的 Rust Web 服务，使用 Axum + SQLx
§
这台机器运行 Ubuntu 22.04，安装了 Docker 和 Podman
§
用户更喜欢简洁的回复，不喜欢冗长的解释
```
这里有我喜欢的一些微妙的设计选择：
1. 它使用字符限制，而不是 Token 限制
这使记忆逻辑与模型无关。Hermes 不需要特定于模型的分词器来决定记忆是否已满。
2. 它使用简单的基于分隔符的文件格式
条目之间用 `§` 分隔。没有向量数据库。没有自定义二进制存储。只有纯文本文件。
3. 它将系统提示记忆保持得非常小
这可能是整个设计中最重要的一点。Hermes 并没有试图将它的整个历史塞进提示记忆中。它只想要最高价值的事实。
4. 它将记忆视为经过筛选的状态，而不是日记
这是 Hermes 与 OpenClaw 非常不同的地方。
OpenClaw 的每日日志有一种只追加的味道。Hermes 明确地反向操作。工具模式和测试表明：
- 保存用户偏好
- 保存环境事实
- 保存反复出现的修正
- 保存稳定的约定
- 不要保存任务进度
- 不要保存会话结果
- 不要保存临时的 TODO 状态
事实是，Hermes 希望 `MEMORY.md` 和 `USER.md` 保持热加载、紧凑和缓存友好。
## `memory` 工具
Hermes 通过一个单一的 `memory` 工具管理这些文件，该工具具有三个操作：
- `add`（添加）
- `replace`（替换）
- `remove`（移除）
在当前的工具界面中没有真正的读取操作，因为记忆在会话开始时就已经注入到提示中了。
一个很好的可用性细节是，`replace` 和 `remove` 使用子字符串匹配。你不需要内部 ID。你只需传入现有条目中的一个唯一子字符串。
例如：
```
memory(
action="replace",
target="memory",
old_text="dark mode",
content="用户在 VS Code 中偏好浅色模式，在终端中偏好深色模式"
)
```
系统还会拒绝完全重复的条目，并在危险内容进入提示记忆之前将其阻止。源码会扫描记忆条目中的提示注入模式、凭据泄露字符串、SSH 后门提示和不可见的 Unicode 字符。
这很有道理。写入记忆的任何内容实际上都会成为未来系统提示的一部分。
## 第 2 层：`session_search` 用于情景回忆
如果 `MEMORY.md` 和 `USER.md` 是 Hermes 的热记忆，那么 `session_search` 就是它的长尾回忆系统。
所有过去的会话都存储在 `~/.hermes/state.db` 中，这是一个 SQLite 数据库，包含：
- 一个 `sessions` 表
- 一个 `messages` 表
- 一个 FTS5 全文搜索索引
- 通过 `parent_session_id` 建立的谱系链接
当模型需要回忆之前对话中的某些内容时，Hermes 不会搜索 `MEMORY.md`。它搜索会话数据库。
流程如下：
```
对过去消息进行 FTS5 搜索
-> 按会话分组结果
-> 解析父/子谱系
-> 加载匹配度最高的会话
-> 截断相关匹配点周围的逐字稿
-> 使用廉价的辅助模型总结每个会话
-> 将重点回顾返回给主模型
```
这与试图对每条记忆笔记进行语义索引的系统截然不同。
Hermes 基本上是在说：
- 保持始终注入的记忆极小
- 将真实的历史存储在 SQLite 中
- 仅在需要时搜索该历史
- 在交还之前对结果进行总结
这是一个务实的设计。
这也比盲目地将长历史塞进每个提示要便宜。
文档将 `session_search` 描述为回答以下问题的一种方式：
- “我们上周讨论过这个吗？”
- “我们对于 X 做了什么？”
- “正如我之前提到的……”
换句话说，`MEMORY.md` 用于持久化事实，而 `session_search` 用于情景回忆。
## 第 3 层：压缩与记忆刷新
Hermes 另一个聪明之处在于它在压缩长对话之前所做的工作。
随着会话的增长，Hermes 最终会总结对话的中间部分，以保持在模型的上下文窗口内。但总结是有损的。重要的事实可能会丢失。
所以 Hermes 首先进行记忆刷新。
在压缩之前，它会注入一条合成的系统/用户指令，基本上是这么说的：
```
会话正在被压缩。
保存任何值得记住的内容。
优先考虑用户偏好、修正和反复出现的模式，而不是特定于任务的细节。
```
然后，它只使用 `memory` 工具再运行一次额外的模型调用。
如果模型认为某些内容应该在压缩后保留，它会在对话被总结之前将其写入 `MEMORY.md` 或 `USER.md`。
这确实是一个很好的模式。
它在对话中间部分被折叠之前，给模型最后一次提炼持久化内容的机会。
更好的是，压缩后，Hermes 会使缓存的系统提示失效并重建，从磁盘重新加载记忆。这意味着就在压缩之前刷新的任何内容都将成为下一个稳定提示快照的一部分。
所以流程是：
```
长对话
→ 将持久化事实刷新到记忆
→ 压缩旧的轮次
→ 重建提示
→ 以更小的上下文和更新的记忆继续
```
正是这类事情让 Hermes 感觉像是一个真正的记忆架构，而不是一个附带的笔记存储。
## 第 4 层：作为程序性记忆的技能
Hermes 的记忆不仅仅是事实和逐字稿。
它还有技能。
技能位于 `~/.hermes/skills/` 下，充当可复用的知识文档。文档明确将它们描述为 Agent 的程序性记忆。
当 Hermes 发现一个非平凡的工作流，修复了一个棘手的问题，或者学会了更好的做事方法时，它可以将其保存为技能并在以后重用。
这是一件大事。
大多数记忆系统只关注语义回忆：名字、偏好、事实和总结。但 Agent 还需要记住如何做事情，而不仅仅是发生了什么。
Hermes 通过将程序性知识与提示记忆分离来处理这个问题：
- `MEMORY.md` / `USER.md` 用于紧凑、持久化的事实
- `session_search` 用于情景回忆
- `skills` 用于可复用的工作流
这里还有一个不错的 Token 效率技巧。Hermes 不会盲目地将每个技能注入提示。它注入一个紧凑的技能索引，并且只在需要时加载完整的技能内容。
这使得程序性记忆可用，而无需在每一轮都支付完整的 Token 成本。
## 第 5 层：Honcho 用于更深入的用户建模
还有可选的 Honcho 层。
如果说本地记忆是 Hermes 的筛选笔记本，那么 Honcho 就是它对更丰富用户模型的尝试。
Honcho 默认以 `hybrid` 模式与内置记忆系统并行运行。它增加了：
- 跨会话用户建模
- 跨机器和跨平台连续性
- 对用户上下文的语义搜索
- 关于用户或 AI 同行的辩证、LLM 生成的答案
有趣的是 Hermes 如何在破坏提示缓存的情况下集成它。
第一轮 vs 后续轮次
在会话的第一轮，预取的 Honcho 上下文可以烘焙到缓存的系统提示中。
在后续轮次中，Hermes 避免改变那个稳定的系统提示。相反，它仅在 API 调用时将 Honcho 回忆附加到当前用户的轮次。这意味着：
- 稳定前缀保持稳定
- 提示缓存仍然有效
- 第 N 轮可以消耗在第 N-1 轮后在后台预取的上下文
这是一个非常聪明的折衷方案。
Honcho 本身也建模了两个同行：
- 用户
- AI 助手
所以 Hermes 不仅试图记住你。它还可以随着时间的推移建立自己的表示。
这既酷又有点狂野。
# Hermes 与 OpenClaw 的不同之处
既然我最近写过关于 OpenClaw 的文章，这个比较值得明确提一下。
## OpenClaw
- 记忆更接近 Markdown 优先存储
- 每日日志和长期记忆文件作为主要真实来源
- 记忆回忆依赖于对存储笔记的混合搜索
## Hermes
- 提示记忆被激进地限制
- 会话历史存在于 SQLite 中，而不是在提示记忆文件中
- 过去的工作通过 `session_search` 回忆
- 程序性记忆被推入技能
- 更深入的用户建模被可选地委托给 Honcho
这里的关键洞察是，Hermes 比 OpenClaw 更有缓存意识。
OpenClaw 更倾向于“记忆作为可搜索的存储知识”。Hermes 更倾向于“记忆作为热工作集加冷检索层”。
我实际上认为这是生产环境 Agent 的正确方向。
不是所有东西都值得生活在系统提示中。
# Hermes 做对的地方
在浏览了代码库和文档后，我认为 Hermes 做对了三件大事。
## 1. 它将热记忆与冷回忆分开
这是核心架构上的胜利。
对于总是重要的事情，使用小的提示记忆。对于只是有时重要的事情，使用搜索。
## 2. 它将提示稳定性视为一等约束
许多 Agent 系统谈论记忆却不谈论缓存。Hermes 显然关心两者。
冻结快照、延迟提示更新、轮级 Honcho 注入和压缩会话重建都指向同一个设计原则：如果你想要良好的延迟和成本，就不要随意改变你的提示。
## 3. 它承认记忆是复数的
Hermes 不假装一个存储能解决所有问题。
它有：
- 语义档案记忆
- 情景会话回忆
- 通过技能实现的程序性记忆
- 通过 Honcho 实现的可选高阶用户建模
这是一个对 Agent 实际需求更现实的看法。
# 结论
Hermes 的记忆系统不是一个巨大的知识库，也不是一个花哨的向量存储。它是一个分层的连续性架构。
中心是一个微小的、经过筛选的提示记忆：`MEMORY.md` 和 `USER.md`。周围是一个用于情景回忆的可搜索 SQLite 历史。除此之外是一个用于程序性复用的技能系统。如果你启用 Honcho，Hermes 会在所有这些之上添加一个更深的用户模型。
其下的设计原则是最让我印象深刻的：记忆应该帮助 Agent 保持有用，而不破坏提示稳定性。
这才是真正的技巧。
不是记得更多。而是在正确的层级，以正确的成本，记住正确的事情。
# 参考文献
- Hermes Agent GitHub 仓库
- Hermes 持久记忆文档
- Hermes 提示组装文档
- Hermes 会话存储文档
- Hermes 技能文档
- Hermes Honcho 文档
这篇文章基于直接阅读 Hermes 源代码和文档，而不是黑盒逆向工程，所以如果上游实现发生变化，本文分析的某些部分可能会过时。如果你觉得这很有趣，我很想听听你的想法。在 X/Twitter、LinkedIn 上分享，或者通过 guptaamanthan01[at]gmail[dot]com 联系我。