为什么 OpenClaw 会“失忆”？如何把它变成真正的第二大脑
很多人用 OpenClaw，一段时间后都会遇到同一个问题：聊着聊着，它突然像失忆了一样，不记得前面说过什么；或者刚聊完一个话题，切到下一个话题，它就像换了一个人，之前的上下文全断掉了。
这种体验会让人很抓狂，因为你明明已经投入了很多时间跟它建立协作关系，但它总在关键时刻“忘事”。但这件事其实不是 bug，本质上，是大多数人并没有真正理解 OpenClaw 的记忆系统是怎么运作的。
今天这篇文章，我一次性把这件事讲透：OpenClaw 的“失忆”到底是怎么发生的，短期记忆应该怎么管理，长期记忆应该怎么构建，以及怎么把 OpenClaw 真正调教成一个越来越懂你的“第二大脑”。
只要你理解它的记忆机制，并做几步正确配置，OpenClaw 不但不会遗忘，反而会越用越了解你。
我现在每天都离不开 OpenClaw，就是因为它记得我所有的事情、所有的对话，也拥有我知识库里的大量知识。很多事情我一时想不起来，第一反应就是去找它。如果你把这套方法搭起来，你也会开始有这种感觉。
一、先建立一个最重要的认知：OpenClaw 有两种记忆
对于 OpenClaw 这样的 AI 智能体来说，它的记忆能力可以分成两类：短期记忆和长期记忆。很多人用 AI 出问题，往往不是因为模型不够强，而是因为把这两种记忆混在一起了。
1）短期记忆：上下文窗口
所谓短期记忆，就是你这一次对话里的上下文。在当前会话中，它会一直记得你前面说过的话、给过的任务、贴过的资料，以及工具调用过程中产生的各种结果。
但短期记忆不是无限的，它受模型上下文窗口限制。比如 GPT-5.4 的上下文窗口大约是 256k token，Claude Opus 的窗口可以到 100 万 token。窗口越大，一次能容纳的内容就越多；但一旦内容开始逼近上限，系统就会压缩甚至丢弃更早的内容。你感觉到的“它突然失忆了”，很多时候就是这么来的。
你可以把短期记忆想象成你的工作台。工作台当然很重要，因为你现在正在处理的东西都摆在上面。但工作台是有面积的，你往上面不断堆东西，堆到最后，最底下的内容就会被压住、被挤掉、被看不见。
所以短期记忆的核心问题，从来不是“它要不要记”，而是两件事：它一次能装多少，以及你有没有在合适的时候清理它。
2）长期记忆：持久化存储 + 检索唤起
长期记忆，则是另外一套机制。它不是把所有东西一直塞在当前上下文里，而是把历史信息保存到文件、数据库或者索引系统中，等未来聊到相关话题时，再把最相关的部分提取出来，重新带回当前对话。
你可以把它理解成档案柜。工作台上放的是你当前正在处理的东西；档案柜里放的是你过去积累下来的资料、偏好、项目状态、知识库和历史记录。工作台空间有限，档案柜容量几乎无限。
所以现在你就能理解一个核心问题了：大多数人觉得 AI 会失忆，不是因为 AI 真的不能记，而是因为只在用短期记忆，没有建好长期记忆。你如果试图只靠上下文窗口解决所有问题，迟早会撑爆。
二、短期记忆怎么管：核心不是更大，而是更干净
很多人以为，只要把上下文窗口开得越大越好，AI 就越不容易忘。这其实是一个很常见的误区。因为上下文窗口变大，当然能让它在单次对话中记住更多东西，但你也要同时承担代价。
1）第一个代价：Token 消耗会暴涨
假设你把一个 100 万 token 的窗口聊满了，那么之后你每发一条新消息，系统都可能要把这整个窗口重新提交给模型处理。也就是说：
聊 1 次，可能就是 100 万 token
聊 10 次，就是 1000 万 token
聊 100 次，就是 1 亿 token
所以很多人看到别人“每天消耗几亿 token”，会觉得不可思议。其实很多时候不是他做了多夸张的事情，而是因为上下文窗口一直处于高负载状态。
2）第二个代价：速度和性能都会下降
上下文越大，模型处理负担越重，延迟越高，GPU 资源消耗也越大。所以除非你是在做那种确实需要一次性读取超大代码库、超长文档的工作，否则上下文窗口并不是越大越好。
短期记忆最好的状态，不是“无限大”，而是三个词：够用、轻量、干净。
三、OpenClaw 如何自动瘦身短期记忆
这里要补充一个很多人不知道的细节。很多人以为 OpenClaw 会一直把所有上下文无限堆上去，完全不做处理。严格来说，不是这样。OpenClaw 提供了一个叫 contextPruning 的配置，可以用来做短期记忆的自动瘦身。
比如我自己的配置是这样的：
"contextPruning": {
"mode": "cache-ttl",
"ttl": "2h"
}这段配置的意思是：当一个会话闲置超过两小时后，在下一次请求发给模型之前，系统会自动剪裁旧的工具结果。
这里被剪裁的，主要是这些内容：
检索片段
文件读取内容
命令输出
浏览器快照
其他工具调用产生的大块结果
这些内容可能会被替换成占位符或者摘要；而用户与 assistant 的核心对话消息，会优先保留。你可以把它理解成一种轻量级的自动清理机制，它的作用主要有三个：
控制 token 消耗
降低延迟
避免工具结果不断堆积，把上下文撑爆
但这里有一个很关键的点：它解决的是“上下文太胖”的问题，不是“你已经换了一个新话题”的问题。
也就是说，它会帮你自动瘦身，但它并不知道你现在是不是应该彻底翻篇了。所以，自动瘦身有用，但还不够。
四、短期记忆最重要的习惯：聊完一个话题就 /new
如果你问我，管理短期记忆最好的方法是什么，我的答案不是装一堆复杂插件，而是养成一个非常简单的习惯：聊完一个话题，就输入 /new。
这是一个非常重要的动作，因为它会做两件事：
把当前对话归档
清理当前上下文，开启一个新话题
这意味着什么？意味着你不需要强迫 OpenClaw 把所有东西一直背在身上。你可以很自然地让它“做完这件事，就翻篇”。这其实特别符合真实工作流。
比如你刚才在聊编程，下一分钟开始规划文章选题，你并不需要它继续把前面一大段代码细节背在上下文里，因为那些内容对当前任务已经不重要了。
这也是为什么我一直觉得，短期记忆最好的管理方式，不是“永不清理”，而是“及时清理”。很多人之所以觉得 OpenClaw 特别烧 token，本质上就是因为从来不清 Context。一直聊、一直堆、一直不翻篇，最后自然就越来越重。
只要你养成“一个任务结束就 /new”的习惯，256k 的上下文窗口在大多数日常使用场景里其实完全够用了。
但这时很多人会问一个问题：那我频繁 /new，前面聊过的东西不就全没了吗？不会，前提是你把长期记忆建起来。
五、长期记忆怎么建：静态记忆 + 动态记忆
真正成熟的 OpenClaw 记忆系统，不是只靠一个功能，而是两层结构同时存在：
一层是静态记忆，写死在规则文件里
一层是动态记忆，通过检索系统随用随取
