在「记忆互通」上线之前，我给 WorkBuddy 接了一个跨设备记忆层

作者：Yujia Xian（鲜妤佳）｜河北金融学院 项目：memory-bridge（记忆桥）｜MIT 协议｜github.com/jiabaobei/memory-bridge 论文：CDSMP，DOI 10.5281/zenodo.22065186

一、先说我为什么不等官方

10 月 29 日那场发布会之后，我把 Buddy One 的文档从头看到尾。五个统一里，我最关心的是「记忆与数据」，因为那是我自己吃了很久苦头的地方。

但翻到文档末尾，看到一行小字：记忆互通，即将上线。

那一刻我其实有点激动——不是因为失望，是因为我知道那个坑有多深。因为我在自己的机器上，已经填了一年。

我是一名大四学生，学区块链工程。我用过七八个 AI 工具，电脑上同时装着 WorkBuddy、Claude Code、Cursor、ZCode。我最痛苦的事不是模型不够聪明，是每换一个工具，就要把背景重讲一遍。

在家里电脑上聊过的方案，出门用手机再问一遍，它完全不认得；在手机上让它整理过的材料，回到电脑上接着改，得从头再讲一遍。每一次换设备，等于重新认识一个新用户。

这不是麻烦，这是时间被反复消耗。所以我从 2026 年 8 月开始，自己写了一个东西，叫 memory-bridge。它干的事很简单：把记忆从 AI 内部搬出来，放到所有 AI 都能来取的地方。

二、它现在是什么状态

不是 Demo，是在跑的。

• 28 个模块、6900 余行代码，纯 Python 标准库实现，零第三方运行时依赖
• MIT 协议开源，GitHub 450+ stars，一年多时间里发了 16 个版本
• 记忆库当前状态：747 条记忆节点、67756 条语义关联边
• 跨 3 台设备同步（本机、另一台 Windows、一台容器），走坚果云通道，加密差分传输
• 已经接入 WorkBuddy（SessionStart + UserPromptSubmit 双钩子）、Claude Code、Cursor、ZCode

在同名论文 CDSMP（Cross-Device Semantic Memory Persistence）里，我把这套架构写完了，发表在 Zenodo，也被 ATCIDS 2026 收录。论文和代码是同一个人做的——架构怎么设计，代码就怎么实现，中间没有信息损耗。

三、我是怎么接进 WorkBuddy 的

方法比想象的简单，因为 WorkBuddy 允许外部钩子。

核心只有一条命令：

membridge hook --install

它做的事是：往宿主（WorkBuddy）的配置里注册两个钩子——SessionStart 和 UserPromptSubmit。之后每次你开一个新会话、或者发一条消息，WorkBuddy 会先调一次：

membridge hook

这个命令只读缓存，不查库，毫秒级返回，输出一段按当前任务过滤过的记忆上下文。

缓存由 membridge hook --warm 在空闲时预热。实测下来，注入这一步几乎感知不到延迟——因为它读的是一个 JSON 文件（inject-cache.json），不是数据库。

另外还有一条路：membridge mcp 会把记忆库起成一个 MCP server，任何支持 MCP 的客户端都能接。这条更适合想自己做集成的人。

关键点在于：整个过程不需要改 WorkBuddy 一行代码。 它只要求宿主愿意在会话开始时读一段外部文本。

四、技术上我做了三个取舍

第一，检索不靠关键词。 我做的是语义关联网络（SAN）——记忆之间会形成关系边，检索时沿着边走，而不是字符串匹配。现在库里有 67756 条边，其中 66965 条是语义边。好处是你说「上次那个方案」，它真能找回上次那个方案，而不是把含「方案」两个字的全捞出来。

第二，同步只传变化。 差分语义同步（DSS）——只把新增或修改的节点打包，加密后投递到通道目录，对端取走再合并。同步开销比全量传输降低了 92%，这是跨设备能一直开着的前提。

第三，隐私边界写进代码，不写在文档里。 很多项目讲隐私靠「要求大家遵守」，我选择让它结构上做不到违反：设备级记忆禁止离开原设备，跨场景调用需要显式授权，内容级敏感信息在传输前脱敏。不是靠「要求不该改」，而是让实现在「做不到改」。

这一条我后来发现，和腾讯网盘那次实测里「这个我读不了，要不要帮你申请权限」是同一个思路——记忆层的护城河不是容量，是权限的诚实。

五、我看到的空档

腾讯这套东西的方向我认为是对的：接得上别家，才叫中枢；只接自家，那叫附件。 连接名单里出现百度网盘，说明这件事他们是认真想做的。

但从工程角度看，现在有三处还是空的：

1. 记忆互通标着「即将上线」 —— 目前是只读检索，跨应用写入还得回 MCP
2. 不支持解绑 —— 账号绑错只能换号重来，上下文和积分都不跟着走
3. 记忆存在网盘里，是可见的 —— 可见很好，但「可见」和「可治理」之间还有距离

第 2、3 条是我在自己项目里反复踩过的坑。我的做法是：通道身份可校验、设备可摘除、同步包可审计（每条边都能追溯来源）。这些不一定适用于腾讯的架构，但如果他们要补，我这边有踩过的坑可以分享。

六、我想说的就一句

我不是来推荐项目的。腾讯有太多比我强的人，一个学生的个人项目不可能被正式采用，这点我很清楚。

我只是想说：「记忆互通」这件事，在它上线之前，已经有人在用另一种方式跑通了。 代码在那里，MIT 协议，谁都可以拿去用，包括腾讯。用不用、怎么用，都不是我能决定的。

但如果腾讯真的从里面看到了一点点有用的东西，哪怕只是在某篇文档的脚注里写一句「参考了 CDSMP / memory-bridge」，对我来说就足够了。

那说明我这一年没有白写。

项目地址：github.com/jiabaobei/memory-bridge

论文：Cross-Device Semantic Memory Persistence，DOI 10.5281/zenodo.22065186

接入方式：pip install membridge → membridge init → membridge hook --install