OpenClaw 长期记忆升级手记:把 Embedding 换成 BGE-M3

一、为什么动了换模型的念头

OpenClaw 的 Memory Search 本质上是个轻量 RAG：把对话记录、日志、笔记索引成向量，靠语义相似度检索。这套方案的天花板由 Embedding 模型决定——模型弱，记了等于没记。

之前一直用 bge-small-zh-v1.5，33M 参数的中文小模型。用了几个月，问题暴露得很彻底：

• 上下文不够用
  
  ：官方说 512 tokens，但 OpenClaw 的 chunk 还要带文件路径、时间戳等元信息，留给正文只剩约 300 字符——日志写长了直接砍尾
• 区分度低
  
  ：512 维向量，”重启 aaaprod”和”重启 bbbprod”经常被归为同一条
• 得另挂一个 HTTP 服务
  
  ：走 OpenAI Compatible API 暴露推理端口，得多维护一个 Python 进程

三个问题叠在一起，终于下决心换掉它。

二、四个候选横向对比

把常见方案摆到一张表里看，一目了然。

本地 Embedding

云端 API（备选）

我的筛选路径很直接：

• 云端 API 直接出局——记忆里全是私人对话和工作日志，让它过一遍别人的服务器心里过不去
• bge-small-zh-v1.5
  
   就是要换掉的，不再看
• bge-large-zh-v1.5
  
   维度够，但上下文还是 512 tokens，纯中文
• nomic-embed-text
  
   是个合格的备选，768 维 + 8192 上下文，可惜多语言和精度略逊
• bge-m3
  
   各项几乎拉满——1024 维、8192 tokens、多语言、Ollama 原生支持

三、不同服务器的推荐配置

模型选定之后，还要看自己的机器吃得消不。下面按常见规格给三档建议。

🥉 2 核 4G（入门级）

最常见的轻量云服务器，4G 内存分给 OS、OpenClaw、Embedding 模型之后已经有点紧张。推荐选 nomic-embed-text，必要时退到 bge-small-zh-v1.5。内存预算大约 2.2GB，余下 1.8GB 给系统，CPU 模式下响应延迟 30-80ms，体验还行。

💡 硬上 bge-m3 也能跑——加 2G swap 顶一下内存峰值，但不建议长期这么干。

安装步骤：

curl -fsSL https://ollama.com/install.sh | shollama pull nomic-embed-textollama show nomic-embed-text

OpenClaw 这边切模型：

openclaw config set plugins.entries.memory-core.config.embedding_model nomic-embed-textopenclaw memory index --force

🥈 2 核 8G（推荐配置）

8G 内存是舒服的起点，跑 bge-m3 游刃有余。内存预算大约 4GB 用掉，余下 4GB 给系统和缓存。CPU 模式单次 Embedding 50-200ms，对记忆搜索这种非实时场景完全够用。

三步搞定：

curl -fsSL https://ollama.com/install.sh | shollama pull bge-m3ollama show bge-m3

验证一下输出长这样：

embedding length    1024capabilities        embedding

OpenClaw 同机器直接用，不在同机器的话改一下 base_url：

openclaw config set plugins.entries.memory-core.config.embedding_base_url http://<OLLAMA_IP>:11434openclaw memory index --forceopenclaw memory status --index

看到下面这行就说明通了：

Provider: ollamaModel: bge-m3Vector dims: 1024

🥇 4 核 16G+（无脑上）

没什么好纠结的，bge-m3 随便跑。如果还要同时跑 LLM 推理，或者记忆量大到几万个文件，这个配置体验最好。

四、为什么 BGE-M3 全维碾压

1. 上下文：从 300 字符到 8192 tokens

这是体验差距最大的一环。bge-small-zh-v1.5 官方说 512 tokens，但 OpenClaw 的 chunk 还要带文件路径、时间戳等元信息，留给正文的只剩 300 字符左右。一篇工作日志动辄上千字，截断之后后半段直接被砍掉，搜索自然找不到。

换到 bge-m3 后 8192 tokens，再长的 chunk 也能完整编码。我测了一下：搜 “Jenkins cnbguat deploy status 修复”，6 条结果全部精准命中对应修复记录，向量分 0.52-0.68。换模型之前经常搜不到，或者返回完全不相干的内容。

2. 维度：512 → 1024

维度从 512 拉到 1024，语义空间的容量翻倍。举个实际的例子——”重启 cnbgprod 的 apps-ingage-doc”和”重启 xdprod 的 apps-ingage-doc”这两条记录，旧模型经常混到一起，新模型能很好地区分环境名和服务名的差异。

3. 多语言

我的记忆文件里中文英文混着写——技术术语、服务名、错误堆栈全是英文。bge-m3 是多语言模型，混排也能准确编码。bge-large-zh-v1.5 维度一样，但只针对中文，遇到英文术语就抓瞎。

4. Ollama 部署，省心

Ollama 是这次选型的关键变量：

• 一行装好：curl -fsSL https://ollama.com/install.sh | sh
• 一行拉模型：ollama pull bge-m3
• systemd 自动管理，安装即开机自启
• 有 NVIDIA GPU 自动用 GPU，没有就 CPU，零配置
• OpenClaw 默认对接 localhost:11434，不用额外配置

对比之前用 OpenAI Compatible 方案——自己写 Python HTTP 服务、自己写 systemd unit，Ollama 至少省了三天的折腾。

5. CPU 模式够用

我的服务器没显卡，纯 CPU 跑 bge-m3 单次 Embedding 50-200ms。记忆索引是异步的，搜索也是按需触发，延迟感知很弱。

6. 隐私

所有 Embedding 计算在本地完成，记忆文件不出服务器。这点和云端 API 之间差距最大——个人对话、工作日志、技术笔记，让它们每条都上传一遍，心里那关过不去。

一张表看完选型结论

💡 2C8G 以上无脑 bge-m3；2C4G 选 nomic-embed-text；再低的配置直接走云端 API，硬扛本地没意义。

五、迁移：5 分钟搞定

从旧模型切到 bge-m3 只需要三步：

ollama pull bge-m3openclaw memory index --forceopenclaw memory status --index

重建索引过程中 OpenClaw 仍然可用，搜索会自动切到新模型。等索引跑完就是 1024 维 + 8192 tokens 的精准记忆搜索了。

六、踩坑实录

坑 1：旧模型上下文截断，搜索不准

512 tokens 听起来够用，但 OpenClaw 的 chunk 会带元信息，真正留给正文的只有 300 字符左右。长日志的后半段直接被砍，搜索要么找不到，要么返回不相关的内容。

坑 2：Ollama 默认只监听本地

OpenClaw 和 Ollama 不在同一台机器时，要改 Ollama 的监听地址：

sudo mkdir -p /etc/systemd/system/ollama.service.dsudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF'[Service]Environment="OLLAMA_HOST=0.0.0.0:11434"EOFsudo systemctl daemon-reloadsudo systemctl restart ollama

坑 3：换模型后索引不会自动重建

换了 Embedding 模型必须手动 openclaw memory index --force。不然旧向量（512 维）和新模型（1024 维）维度对不上，搜索直接报错。

七、迁移前后的对比

迁完之后体感差异很明显：

八、写在最后

Memory Search 是 AI 助手的”长期记忆”，Embedding 模型决定记忆的质量底线。模型选对了，助手越用越顺手；选错了，记了一堆也搜不出来。

对于个人开发者和小团队，Ollama + BGE-M3 是本地 Embedding 的最优解——部署简单、隐私可控、精度够用。2 核 8G 的小服务器就能舒服地跑，月成本几十块，比云端 API 划算得多。

如果你也在用 OpenClaw 或者搭自己的 RAG 系统，强烈建议试一下这个组合。

— 基于 OpenClaw v2026.6.x + Ollama 0.x + bge-m3 实测整理 —

💬 如果觉得有收获，欢迎在评论区留言交流 👇

作者 · VV · AI 工具 & 技术分享