搜索 “Hermes memory” 的用户，多半已经跑通了 Hermes，但开始担心另一个问题：哪些东西应该让 Agent 长期记住，哪些东西应该留在项目文档、session search 或一次性上下文里？
Hermes Memory 的价值不在于“什么都记”，而在于把少量长期事实注入新会话。官方 memory 文档强调它是 bounded、curated memory，并说明 Hermes 会把 MEMORY.md 和 USER.md 的内容合并进上下文。记忆一旦污染，后续每一次判断都会被带偏。
先抓住 4 个判断
- Memory 适合保存会反复影响未来决策的事实和偏好，不适合保存临时日志。
MEMORY.md更偏项目与环境事实，USER.md更偏用户偏好和长期工作方式。- Memory 会在会话开始时进入上下文；session search 是查历史，不是把历史全部塞进 memory。
- 外部 memory provider 是扩展选择，不是默认必需；启用前要先想清隐私、权限和同步边界。
两类长期记忆怎么分
| 文件 | 更适合保存 | 不适合保存 |
|---|---|---|
MEMORY.md | 项目路径、工具链、构建命令、部署约定、已验证踩坑、长期禁用动作 | 临时日志、整段代码、一次性报错、未验证猜测 |
USER.md | 用户偏好、沟通风格、长期工作期待、固定输出格式 | API Key、隐私凭据、短期情绪、一次性喜好 |
| Session Search | 查过去某段对话、命令、决定或上下文 | 代替结构化项目文档或长期规则 |
| 项目 README | 公开或团队共享的架构、命令、部署步骤 | 个人偏好、私密身份信息 |
一个简单判断：如果这条信息会在未来 5 次以上影响 Hermes 的选择，就可以考虑 memory；如果只是今天这次任务要用，放在当前上下文或任务记录里就够了。
推荐写入的内容
适合写入 memory：
- 这个项目使用 Astro，发布前必须依次跑
npm run build、npm run seo:check、npm run smoke:check。 - 用户偏好中文短段落，不要写空泛营销话术。
- 某个仓库禁止使用 destructive git 命令。
- 某个部署环境固定 Node 版本，不能临时升级。
- 某次迁移已经完成，后续不要重复执行。
- 某个 profile 只用于测试，不能访问生产 secrets。
不适合写入 memory：
- “用户今天问了 Python” 这种太模糊的信息。
- 大段错误日志和完整终端输出。
- 能轻易重新搜索到的通用知识。
- token、密码、私钥、session cookie、OAuth refresh token。
- 尚未验证的一次性猜测。
- 高频变化的待办事项，例如“明天上午十点发消息”。
三个真实场景
场景一：你长期维护一个 Astro 站点。适合写入 memory 的不是“今天改了首页”，而是“这个项目发布前必须串行跑 build、seo-check、smoke-check；smoke 会启动本地 listener；不要把 .codex/ 提交”。这类规则会反复影响后续任务。
场景二：你常让 Hermes 帮你写内容。适合写入 USER.md 的不是临时情绪，而是稳定偏好，例如“标题要具体，不写空泛口号，中文段落保持短句，并给出下一步内链”。这样 Agent 后续会延续你的写作标准。
场景三：你让 Hermes 接了消息入口。不要把群聊里的所有临时讨论写进 memory。只有当某个决定会长期影响项目，例如“生产环境不能自动执行 destructive 命令”或“外部消息入口只能触发只读检查”，才应该沉淀。
Memory 写入规则
建议你给 Hermes 一条明确约束：
只有当信息会在未来多次影响项目决策、工具调用或沟通偏好时，才写入 memory。
不要保存 secrets，不要保存临时日志，不要保存未验证猜测。
当 memory 接近容量或出现重复时，先合并旧条目，再写入新条目。如果你和 Hermes 一起维护多个项目，可以再加一条：
写入项必须标明适用项目、profile 或环境；不确定适用范围时，先不要写入全局 memory。什么时候用 session search
session search 更适合回答“之前我们怎么做过”：
| 问题 | 推荐位置 |
|---|---|
| 上次迁移失败的报错是什么 | session search |
| 这个项目永久不用 force push | memory |
| 这周讨论过哪些候选标题 | session search 或任务文档 |
| 发布前必须串行跑哪些命令 | memory 或 skill |
| 某个功能的长期架构说明 | 项目 README |
不要把 session search 查出来的整段历史复制进 memory。更好的做法是把历史压缩成一句可执行规则，再决定是否写入。
外部 memory provider 怎么判断
官方 Memory Providers 文档提供了外部 provider 的配置方向。对个人用户来说，默认文件记忆通常已经够用；外部 provider 更适合团队、跨设备、集中管理或需要更强检索能力的场景。
启用前先回答这些问题：
- 这份记忆会不会包含客户、团队或个人隐私？
- 谁能读取 provider 里的数据？
- profile 切换后是否会共享同一套 memory？
- provider 挂掉时 Hermes 应该继续运行、降级还是停止？
- 如何导出、清理或撤回错误写入？
如果这些问题答不上来，不要为了“更高级”而启用外部 provider。memory 是长期输入源，权限边界比功能数量更重要。
每周维护节奏
每周或每次大项目完成后，做一次记忆整理：
- 删除过期项目路径。
- 合并重复偏好。
- 把“踩坑”改写成可执行约定。
- 把临时任务记录移出 memory。
- 检查是否出现 secrets、token 或内部链接。
- 确认每条规则都有适用项目或 profile。
- 把稳定流程移到 skill，把公开团队约定移到 README。
很多 memory 问题不是“记得太少”，而是“记得太杂”。越是长期运行的 Agent，越需要定期把记忆压缩成清晰规则。
记忆失效时先查什么
如果你觉得 Hermes “明明应该记得却没记住”，不要立刻继续追加 memory。先按顺序检查：
- 这条信息是否真的写入了
MEMORY.md或USER.md。 - 写法是否太长、太散，导致模型抓不到关键约束。
- 是否存在相互矛盾的旧记忆。
- 当前 profile 是否和写入 memory 的 profile 一致。
- 是否被新会话、provider、session 或上下文边界影响。
- 这个场景是否更适合 skill、项目 README 或 session search，而不是 memory。
如果你已经遇到具体故障，下一步看 Hermes memory 不生效排查。那篇会按“没写入、没注入、被覆盖、profile 错配、内容太散”逐层定位。
和 Skills 的关系
Memory 存事实，Skills 存动作。比如：
- “这个项目使用 pnpm” 适合进入 memory。
- “发布前依次跑 lint、build、seo-check、smoke-check” 更适合变成 skill。
- “这个用户不喜欢营销话术” 适合进入
USER.md。 - “每周生成内容缺口报告并输出表格” 适合进入 skill 候选池。
如果把动作塞进 memory，会让上下文变长但执行仍不稳定；如果把事实写进 skill，又会让技能在不同项目里变得脆弱。长期协作要把事实、流程和历史分别放在正确位置。
完成检查
- 你能分清
MEMORY.md和USER.md的用途。 - 你知道哪些信息绝不能写入 memory。
- 你已经给 Hermes 一条明确的 memory 写入原则。
- 你知道 session search 不是 memory 的替代品，而是查历史对话的工具。
- 你能判断是否真的需要外部 memory provider。
- 你知道什么时候应该把稳定动作沉淀成 skill。