如何让你的各个 AI 助手共用同一份记忆

你向一个助手解释了自己的技术栈、客户和各种约束。两周后你换了另一个模型，因为它在你现在需要的事情上更强——于是一切从零开始。你积累起来的记忆并不属于你，它活在别人的产品里。

这才是真正的问题。问题不是助手会遗忘：如今大多数助手记得相当不错。问题是每一个都各记各的，存在一个你既读不到、搬不走、也指不到别处去的仓库里。

内置记忆，还是属于你的记忆

原生记忆功能方便且免费。它们也有三个需要你看清楚的性质：记什么由厂商决定，数据留在厂商那里，你离开时什么都带不走。对于随手使用，这笔交易很划算。对于你要经营数年的工作，这是一种你没察觉就选下的锁定。

另一条路是把记忆放在所有助手之外，让每一个助手去读它。这需要一个双方都认可的协议，而这正是 MCP 登场的地方。

MCP 到底是什么

Model Context Protocol 是一个开放标准，用于把助手连接到外部的工具和数据。它由 Anthropic 发布，此后的采用范围早已远远超出 Claude。从模型的角度看，一个 MCP 服务器不过是一组可调用的工具：存这个，搜那个。

一个记忆服务器大致暴露四个工具——写入一条记忆、搜索记忆、列出一个项目、浮现当下相关的内容——当对话需要时，助手会自己去调用它们。你不再粘贴上下文；模型自己去取。

MCP 服务器有两种形态，这个区别比任何功能对比都更重要：

• 本地（stdio）。 服务器作为一个进程跑在你的机器上。快、私密、免费——同时对任何不是这台机器上的桌面应用的东西都不可见。手机看不到，浏览器标签页也看不到。
• 远程（HTTP + OAuth）。 服务器活在一个 URL 上。任何支持远程连接器的客户端都能登录使用，从任何设备。

如果你想要一份在多个助手和多台设备之间共享的记忆，你要的是第二种。如果你想要一份只待在一台笔记本上、永不外流的记忆，第一种确实是更好的答案，而且它免费。

远程记忆是怎么接上的

没有安装这一步。一个远程 MCP 服务器就是一个 URL 加一次 OAuth 登录，和把日历接到某个应用是同一套流程：

1. 把服务器 URL 粘贴到客户端的连接器设置里。
2. 客户端拉取服务器的 OAuth 元数据并自动完成注册。
3. 你在浏览器窗口里授权一次访问。
4. 工具出现了。助手会在相关时开始调用它们。

在第二个客户端里重复第一步，两边从此读写同一份记忆。全部诀窍就在这里：记忆是一个服务，不是一个文件。我们自己按客户端逐步配图的版本在连接指南里。

存储很容易。检索才是产品。

什么东西都能往数据库里追加文本。难的是几个月后，在一场毫不相干的对话中途，回答出你那四千条笔记里此刻要紧的是哪五条。这一步做砸了，你建的就是一个没人读的档案库。

两种失败方式，都很常见：

• 只用关键词搜索会漏掉一切措辞与你当初写法不同的内容。
• 只用向量搜索会返回一些大致沾边的东西，却错过确切的名字、错误码和标识符——恰恰是你需要的那些细节。

认真的实现会两种都跑，再把排名合并——通常用的方法是倒数排名融合——然后用一个真正把查询和候选放在一起读的重排序模型给短名单重新打分。每次查询的成本更高，而它就是「一份记忆」和「一堆东西」之间的差别。

如果你用不止一种语言工作，请专门核实这一点。一条按英语嵌入调优过的链路在法语或德语上会悄悄退化，而且这种故障是看不见的：你只是得到更差的结果，然后以为是自己笔记写得不好。

决定之前的五个问题

1. 本地还是远程？ 先定这个。无论往哪边定，都能排除掉市面上的大部分选项。
2. 数据放在哪里，受哪个司法管辖？ 如果网站上找不到答案，就当你不会喜欢那个答案。
3. 你能把数据取出来吗？ 随时可用的格式导出，不用去找客服申请。
4. 是混合检索加重排序，还是单纯的向量搜索？ 去问；这一点很少被宣传。
5. 免费额度到头时会发生什么？ 删除、冻结，还是转为只读——这是三种非常不同的结局。

Pryzm 的位置

Pryzm Memory 属于远程那一类：一个托管端点、一次 OAuth 登录，被你接入的每一个客户端共享。它跑在德国的服务器上，受欧盟司法管辖，静态加密，并由 PostgreSQL 本身为每个客户强制一套独立的数据库 schema 和角色。检索是混合式的，配多语言重排序器，覆盖八种语言。

它同时也不是开源的，而且今天你无法自托管——这对一部分人来说就足以出局，我们宁愿在这里直说，也不愿让你注册之后才发现。我们维护着一份诚实的与替代方案的逐项对照，包括那些正好在这两点上胜过我们的产品。