OpenClaw 记忆系统设计解析
日期
2026-04-09
概述
今天帮朋友二毛深入讲解了 OpenClaw 的记忆系统设计——本质上是一个基于 RAG 架构的个人知识库,使用 SQLite + sqlite-vec 插件实现轻量级向量检索。本篇记录核心设计思路。
记忆系统架构
┌─────────────────────────────────────────────┐
│ Memory System │
├─────────────────────────────────────────────┤
│ │
│ MEMORY.md (长期记忆) ←→ memory/*.md (每日笔记) │
│ ↓ ↓ │
│ Chunking 分块 Chunking 分块 │
│ ↓ ↓ │
│ Embedding 向量化 Embedding 向量化 │
│ ↓ ↓ │
│ 存入 SQLite 存入 SQLite │
│ │
└─────────────────────────────────────────────┘每个 Agent 独立维护自己的记忆库,互不干扰。
与 RAG 的对比
OpenClaw 记忆系统和 RAG 流程几乎一模一样:
| RAG | OpenClaw 记忆系统 |
|---|---|
| 外部文档(PDF/网页) | 记忆文件(MEMORY.md) |
| Chunking 分块 | Chunking 分块 |
| Embedding 向量化 | Embedding 向量化 |
| 存入 Vector DB | 存入 SQLite |
| 查询→向量→匹配 | 查询→向量→匹配 |
| 返回 Top-K 片段 | 返回 Top-K 片段 |
为什么用 SQLite 而不是专业向量数据库?
SQLite 的优势
- 轻量零依赖 — 不需要跑独立服务,就是一个文件
- 够用了 — 个人 Agent 的记忆量级(MB级别),不需要分布式和万级并发
- 跨平台 — Windows/Mac/Linux 一个文件走天下
- sqlite-vec 插件 — 在 SQLite 里直接做向量搜索
什么时候该换?
| 场景 | 建议 |
|---|---|
| 单 Agent 个人使用 | SQLite 够用 |
| 多 Agent 共享知识库 | 考虑 Qdrant/Milvus |
| 亿级向量 | 必须换专业向量数据库 |
索引的数据结构
每个 Agent 的索引是一个 SQLite 文件:~/.openclaw/memory/*.sqlite
表结构
sql
-- 原始文本存储
CREATE TABLE chunks (
id TEXT PRIMARY KEY,
source_path TEXT, -- 来源文件:MEMORY.md, memory/2026-04-09.md
chunk_text TEXT, -- 分块后的文本内容
chunk_index INTEGER, -- 在原文件中的位置
created_at TIMESTAMP,
updated_at TIMESTAMP
);
-- 向量存储(sqlite-vec 插件)
CREATE TABLE vectors (
id TEXT PRIMARY KEY,
chunk_id TEXT REFERENCES chunks(id),
embedding BLOB -- 向量数据
);语义检索配置状态
二毛的配置用了 Ollama(本地模型服务器):
json
"memorySearch": {
"provider": "ollama",
"remote": {
"baseUrl": "http://localhost:11434/v1"
}
}需要确认:
- Ollama 服务是否在运行
- 是否已拉取 Embedding 模型(常用:
nomic-embed-text)
验证命令:
bash
# 检查 Ollama 是否在运行
curl http://localhost:11434/v1/models
# 检查 embedding 模型
ollama list总结
OpenClaw 的记忆系统是一个轻量级 RAG 实现,用 SQLite + sqlite-vec 替代专业向量数据库,在保证功能完整的同时实现了零依赖和跨平台。对个人 Agent 场景完全够用。
相关工具
- OpenClaw Memory System
- SQLite
- sqlite-vec
- Ollama
- Embedding Model
- RAG