前几天我在用 OpenClaw 的时候，先让它帮我整理一批材料，转头又让它接着写一段说明。结果我刚把话题切过去，它的口气就变了，像是前面那半小时根本没发生过。
那一瞬间我其实挺烦的。第一反应是 bug，第二反应是上下文不够大，第三反应才轮到我自己：是不是我把它当成了一个“什么都该一直记着”的聊天对象。折腾了一圈之后，我才慢慢意识到，OpenClaw 的记忆问题不是“记不住”，而是我一直把它的记忆当成一条线看。
我后来把这件事拆开之后，才发现它至少分成两层：短期记忆和长期记忆。只把它当成聊天框，很容易误判；把它当成一套工作系统，很多现象就突然能解释通了。
先说短期记忆
短期记忆其实就是当前会话里的上下文。你刚说过的话、贴过的代码、让它执行过的工具调用结果，都会暂时留在这一次对话里。
问题在于，这个“暂时”不是无限的。上下文越堆越多，OpenClaw 就越容易变重，越容易把更早的内容挤出去。你感觉它突然忘事，很多时候不是模型不行，而是工作台太满了。
我后来把这个问题想得很简单：短期记忆不是越大越好，而是要够用、轻量、干净。真正影响体验的，不只是窗口大小，还有你有没有及时把当前任务收口。
这里我踩过一个很现实的坑。比如我先让它看一段日志，再让它改一段配置，接着又让它写说明文档。我原本以为这是一条连续任务，实际上它已经是在同时背三份工作了。结果就是 token 费得快，响应也变慢，最后还会把前面已经定下来的东西重新问一遍。
我现在更认真地用 /new
如果只能选一个最有效的习惯，我现在会选 /new。
不是因为它很高级，而是因为它真的符合工作方式：一个话题结束，就翻篇。OpenClaw 不需要把所有旧任务都背在身上，你也不应该逼它一直背。
我现在更愿意把它当成一个节奏控制器。比如，我已经把一个问题的结论确认完了，或者一个任务已经收尾了，我就直接切到新会话。这样做的好处很直接：
- 上下文不会一直膨胀
- token 消耗会好看很多
- 新任务不会被旧噪音污染
以前我总觉得“记得更多”才是强能力。后来发现，真正强的是“该忘的时候能忘，该记的时候能找回来”。
长期记忆才是关键
短期记忆解决的是“这一次别断线”，长期记忆解决的才是“下次还能接上”。
OpenClaw 的长期记忆，我后来大致分成两部分看。
第一层是静态记忆，也就是 MEMORY.md。这更像一份长期规则。它适合放那些稳定不变的东西，比如我写东西时喜欢先结论后过程、我不想它一上来就铺太多方案、某些工作流要先确认边界再动手。
第二层是动态记忆，也就是 Memory Search。它不是把所有历史都硬塞回当前上下文，而是通过检索，把最相关的东西重新找出来。
这个区别很重要。MEMORY.md 解决的是“固定原则”，Memory Search 解决的是“按需回忆”。
如果只靠 MEMORY.md，它会变成一个越来越厚的规则文件，最后反而拖累短期记忆。
如果只靠 Memory Search，它又会缺少稳定的行为边界，今天记住，明天忘掉。
所以我现在更愿意把它们理解成两种不同的记忆方式：一个负责长期稳定，一个负责语义召回。
我现在怎么看 MEMORY.md
我以前对 MEMORY.md 的期待很高，后来才发现它其实不适合装“知识库”。
它更适合装规则和偏好。比如：
- 我让它先看完我的写作要求，再开始起草
- 某些话题必须先确认我到底是要整理、改写，还是直接产出
- 某些输出格式要默认固定，不要每次都重问一遍
这类东西很适合写进去，因为它们稳定，而且每次都能用。
但如果你把海量材料、碎片知识、项目历史全往里塞，它很快就会变胖。那样一来，短期记忆反而会被 MEMORY.md 自己吃掉。
所以我现在对它的定位很明确：MEMORY.md 不是仓库，MEMORY.md 是规则卡。
Memory Search 更像真正的档案柜
真正让我觉得 OpenClaw 变“像人”的，是 Memory Search。
它的工作方式不是把所有历史全文都灌回来，而是先去找最相关的那一小部分，再放回当前对话。这个体验很像人类回忆：不是把过去全部复读一遍，而是被某个关键词、某个项目名、某个上下文点一下，然后整段记忆回来。
这也是为什么我现在不太害怕 /new。因为会话结束不代表记忆断掉，只是从工作台上撤下来了。真正重要的东西，应该留在长期记忆里，等下一次再被召回。
我后来越来越确定，好的 AI 记忆系统不是“永不忘记”，而是“知道什么时候该放下，知道什么时候该找回”。
配置上，我更在意什么
如果要把这套东西真正跑起来，我现在最在意的不是“有没有记忆”，而是三件事：
- 短期记忆是不是足够轻
MEMORY.md里的规则是不是足够稳定- Memory Search 的检索是不是足够准
至于 embedding model，我反而没有那么执着。云端模型能用，本地模型也能用。真正在意的是：索引会不会太慢、召回会不会太偏、中文场景会不会跑偏、批量重建时会不会被限流。
我现在更能接受的方案，是把长期记忆拆成“规则”和“召回”两层来做。前者负责边界，后者负责恢复上下文。只要这两层配合好，OpenClaw 就不会像很多人想象得那样“聊着聊着就失忆”。
这套方法的代价
当然，它也不是没有代价。
第一，/new 用得太少，短期记忆还是会膨胀。
第二，MEMORY.md 写得太多，长期记忆反而会拖慢系统。
第三，Memory Search 如果调得不好，找回来的内容可能不够准，甚至会把你带偏。
所以这不是一个“配置完就结束”的问题，而是一个持续调整的问题。记忆系统本身就是工作流的一部分，不是一次性开关。
我现在的结论
我现在对 OpenClaw 记忆能力的理解，已经和最开始不太一样了。
我不再把“它会不会忘”当成唯一问题，而是把问题改成：
- 当前会话是不是太重
- 任务边界是不是该收口了
- 长期记忆有没有把真正重要的东西留下来
一旦这么看，很多“失忆”都不再像 bug，反而像一种提醒：你该翻篇了。
对我来说，OpenClaw 最实用的记忆能力，不是把一切都记住，而是让我可以放心地结束一个话题，再在下一个话题里继续接上。