OpenClaw 向量数据库:SQLite + sqlite-vec

OpenClaw 中的向量数据库实现方式

OpenClaw（中文社区常称“小龙虾”或“龙虾”）是一个非常火的开源个人AI Agent框架，它的核心设计哲学是本地优先、零运维、可读、可审计，因此在向量存储和检索上它并没有使用传统独立的向量数据库（如 Pinecone、Weaviate、Milvus、Chroma、Qdrant 等）。

核心存储方案：SQLite + sqlite-vec 扩展（内置混合向量引擎）

OpenClaw 默认采用以下架构来实现向量检索：

数据源
：所有记忆以纯 Markdown 文件形式存储在本地文件系统（用户可直接用编辑器打开、修改、Git 版本控制）
索引层
：使用 SQLite 作为一体化的存储引擎（单文件 .sqlite，无需额外服务）
向量支持
：通过官方 sqlite-vec 扩展（或类似 vector 扩展）实现高效的向量相似度计算
混合检索
（Hybrid Search）：最经典的配置是 70% 向量相似度 + 30% 全文搜索（BM25/FTS5） 加权融合，经过社区大量验证被认为是目前性价比最高的平衡点

典型的数据表结构大致如下（简化版）：

SQL

-- 文本块表CREATE TABLE chunks (  id INTEGER PRIMARY KEY,  file_id INTEGER,  text TEXT,  hash TEXT UNIQUE,           -- 用于去重  embedding BLOB,             -- 序列化的 FLOAT32 向量数组  created_at INTEGER);-- 全文搜索虚拟表（FTS5）CREATE VIRTUAL TABLE chunks_fts USING fts5(text, content='chunks');-- 向量虚拟表（sqlite-vec）CREATE VIRTUAL TABLE vec_chunks USING vec0(embedding float[384]);  -- 或 768/1536 维-- 或使用索引方式：CREATE INDEX idx_embedding ON chunks(embedding) USING vector(dim=384, metric='cosine');

检索时主要调用 sqlite-vec 提供的函数，例如：

SQL

SELECT *, vec_distance_cosine(embedding, query_embedding) AS distanceFROM chunksORDER BY distanceLIMIT 20;

再结合 FTS5 的关键词匹配结果做加权 rerank，就得到最终的混合召回。

为什么不直接用独立的向量数据库？

维度	OpenClaw (SQLite + sqlite-vec)	独立向量数据库 (Chroma / Qdrant 等)
部署难度	零运维，单文件	需要额外启动服务/Docker
数据所有权	完全本地，可读 Markdown + SQLite	通常不透明二进制存储
启动速度	毫秒级	秒级甚至更长
资源占用	极低（几MB ~ 几十MB）	较高
可解释性	极高（可手动改文件+数据库）	较低
海量数据场景	中等（百万级 chunk 仍可接受）	更强

社区常见的进阶/替换方案

很多人觉得内置的 sqlite-vec 在超大规模记忆或追求极致精度时不够用，于是社区出现了各种增强插件：

LanceDB 插件
：目前最受欢迎的第三方记忆增强方案，支持更强的 ANN 索引、多 scope 隔离、MMR 去重、噪声过滤等，效果明显优于原生记忆
Milvus / memsearch
：有人把 OpenClaw 记忆系统抽出来做成独立模块，支持更专业的向量数据库后端
Qdrant / Chroma
：部分重度用户会自己写适配层接入
Graphiti + QMD
：结合知识图谱 + 向量的混合记忆方案

总结一句话：

OpenClaw 原生不依赖任何外部向量数据库，而是用 SQLite + sqlite-vec 实现了一个轻量、透明、混合的本地向量检索系统。这正是它能迅速爆火的重要原因之一——极致的“本地优先”体验。如果你追求更高性能或海量记忆，社区已经提供了非常成熟的 LanceDB 等插件替换方案。

需要我帮你找具体的 sqlite-vec 集成代码示例、LanceDB 插件安装步骤，或者对比测试数据吗？