一次讲透 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 记忆系统，不是只靠一个功能，而是两层结构同时存在：

一层是静态记忆，写死在规则文件里
一层是动态记忆，通过检索系统随用随取

1）静态记忆：MEMORY.md

先说静态记忆，也就是 MEMORY.md。在 OpenClaw 的 workspace 目录下，有一个大写的 MEMORY.md 文件，通常位于 ~/.openclaw/workspace/MEMORY.md。

这个文件适合存放那些你希望它长期、稳定、反复记住的信息。比如：

你是谁
你的工作习惯
你的偏好
你跟它协作的规则
某些长期不变的重要背景

OpenClaw 每次新对话时，都会自动读取这个文件，所以写在里面的信息，它原则上都会一直记着。

但这里也有一个边界：MEMORY.md 不能写得太大。因为它每次都会被加载进上下文窗口。如果你把它写成一本书，那它本身就会开始挤占宝贵的短期记忆空间。

所以 MEMORY.md 适合存的是：规则、偏好、长期稳定的信息。 它不适合拿来装海量知识库。

例如，我会在 MEMORY.md 里写上这样的规则：当我提到选题、内容创作、标题、提纲、YouTube 视频、口播稿等话题时，OpenClaw 会主动读取一份选题与创作指南的文档，然后按我要求来执行。

## Content Creation Collaboration
- **核心指南文件**：`~/Workspace/Writing/Operation/公域内容选题与创作指南.md`
- **触发条件**：Kai 提到选题、内容创作、标题、提纲、YouTube 视频、口播稿、公域内容等相关话题时，主动读取该指南并按流程执行
- **核心策略**：工具做入口、方法论做内核、CTA 做出口；选题 7:3 配比（工具切入型 vs 纯观点型）
- **协作流程**：Kai 给选题方向 → Friday 评估公域爆发潜力 + 出标题方案 + 出提纲 → Kai 确认 → Friday 辅助创作

这类东西就非常适合放在 MEMORY.md 里。

2）动态记忆：Memory Search

再说动态记忆，也就是 Memory Search。如果你希望 OpenClaw 不只是记住一些固定规则，而是能真正记住过去所有对话、项目资料、知识库内容，那你就要用到它。OpenClaw 内置了一个基于 SQLite 的本地向量数据库，叫 SQLite-Vec，就是用来实现动态长期记忆的。

它的工作方式很像人类的回忆：当你提到某个话题时，系统不会把“所有历史资料”一股脑塞进当前上下文，而是先去长期记忆库里搜索，找到最相关的那一部分，再把它带回来。

比如当我提到 Palantir 这家公司时，系统就可能自动联想到：

我之前看过哪些资料
我过去写过哪些相关内容
我们之前聊过哪些相关观点

人脑靠联想，OpenClaw 靠向量检索。原理不同，但效果很接近。

现在你应该已经能理解，为什么我前面说频繁 /new 并不会让 OpenClaw 真正失忆。因为每次你 /new，当前对话并不是凭空消失了，而是会被归档、被索引、被纳入长期记忆系统。等未来你再提到相关话题，Memory Search 就会把它重新找回来。

所以理想的状态其实是这样的：

短期记忆保持轻量
长期记忆持续积累
新话题随时翻篇
旧信息需要时自动召回

这才是一套真正成熟的 AI 记忆系统。

六、怎么配置长期记忆：我自己的实战方案

接下来讲最关键的部分：怎么把 Memory Search 真正配置起来。要打开 OpenClaw 的长期记忆能力，核心就是三件事：

开启 Memory Search
告诉它要记住哪些内容
选择一个 Embedding Model

1）Embedding Model 怎么选？

所谓 Embedding Model，本质上就是把文本向量化，让系统可以按语义相似度去做检索。这个模型有很多选法。

如果你图省事，可以直接用云端模型，比如：

OpenAI
Gemini
阿里云
腾讯云

这些模型其实并不贵，正常使用下，一个月大概率也就是几美分到十几美分，不是大问题。

但如果你更想本地化，或者你担心批量索引的时候容易被云端 API 限流，那你也可以像我一样，直接用本地模型。

我现在用的是：

provider: ollama
model: bge-m3

这套方案的优点很明确：

本地成本低
可控性高
做大批量索引时不容易被限流
对中文场景也比较友好

如果你的知识库比较大，或者后面会经常重建索引，本地方案通常会更舒服。

2）最简单的配置方式：让 AI 帮你写

这里我反而不建议你一开始自己手写配置文件。最简单的做法，是直接把需求告诉 Codex 或者其他顺手的 AI 工具，让它帮你生成配置。

比如你可以直接说：

帮我给 OpenClaw 配置 Memory Search，选择一个合适的 Embedding Model，并把我的知识库目录一起纳入索引。

然后把 API Key 或者本地模型方案告诉它，它基本就能帮你把配置写出来。

OpenClaw 的配置文件位置是：~/.openclaw/openclaw.json

我现在在用的 memorySearch 配置如下：

"memorySearch": {
  "enabled": true,
  "sources": [
    "memory",
    "sessions"
  ],
  "extraPaths": [
    "/Users/robbin/Workspace"
  ],
  "provider": "ollama",
  "model": "bge-m3",
  "query": {
    "hybrid": {
      "enabled": true,
      "vectorWeight": 0.7,
      "textWeight": 0.3,
      "candidateMultiplier": 3,
      "mmr": {
        "enabled": true,
        "lambda": 0.7
      },
      "temporalDecay": {
        "enabled": true,
        "halfLifeDays": 90
      }
    }
  }
}

3）这套配置里，最关键的四个点

第一，`sources`

我这里同时打开了 memory 和 sessions。前者负责长期记忆，后者负责近期会话历史。这样配的好处是，它不仅能记住你长期稳定的信息，也能兼顾你最近正在做的任务和上下文状态。

第二，`extraPaths`

这是这套配置里，我认为最关键的一项。我把它指向了我的 Workspace，也就是我平时真正工作的目录。这里面有我的知识库、写作内容、项目资料和工作规划。

你把什么目录接进去，OpenClaw 就更容易理解你什么。所以如果你真的想让它“越来越懂你”，重点不是让它空泛地“多记一点”，而是要让它接触到你真正重要的工作语料。

这也是为什么很多人配置了记忆功能之后，效果还是一般。因为他虽然开了检索，但没有把真正有价值的内容接进去。

第三，`provider` 和 `model`

我这里用的是本地 Ollama 配合 BGE-M3。这样做的好处是：

批量索引的时候不容易碰到云端 API 的并发限制
本地成本低
中文效果也不错

如果你不想折腾本地部署，也完全可以先上云端方案。但如果你后面会频繁重建索引，本地模型通常更省心。

第四，`query` 下面的混合检索策略

我这里不是只用向量检索，而是用了 Hybrid Search。简单理解就是：

70% 靠语义理解
30% 靠关键词匹配

因为单纯靠向量检索，虽然能理解“你在说什么”，但对一些特别具体的内容，比如文件名、命令名、电话号码、地址、某些专有术语，关键词匹配往往更准。

所以混合检索的好处就是：既能理解含义，也能命中精确细节。

另外，我还打开了一个时间衰减机制，也就是 temporalDecay，半衰期设成 90 天。它的意思是：

越新的信息，权重越高
越旧的信息，权重会慢慢降低

这样系统在排序时，会更优先参考近期更有用的内容，而不会总把特别老的内容顶在最前面。

整体来说，这是一套我自己现在在用、而且我觉得比较稳的方案。你完全可以先照着用，后面再按自己的场景慢慢微调。

七、配置好之后怎么用？

配置完成之后，你可以先做两步验证。

第一步：建立索引

执行：openclaw memory index

这个命令会开始批量建立索引，把你的对话历史和知识库内容都向量化，写入长期记忆数据库。索引完成之后，它会存到 OpenClaw 目录下的 memory 子目录里。比如我的机器上，这个数据库文件叫 main.sqlite，现在已经有 176MB 左右了。你放进去的记忆越多，这个数据库自然也会越大。

第二步：做一次手工检索测试

执行：openclaw memory search [关键词]

输入一个关键词，看看它能不能稳定搜出相关内容。如果能搜出来，基本就说明你的长期记忆系统已经搭起来了。

但这里我想强调一点：平时正常使用 OpenClaw，你其实不需要天天手工去 search。真正的价值在于，当你把长期记忆库建好之后，未来你正常跟它聊天时，只要提到相关话题，它就会自己去检索、自己去回忆。

比如你说：“我之前跟你聊过某某某，你还记得吗？”它就会自动去找。

所以这套系统最理想的工作方式其实是：

你平时放心地用 /new 清理短期记忆
所有重要的历史对话和知识库都持续进入长期记忆库
未来需要的时候，它自动帮你找回来

这也是为什么我现在越来越觉得，OpenClaw 不只是一个聊天工具，而是真的开始变成我的第二大脑。

八、最后总结成一句话

如果你想真正把 OpenClaw 用好，你只需要记住一句话：短期记忆靠 /new 管理，长期记忆靠 MEMORY.md 和 Memory Search 来构建。

短期记忆的重点，不是拼命把上下文窗口撑到最大，而是保持它干净、轻量、够用。长期记忆的重点，也不是让它死记硬背所有内容，而是建立起一个可以随时被唤起的记忆库。

当这两套机制配合起来之后，OpenClaw 就不再只是一个聊天工具了。它会越来越了解你，越来越记得你说过的话、做过的项目、积累过的知识。到那个时候，你会发现小龙虾不只是“更聪明”了，而是真的开始变得“更懂你”。