Hermes Agent Memory 解析：边界与取舍
嗨，我是 Lena。关于 Hermes Agent memory，我一直有个问题拖着没想清。每次有人把它描述成“会学习的 agent”，我都会停一下。到底学了什么？又记在哪里？我来回翻了几次文档，才觉得自己勉强摸到了一半答案。下面是我注意到的东西。
我写这篇，不是以 Hermes 构建者的身份，而是以一个旁观者的身份：我看这个系统看得足够久，慢慢看清它的 memory 在哪些地方确实符合人的预期，又在哪些地方其实安静地没有做到。两者之间的缝隙，比市场话术暗示的要大。诚实一点说出来，是值得的。
Hermes memory 实际存了什么
我首先得放下一个误解：Hermes 不是只有一套 memory 系统。它有好几套，而且做的不是同一件事。 我见过的大多数困惑，都来自把它们当成同一个东西。
MEMORY.md, USER.md, and frozen session snapshots
内置这一层，是放在 ~/.hermes/memories/ 里的两个 markdown 文件。根据 Hermes 官方 memory 文档，MEMORY.md 上限大约是 2,200 个字符（约 800 tokens），用来保存环境事实、项目约定，以及 agent 认为值得留下来的经验。USER.md 更小一些，大约 1,375 个字符，约 500 tokens，用来保存关于你的偏好。
这两个文件都会在 session 开始时作为 frozen snapshot 加载，并注入到 system prompt 里。这个词——frozen——就是我第一次读文档时一直漏掉的关键。session 中途写入的内容会立刻持久化到磁盘，但 active prompt 里的 snapshot 不会刷新，要等到下一次 session 开始。
我在这里停了一会儿。它解释了一个我之前见过、却一直对不上号的行为：agent 保存了某个东西，也说自己保存了，然后接下来却像还没真正拥有它一样继续行动。这不是 bug，而是 snapshot model。理解这一点之后，一些小小的不一致感就不再显得不一致了。
“Persistent” 在实践里到底是什么意思
这里的 “persistent” 确实有意义，但它做的事比市场词汇暗示的要窄。文件会跨 session 保留下来。它们是 agent-curated，不是 agent-recorded——由 LLM 判断什么值得保存。而且它们有意设置了上限：小而稳定的 system prompt，才让 prefix caching 变得高效；而 prefix caching 也是 agent 反应看起来很快的一部分原因。
所以，当有人说 Hermes “记得”时，更准确地说通常是：一个很小、刻意设边界的笔记本，会在每次 session 顶部重新加载；旁边还有一个可搜索的历史对话归档。两件不同的事，两种不同的访问模式。
Hermes memory 擅长什么
我想公平一点。内置系统确实有用——它只是并不是大多数人最初想象的那个东西。
Preferences, environment facts, recurring context
它最适合保存小而稳定、经常相关的事实。比如：
- “User's project is a Rust web service using Axum + SQLx”
- “User prefers concise responses, dislikes verbose explanations”
- “This machine runs Ubuntu 22.04, has Docker installed”
这类上下文每次都放进 system prompt 是合理的，Hermes 处理得也不错。agent 判断某些内容值得保留时会自动保存；条目堆多了也会做 consolidation，比如把三条 “project uses X” 合并成一段项目描述。在很短或范围很窄的 session 里，你可能完全看不到写入——这是 feature，不是 failure。大多数短任务本来就不该污染你的长期笔记本。
我还注意到 memory 条目会经过一个安全扫描步骤，用来捕捉 prompt-injection 尝试。这一点是在 Hermes GitHub 源码 里看到的，我挺喜欢这个细节。它很小，但正是这种细节会告诉你：有人认真想过，当一个 LLM 负责写自己的 memory 时，哪里可能出问题。
Hermes memory 解决不了什么
这里我不得不慢下来。很多期待会在这里断掉。我不觉得这是系统做错了什么——我更觉得是 memory 这个词承担了太多含义。
Bounded memory, session resets, no automatic validation of learned behavior
有几件事值得坦白讲清楚：
Memory 是有边界的。 环境信息大约 ~2,200 chars，用户信息大约 ~1,375 chars。达到上限之后，agent 必须先 consolidation 或移除条目，才能加入新内容。细腻的具体细节，可能就在这个过程中被压缩掉。 这是最常见的意外点——人们以为 memory 会增长；其实不会。小而固定的预算，就是这个设计本身。
Session 中途写入，不会出现在同一个 session 里。 frozen snapshot model 意味着 agent 会基于开头加载的内容行动，即使它后来写入了新条目。重启 session，它们才会进入上下文。如果你需要 agent 立刻基于刚写入的东西行动，就在对话里明确引用它——不要期待它自动出现。
Agent 必须自己 决定 要保存。 内置 memory 是基于判断的。没有自动转录。可配置的 nudge_interval 会周期性提示 agent 反思，但在短 session 里，你真的可能看到空文件。我可能有点过度解读了，但我觉得这是整个设计里最少被讲清楚的一部分。
没有自动验证。 如果 agent 保存了一条 “lesson learned”，而那条经验其实是错的，没有任何机制会自动标记它。这个事实会一直待在 snapshot 里，直到被某个东西替换掉。Memory 不等于经过验证的 knowledge——它只是某个 model 在某个时刻认为值得保留的东西。
Memory is not the same as reusable capability
这一部分我还专门回去重读了自己的笔记。Hermes 还有 skills——放在 ~/.hermes/skills/ 里的 markdown 文档，用来记录流程、用过的工具，以及跑通的步骤。Skills 通常会在复杂任务后被动创建（一般是 5+ 次 tool calls），并通过 progressive disclosure 按需加载：Level 0 只是 skill 名称和简短描述列表，Level 1 则在需要时加载某个具体 skill 的完整内容。
Memory 和 skills 是两回事，哪怕它们看起来都像 markdown 文件。
Memory 是“这个用户偏好什么、我们处在什么环境里”。Skills 是“这类任务应该怎么做”。一个偏好不会告诉 agent 如何 debug OAuth flow；一个 skill 可能会。把两者混在一起，我觉得是人们说“agent 没有学习”时最大的困惑来源。它也许确实在学习——只是没有发生在你正在检查的那一层。
Cross-session recall, session search, and where people get confused
除了 MEMORY.md 和 USER.md，Hermes 还会把所有 CLI 和 messaging sessions 存进 ~/.hermes/state.db 里的 SQLite，并用 FTS5 做全文搜索。agent 可以调用 session_search 工具来检索过去的对话，然后用一个小模型把结果总结出来。
有两个细节值得知道。
FTS5 是基于关键词的。 它是一个强大、工程成熟的索引——SQLite FTS5 documentation 解释了它如何 tokenize 内容，并基于这些 tokens 匹配——但它匹配的是 exact tokens，不是语义。如果过去某个 session 里说的是 “authentication microservice uses Redis”，你问 “what did I tell you about the auth service?”，它可能检索不到。agent 必须知道要调用 session_search，而且 要用对查询词。这里没有 entity resolution，没有关系追踪，也没有语义改写。
Session search 不是自动的。 它是一个由 agent 决定是否调用的工具。如果 agent 在回答前没想到要调用它，过去的对话就不会被查阅。这是行为上的缺口，不是存储上的缺口——数据在那里，只是 retrieval 没有发生。
这也是我看到人们最容易沮丧的地方。他们看到 agent 三周前讨论过某件事，就默认它会自然浮现。有时候会。更多时候不会，因为没有任何东西触发搜索。Vectorize 在他们的 Hermes memory troubleshooting 文章里对这些 failure modes 做了一个挺有用的拆解，我回去看了两遍。
Practical design advice for long-running Hermes workflows
我其实有点犹豫要不要给建议——我只是一个数据点。但观察了一阵子之后，有几件事确实很突出。
把内置 memory 当成一个小笔记本，而不是数据库。 任何需要随对话长度一起扩展的东西，都不该放在那里。用它保存那些稳定、每次都应该进入上下文的事实，同时接受一个现实：预算用完时，细节会被压缩。
重要的事要说清楚。 “Remember that my production database runs on port 5433” 比希望 agent 自己标记它要可靠。内置 memory 是 curated，不是 recorded——而 agent 对“什么重要”的判断，不会永远和你一致。
需要结构化 recall 时，就用 external provider。 Hermes memory providers page 列出了八个可插拔选项——Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, and Supermemory。它们是 additively 叠加在 MEMORY.md 和 USER.md 之上的，后两者会照常工作。内置层不会消失；外部层只是补上它做不到的部分。
具体到跨 session 的 user modelling，Honcho 采用的是 peer-based approach——用户和 AI 都被建模成 peers，各自有自己的 representation，并随着时间从 observations 中更新。这和扁平 fact store 是很不一样的设计哲学。我还在想，什么时候我会选它，什么时候用一个更简单的 vector store 就够了。但 multi-pass dialectic reasoning 确实有意思，尤其是 cold-start 和 warm-session 的区分。
不要把 memory 和 capability 混为一谈。 如果你希望 agent 下一次把某件事 做得 更好，你大概率想要的是 skill，而不是 memory entry。如果你希望它下一次一定 正确，那 memory 和 skills 都不会替你验证——你得自己验证。这也是我一直绕回来的地方。
FAQ
Hermes Agent memory 会随着时间变聪明吗？
文件会积累事实。至于这算不算“更聪明”，取决于你怎么定义。agent 会使用 snapshot 里的内容，但它不会对 memory edits 的 history 做推理，除非你接入了会做这件事的 external provider。这里我会谨慎使用 learn 这个词。
为什么跑了几个 sessions 之后，MEMORY.md 还是空的？
最可能的原因是 agent 从来没判断出有东西值得保存——短 session 或任务导向很强的 session，经常不会产生写入。检查一下你的 nudge_interval 配置；如果你想要不依赖 agent 判断的自动捕获，可以考虑 external provider。
我能不能直接把 limit 调大？
可以。字符上限可以在 ~/.hermes/config.yaml 里配置。但这个上限存在是有原因的——snapshot 越大，留给实际对话的空间越少，prefix-cache 的收益也越弱。更大不是免费的。
Session 中途 memory 会发生什么？
写入会落盘。active prompt 不会刷新，要等到下一次 session。这是预期行为。如果试图依赖同一个 session 内的 memory 更新，你会花很多时间 debug。
Session search 和 memory 是一回事吗？
不是。Memory 是始终加载的 snapshot。Session search 是对过去对话进行按需关键词检索。机制不同，延迟不同，失败模式也不同。
我还不准备给这件事画句号。Hermes Agent memory 这套栈里还有很多东西值得继续观察——尤其是当 external providers 背后有了几个月的数据之后，它们到底会怎样表现。至少现在，我的理解停在这里。
