给14个AI Agent装上共享记忆：MemOS踩坑实录

我们有15个 Agent 在跑，每个都是孤岛——同一件事各自记了一遍，或者完全没记。问一个 Agent 上周发生了什么，它一脸空白。这个问题拖了很久，直到我们把 memos-local-openclaw-plugin 接上去。

这篇是接入过程的完整踩坑记录，三个 bug，每个都不算小。

为什么要做共享记忆

当你有一个 Agent 的时候，记忆问题不明显，上下文撑得住。但我们有14个。每个 Agent 负责不同的职能：内容、代码、部署、设计、SEO、社群……它们之间没有共享状态，每次召唤都是全新的。

真正让我们下决心做这件事的是一次具体事故：小蜜蜂在某台服务器上部署了一个服务，但这件事没有任何地方记录。两周后，另一个 Agent 被问到那台服务器的状态，回答说不知道。问小蜜蜂，它也忘了。

答案其实在，只是没有地方存。

这是我们选的方案。本地运行，基于 SQLite，通过 OpenClaw plugin 接口暴露给所有 Agent，不依赖外部服务。理论上挺干净的。

实际上踩了三个 bug。

第一个发现的问题：搜索记忆时，只要 filterRelevant 这一步出了任何异常，返回的就是空列表——不是报错，是静默返回空。

Agent 以为没有相关记忆，实际上是有的，只是过滤这一步炸了。

我们查了一下，触发条件是候选数量为零时 filterRelevant 里有一处除以零的隐患。不过更根本的问题是：filterRelevant 失败不应该让整个搜索失败。

修法：filterRelevant 失败时，fallback 返回全量候选，让 Agent 自己判断相关性，总比丢数据好。

我们的 MemOS 用了 Qwen3.5 做语义相关性判断。Qwen3.5 在 thinking 模式下，content 字段可能是空字符串，实际的推理结果在 reasoning 字段里。

原来的代码直接读 content，拿到空字符串，判定所有候选都不相关，全部过滤掉。

修法：加 fallback——content 为空时读 reasoning 字段。一行代码，但找到这个问题花了不短的时间，因为表现和 Bug 1 一模一样：搜什么都没有结果。

这个最蠢，也最快修。

代码里用了 ?? 操作符（nullish coalescing），OpenClaw 内嵌的 JS 解析器不支持这个语法，直接抛 parse error，整个插件起不来。

把所有 ?? 换成 ||，插件跑通了。

顺手记一下：OpenClaw 的 JS 解析器对 ES2020+ 语法支持不完整，之后写插件要注意。

在三个逻辑 bug 之外，还有一个环境问题：better-sqlite3 的 native binding 是针对特定 Node.js 版本编译的。我们跑 Node v25，但 npm 下载的 prebuilt binary 是针对旧版本的，直接加载会失败。

解法是重编译：npm rebuild better-sqlite3。这一步需要本机有 Xcode Command Line Tools，M 系列芯片上一般都有。

搜「小蜜蜂部署服务器」，秒命中那次部署记录。全队14个 Agent 共享同一个知识库，任何一个 Agent 存进去的东西，其他 Agent 都能查到。

这个改变比我预期的影响更深。以前每个 Agent 都是无状态的，每次召唤都要重新建立上下文。现在有了共享记忆之后，Agent 之间开始有了延续性——它们记得发生过的事，记得做出的决定，记得踩过的坑。

共享记忆不是锦上添花，是多 Agent 协作的基础设施。踩的坑不多，但每一个都藏得很深。