使用 WoClaw 解决多智能体共享记忆：让 OpenClaw、Codex、Claude、Gemini 站在同一张桌子上

我一直觉得，多智能体系统最难的不是“谁更聪明”，而是“谁还记得上一次已经讨论到哪里了”。

当你把 OpenClaw、OpenAI Codex、Claude、Gemini 这些工具放进同一个工作流里，最容易出现的问题并不是回答质量不够，而是上下文开始分叉：

1. OpenClaw 记住了调度顺序，Codex 记住了代码细节，Claude 记住了讨论结论，Gemini 记住了背景资料，但它们彼此并不知道对方知道什么。
2. 每个工具都有自己的会话生命周期，今天说过的话，明天可能就不在同一个上下文里了。
3. 一旦项目进入“多人、多轮、多工具”的阶段，重复解释背景会比真正解决问题更耗时。
4. 如果没有统一的记忆层，最后你得到的不是协作，而是几份彼此相似、又彼此不兼容的局部答案。

这篇文章想讲的就是：我怎么用 WoClaw 把这些工具拉到同一套共享记忆里，让它们从“各说各话”变成“围着同一份状态协作”。

为了避免泄露任何隐私信息，下面所有例子都做了抽象处理，不包含真实机器名、账号、地址、密钥和内部项目代号。

1. 多智能体真正难的，不是推理，而是记忆不同步

很多人第一次接触多智能体协作，直觉上会把重点放在“模型能力谁更强”。这当然重要，但在真实工程场景里，第一道坎往往不是模型是否聪明，而是它们是否能对齐同一份事实。

例如，一个简单的任务“给项目补一个 feature 并补齐测试”，在单智能体里可能只是一个连续会话；可一旦拆成多个角色，问题立刻复杂起来：

• OpenClaw 负责调度：谁先做、谁后做、哪个步骤需要等待。
• Codex 负责实现：改哪些文件、补哪些单测、如何修掉编译或类型问题。
• Claude 负责审查：从风险、边界条件、回归角度看有没有遗漏。
• Gemini 负责资料：查公开文档、核对外部信息、补足背景。

如果这四个工具没有共享记忆，那么每个人都只能依赖自己那一小段上下文。于是你会看到非常典型的现象：

1. Codex 改完代码后，Claude 还在按旧版本评审。
2. Gemini 查到的新资料没有及时喂给 OpenClaw，调度决策还是基于过时背景。
3. OpenClaw 重新分配任务时，忘了之前已经约定好的命名、路径或者部署策略。
4. 你本人则不得不在不同工具之间反复搬运同一段说明。

这个过程里最浪费的不是 token，而是人的注意力。

所以我后来慢慢形成一个判断：多智能体系统的核心，不是把更多模型叠在一起，而是把记忆和状态做成基础设施。 只要状态层做不好，再强的模型组合都会退化成“会说话的孤岛”。

2. WoClaw 的定位：不是另一个聊天工具，而是一层共享状态基础设施

WoClaw 的作用，不是替你“再造一个聊天框”，而是给多智能体工作流增加一层稳定的状态中枢。它把三件事分开处理：

1. Topics 负责实时协作，类似项目里的讨论室或者工单室。
2. Memory 负责长期事实，类似共享知识库、决策记录、约定事项。
3. History / Search / Versions 负责回溯，让你知道“当时为什么这么决定”。

这个分层很重要。因为现实里，实时讨论和长期事实不是一回事：

• 实时讨论适合放在 Topic 里，谁在线、谁加入、谁回复，都需要立刻可见。
• 长期事实适合放在 Memory 里，比如项目约定、默认命令、风险边界、已知坑位。
• 历史回溯则是另一层能力，它回答的是“这条记忆是怎么来的、什么时候改过、以前是什么”。

WoClaw 的价值就在于，它把这些能力统一到一个 Hub 里，OpenClaw、Codex、Claude、Gemini 都可以接上来，不必各自维护一套孤立状态。

图 1：WoClaw 的整体结构。多个智能体通过同一个 Hub 共享 Topics、Memory、Search 和 History。

在实现层面，我后来越来越确认一件事：共享记忆不是一个功能点，而是协作系统的骨架。 没有这个骨架，Topics 只能变成聊天室，CLI 只能变成短期传话筒，插件和 Hook 也只能把临时上下文搬来搬去，无法形成真正稳定的工作流。

3. 从广播到定向：@agent 让 Topic 真正变成协作空间

如果 Topic 只是“所有人都能看见的广播列表”，那它的协作效率其实并不高。因为真实协作里，经常不是“所有人都要回复”，而是“只让这两个人先处理”。

这就是我为什么给 WoClaw 加了真正的 @agent 机制。

它解决的不是语法问题，而是路由问题。也就是说：

• 你在一条 Topic 消息里写 @codex @claude，Hub 会把消息只投递给这两个被点到的 agent。
• 如果消息里既有 @agent，也有普通文本，普通文本仍然会被保留，只有目标路由发生变化。
• 如果点名的对象并不是当前 Topic 的成员，Hub 不会把它当作“未登录的广播目标”，而是直接忽略。
• 如果一个 @agent 都没有命中当前 Topic 的成员，系统会返回错误，避免你以为消息发出去了，其实没人收到。

这样做的好处很直接：

1. 降噪。不是每条消息都让所有人看到。
2. 定向。你可以明确指定谁先看、谁后看。
3. 可读。消息本身就携带协作意图，不需要额外约定。
4. 可回溯。消息依旧会留在 Topic 历史里，不会因为定向路由就消失。

图 2：@agent 不是纯文本装饰，而是 Topic 内的定向路由语义。

我更愿意把它理解成“Topic 里的工作单”。广播适合通知，点名适合协作。两者并不冲突，但它们解决的是不同层级的问题。没有 @agent 的 Topic 更像群聊，有了 @agent 的 Topic 才更像可以分派任务的协作室。

在日常使用里，这种机制特别适合下面几类场景：

• 让 Codex 先实现，Claude 再 review。
• 让 Gemini 先查资料，再把结论发回同一个 Topic。
• 让 OpenClaw 只把某个任务推给当前真正需要响应的 agent，而不是全员广播。

这不是“锦上添花”，而是减少噪声、降低误操作概率的核心设计。

4. 共享记忆不是一个 JSON 文件，而是一层可持续演进的状态层

很多人第一次做共享记忆时，会本能地想到一个简单方案：把所有东西写到一个 JSON 文件里。这个方案在原型阶段是够用的，但一旦进入真实协作环境，问题很快就会暴露出来：

1. 没有版本历史，改过什么很难追踪。
2. 没有结构化字段，标签、TTL、作者、更新时间都容易混在一起。
3. 没有稳定的查询能力，记忆一多就很难找。
4. 并发写入时，单文件方案很容易变得脆弱。

所以 WoClaw 这次把 Memory 层做成了真正可用的存储后端：默认是本地 SQLite，也可以切换到 MySQL。对我来说，这个选择背后的逻辑很清楚：

• 单机、自托管、小团队环境，SQLite 已经足够好，启动简单，维护成本低。
• 如果你后面需要更强的并发、更统一的部署策略，MySQL 也能接上去。
• 关键不是“哪种数据库看起来更高级”，而是它能不能稳定承载多智能体场景里的长期状态。

WoClaw 的 Memory 也不是单纯的 key/value。它同时支持：

• tags：帮助你按照主题、项目、类型去查。
• ttl：让某些临时记忆自动过期。
• versions：保留历史版本，知道一条记忆是怎么演进的。
• search 和 recall：让你既能做偏精确的关键词搜索，也能做偏宽松的语义召回。

图 3：Memory 的生命周期不是“写一次就完了”，而是“导入、存储、检索、回写、再协作”的循环。

我现在更愿意把 Memory 当成“团队共识的外置内存”。它存的不是聊天记录，而是：

• 项目约定。
• 常用命令。
• 默认配置。
• 已知风险。
• 关键决策。
• 重复出现的故障模式。

反过来说，它不应该存秘密、密码、临时噪声、或者任何不该被长期保留的内容。 这也是我为什么在自托管场景里特别强调鉴权、作用域和数据边界。共享记忆的前提，不是“到处都能看”，而是“在控制范围内共享”。

5. 把历史导进来：真正有用的不是摘要，而是可搜索的原始记忆

如果一个共享记忆系统只能接收“当前时刻的新内容”，那它很容易变成一个空仓库。真正有价值的系统，必须能把过去积累下来的历史也导进来。

我在 WoClaw 里最看重的一点，就是它不只支持在线写入，还支持把已有历史迁移过来。这样 OpenClaw、Codex、Claude、Gemini 就不是从零开始，而是带着已有经验进入同一套中枢。

这件事表面上看是“导数据”，实际上是在解决两个问题：

1. 避免重复劳动。 如果过去已经讨论过的结论还能被检索到，新的 agent 就不必从头再推一遍。
2. 避免知识断层。 历史记忆不是为了怀旧，而是为了让新的决策站在旧决策之上。

迁移时我会尽量保留原始内容，而不是只留短摘要。原因很简单：摘要在当下看起来轻便，但一旦你后面要追溯细节，它往往会变得不够用。尤其是一些技术场景，真正有用的是正文里的上下文、关键词、边界说明、甚至是“为什么不这么做”的记录。

这也是为什么 WoClaw 的历史导入不是“塞一段介绍文字”，而是尽量把原始内容、作者、时间、来源一起带上。这样后续检索、版本追踪、topic 回看才会更有意义。

在实际使用里，我会把历史迁移理解成三种层次：

1. OpenClaw 历史：把工作区里原有的记忆、会话存储和项目文档导进来。
2. Codex 历史：把会话、transcript、压缩前后的关键信息导进来。
3. Claude / Gemini 历史：把各自工具里的日志或历史记录导进来。

迁移这件事的核心，不是“导得越多越好”，而是“导得够完整、够干净、够能搜”。

6. 四种工具，各做各的强项，然后在 WoClaw 里对齐

我在实际工作里并不追求让一个模型包打天下。相反，我更愿意让每个工具做自己最擅长的事，然后由 WoClaw 负责把它们的状态对齐。

一个典型工作流大概是这样的：

1. 我先在 Memory 里写下项目上下文。
2. OpenClaw 根据上下文把任务拆成几步。
3. Gemini 先去做资料补充，把外部背景写回同一个记忆层。
4. Codex 根据统一上下文改代码、补测试、修兼容问题。
5. Claude 负责看回归风险、边界条件、文档表达是否准确。
6. 最后所有关键结论再回写到 Memory，形成下一轮工作的起点。

一个很实用的例子是这样的：

woclaw memory write project-context "本项目需要支持多智能体共享记忆、topic 路由和历史导入"
woclaw send design-review "@codex 请先实现话题点名路由，@claude 请 review 边界条件，@gemini 请核对外部资料"
woclaw memory search "共享记忆"

这类命令看上去很朴素，但它背后的协作方式已经和“每个工具各玩各的”完全不一样了。你不是在不同模型之间复制粘贴，而是在同一份状态上接力。

我尤其喜欢这种工作流的一个原因，是它让“谁负责什么”非常清楚：

• Codex 写代码。
• Claude 看风险。
• Gemini 查背景。
• OpenClaw 把流程串起来。
• WoClaw 负责把所有结果留在同一个地方。

当你把职责边界讲清楚之后，多智能体系统就不再是“所有人一起瞎忙”，而是“每个人都在同一条主线上提供自己的强项”。

7. 我真正关心的，不是功能数量，而是闭环

做这类系统做久了，你会慢慢发现：功能堆得再多，如果不能形成闭环，最后还是会回到“临时看一眼、然后忘掉”。

所以我现在更看重 WoClaw 的不是某一个单项能力，而是它是否真的把下面这些环节串起来了：

1. 写入：新的事实、结论、决策能不能方便地写进去。
2. 检索：后面要找时，是不是能找到。
3. 历史：这条内容什么时候改过，旧版本是什么。
4. 路由：Topic 消息是不是能准确送给该看的 agent。
5. 可视化：Web UI 能不能让你在浏览器里看懂当前状态。
6. 接入方式：CLI、Hook、Plugin、MCP 是否都能复用同一层逻辑。

如果这几个环节能连起来，系统才有“可维护性”。否则它只是一个能发消息的工具箱。

这里我特别想强调一下搜索。共享记忆如果只有“按 key 精确读写”，它会很快卡死在组织成本上；但如果搜索过于宽松，又会把很多无关项捞上来，最后用户被噪声淹没。后来我把搜索调成更偏关键词、更偏正文匹配的逻辑，就是为了让它更接近“我真的能找到我想要的那条记忆”，而不是“系统猜测也许你想要这个”。

对我而言，一个好用的共享记忆系统，应该让你能回答下面这些问题：

• 这件事到底有没有写进记忆？
• 当时是谁写的？
• 哪个版本是最新的？
• 之前有没有改过？
• 同一个 topic 下，相关消息是怎么往下传的？

如果这些都能快速查出来，那它就不是“辅助工具”，而是工作流的一部分。

8. 隐私和安全：能共享，不代表该公开

共享记忆最容易被误解的一点，就是“共享”不等于“公开”。

我在设计 WoClaw 的时候，始终把它当成自托管基础设施，而不是公有云聊天服务。这里有几个原则我一直很坚持：

1. 只在自己可控的环境里部署。
2. 不把密钥、密码、Token 之类的敏感信息写进共享记忆。
3. 对 topic 和 memory 保持最小必要的可见范围。
4. 对历史导入做筛选，避免把不该保留的内容一股脑搬进来。
5. 通过鉴权、私有 topic、TTL 和存储策略控制数据边界。

这也是为什么我不喜欢把“共享记忆”描述成一种很玄的能力。它本质上还是工程问题：权限怎么管、数据怎么存、过期怎么删、谁能读谁能写，都得讲清楚。

尤其是当你把多个工具接进来之后，安全边界更要明确：

• OpenClaw 可能是入口层，所以它应该只拿到它需要的最小能力。
• Codex 可能负责执行，所以它不应该接触不必要的敏感项。
• Claude 和 Gemini 可能参与分析和研究，因此它们也应只看到被授权的上下文。

共享记忆的目标，是让协作更顺畅，不是让所有东西都毫无边界地扩散。

9. 如果你也要落地，建议先做一个最小闭环

如果你想把类似能力接到自己的项目里，我建议不要一上来就追求“所有模型都接好、所有历史都导完、所有 UI 都做出来”。最稳的方式，是先做一个最小闭环。

我会把这个最小闭环拆成四步：

第一步：先起 Hub

先把 WoClaw Hub 跑起来，确认 topic 和 memory 都可以正常写入、读取、回看历史。

第二步：只接一个主入口

先让 OpenClaw 或你最常用的那个入口接上去，确认它能读写共享记忆，能发 topic 消息。

第三步：加上 @agent

挑一个明确场景，比如“让 Codex 写、Claude review”，用 @agent 把消息路由给指定对象，确认路由语义是准确的。

第四步：导入一小段历史

先导入一小段最关键的历史，不要一口气把所有内容都搬进来。导入之后，先试着搜索、回看、再写回新的记忆。

一个很实用的检查顺序是：

woclaw status
woclaw topics
woclaw memory write project-context "..."
woclaw send review "@codex @claude 请检查这条规则"
woclaw memory search "project-context"

如果这五步都能顺畅跑通，那你已经有了一个真正可用的协作骨架。后面的工作，无论是接更多工具、做更复杂的 UI，还是扩展更多自动化任务，都会容易很多。

10. 一个更具体的工作流样例

为了把上面这些概念落到地上，我更愿意用一个具体但抽象化的例子来收尾。

假设你现在要做一个功能：为 WoClaw 增加一个更精确的 topic 搜索，同时让 OpenClaw、Codex、Claude、Gemini 都知道这次改动的上下文。

我会这样做：

1. 先用 Memory 写下这个功能的目标、约束和验收标准。
2. 让 OpenClaw 把任务拆成“代码修改、测试、文档、发布”四个部分。
3. 让 Gemini 先查外部资料，确认有没有相关的实现思路或者兼容性风险。
4. 让 Codex 实际改代码，补单测，修编译错误。
5. 让 Claude review 变更是否会破坏现有 topic 历史、memory 搜索、权限边界。
6. 把最后确认过的结论再写回 Memory，作为下一次功能演进的起点。

这个流程里最重要的一点是：任何一个工具完成的信息，都不会只停留在它自己的会话里。 它要么进入 Memory，要么进入 Topic 历史，要么进入可检索的版本记录。这样下一轮工作才不会从零开始。

这也是我做 WoClaw 最核心的动机：不是为了让模型之间互相聊天，而是为了让它们真正共享状态、共享历史、共享协作上下文。

结语

如果一定要用一句话概括这篇文章，我会说：多智能体协作真正缺的，不是更多模型，而是一个大家都能信任的共享记忆层。

WoClaw 解决的正是这件事。它让 OpenClaw 负责调度，让 Codex 负责实现，让 Claude 负责审查，让 Gemini 负责补充资料，而把“共同记住什么、怎么记、怎么找回来”交给统一的 Hub。

当你把这个基础设施搭起来之后，多智能体系统才会从“临时拼装”变成“可持续协作”。这也是我现在对这类系统最现实、也最有信心的一种理解。

GitHub 项目链接：https://github.com/XingP14/woclaw