前几天我折腾了一轮 OpenClaw 的记忆系统，起因很简单：我是在抖音上看别人推荐，才去装 memory-lancedb 插件的。
视频里吹得很猛，讲得像是装上之后记忆能力直接起飞，什么长期记忆、智能召回、越用越懂你，听起来特别像那么回事。
我当时也确实被说动了，觉得官方默认那套可能偏保守，memory-lancedb 也许才是更强的“进阶方案”。
结果真正用下来之后，我的结论很干脆：根本不好用。
这里不是“试了几轮就下判断”。
我是实打实用了好几天，而且强度不低：
- 主力模型是 gpt-5.4 和 gpt-5.2-codex
- 平均每天大概 90 美元 token 成本
- 总量已经跑到了 七八亿 tokens
这种使用强度下，很多东西其实藏不住。
好不好用，不用听谁吹，跑几天就知道了。
memory-lancedb 最大的问题，不是不能跑，而是它在真实使用里远没有宣传得那么神。
手动 memory_store、memory_recall 都能通，表面上看功能齐全，但一到自动召回，问题就来了：乱召回、带偏上下文、把一堆不该出现的东西塞进当前对话。
我一开始怀疑过 embedding、怀疑过向量维度、也怀疑过索引是不是坏了。后来一路查下来，问题其实挺直接：
memory-lancedb更像一个轻量插件，召回逻辑很简单- 我把不少 memory 文档直接灌进了向量库，候选池一下子变脏了
- 它能查到东西，但经常查到的是“不该现在出现的东西”
最直观的感受就是：
你问一个当前问题，它给你翻出旧日志、联系人碎片、论坛账号，甚至是排障过程里的技术细节。系统看起来很勤快，但实际是在污染上下文。
后面我也不是没补救。我做过一轮排查和修补：
- 关掉
memorySearch - 把
memory插槽切到memory-lancedb - 调小文档分块
- 重灌文档到 LanceDB
- 调整 autoRecall 注入条数
这些动作不是完全没用，短时间内确实缓了一点。
但问题始终没有真正解决。越往后我越确定：我是在拿一个适合“手动长期记忆”的插件，硬扛官方主记忆系统的活。
再往后我去看 OpenClaw 本地文档和内置实现，方向就清楚了。官方路线其实一直写得很明白：
memory-core才是默认 memory 插件- 主工具是
memory_search和memory_get - 默认 backend 是
builtin - QMD 是实验性的 sidecar，不是默认必选项
官方文档里那句话我觉得很重要：除非你明确要运行 QMD，否则保持 builtin。
我后来就是按这个思路回切的：
- 恢复
agents.defaults.memorySearch.enabled = true - 把
plugins.slots.memory改成memory-core - 禁用
memory-lancedb - 重启 gateway
- 重新检查 memory 状态
切回之后，系统一下子顺了很多。
openclaw status 里能直接看到：
plugin memory-core- FTS ready
- vector ready
- memory files 已接管
再做检索测试，虽然还谈不上特别聪明，但至少回到了一个正常系统该有的样子。
查用户偏好，会先命中 entities/wood.md 和 opinions.md；查联系人，也会优先落到实体页和用户页。尾部还是会有一点噪音，但已经不是之前那种“什么都往上冒”的状态了。
这轮折腾下来，我的判断很简单。
1. memory-lancedb 适合做轻量插件，不适合顶替官方主记忆链路
如果你只是想手动存一些偏好、事实、决定，它能用。
但如果你想让它长期承担自动召回，又把很多文档直接往里灌，基本迟早失控。
2. 官方默认路线没有想象中弱
我一开始也有点先入为主，总觉得 builtin 不够强，QMD 才像“完整版”。后来实际跑下来发现不是这么回事。
memory-core + memorySearch + builtin 本身就是一条完整路线，而且明显更稳、更省心。
3. 真正拖后腿的，不只是引擎，还有 memory 文件本身
切回官方路线后，我继续看索引结果，发现另一个现实问题：同一事实散落在多个文件里重复出现。
比如一个联系人信息，可能同时出现在：
- daily 日志
world.mdentities/*.mdusers/*.md
这样一来，就算官方 memory 再稳，召回时也容易把重复事实一起带出来。
所以后面我又做了一轮很小的整理，不大改结构，只收掉最明显的重复项和不该长期保留的内容，比如：
- 把联系人详情收口到实体页 / 用户页
- 把 public 长期记忆里的明文账号密码去掉
- 把 daily 里已经沉淀过的长期事实弱化掉
这一步反而很关键。因为记忆系统再强，源头文件乱，结果照样会乱。
4. 这类问题，只有高强度用几天之后才会彻底暴露
这次让我更确定的一点是：记忆系统不能看演示视频，更不能只看“能不能跑通”。
小规模测试时，很多方案都像是可用的。
但当你真的连续用几天、每天烧掉几十美元 token、总量跑到几亿 token 之后，很多视频里放大的“优点”很快就会褪色，真正的问题反而会越来越明显。
memory-lancedb 在我这里就是这样。
拿来做 Demo，它挺像那么回事。
放进高强度日常使用，噪音和上下文污染会越来越烦。
5. 我现在的选择很简单：先回官方默认链路
至少在当前阶段，我不会继续折腾 QMD，也不会再把 memory-lancedb 拉回来当主系统。
后面的原则就是：
- 主记忆：
memory-core - backend：
builtin - memory 文件继续分层、去重、收口
- daily 主要记当天，长期事实尽量沉淀到固定文件
这样不花哨，但稳。
最后说一句。
如果你也在折腾 OpenClaw 记忆，而且已经开始觉得“是不是该换插件、换后端、换 embedding 才能救”，我会建议你先停一下，先确认两件事：
- 你是不是已经偏离了官方默认链路
- 你的 memory 文件本身是不是已经写乱了
很多时候，问题不在模型有多强，而在路径走偏了。