OpenClaw养成:不花钱的本地化持久记忆方案 lily-memory

序言

想象这样一个场景：你花了半小时向 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 月密集发布了一系列记忆相关的更新：

QMD 后端是 OpenClaw 官方推出的新一代记忆后端。它的核心思路是：不再依赖 Agent 进程内部的索引机制，而是用一个独立的本地搜索边车进程来处理所有的语义检索。QMD 默认使用 SQLite FTS5 作为底层引擎，性能比之前的内置方案提升了约 40%。

但值得注意的是，QMD 本身是一个「检索层」的优化——它让搜索更准了，但没有解决「记忆是否被写入」和「哪些记忆更重要」的问题。

当前 OpenClaw 的官方检索方案是 BM25 + 向量语义搜索的混合模式：两路结果通过加权融合（默认权重是 Vector 70% + BM25 30%）汇成最终结果。

尽管官方在快速迭代，但核心问题仍然是：检索层优化不能解决存储层问题、依赖外部嵌入模型（涉及 API 费用或本地资源占用）、缺少自动组织能力。

社区方案：七大第三方方案

社区没有等待官方，在 2026 年 1-2 月期间，至少出现了七款第三方记忆增强方案：

综合考虑本地隐私、零 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-memorynpm install better-sqlite3# 3. 下载嵌入模型（274MB）ollama pull nomic-embed-text# 4. 配置 openclaw.json（见下文）# 5. 重启 Gatewayopenclaw gateway restart

3.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 参数详解

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 装饰器」→ 命中

• 向量检索：搜索「怎么给函数加额外行为」→ 命中（语义关联）

• 混合检索：搜索「给函数加额外行为」→ 同时返回两条结果，综合评分更高

性能对比

五、升华与收束：未来展望

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's 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

八、广而告之