搜索 “Hermes memory” 的用户，多半已经跑通了 Hermes，但开始担心另一个问题：哪些东西应该让 Agent 长期记住，哪些东西应该留在项目文档、session search 或一次性上下文里？
Hermes Memory 的价值不在于“什么都记”，而在于把少量长期事实注入新会话。当前官方默认上限是 MEMORY.md 2200 字符、USER.md 1375 字符；超过上限时工具返回错误，不会静默丢弃旧条目。两个文件在会话开始时作为冻结快照进入系统上下文，因此记忆一旦污染，后续判断也会被带偏。
本站验证范围： 本页于 2026-09-09 核读 v0.21.1 / v2026.9.7 当前 Persistent Memory、Memory Providers、Sessions 和 CLI Commands，并检查 M00–M12 空白验收表；没有安装 Hermes、写入真实记忆或连接外部 provider。
先抓住 5 个判断
- Memory 适合保存会反复影响未来决策的事实和偏好，不适合保存临时日志。
MEMORY.md更偏项目与环境事实，USER.md更偏用户偏好和长期工作方式。- Memory 会在会话开始时进入上下文；session search 是查历史，不是把历史全部塞进 memory。
- 默认
write_approval: false会允许前台和后台复盘自由写入；敏感环境应先打开审批门禁。 - 外部 memory provider 是叠加能力，不会替代内置文件；当前一次只能启用一个。
两类长期记忆怎么分
| 文件 | 更适合保存 | 不适合保存 |
|---|---|---|
MEMORY.md | 项目路径、工具链、构建命令、部署约定、已验证踩坑、长期禁用动作 | 临时日志、整段代码、一次性报错、未验证猜测；默认 2200 字符 |
USER.md | 用户偏好、沟通风格、长期工作期待、固定输出格式 | API Key、隐私凭据、短期情绪、一次性喜好；默认 1375 字符 |
| Session Search | 查过去某段对话、命令、决定或上下文 | 代替结构化项目文档或长期规则 |
| 项目 README | 公开或团队共享的架构、命令、部署步骤 | 个人偏好、私密身份信息 |
一个简单判断：如果这条信息会在未来 5 次以上影响 Hermes 的选择，就可以考虑 memory；如果只是今天这次任务要用，放在当前上下文或任务记录里就够了。
做一次跨会话记忆练习
本练习使用默认文件记忆，并始终在一个专用测试 profile 中进行。不要同时让两个 Agent 进程写同一个 Hermes home。默认文件位于 ~/.hermes/memories/；使用 profile 时，以 hermes dump 显示的实际 HERMES_HOME 为准。
下载 M00–M12 记忆生命周期验收表。任何未做的步骤填“未验证”，不要把预期答案复制到实际结果栏。
M00–M02：先建立基线和审批门禁
在本机检查 MEMORY.md 与 USER.md 都没有 AC-MEM-041，只记录匹配结果，不把整份私人记忆复制到验收表。
在测试 profile 的 ~/.hermes/config.yaml 设置：
memory:
memory_enabled: true
user_profile_enabled: true
memory_char_limit: 2200
user_char_limit: 1375
write_approval: true当前官方说明，write_approval: true 会让前台写入、消息入口写入和后台自我改进复盘先进入 staged 状态。它不是关闭 Memory；完全关闭内置记忆需要同时把 memory_enabled 与 user_profile_enabled 设为 false。
M03–M06：拒绝一次，再批准一次
发送下面的写入请求，观察是否真的调用 memory 工具并把目标写成 memory。聊天里说“记住了”不等于已经持久化。
这是一次默认文件记忆练习，测试后会清理。
请使用 memory 工具，仅添加下面这一条带范围的测试事实，不修改其他记忆：
“仅用于 AC-MEM-041 练习项目：报表尾注标记是松果-73。”
告诉我写入到了哪个记忆目标，以及工具是否报告成功。
如果不能保存，请如实说明原因，不要把聊天回复当作写入成功。第一次请求后运行：
/memory pending
/memory reject <id>拒绝后检查 MEMORY.md 仍不含标记。再发送同一请求，用 /memory pending 找到新的 ID，先核对完整内容，再执行 /memory approve <id>。只有文件出现精确条目，M06 才通过。
M07–M09：区分同会话、冻结快照和历史检索
同一会话先问一次标记，只把它记作 M07。然后结束会话，在同一个 profile 中新建会话。默认文件记忆会在会话开始时以冻结快照进入系统上下文；同一会话追问不能证明新会话注入成功。
新会话只发送下面的问题，不带答案：
AC-MEM-041 练习项目的报表尾注标记是什么？
请说明依据来自持久记忆还是历史会话检索；没有依据就回答未知，不要猜。验收分两层： 文件里存在记录只证明持久化；同 profile 新会话依据冻结记忆回答，才证明本次注入可用。如果它调用 session_search 才找到答案，应记为历史会话检索成功，不能当作默认 Memory 注入成功。
M10–M12：替换、删除和历史边界
要求 Hermes 用唯一 substring 松果-73 把标记替换为 松果-74。当前 replace 与 remove 都使用唯一子串匹配；匹配多项时应返回错误，不能随意修改所有条目。
替换通过后，只删除含 AC-MEM-041 的练习条目，检查文件确认新旧值都已移除。删除默认记忆不等于删除历史对话；之后仍可能通过 session search 找到测试内容。需要清理历史时，按官方会话管理说明定位测试会话，不直接清空整个数据库。
推荐写入的内容
适合写入 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 文档列出 Honcho、OpenViking、Mem0、Hindsight、Holographic、RetainDB、ByteRover 和 Supermemory 八种插件，一次只能启用一个。外部 provider 会叠加上下文预取、会话同步、结束时提取和 provider 工具；内置 MEMORY.md / USER.md 仍继续工作，因此启用外部 provider 会扩大数据流，而不是把本地文件自动迁走或替换。
先用命令确认状态，不在聊天里粘贴密钥：
hermes memory status
hermes memory setup
hermes memory off对个人用户来说，默认文件记忆通常已经够用；外部 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 写入原则。
- 你验证了 write approval 的 pending、reject 和 approve，而不是只看聊天回复。
- 你在同一 profile 的新会话中区分了冻结记忆注入与 session search。
- 你用唯一 substring 完成替换与删除，且没有碰到其他条目。
- 你知道 session search 不是 memory 的替代品，而是查历史对话的工具。
- 你能判断是否真的需要外部 memory provider。
- 你知道什么时候应该把稳定动作沉淀成 skill。