OpenClaw 的 Memory 到底是怎么工作的？

很多人第一次接触 OpenClaw Memory，会把它理解成：

Memory 不就是一个本地 RAG 吗？

确实很像。

它同样涉及 Chunk、Embedding、向量检索、全文检索和混合召回。

但要真正理解 Memory，得先搞清楚它到底“记”了什么。

一、Session 和 Memory 有什么区别？

OpenClaw 的记忆可以简单理解成两层：

Session
   ↓
原始对话记录
   ↓
提炼重要信息
   ↓
Memory

Session：短期记忆

Session 保存当前会话中的原始对话。

例如：

用户：我是 Java 后端开发。
用户：以后回答技术问题尽量使用 Java 技术栈。
用户：文章不要写得太像营销号。

这些首先属于会话记录。

Memory：长期记忆

真正值得长期保留的信息，可以进一步沉淀到 Memory，例如：

用户偏好：
- Java 后端开发
- 技术问题优先使用 Java 技术栈
- 写作避免营销号、爆款腔

所以两者最大的区别是：

Session 记录“聊过什么”，Memory 保存“以后还值得记住什么”。

二、Memory 本质上存在哪里？

OpenClaw 的长期记忆本体主要是 Markdown 文件。

例如：

MEMORY.md
memory/
├── 2026-03-18.md
├── 2026-03-19.md
└── ...

可以简单理解为：

MEMORY.md
→ 更长期、更稳定的结论和偏好

memory/*.md
→ 日记式记忆，记录阶段性的重要信息

这里有一个非常重要的概念：

Markdown 才是 Memory 的内容本体，SQLite 更像它的检索加速层。

否则 Memory 文件越来越多，总不能每问一个问题，就把几百个 Markdown 全部读一遍。

所以 OpenClaw 会给 Memory 建索引。

三、Memory 怎么建立索引？

整个过程可以压缩成四步：

Markdown
   ↓
发现文件变化
   ↓
切成 Chunk
   ↓
建立全文 + 向量索引
   ↓
SQLite

比如一篇很长的 Memory，会先被拆成多个 Chunk。

每个 Chunk 再走两条路：

              Chunk
             ↙     ↘
          FTS      Vector
           ↓          ↓
       关键词检索    语义检索

这样以后查记忆，就不用扫描全部 Markdown。

可以通过：

openclaw memory status

查看 Memory 当前的索引状态。

四、为什么要做混合检索？

这是 OpenClaw Memory 很关键的一点。

它不是只做向量检索，而是把关键词检索和语义检索结合起来。

比如搜索：

openclaw memory search "nomic-embed-text"

这种查询最重要的是：

字符串要准确命中。

这时候全文检索更有优势。

而如果搜索：

上次说过不要那种爆款腔的写法是什么？

用户可能根本没有说出 Memory 原文中的关键词。

但：

爆款腔
营销号
写作风格
表达偏好

语义上又非常接近。

这时候向量检索就更有价值。

所以可以简单理解成：

FTS5 + BM25
负责“字面上像不像”

Vector / Embedding
负责“意思上像不像”

        ↓

     混合召回

这其实已经非常接近一个轻量级 RAG 系统了。

五、Memory 和 RAG 到底有什么区别？

两者底层思想确实非常像：

        Memory / RAG
             │
             ↓
           Chunk
             ↓
         Embedding
             ↓
      Keyword + Vector
             ↓
          Retrieval
             ↓
            LLM

真正的区别更多在使用场景。

RAG 通常解决：

“从外部知识库里找到答案。”

比如公司文档、产品手册、技术资料、客服知识库。

Memory 更偏向解决：

“从 Agent 自己过去的经历里找到答案。”

比如：

用户是谁
用户有什么偏好
之前做过什么决定
上次任务执行到了哪里
哪些信息以后还需要继续使用

所以可以记一句：

RAG 检索的是知识，Memory 检索的是过去。

六、Agent 怎么使用 Memory？

Memory 并不是每次对话都把所有文件塞进上下文。

更合理的方式是：

用户提问
   ↓
Agent 判断需要历史信息
   ↓
memory_search
   ↓
找到相关片段
   ↓
memory_get
   ↓
读取具体内容
   ↓
生成答案

例如 Agent 想知道：

用户以前喜欢什么文章风格？

先搜索相关 Memory。

找到对应文件和片段后，再读取具体内容。

这样最大的好处就是：

Memory 可以越来越多，但不需要每次全部塞进 Context。

既保留了长期记忆，又控制了 Token 消耗。

七、Memory 最适合记什么？

比如我有一个 Agent 专门处理账号审核。

每次都重复告诉它：

审核完成发到哪个群
加入哪个项目组
回复采用什么格式

非常麻烦。

这些稳定规则就很适合沉淀成 Memory：

# 审核偏好

- 审核完成后通知运营群
- 通过后加入指定项目组
- 回复采用固定审核格式

以后 Agent 再执行类似任务，就可以从 Memory 中找回这些规则。

这才是长期记忆真正有价值的地方。

最后总结

OpenClaw Memory 的整个工作流程，其实可以浓缩成一张图：

Session 原始对话
       ↓
   提炼重要信息
       ↓
Markdown Memory
       ↓
     Chunk
       ↓
┌──────┴──────┐
↓             ↓
FTS/BM25    Embedding
关键词检索    向量检索
└──────┬──────┘
       ↓
    混合召回
       ↓
memory_search
       ↓
 memory_get
       ↓
     Agent

所以面试官再问：

“OpenClaw Memory 和 RAG 有什么区别？”

千万别只回答：

一个 SQLite，一个 Elasticsearch。

更准确的理解是：

两者底层都可以使用 Chunk、Embedding 和混合检索，但解决的问题不同。RAG 主要让 Agent 检索外部知识，Memory 主要让 Agent 找回自己的历史、上下文和用户偏好。

RAG 让 AI 有知识，Memory 让 AI 有过去。

而一个真正长期陪伴用户工作的 Agent，不能只有知识，还得记得我们曾经一起做过什么。