别把聊天记录全塞进知识库：AI 记忆到底怎样才省钱又找得准？

别把聊天记录全塞进知识库，这篇文章帮你理清AI记忆系统的设计逻辑，学会如何省钱又高效。
核心内容：
1. 完整聊天记录不适合长期记忆的底层原因
2. OpenClaw三层记忆系统的分工与设计本意
3. 实现精准检索的关键因素与常见误区

_{桦说AI ｜ 2026-07-22}

先问你一个问题。

你有没有干过这种事：用 AI agent 攒了几个月的聊天记录、笔记、文档，心一横，全塞进它的长期记忆里——想着"资料越全，它就越懂我"。

结果呢？越用越贵，越问越答不到点子上。

如果你正卡在这儿，这篇文章就是写给你的。我拿 OpenClaw 这套记忆系统当样本，把"该不该全塞进去""为什么检索不准又烧钱"这两件事，掰开揉碎讲清楚。

说在最前面：这篇不卖结论，卖方法。 我不会甩给你"省了 60% token""快了 3 倍"这种数字——那些必须来自你自己在同等条件下的实测。我给你的是一套能自己验证的思路，加上一堆有官方出处的事实。

一、那个很多人踩的坑

先讲个反直觉的点。

你以为把东西写进长期记忆文件（OpenClaw 里叫 MEMORY.md），AI 每次都能读到全部。

错。

OpenClaw 官方文档写得很明白：当 MEMORY.md 超过了"启动预算"，磁盘上的文件是完整的没错，但真正注入到对话上下文里的那份副本，会被截断。

换句话说，你塞得越多，超出预算的那部分根本进不了 AI 的脑子。你付了存储的心理成本，却没换来任何效果，反而因为文件臃肿拖慢、拖贵了每一次调用。

官方甚至直接把这个当成一个"信号"：一旦被截断，就说明你该把细节挪走了——长期记忆里只留持久的摘要，细节沉到每日笔记里去。

这就是第一课：完整聊天记录，天生就不该待在长期记忆里。 这不是我的观点，是这套系统的设计本意。

二、先搞懂：AI 的记忆其实是分层的

要理解上面那个坑，得先看清 OpenClaw 把记忆分成了几层。它本质上就是磁盘上的几个 Markdown 文件——"模型只记住写到磁盘上的东西，没有隐藏状态"。

第一层｜MEMORY.md（长期 · 策展层） 只放持久事实、你的偏好、既定决策、短摘要。官方原话：它是"精炼、经过策展的一层，不是原始记录、不是每日日志、不是完整归档"。每次会话开始时加载。

第二层｜memory/YYYY-MM-DD.md（每日 · 工作层） 放具体的运行上下文、观察、细节。它会被检索索引，但不会每一轮都硬塞进上下文——要用的时候才检索出来。

第三层｜DREAMS.md（可选 · 复盘层） 记忆整理和复盘时的人工可读产物。

关键在于：AI 会自己随时间把每日笔记里有用的内容"蒸馏"进长期记忆，并删掉过期的旧条目。你不需要手工逐条搬。

看明白了吗？这套三层设计从头到尾都在说同一句话——别把完整记录堆在长期层，让细节待在工作层、按需取用。

三、"找得准"到底靠什么？

很多人一遇到检索不准，第一反应是"换个更好的 embedding 模型"。

这想法太窄了。看看 OpenClaw 检索时到底在干嘛：

它同时跑三条路再合并结果—— - 向量检索：管"语义相近"（你问的和记的意思接近） - BM25 关键词检索：管"精确命中"（报错串、配置项、ID 这种一字不差的东西） - 文件名检索：单独一条索引路径

光换 embedding 模型，你只动了三分之一。

更要命的是，有两个直接影响准确率的开关，默认都是关着的：

时间衰减（Temporal decay） — 默认关。开启后新资料优先（默认 30 天半衰期），且只有日期笔记会衰减，MEMORY.md 这种"常青"文件永不衰减。如果你攒了几个月笔记、老被陈旧信息压过新内容，这个开关就是解药。

MMR 多样性 — 默认关。开启后能减少"几乎重复"的片段，让检索出的头部结果覆盖不同主题，而不是六条都在讲同一件事。

所以"找得准"这件事的真相是：新旧权重 + 结果多样性 + 关键词和向量协同，是个组合拳。不是换个模型就能一劳永逸。

四、三种资料组织方案，摆上台面比

与其空谈，不如把常见的三种做法列出来对比。

方案 A｜整库全塞 把所有记录一股脑索引。假设是"资料越全越好"。风险：就是开头那个坑——臃肿、截断、噪音多、贵。

方案 B｜每日摘要 只保留每天的摘要。假设是"提炼过就够用"。风险：摘要可能丢掉后来才用得上的细节。

方案 C｜分层 + 按需检索 长期层只留策展摘要，细节沉到每日工作层，靠检索按需调取。也就是这套系统本来推荐的姿势。

我个人的判断（也是这篇想验证的）：在同一模型、同一套问题下，C 大概率能在减少无关上下文的同时，保住甚至提高命中率。 但注意——这是待验证的假设，不是结论。怎么验证，第六节讲。

五、基线和进阶：别把"高配"当成必需

OpenClaw 默认这套引擎（Builtin）其实已经很能打，新手直接用就行：

- 索引存在每个 agent 各自的 SQLite 库里，零额外依赖 - 关键词（BM25）+ 向量 + 混合检索 + 中日韩分词全都有 - 配好 OPENAI_API_KEY 就能用向量检索，默认模型 text-embedding-3-small - 默认切分：每块 400 token、重叠 80 token

那些"高配"方案，是规模和需求上来之后再考虑的：

QMD（本地优先的检索加速）：能索引工作区之外的目录、带重排序和查询扩展，不可用时自动回退。代价是——首次搜索会自动下载约 2GB 的模型，冷启动有成本。

LanceDB（npm 插件）：带自动召回/捕获。但有个坑：它不为 Intel Mac 发布原生构建，那台机器上装了直接报不可用。

一句话：新手用默认的就好，进阶方案等你真的撞到规模瓶颈再上。

六、重点来了：怎么做才算"公平实测"

这是全文最关键的一节，也是最容易自欺欺人的地方。

有一条红线你必须知道：

这意味着什么？意味着你如果为了对比 A/B/C 而改了上面任何一个变量，旧索引就不能直接拿来比了。系统会暂停向量检索、报"索引身份警告"，它不会自动帮你重新嵌入全部内容。

你必须手动重建：

 openclaw memory index --force 

重建之后再测，结论才成立。否则你以为在比方案，其实在比两套根本对不齐的索引——数据再漂亮也是废的。

还有个细节：embedding 缓存默认开着。所以测"冷启动"之前记得先重建，别让缓存把"重复查询变快"的假象混进你的结论里。

至于怎么设计测试，思路是：

- 出一套 15–20 道题，覆盖五类问题（语义、精确 ID、时间敏感、跨主题、重复项） - 准备五张记录表，分别记：命中率、响应时间、成本、上下文质量、维护成本 - 三个方案跑同一套题、同一个模型，逐格填

七、诚实收尾：结论只在你自己的条件里成立

到这儿你可能想问：那到底省多少、快多少？

我的答案是：我不知道，你也不该信任何人给的通用数字。

因为表现会随模型、版本、机器、资料而变。举个例子，OpenClaw 在 v2026.7.1 就改了 QMD 的重排序逻辑和大索引的召回方式——版本不同，结果就可能不同。 所以任何实测记录，都务必写清楚你用的模型、openclaw --version、机器配置和时间。

把这篇浓缩成一句话带走：

先分层，再按需检索；一改配置就重建索引；结论只在你自己的实测条件内成立。

别再把聊天记录一股脑往里塞了——那个塞爆的抽屉，装得越满，找得越慢。

（—— 桦说AI，我们下篇见）

登录查看剩余 70% 内容