本地存储

Key Takeaway

虽然我经常喷OpenAI，不过他们关于“全局记忆”的判断和观点我是非常认同的。

往小了说，“全局记忆”关系到对话的连贯性。这是今天AI在体验上的一大痛点。

你回想一下，今天大多数的AI客户端，你每开一个新的对话，是不是就好像在跟一个陌生人对话。因为你们过去交流的，它都不知道，你又得重新聊一遍。

这么搞，效率很低，而且工具感很强，你不会觉得这是个有智能的生命。

往大了说，“全局记忆”不只覆盖所有的历史对话，还可以、也应该包括用户的各种资料，甚至包括更广的知识库。

一旦技术成熟，把AI打造成为一个全面的个人助理、一个全球知识共享工具是很有可能的。这个就是OpenAI的野心。

当然啦，这个愿景有点远。不过站在今天，我们还是可以先体验一下的——通过OpenMemory这个项目。

简单来说，OpenMemory的作用就是把聊天记录单独存储。任意一个客户端里聊的东西都可以存进去。然后通过MCP进行调用。任意一个客户端都可以调用任何记录。我给你们演示一下就明白了。

我已经安装OpenMemory，并且通过SSE的连接方式与客户端ChatWise连上了。可以看到，这个MCP一共有四个tools，分别是添加、查询、检索、删除。

我这边准备了一段话，让AI把这些关于Prompt House的内容保存。LLM接到请求后，通过MCP调用add_memories这个tool，成功把那一段话保存起来了。

这时，在同一个对话框，我提出问题：记忆中都有哪些内容？可以看到，LLM很顺利把刚才保存的那条记录调出来了。

接下来，我们打开一个新的对话框，看看AI是否还“记得”刚才的内容。问题很简单：Prompt House主要解决哪两个问题？通过list_memories和search_memories两个tools，LLM把刚才存进去的内容调出，并基于内容完成回答。

同一个客户端的不同对话框，LLM能够自由存储和调用记忆。那么，跨应用呢？我这边打开Cursor，同样的问题：Prompt House主要解决哪两个问题？Claude Sonnet 4也是使用search_memories这个tool，把记忆取回。

你看，无论是跨对话框还是跨客户端，OpenMemory MCP都能实现记忆的存储和调取。

为了实现这些功能，OpenMemory做了三点：

第一，调用大模型。

要把用户的对话存储起来，首先要做的就是“理解”——先理解语义，才能区分哪些是噪音，哪些是重要信息。

不仅如此，在存储的时候，还需要大模型去区分记忆当中的冲突，完成更新。在检索的时候，也需要大模型在语义层面进行检索，而不只是关键词检索。

默认情况下，OpenMemory用的是OpenAI的模型，需要我们输入OpenAI API Key。不过它也支持别家的模型，包括开源大模型。如果你对隐私安全非常非常重视的话，可以连接Ollama。

第二，本地化存储。

为了让用户放心，OpenMemory把所有信息都存在本地。它采用双数据库架构，一个负责存储记忆的向量嵌入，一个存储结构化元数据。

这么设计的好处，一是完全本地化，敏感信息不会上传到云端；二是数据可移植，可以轻松备份和迁移整个数据目录；三是扩展性高，可以切换不同的大模型提供商，或者用本地模型。

第三，MCP。

任何支持MCP协议的客户端都可以通过SSE连上OpenMemory。它的MCP提供四个工具：添加，检索，查看，删除。

有了这四个工具，不同客户端就可以共享同一个内存。上下文就可以在不同客户端之间无缝传递。

我非常看好“全局记忆”这个方向。虽然巨头在做，但是，创业者也有很大机会。

因为，既然是“全局”，那就不能一家独大，就必须开放。在现阶段，有哪家能做到？这不就给了创业者生存、发育的窗口吗？

而且，现在巨头的主要精力还是放在提升模型能力上。所以，几个月前我就在社群里分享了一个思路：

把知识库的存储和调用分开。存储就放在本地，用Cursor创建一个Milvus向量数据库。调用就通过Milvus MCP。当时看大家挺感兴趣的，我还特意出了一期社群专属视频，介绍怎么搭建。

站在用户的角度看，这套思路的好处是，模型的选择会更加自由。谁的模型牛逼，我就对接过去。

站在做产品的角度看，最终留住用户的，不是智能，而是数据。智能只是一个钩子，把用户吸引过来，完成数据的迁移。

而且，智能要发挥作用、要创造价值，一定离不开上下文。这个就是我之前在社群内说的：Context Matters。

回过头来看，过去几个月我分享的那些零散的思路，还有我最近的尝试，全都串起来了。

OK，不多说了。我要继续做产品去了。想了解AI，想成为超级个体，想找到志同道合的人，就来我们newtype社群。我所有的感悟和认知，都会在社群内分享。那咱们下期见！