夜雨聆风很多人一听到 OpenClaw 里的 memory search，就会下意识地把它理解成一套“标准企业知识库 + 外部向量数据库”的方案。
但实际上，OpenClaw 默认的向量检索机制，并不是那种必须单独部署 Milvus、Qdrant、pgvector 的重型架构。
它更像是一套内置型、轻量级、以 Memory 为核心的数据检索机制。
今天就用一篇文章，把这件事彻底讲明白：
OpenClaw 默认到底用什么做“向量库”？
向量库里到底存的是什么？
它和企业知识库系统里的向量库，有什么本质区别？
一、OpenClaw 默认用的“向量库”是什么？
先说结论：
OpenClaw 默认并不是依赖外部独立向量数据库服务，而是走内置 memory search 存储路线。
更准确一点说，它默认使用的是：
SQLite + sqlite-vec（若可用）
如果 sqlite-vec 不可用，则退回到进程内做向量相似度计算。
也就是说，OpenClaw 默认并不是一上来就要求你部署 Milvus、Qdrant、ES + 向量检索那种企业级组件，而是先用一套轻量、本地、可嵌入式的方式，把 Memory 检索能力跑起来。
你可以把它理解成：
1. 默认方案：SQLite 路线
当 sqlite-vec 扩展可用时，OpenClaw 会把 embedding 存进 SQLite 的向量表中，在库内直接完成向量检索。
2. 回退方案：进程内相似度计算
如果 sqlite-vec 没有安装成功，或者当前环境不支持，OpenClaw 也不会彻底失去 memory search 能力，而是退回到应用进程里做 cosine similarity 之类的相似度匹配。
3. 可选增强：QMD backend
OpenClaw 还支持可选的 QMD backend，它可以把 BM25、向量检索、rerank 结合起来，但这不是默认开启项。
4. 插件扩展：LanceDB
仓库里也有 memory-lancedb 插件，说明它还支持通过插件把长期记忆能力接到 LanceDB 上。但这属于扩展路线，不是默认主路径。
二、所以，OpenClaw 默认不是“企业级外部向量库”架构
这一点很重要，很多人容易误解。
OpenClaw 默认的 Memory 检索，更像是：
“本地化、内置化、小型语义检索能力”
而不是：
“面向海量知识库的大规模分布式向量数据库系统”
这意味着它的设计初衷，不是做一个传统意义上的知识中枢或企业知识底座，而是优先解决：
agent 的长期记忆
memory 文件的语义检索
本地上下文召回
轻量级可用性
所以如果你是从政务知识库、企业知识库、RAG 平台的视角去看，OpenClaw 的“向量库”更接近一种内置记忆检索模块，而不是完整的知识库基础设施。
三、向量库里到底存什么？
这个问题更关键。
很多人会问：
OpenClaw 的向量库里，存的是不是所有聊天记录？
是不是所有文件都会自动进库？
是不是像企业知识库一样，把各种 PDF、Word、网页、FAQ 全都切片后存进去？
答案是：
默认都不是。
OpenClaw 默认存进去做向量检索的，主要是它配置里的 memory sources。
最核心的默认来源，是下面两类 Markdown 文件：
1. MEMORY.md
这是最基础的记忆文件。
2. memory/*.md
比如按日期沉淀的记忆文件、历史记录文件等。
这些文件会被构建成小型向量索引，供 memory_search 做语义召回。
所以默认情况下，OpenClaw 向量库里最主要存放的是：
Memory 文本内容
对应生成的 embedding 向量
检索所需的索引信息
四、除了默认 Memory 文件，还能存什么？
如果开启了额外配置，OpenClaw 的向量索引还可以扩展到更多数据来源。
1. 额外 Markdown 文档
通过 memorySearch.extraPaths，你可以增加其他目录或 Markdown 文件路径。
这些路径下的 .md 文件也可以被递归扫描并纳入索引。
这意味着你可以把一些额外的项目笔记、共享说明文档、工作日志，作为额外记忆源接进来。
也就是说，向量库里除了默认的 MEMORY.md 之外，还可以存：
其他 Markdown 文档内容
这些文档对应的 embedding
文档级或片段级索引信息
2. Session 会话记录（默认不开）
这一点也很容易被误解。
OpenClaw 并不是默认把所有聊天会话都自动向量化入库。
只有在显式开启 experimental.sessionMemory: true，并把 sources 配置成包含 sessions 时，才会对 session transcripts 建立索引。
这说明两件事：
第一，会话记忆是可选能力，不是默认能力。
第二，默认情况下，向量库主要还是围绕 Memory 文件，而不是围绕聊天记录。
所以如果你问“向量库里是不是默认存所有聊天记录”，答案是：
不是。默认主要存 Memory Markdown。
3. 图片和音频（更可选）
如果启用了多模态 memory search，并配置了相应 embedding 模型，例如 Gemini embedding，那么 extraPaths 下的图片和音频也可以被纳入索引。
这时候，向量库里存的就不只是文本 embedding 了，还可能包括：
图片 embedding
音频 embedding
对应的文件路径、说明信息、索引元数据
但这里要注意：
默认 memory 根目录主要还是面向 Markdown，图片和音频索引属于额外能力，不是基础默认项。
五、向量库里一条记录大概长什么样？
官方文档没有把默认 SQLite 表结构完整展开，但从 OpenClaw 的相关插件实现思路来看，一条 memory entry 通常不只是“一个向量”那么简单，而是会包含一组元数据。
一般会类似于：
id
text
vector
importance
category
createdAt
也就是说，向量库里通常会同时保存：
文本内容
也就是原始 memory 文本、片段文本或摘要文本。
向量
由 embedding 模型生成的语义向量。
元数据
比如：
记录 ID
创建时间
类别
重要性
来源信息
这也符合向量检索系统的一般设计：
检索时靠向量召回，展示时靠文本和元数据还原。
六、那它“不存什么”？
为了避免误解，这里反过来再说一遍。
OpenClaw 默认的向量库，不是下面这些东西：
1. 不是默认存所有 OpenClaw 数据
不是整个系统里所有内容都会自动进入向量索引。
2. 不是默认存全部聊天记录
聊天 session 只有在你显式开启 session memory 时才会纳入索引。
3. 不是默认连接外部独立向量数据库
默认不是 Milvus、Qdrant、pgvector 那种外部服务模式。
4. 不是“所有原始二进制文件都直接读得出来”
即便开启多模态索引，图片和音频主要是“可搜索”，不代表可以像普通文件存储系统一样直接从向量库还原原始内容。
七、怎么理解 OpenClaw 的“向量库”最准确？
我建议把它拆成三层来看，这样最不容易混淆。
第一层：原始内容层
包括：
MEMORY.md
memory/*.md
可选的 extraPaths 文档
可选的 session transcript
可选的图片/音频文件
第二层：索引层
包括：
BM25 检索索引
embedding 向量索引
可能的 hybrid search 能力
第三层：存储层
默认主要是：
SQLite
sqlite-vec
可选增强包括：
QMD backend
LanceDB 插件
这样理解之后你会发现：
OpenClaw 的“向量库”，本质上更像是 agent memory 的语义检索底座，而不是一个面向企业级海量知识资产管理的完整向量库平台。
八、它和企业知识库系统的向量库，有什么本质区别？
这一点非常值得讲清楚。
企业知识库里的向量库，通常关注的是：
海量文档接入
多格式解析（PDF、Word、Excel、网页、图片）
切片策略
元数据治理
多租户隔离
大规模召回与重排
权限控制
知识更新同步
溯源展示
而 OpenClaw 默认的 memory 向量检索，更关注的是：
agent 的记忆沉淀
memory 文件的语义召回
小规模本地索引
轻量级嵌入式运行
对话与任务执行中的上下文补充
所以这两者不是谁替代谁的关系，而是设计目标不同。
企业知识库更像“知识基础设施”。
OpenClaw memory 更像“智能体的长期记忆能力”。
九、最后用一句话总结
OpenClaw 默认并不是外接大型向量数据库，而是以内置 SQLite / sqlite-vec 为核心，为 MEMORY.md、memory/*.md 以及可选扩展记忆源建立轻量级语义检索索引。它存的不只是向量，还包括文本内容和元数据；它更偏向智能体记忆系统，而不是传统企业知识库底座
