Hermes Memory 实战：长期记忆适合存什么，不适合存什么

Hermes 应用 进阶 进阶 预计 13 分钟 发布于 2026/5/23 核验于 2026/6/1

Hermes Memory 的价值不在于“什么都记”，而在于知道什么值得长期记住。记忆一旦污染，会让 Agent 后续判断越来越偏。

官方文档说明 Hermes 有 bounded、curated memory，并使用 MEMORY.md 与 USER.md 两类文件来保存长期信息。这两个文件会在会话开始时注入系统提示，因此写入内容必须克制。

两类记忆怎么分

推荐写入的内容

适合写入 memory：

• 项目使用 pnpm、Astro、Vercel，构建命令是 npm run build。
• 用户偏好中文简洁回答，代码解释不要太长。
• 某个项目不要用 destructive git 命令。
• 某个部署环境只能使用固定 Node 版本。
• 迁移已在某天完成，后续不要重复执行。

不适合写入 memory：

• “用户今天问了 Python” 这种太模糊的信息。
• 大段错误日志和原始输出。
• 能轻易重新搜索到的通用知识。
• token、密码、私钥、session cookie。
• 尚未验证的一次性猜测。

三个真实场景

场景一：你长期维护一个 Astro 站点。适合写入 memory 的不是“今天改了首页”，而是“这个项目部署在 Vercel，构建前需要跑 build、seo-check、smoke-check，站点偏好中文内容和明确内链”。这类信息会反复影响未来任务。

场景二：你常让 Hermes 帮你写内容。适合写入 USER.md 的不是临时情绪，而是稳定偏好，例如“标题要具体，不写空泛口号，中文段落保持短句”。这样 Agent 后续会更像在延续你的写作标准。

场景三：你让 Hermes 接了消息入口。不要把群聊里的所有临时讨论都写进 memory。只有当某个决定会长期影响项目，例如“生产环境不能自动执行 destructive 命令”，才应该沉淀。

一句话：memory 不是日记本，而是长期协作的操作约定。

Memory 写入规则

建议你给 Hermes 一个明确的约束：

只有当信息会在未来多次影响项目决策、工具调用或沟通偏好时，才写入 memory。
不要保存 secrets，不要保存临时日志，不要保存未验证猜测。
当 memory 接近上限时，先合并旧条目，再写入新条目。

维护节奏

每周或每次大项目完成后，做一次记忆整理：

1. 删除过期项目路径。
2. 合并重复偏好。
3. 把“踩坑”改写成可执行约定。
4. 把临时任务记录移出 memory。
5. 确认没有 secrets。

记忆失效时先查什么

如果你觉得 Hermes “明明应该记得却没记住”，不要立刻继续追加 memory。先按顺序检查：

1. 这条信息是否真的写入了 MEMORY.md 或 USER.md。
2. 写法是否太长、太散，导致模型抓不到关键约束。
3. 是否存在相互矛盾的旧记忆。
4. 当前 profile 是否和写入 memory 的 profile 一致。
5. 这个场景是否更适合 skill、项目 README 或 session search，而不是 memory。

很多 memory 问题不是“记得太少”，而是“记得太杂”。越是长期运行的 Agent，越需要定期把记忆压缩成清晰规则。

和 Skills 的关系

Memory 负责记住事实和偏好，Skills 负责沉淀可复用动作。不要把流程步骤都塞进 memory；一旦某个流程稳定、重复、可审查，就应该考虑写成 skill。

完成检查

• 你能分清 MEMORY.md 和 USER.md 的用途。
• 你知道哪些信息绝不能写入 memory。
• 你已经给 Hermes 一条明确的 memory 写入原则。
• 你知道 session search 不是 memory 的替代品，而是查历史对话的工具。