别再抱怨 Hermes 记不住了，这才是它记忆系统的正确打开方式
Hermes 最常见的吐槽就是："我明明告诉过它，为什么还是不记得？"其实它有一套 Agent-curated memory 机制，它不是存储器，而是一个有选择、有原则的记忆大脑。高手从不指望它自动记住一切，而是主动设计三层记忆架构，让 Agent 的大脑保持高密度、可进化。今天这篇文章，就是把这套记忆系统的底层逻辑讲清楚，让你从"抱怨它记不住"升级到"主动设计它的记忆"。
一、三层记忆的严格职责划分
Hermes 的记忆系统分为三层，每一层都有明确的职责边界，混用就会出问题。这个设计看起来简单，但真正理解并用好它的人并不多，大多数人吃亏就吃亏在把不该放这里的记忆放到了那里。
第一层：SOUL.md — Agent 的宪法
这一层位于 ~/.hermes/SOUL.md，是整个记忆系统的根基。它的定位是"你写的、Agent 只读不变的硬性规则"。你的核心价值观、不可覆盖的偏好、行为准则全部写在这里。Agent 在任何情况下都不会主动修改它，除非你手动编辑。这就像给 Agent 立下的契约——它是铁律，是红线，是 Agent 决策的最高依据。把什么放这里？你的编程语言偏好、代码风格规范、项目命名约定、对特定问题的处理原则，凡是"不管什么任务都不能违背"的东西，都写进 SOUL.md。
第二层：MEMORY.md — Agent 的工作笔记
这一层位于 ~/.hermes/memories/MEMORY.md，由 Agent 自己维护，有 2,200 字符的硬上限。这里放的是当前项目的状态事实：项目结构是什么样的、当前在处理什么问题、用了什么技术方案、遇到了什么坑。MEMORY.md 是 Agent 在每个会话开始时注入上下文的第一块拼图，它让 Agent 知道自己身处什么环境、正在做什么事。但正因为它是自动维护的，所以有一条铁律必须记住：固定规则只写 SOUL.md，动态事实只写 MEMORY.md。MEMORY.md 会触发自动有损压缩，如果把你的核心规则写在这里，它会被压缩消失，然后你就会困惑"为什么 Hermes 又不记得这个规则了"。
第三层：USER.md — 用户画像
这一层位于 ~/.hermes/memories/USER.md，同样由 Agent 自己维护，有 1,375 字符的硬上限。顾名思义，这里存放的是关于"你"的信息：你的沟通风格是直接还是委婉、你习惯用中文还是英文、你更偏好详细解释还是简洁答案、你有什么特殊癖好或忌讳。USER.md 让每次新的会话都能快速重建对"这个用户是谁"的理解，而不需要从零开始猜。Agent 会自动把你透露的偏好同步到这里，省去你每次重复说明的麻烦。
三层记忆的注入时机是每个会话开始时：SOUL.md + MEMORY.md + USER.md 会以冻结快照的方式注入到 Agent 的上下文中。所以你每次开启新会话，Agent 都"记得"上次的重要信息——前提是你正确使用了各层级的存储位置。
二、主动管理容量，别等 Agent 乱删
MEMORY.md 的 2,200 字符上限不是摆设。当内容接近这个上限时，系统会触发有损压缩——自动删除部分"不太重要"的记忆来腾出空间。问题在于，Agent 对"重要"的判断未必和你一致，结果就是：你觉得关键的信息被删了，你觉得无关紧要的反而留下了。
高阶玩家的做法是主动干预容量管理，而不是被动等待系统乱删。以下是两个核心指令，直接发给 Hermes 就行：
第一，整理记忆指令。当你发现 MEMORY.md 快满了，或者 Agent 开始"健忘"了，直接说："请整理你的记忆，删除过时条目，合并重复内容，腾出空间。"Agent 会重新审视 MEMORY.md 中的每一条信息，删掉那些已经失效的、合并内容重叠的、优化表达方式，从而释放更多可用字符。这个操作你应该定期做，而不是等到问题出现了才想起来。
第二，提炼 Skill 指令。当同一个工作流在 MEMORY.md 里重复出现超过两三次了，这就是一个信号——应该把它固化成一个独立的 Skill 了。你可以对 Agent 说："请把这个部署流程提炼成 Skill，命名为 deploy-workflow，然后从 MEMORY.md 中删除。"这样做有两个好处：一方面 MEMORY.md 空间被释放给了真正需要频繁更新的信息，另一方面 Skill 是独立存储的，不受字符上限约束，随时可以调用。Skill 的本质就是把"程序性记忆"从紧张的工作笔记里剥离出来，让工作笔记只保留"当前状态"。
如何查看当前 MEMORY.md 的使用量？终端里执行一行命令就够了：wc -c ~/.hermes/memories/MEMORY.md。它会告诉你当前文件有多少字节，2,200 的上限用掉了百分之多少。建议你每周至少检查一次，在它接近满之前就做整理，而不是等它被系统强制压缩之后再来救场。
三、Flush 不是让它"现在就记住"
很多人在长任务进行中突然想起来一个重要信息，于是手动 Flush，然后期待 Agent 立刻改变行为——结果发现没有效果，于是又吐槽"Hermes 记不住"。这个误区的根源在于没有理解 Flush 的实际机制。
Hermes 每次会话开始时，会把 MEMORY.md 以冻结快照的方式注入上下文。这意味着注入之后的内容变化，在本次会话内是看不到的。你在会话中途写入 MEMORY.md 的内容，要到下一个新会话才会生效。Flush 操作本质上是在为下一个会话打草稿，而不是改变当前会话的行为。
这个机制有一个重要推论：长任务结束前必须做记忆总结。当你完成了一个复杂任务，在退出当前会话之前，应该让 Agent 总结当前进度，作为 Checkpoint 写入长期记忆。具体做法是：告诉 Agent "任务告一段落了，请把你的当前进度整理后写入 MEMORY.md，包括做到了哪一步、下一步计划是什么、有什么需要注意的事项"。这样下一会话开始时，Agent 直接从这个 Checkpoint 继续，而不需要你从头交代背景。
退出后记得验证是否写入成功：cat ~/.hermes/memories/MEMORY.md。检查一下刚才的内容是否真的出现在文件里了。如果文件里没有，那下一会话 Agent 就会"失忆"，你又要重新解释一遍。养成这个验证习惯，可以省去很多"它怎么又不记得了"的烦恼。
四、SOUL.md 模板，直接抄
理解了原理，接下来就是实操。SOUL.md 的内容完全由你决定，但下面这个模板经过实战验证，直接复制粘贴到你的 ~/.hermes/SOUL.md 里，按需修改即可。
nudge_interval 已在 config.yaml 中设为 3，每 3 轮必须触发记忆复盘，不得跳过。
用户说"记住这个硬性偏好"时，必须立即写入 MEMORY.md。
用户说"强制 Flush 记忆"时，必须调用 patch_memory 固化当前进度。
MEMORY.md 只保留结构化事实、偏好、项目蓝图，禁止写入对流水账。
本文件为元记忆锚点，任何自动压缩、重写或删除操作均被禁止。这五条规则覆盖了三个最核心的记忆管理场景：第一是确保记忆复盘足够频繁，不让过时信息积累；第二是确保用户的硬性偏好立刻被固化，不会因为会话结束而丢失；第三是确保 MEMORY.md 保持高密度，只装真正有价值的信息，把流水账式的过程记录拒之门外。
配合 SOUL.md 的使用，建议同时调整 config.yaml 中的 nudge_interval 参数。这个参数控制 Agent 多久触发一次记忆复盘行为，默认值是 10，但如果你和 Hermes 的会话通常比较短（比如每次只有五六轮），默认值就永远触发不了复盘。把它改成 3，每 3 轮强制触发一次，能让你的记忆系统运转得更及时。修改方法是在 config.yaml 的 memory 段落下添加或修改这一行：
memory:
nudge_interval: 3当然，数值越小触发越频繁，token 消耗也会相应增加。根据你的实际使用频率和会话长度，调整到适合自己的值。
五、入门靠自动，高手靠设计
说了这么多，核心观点其实就一句话：Hermes 的记忆系统不是自动运行的黑箱，你需要主动设计它。
入门玩家使用 Hermes 时，倾向于"我告诉它一次，它就应该记住"——这种思路在简单场景下或许能工作，但一旦任务复杂起来、项目多起来，就会发现 Agent 不是健忘就是乱记。问题的根源不在于 Hermes"笨"，而在于你没有给它设计好记忆架构。三层记忆体系的划分、本地上下文 vs 长期记忆的区分、容量上限的管理策略，这些都不是 Hermes 自动处理的，而是需要你作为主人来设计的。
高手的思维方式完全不同。他们把 SOUL.md 当作"宪法"，把 MEMORY.md 当作"项目状态面板"，把 USER.md 当作"用户画像档案"。他们定期检查容量、主动整理记忆、把重复流程提炼成 Skill、把重要结论固化为 Checkpoint。他们不是在"使用"记忆系统，而是在"运营"记忆系统——就像一个团队负责人持续维护知识库一样。
记忆系统的本质，是让 Agent 的大脑保持高密度、不腐烂、可进化。高密度意味着有限空间里装最有价值的信息；不腐烂意味着不会因为自动压缩而丢失关键规则；可进化意味着每次会话结束后都有新的积累而不是重置。做到这三点的记忆架构，才是真正有效的架构。
如果你之前一直在抱怨 Hermes 记不住，不妨从今天开始换个思路：不是问"它为什么不记得"，而是问"我有没有给它设计好记忆的位置"。答案往往就在三层记忆架构里。
