OpenClaw内置向量记忆插件memory-lancedb研究

一、什么是 memory-lancedb 插件

memory-lancedb 是 OpenClaw 内置的向量记忆插件，基于 LanceDB 向量数据库实现，为 AI 对话提供语义搜索能力。

向量数据库在 AI 记忆中的位置

AI 记忆系统通常有两层：

向量数据库的核心思想是：将文本转换成”数字向量”（embedding），存入向量库。搜索时，把问题也转成向量，找出”距离最近”的记忆——这比关键词匹配强大得多。比如问”备份老失败怎么办”，向量搜索能找到所有相关讨论，而不只是包含”备份”这个词的记录。

memory-lancedb 与内置记忆系统的关系

OpenClaw 已有两套记忆系统：

• MEMORY.md + 每日笔记
  
  ：人工维护的结构化长期记忆，按日期组织
• 梦境系统（Memory-Core）
  
  ：每日凌晨批量处理 session 文件，高分内容写入 MEMORY.md

memory-lancedb 是第三套，主打实时语义搜索，与上述两者不冲突，可以共存。

二、如何安装和启用

前置条件

memory-lancedb 需要以下组件：

1. Ollama
   
   （本地 LLM 运行时）
2. nomic-embed-text
   
    模型（向量编码模型，768 维）

安装 Ollama：

curl -fsSL https://ollama.com/install.sh | sh

拉取向量模型：

ollama pull nomic-embed-text

启动 Ollama 服务：

systemctl start ollama

插件启用配置

修改 ~/.openclaw/openclaw.json，在 plugins.entries 中添加或确认以下配置：

{  "plugins": {    "entries": {      "memory-lancedb": {        "enabled": true,        "config": {          "embedding": {            "apiKey": "not-needed",            "model": "nomic-embed-text",            "baseUrl": "http://127.0.0.1:11434/v1",            "dimensions": 768          },          "autoCapture": true,          "autoRecall": true,          "captureMaxChars": 1000        }      }    }  }}

关键参数说明：

验证是否正常运行

启用后重启 Gateway：

systemctl restart openclaw-gateway

查看日志确认插件加载：

tail -f /root/.openclaw/logs/gateway.log | grep "memory-lancedb"

正常输出：

memory-lancedb: initialized (db: ~/.openclaw/plugin-runtimes/memory-lancedb/lancedb, model: nomic-embed-text)

三、工作原理

整体架构

用户对话 → agent_end 钩子触发 → 提取对话文本（role=user 的消息）→ 关键词过滤（MEMORY_TRIGGERS 匹配）→ 调用 Ollama（nomic-embed-text）生成向量 → 存入 LanceDB 表（id / text / vector / importance / category / createdAt）→ 搜索时：query → 向量 → LanceDB 向量搜索 → 相似度排序 → 返回结果

存储 Schema

LanceDB 表结构（表名：memories）：

自动捕获机制

插件通过 before_prompt_build 和 agent_end 两个钩子实现自动捕获：

触发条件（MEMORY_TRIGGERS）：

• 包含”记住”/”remember”/”prefer”等关键词
• 包含邮箱、手机号（10 位以上数字）
• 包含”always”/”never”/”important”等强度词
• 包含”My xxx is…” / “I like…” 等偏好表达

捕获上限：每次对话最多捕获 3 条，防止数据爆炸。

去重机制：存入前会先搜索是否有相似内容（相似度 > 0.95 则跳过），避免重复记录。

搜索机制

向量搜索使用 LanceDB 的 vectorSearch 方法：

1. 将用户 query 通过同一 embedding 模型转成向量
2. 在 LanceDB 表中做向量最近邻搜索（默认返回 5 条）
3. 计算余弦相似度分数：score = 1 / (1 + distance)
4. 过滤：只返回 score >= 0.5 的结果
5. 注入到下次推理的 system prompt 中

四、优势

1. 语义搜索能力强

传统关键词匹配只能找包含相同词的内容，向量搜索能理解语义。例如：

• 问题：”上次那个备份失败的问题怎么处理的？”
• 向量搜索能找到关于备份的所有相关讨论，即使从没出现”备份”这个词

2. 自动运行，无人工成本

autoCapture: true 后，对话中的关键信息自动被提取存入，不需要人工整理。

3. 实时更新

不同于每日批量处理的梦境系统，memory-lancedb 在每次对话结束后立即存入，记忆几乎是实时的。

4. 与现有记忆系统互补

• MEMORY.md
  
   = 人工精选的长期记忆（高质量但稀疏）
• 梦境系统
  
   = 每日提炼的精华（中等质量，定时）
• LanceDB
  
   = 全量捕获的语义记忆（高数量，实时）

三者可以并存，各司其职。

五、劣势

1. Agent 数据不隔离（核心问题）

所有 Agent 的对话数据存入同一张表，没有 agentId 字段区分。

当前存储 schema 中没有 agentId，agent_end 钩子虽然能通过 ctx.agentId 获取来源 Agent，但插件代码完全忽略了这个字段。

这意味着记忆全部混存在一起，搜索时可能互相污染。

2. 部署复杂度增加

需要额外部署 Ollama + 拉取模型，增加了运维负担。且 nomic-embed-text 模型约 274MB，需要预留存储空间。

3. 向量数据存储开销

每条记忆除了原始文本，还需存储 768 维浮点向量（约 3KB/条）。对话量大时存储增长明显。

4. 无法按 Agent 禁用

插件启用是全局性的。一旦开启，所有 Agent 的对话都会被捕获，无法只让特定 Agent 使用，或排除特定 Agent。

5. 搜索质量依赖 embedding 模型

nomic-embed-text 是轻量级模型，中文语义理解能力有限，中文对话的向量化效果可能不如英文。

六、建议

当前环境不建议启用

在我们当前的多 Agent 环境下（main / loan / observer / writer / coder），数据隔离问题是决定性障碍。loan 处理客户敏感信息，一旦与 main 的对话混存，存在数据泄露风险。

仅单 Agent 或可尝试

如果只有单一 Agent 使用场景（如个人助手），或能接受所有数据混存，启用后能获得不错的语义搜索体验。

关注后续版本

建议关注 OpenClaw 后续版本更新，等待插件支持：

• agentId
  
   字段（存入时标记来源）
• 搜索时按 agentId 过滤
• per-agent 启用/禁用开关

替代方案

当前阶段，保持现有记忆体系即可：

• MEMORY.md
  
   管理精选长期记忆
• 每日笔记（memory/YYYY-MM-DD.md）
  
   记录日常对话
• 梦境系统
  
   凌晨提炼精华写入 MEMORY.md

这套体系虽然不如向量搜索”智能”，但胜在安全、可控、无额外依赖，且完全按 Agent 路径天然隔离数据。

附录：相关文件路径

研究结论：memory-lancedb 是一个有潜力的向量记忆方案，但当前版本在多 Agent 环境下的数据隔离机制不完善，建议等待后续版本更新后再正式启用。