OpenClaw 记忆系统
解释 OpenClaw 的记忆到底怎么工作、为什么它看起来会“失忆”，以及怎样把记忆做得更稳定。
为什么 OpenClaw 看起来会“失忆”
OpenClaw 不是因为一次聊天“很重要”就自动记住。它只有在信息被写进 workspace，并且后续还能被重新读取时，才算真的记住。
所以很多人以为记忆坏了，实际问题通常是下面几种：
- 重要信息根本没有落盘
- 写进了错误的记忆层
- 对话发生在群组上下文里
- session 在压缩前没有把持久信息写下来
理解这一点之后，OpenClaw 的记忆行为就会变得可解释很多。
记忆的真实来源是磁盘上的 Markdown
官方文档对这件事写得很明确：OpenClaw 的记忆是 workspace 里的 Markdown 文件，文件本身才是 source of truth，不是模型脑内的上下文幻觉。
这带来两个直接结果：
- 记忆对人类是可读、可改、可审计的
- “记住这件事”只有在它真的被写入文件时才有意义
这也是为什么安装和 workspace 健康状态，直接决定了记忆是不是可靠。
默认的两层记忆结构
memory/YYYY-MM-DD.md
这是每天的记忆日志。
- 默认按追加方式写入
- 适合运行中的上下文、临时笔记和当日工作记录
- OpenClaw 在 session 启动时会读取今天和昨天的文件
你可以把它理解成“运行记忆”，而不是整理好的知识库。
MEMORY.md
这是整理后的长期记忆层。
- 适合保存长期偏好、稳定事实和关键决策
- 应该比 daily log 更干净、更克制
- 只会在主私聊 session 中加载，不会在群聊上下文里直接带上
最后这一点，正是很多“为什么私聊记得、群里不记得”问题的根源。
不同信息应该写到哪里
最简单的判断规则是：
- 长期偏好和稳定事实写进
MEMORY.md - 临时上下文和过程性记录写进
memory/YYYY-MM-DD.md - 如果你真的想让某件事留下来，就明确让 assistant 把它写进去
不要把聊天记录本身等同于记忆。OpenClaw 可以帮你回忆，但持久层仍然是文件。
OpenClaw 是如何“回忆”的
OpenClaw 提供两个和记忆相关的工具：
memory_search：做语义检索memory_get：读取指定文件或指定片段
这说明“记忆”不是一个无限堆叠的大 prompt。更准确地说，它是把相关内容检索回来，再注入到当前回合里。
官方文档还特别提到，memory_get 在目标文件还不存在时会优雅退化，不会因为“今天的 memory 文件还没生成”就直接抛错。
向量记忆检索是增强，不是基础
OpenClaw 可以给 MEMORY.md 和 memory/*.md 建立语义索引。这样以后即使你的提问换了说法，也更容易把相关记忆找回来。
但这仍然不是魔法：
- 远程 embeddings 需要真实可用的 provider 和 API key
- 本地 embeddings 需要你把本地模型链路配好
- 就算没配向量检索，文件记忆仍然存在，只是 recall 质量会弱一些
所以最稳的顺序是：
- 先把 workspace 和文件结构配对
- 再确认 assistant 真的会写持久记忆
- 最后才去调向量检索
自动 memory flush 到底在做什么
OpenClaw 有一个 pre-compaction memory flush 机制。简单说，就是在 session 快要 compaction 时，它会触发一个静默的内部回合，提醒模型把值得保留的内容先写进记忆，再进行上下文压缩。
这很有用，但它不是万灵药。
边界很明确：
- 默认通常是静默执行，用
NO_REPLY避免打扰用户 - 每个 compaction 周期只会触发一次
- 依赖 workspace 可写
- 它救不回“从来没被判断为值得保存”的信息
如果 agent 运行在只读 workspace 里，这个安全网就会被跳过。
为什么私聊和群聊的记忆体验不同
OpenClaw 的记忆默认就是按上下文隔离的。私聊和群聊，本来就不该被当成同一块记忆池。
这不是 bug，而是安全设计。
- 长期
MEMORY.md默认服务于主私聊 session - 群聊上下文不应该随意继承私人记忆
- 检索范围也可以被 session policy 限制
所以如果你在群聊里测试记忆，不要默认它会和 dashboard 私聊一样。
常见记忆误区
以为聊天记录本身就是记忆
对话发生了，不代表持久记忆已经建立。
把 MEMORY.md 当成垃圾桶
如果所有东西都变成长记忆，那它很快就不再清晰，也不再容易检索。
期待群组默认继承私人记忆
大多数时候就不应该这样。OpenClaw 是故意保留这条边界的。
没配 embeddings 却期待高质量语义 recall
没有 embeddings 仍然能工作，但检索效果通常会弱一些。
workspace 是只读，却还期待记忆能稳定落盘
如果不能写文件，长期记忆和 compaction 前 flush 都会受影响。
一套更稳的记忆使用方式
对大多数操作者来说，最稳的顺序是：
- 先让 onboarding 正常创建 workspace
- 保留一个主私聊 session 作为长期记忆入口
- 需要记住时，优先在 dashboard 或私聊里操作
- 定期看一眼
MEMORY.md，保持它是整理过的 - 把 daily log 留给过程性上下文
- 只有基础稳定之后，再去调 vector search 或 QMD
这比把所有聊天面都强行当成一个全局记忆池，可靠得多。
FAQ
OpenClaw 的记忆存在哪里？
默认是 workspace 里的 Markdown 文件，通常位于 ~/.openclaw/workspace，包括 MEMORY.md 和 memory/YYYY-MM-DD.md。
为什么它在私聊记住了，在群聊却没记住？
因为长期整理后的记忆默认服务于主私聊 session，群聊上下文本来就会被更严格隔离。
没有向量检索，记忆还能工作吗？
可以。文件记忆本身仍然存在。向量检索只是增强 recall，不是记忆系统的地基。
想让记忆效果立刻变好，最该先做什么？
先确认 assistant 真的把重要事实写到了磁盘，保持 MEMORY.md 精炼，并且优先在私聊上下文里调试记忆，而不是直接在群里排查。