记忆架构：3 层混合系统
为什么单靠向量搜索不够——以及如何将 SQLite+FTS5、LanceDB 和 memory.md 组合成一个真正记得住事的个人助手。
SQLite+FTS5
80% of lookups
LanceDB
Semantic recall
memory.md
Always in context
记忆问题
大多数 OpenClaw 用户从一种记忆方案开始：要么是向量数据库，要么是平坦的 memory.md 文件。两种方案都有效——直到失效。向量搜索在模糊语义召回方面很出色，但对于事实查找来说既昂贵又不精确。纯文本文件始终在上下文中，但不能扩展。解决方案？一个覆盖完整频谱的 3 层混合架构。
3 层架构
零外部依赖的精确事实检索。覆盖个人助手 80% 的实际需求——日期、姓名、偏好、决策。FTS5 全文搜索使其快速且灵活。
模糊语义召回用于上下文关联。当你问"上周关于餐厅的那次对话是什么"时，即使你不记得确切的词语，向量搜索也能找到它。
必须始终在 LLM 上下文窗口中的关键信息。你的名字、偏好、关键关系、活跃项目。小巧、精选、始终存在。
为什么不只用向量搜索？
我直接用了 LanceDB，因为向量搜索感觉像是"AI 原生"方法。但对于个人助手，大多数记忆查询都是结构化查找。SQLite + FTS5 从第一天就能零依赖地满足我 80% 的需求。
向量搜索擅长模糊语义召回——"找到类似 X 的对话"。但对于"我伴侣的生日是什么？"或"我用什么模型做心跳？"这类问题就是大材小用了。这些是简单数据库处理得更好、更快、更便宜的结构化事实。
混合方法——结构化存储用于精确事实、向量搜索用于上下文召回、始终加载的上下文用于关键信息、时间感知衰减管理新鲜度——覆盖了完整频谱。
记忆方案对比
| 方案 | 优势 | 劣势 | 最适合 |
|---|---|---|---|
| 仅 memory.md | 始终在上下文中，简单 | 不可扩展，需手动管理 | < 50 个关键事实 |
| 仅向量数据库 | 语义搜索，可扩展 | 昂贵，事实查找不精确 | 大型非结构化记忆 |
| 仅 SQLite+FTS5 | 快速、精确、零依赖 | 无语义理解 | 结构化事实查找 |
| 3 层混合 ✅ | 完整覆盖 | 设置更复杂 | 生产级个人助手 |
依赖与设置
better-sqlite3@11.0.0SQLite 驱动 + FTS5 全文搜索@lancedb/lancedb@0.23.0嵌入向量数据库（语义搜索）openai@6.16.0生成嵌入向量（text-embedding-3-small）@sinclair/typebox@0.34.47运行时类型校验（插件配置）构建要求
API 密钥
OPENAI_API_KEYRequired嵌入向量生成必需（text-embedding-3-small）SUPERMEMORY_API_KEYOptional可选——第 2 层云端存档备份每日事实提取
系统包含一个 CLI 命令，可扫描对话日志、提取结构化事实并回填到 SQLite 数据库中。把它想象成安全网——实时捕获遗漏的对话会在每日扫描中被捕获。
设计原则
从一开始就为衰减设计
尽早添加 TTL 分类。没有它，过时的事实会不断积累，使检索结果变得杂乱。"今天的会议"这样的事实不应该持续保存数月。
显式提取决策
不要存储原始对话日志——那是噪音。存储带有理由的提炼决策。"因为最便宜所以选择 Haiku 做心跳"比 500 个 Token 的讨论更有用。
混合优于纯粹
没有单一记忆系统能覆盖所有查询模式。SQLite 管事实、向量管氛围、memory.md 管身份。每一层都有明确的职责。
零依赖优先
从 SQLite+FTS5 开始——它零外部服务就能覆盖 80% 的需求。只有当你真正需要语义召回时才添加向量搜索。