序言
想象这样一个场景：你花了半小时向 AI 助手解释你的项目架构、编码偏好和团队规范，得到了一次满意的协作体验。第二天你带着新问题回来，它却一脸茫然——「请问您的项目使用什么技术栈？」
这不是科幻，这是无数 OpenClaw「养成」过程中最常见的阵痛。
这不是科幻，这是无数 OpenClaw 用户每天都在经历的现实。
「OpenClaw 又忘了！」——这是 GitHub Issue 区最常见的抱怨。就在今年 1 月，一位开发者在 Issue #5429 中诉说了自己的遭遇：他花 45 小时与 Agent 协作积累的配置、技能集成、任务优先级，在一次静默的压缩（compaction）操作后全部消失。原因很简单：OpenClaw 在上下文窗口满载时，会自动对历史对话进行摘要和压缩，而这个过程没有任何警告。
这不是孤例。另一位用户报告说，他正在处理一个重要的代码重构任务，当对话进行到第 72 分钟时，compaction 触发了无限循环，整个 Agent 被锁死了 72 分钟。再重启时，之前的工作成果荡然无存。
本文将带你从痛点出发，遍历官方与社区方案，最终选定 lily-memory 这套「本地化 + 混合搜索 + 零成本」的方案，手把手教你从零养成 OpenClaw 的持久记忆能力。
一、前言：问题本质——三层失效
要理解 OpenClaw 为什么会「失忆」，我们需要理解它的记忆架构。在实际使用中，记忆失效发生在三个层面：
失效层一：从未存储。这是最常见的情况。用户在与 Agent 对话时，会自然地给出一些重要信息：「我习惯用 Tab 缩进」「上次那个 bug 的原因是变量名冲突」。Agent 口头回应「记住了」，但转身就忘。因为这些信息从未被写入磁盘文件，只是在当前上下文中短暂存在。一到新会话，全部归零。
失效层二：压缩中被覆盖。即使信息被写入了当天的记忆文件（memory/YYYY-MM-DD.md），当对话持续较长时，OpenClaw 会触发 compaction（压缩）机制。它会将之前的历史对话压缩成摘要，存储到 context/ 目录。问题是，这个压缩是单向的——压缩后的信息密度降低，一些细节会丢失。
失效层三：检索不到。即使信息好好地躺在记忆文件中，Agent 也可能找不到它。OpenClaw 默认的检索机制是 BM25 全文检索 + 向量语义检索的混合搜索，但默认配置往往没有启用向量检索，或者没有配置好嵌入模型。
社区里流传着一个精辟的总结：「扁平、无差异、被动的记忆。」这六个字，完美概括了 OpenClaw 记忆系统的核心困境。
二、方案介绍：官方方案与社区方案
官方方案：从 QMD 后端到混合搜索
面对社区的强烈反馈，OpenClaw 官方在 2026 年 1-2 月密集发布了一系列记忆相关的更新：
| 版本 | 发布日期 | 更新内容 |
|---|---|---|
| v2026.1.12 | 2026-01-13 | 向量搜索基础设施上线——SQLite 索引 + chunk 分块 + 懒同步 + 文件监控 |
| v2026.1.29 | 2026-01-29 | L2 归一化修复——修复了本地嵌入向量未归一化导致余弦相似度计算不准确的问题 |
| v2026.2.2 | 2026-02-04 | QMD 后端合并（PR #3160）——最重要的架构升级，用本地搜索边车进程替换内置 SQLite 索引器 |
QMD 后端是 OpenClaw 官方推出的新一代记忆后端。它的核心思路是：不再依赖 Agent 进程内部的索引机制，而是用一个独立的本地搜索边车进程来处理所有的语义检索。QMD 默认使用 SQLite FTS5 作为底层引擎，性能比之前的内置方案提升了约 40%。
但值得注意的是，QMD 本身是一个「检索层」的优化——它让搜索更准了，但没有解决「记忆是否被写入」和「哪些记忆更重要」的问题。
当前 OpenClaw 的官方检索方案是 BM25 + 向量语义搜索的混合模式：两路结果通过加权融合（默认权重是 Vector 70% + BM25 30%）汇成最终结果。
尽管官方在快速迭代，但核心问题仍然是：检索层优化不能解决存储层问题、依赖外部嵌入模型（涉及 API 费用或本地资源占用）、缺少自动组织能力。
社区方案：七大第三方方案
社区没有等待官方，在 2026 年 1-2 月期间，至少出现了七款第三方记忆增强方案：
| 方案 | 核心思路 | 亮点 | 缺点 |
|---|---|---|---|
| Mem0 | SDK 化的记忆层 | 自动捕获 + 自动检索，延迟降低 91%，Token 节省 90% | 需要云端 API，隐私顾虑 |
| Hindsight | 本地长期记忆 | 学习循环机制（retain/recall/reflect），1300+ Stars | 配置复杂，上手门槛高 |
| MoltBrain | SQLite + ChromaDB | 生命周期钩子自动捕获上下文，Web UI 可视化管理 | 365 Stars，社区维护力度存疑 |
| lily-memory | 混合搜索（SQLite FTS5 + Ollama） | 完全本地、混合搜索、自动记忆、卡顿检测、优雅降级 | 需要本地 Ollama 环境 |
| LanceDB 插件 | 向量数据库增强 | 7 层混合检索、MMR 多样性去重、多 scope 隔离 | 社区插件，需自行维护 |
综合考虑本地隐私、零 API 成本、配置复杂度，最终选定 lily-memory 作为本次实战的方案。
三、安装与使用：lily-memory 实战
3.1 为什么选择 lily-memory？
选择 lily-memory 的核心理由：
- 完全本地：所有数据存储在本地 SQLite，不上传云端，隐私安全零担忧。
- 混合搜索：SQLite FTS5 全文检索 + Ollama 向量语义检索，双重保障。
- 自动记忆：不用手动调用
memory_store，系统自动捕获 + 自动检索。 - 卡顿检测：能检测重复话题，防止「鬼打墙」式的重复对话。
- 优雅降级：没有 Ollama 也能用，仅启用关键词模式。
- 零 API 成本：本地 Ollama + nomic-embed-text 模型，完全免费。
3.2 安装步骤
# 1. 通过 ClawHub 安装插件
npx clawhub install lily-memory
# 2. 进入插件目录安装依赖
cd ~/.openclaw/workspace/skills/lily-memory
npm install better-sqlite3
# 3. 下载嵌入模型（274MB）
ollama pull nomic-embed-text
# 4. 配置 openclaw.json（见下文）
# 5. 重启 Gateway
openclaw gateway restart3.3 配置示例
在 ~/.openclaw/openclaw.json 中添加或修改：
{
"plugins": {
"slots": {
"memory": "lily-memory"
},
"entries": {
"lily-memory": {
"enabled": true,
"config": {
"dbPath": "~/.openclaw/memory/lily.db",
"autoCapture": true,
"autoRecall": true,
"vectorSearch": true,
"hybridWeight": {
"vector": 0.7,
"bm25": 0.3
},
"ollama": {
"url": "http://localhost:11434",
"model": "nomic-embed-text"
},
"gracefulDegradation": true
}
}
}
}
}3.4 参数详解
| 参数 | 类型 | 默认值 | 说明 |
|---|---|---|---|
dbPath | string | ~/.openclaw/memory/lily.db | SQLite 数据库存储路径 |
autoCapture | boolean | true | 是否自动捕获对话中的关键信息 |
autoRecall | boolean | true | 是否在响应前自动检索相关记忆 |
vectorSearch | boolean | true | 是否启用向量语义搜索 |
hybridWeight.vector | float | 0.7 | 向量搜索结果权重 |
hybridWeight.bm25 | float | 0.3 | BM25 搜索结果权重 |
ollama.url | string | http://localhost:11434 | Ollama 服务地址 |
ollama.model | string | nomic-embed-text | 嵌入模型名称 |
gracefulDegradation | boolean | true | Ollama 不可用时降级为纯 BM25 模式 |
3.5 迁移旧记忆
之前的记忆文件存储在 memory/compressed/ 目录中，格式是 Markdown。需要将其导入到新的 SQLite 数据库中：
const Database = require('better-sqlite3');
const fs = require('fs');
const path = require('path');
const db = new Database('~/.openclaw/memory/lily.db');
const memoryDir = '~/.openclaw/workspace/memory/compressed/';
const files = fs.readdirSync(memoryDir).filter(f => f.endsWith('.md'));
const insertStmt = db.prepare(`
INSERT INTO memories (content, timestamp, type, source)
VALUES (?, ?, ?, ?)
`);
files.forEach(file => {
const content = fs.readFileSync(path.join(memoryDir, file), 'utf-8');
const timestamp = new Date(file.replace('.md', '')).toISOString();
insertStmt.run(content, timestamp, 'imported', file);
});
console.log(`已导入 ${files.length} 条记忆`);实测：8 条记忆，秒级导入。
四、使用场景与案例
案例一：自动捕获用户偏好
操作：在对话中告诉 Agent 「我咖啡只喝美式，不加奶不加糖」。
结果：lily-memory 自动检测到这是一条用户偏好信息，写入数据库。无需手动触发任何命令。
验证：
# 查询记忆库
openclaw memory search "美式咖啡"返回结果中能看到这条记忆被正确存储和检索。
案例二：新会话检索
操作：结束当前会话，开启一个新的会话。
测试 prompt：「我上次跟你说我喝什么咖啡？」
结果：Agent 正确检索到之前保存的偏好信息，回复：「你说你只喝美式，不加奶不加糖。」
案例三：混合搜索效果
场景：记忆库中有一条关于 Python 装饰器的笔记。
- BM25 检索：搜索「Python 装饰器」→ 命中
- 向量检索：搜索「怎么给函数加额外行为」→ 命中（语义关联）
- 混合检索：搜索「给函数加额外行为」→ 同时返回两条结果，综合评分更高
性能对比
| 指标 | 旧方案（memory-v2） | 新方案（lily-memory） |
|---|---|---|
| 搜索响应时间 | 20ms+ | < 5ms |
| 内存占用 | 高（Mac mini 后台运行） | 低（SQLite 单进程） |
| API 成本 | 有（外部嵌入服务） | 零（本地 Ollama） |
| 配置复杂度 | 高 | 中 |
五、升华与收束：未来展望
OpenClaw 的记忆问题，本质上是一个「存储-检索-组织」三层架构的系统性挑战。官方在检索层（QMD + 混合搜索）持续发力，但存储层的自动化和组织层的智能化，仍然需要用户和社区方案来补足。
lily-memory 以「本地化 + 混合搜索 + 零成本」的方式，较好地回答了「如何让 Agent 记住并且能找到」的问题。对于已经在本地部署了 Ollama 的用户来说，这是一个值得尝试的方案。
当然，没有任何方案是完美的。最重要的是理解记忆系统的工作原理，然后根据自己的实际需求（隐私优先 / 成本优先 / 跨设备优先）选择合适的方案，并持续优化配置。
毕竟，最好的记忆系统不是「一步到位」的，而是在使用过程中不断迭代和调优的。
未来演进方向
lily-memory 可能的演进方向包括：
- 与 QMD 深度整合：将索引层对接到 QMD，享受官方持续的性能优化。
- 自动记忆评级：参考 Dwarf Fortress 的三层记忆架构，给每条记忆赋予「常青度」权重。
- 结构化记忆：从纯文本升级为实体-关系模型。
- 多模态记忆：支持图片、文档等多模态内容。
- 记忆可视化：开发 Web 管理界面。
六、注意事项
6.1 适用人群
lily-memory 方案最适合以下用户：
- 已在本地部署 Ollama 的用户
- 对隐私安全有较高要求的用户
- 希望通过零成本方案实现持久记忆的用户
如果你的设备没有 Ollama 环境，需要额外安装，增加了初始配置成本。
6.2 当前局限
lily-memory 解决了「记住」和「找到」的问题，但还没有解决：
- 记忆的重要性排序：一条「用户的咖啡偏好」和「昨天的研究发现」哪个更重要？目前没有差异化处理。
- 遗忘机制：长期积累后，记忆库会膨胀，需要类似时间衰减的机制来自动清理低价值记忆。
- 跨设备同步：本地存储虽然是隐私优势，但限制了多设备场景的使用。
- 结构化提取：目前存储的是原始文本片段，没有做实体抽取和关系建模。
6.3 维护成本
需要维护本地 Ollama 服务的运行状态，服务重启后需要重新加载模型。首次安装需要下载 nomic-embed-text 模型（约 274MB）。
七、参考资料
- OpenClaw 官方文档：Memory System：https://docs.openclaw.ai/concepts/memory
- QMD GitHub 仓库：https://github.com/tobi/qmd
- lily-memory 插件（通过 ClawHub 安装）：https://clawhub.dev/plugins/lily-memory
- GitHub Issue #5429：45 小时上下文丢失事件：https://github.com/openchats/openclaw/issues/5429
- ClawHow：The Ultimate Guide to OpenClaw Memory：https://clawhow.com/article/lijiuer92-openclaw-memory-guide
- Velvetshark：OpenClaw Memory Masterclass：https://velvetshark.com/openclaw-memory-masterclass
- BetterClaw：OpenClaw Memory Is Broken – Here’s How to Fix It：https://www.betterclaw.io/blog/openclaw-memory-fix
- 刘HP博客：OpenClaw记忆系统升级实战——从删库到lily-memory：https://liuhp.net/post/2026-03-02-openclaw-memory-upgrade/
- 博客园：OpenClaw【四、记忆系统】：https://www.cnblogs.com/hewei-blogs/articles/19730086
- SegmentFault：打造会自主学习的AI助手：OpenClaw记忆系统完全指南：https://segmentfault.com/a/1190000047594387
八、广而告之
关注我的公众号：奥德元
一起学习AI，一起追赶时代！
新建了一个AI技术交流群，欢迎大家一起加入讨论。
扫码加入AI技术交流群（微信）
若需联系作者，请加微信：oddmeta
