我在做一个让 AI 真正"记住你"的开源项目——不是 mem0，思路完全不同

(git链接后续更新至评论区)

我想聊一个我最近在解决的问题，顺便预告一个我正在开发的开源项目。

先说问题。

你有没有遇到过这种情况：

跟 Claude 聊了两个小时，帮你梳理清楚了一个复杂系统的架构决策，确定了技术栈，约好了一些不成文的"规范"——比如"这个项目里 async 优先，不用线程池"，"ORM 只用 SQLAlchemy，不碰 Django ORM"。

然后第二天开一个新对话。

AI 完全不记得。你要重新解释一遍背景，重新约定一遍规范，重新建立一遍上下文。这个"重新"，有时候比干活本身还费时间。

如果用instruction或是project，那对全局环境又会有污染。

现有的解决方案是什么？持久化记忆。代表产品是 mem0、Zep、Letta。思路都差不多：把对话内容喂给一个记忆系统，系统自动提炼、存储、下次召回。

这个方向没错，但我用了一段时间之后，发现有几个地方始终让我不舒服：

第一，记忆是系统的，不是我的。我的技术偏好、我的项目决策、我的工作习惯，被存在一个服务里。我换一个 AI 工具，换一个平台，这些记忆没法带走。从 Claude 迁移到 GPT？对不起，重来。

第二，你不知道它记住了什么。大多数记忆系统是黑盒运作的。它悄悄在后台提炼，你不知道它提炼了什么，你也不知道它下次会召回什么。有时候它会把你一句无心的吐槽当成事实存下来——"今天真烦，不想用 TypeScript"——然后在未来某个关键时刻被召回，悄悄影响了 AI 给你的建议。

第三，技能和记忆是两回事，但被混在一起处理了。"用户喜欢 Python"是记忆。"处理 N+1 查询的标准套路"是技能——是一段可复用的、结构化的操作流程。这两样东西的生命周期、使用方式、迁移方式都不同，不应该被同一套逻辑管理。

这三个不舒服，推着我去想：有没有一种方式，让 AI 记忆这件事，回到用户手里？

于是我开始做 CapsuleMemory。

我不打算在这篇文章里讲太多技术细节——项目还没发布，发布的时候会有完整文档和源码。但我想把核心的设计思路说清楚，因为这是我觉得和现有方案最不一样的地方。

核心概念只有一个词：胶囊（Capsule）。

每一次有意义的 AI 对话，都可以被封存成一个胶囊。胶囊是你的，存在你本地，用你的方式加密，随时可以导出、迁移、导入到任何 AI 平台。

胶囊里存的不只是"记忆事实"，还包括这次对话中沉淀下来的可复用技能——那些你和 AI 一起摸索出来的、值得下次直接复用的操作方法。记忆和技能是分开管理的，但可以被打包在同一个胶囊里一起迁移。

更关键的是：封存这件事是你主动触发的，不是系统悄悄做的。 你决定这次对话值不值得留下来，你决定它以什么形式留下来。AI 不会在你不知情的情况下记住任何东西。

迁移也是真正的迁移。导出的格式有三种：完整格式给下一个支持 SDK 的平台用；通用格式给任何平台直接读取；纯文本格式直接粘贴到 ChatGPT 的系统提示框就能用——不需要安装任何东西，不需要对方平台支持任何东西。

这就是我说的"用户主权"。你的记忆跟着你走，而不是跟着平台走。

和 mem0 的差异，我来直说。

mem0 是一个优秀的产品，对我的帮助也是巨大的。但如果你的核心诉求是"我想要一个随时可迁移、我能完全掌控的本地记忆系统"，mem0 的设计目标和你不一样。

mem0 的设计是以持续持久化为核心的：它希望你一直用它，记忆一直在它那里累积，越用越聪明。这对很多场景很好，但本质上，你是在往一个外部系统里存你的上下文，而不是在管理你自己的知识资产。

CapsuleMemory 的设计是以 Session 隔离为默认的：每次对话默认是独立的，只有你觉得值得留存的内容，才会被主动封存。这意味着更干净的上下文，更可控的记忆边界，和真正属于你的数据。

一句话总结差异：mem0 让 AI 更聪明，CapsuleMemory 让你的知识更可迁移。 两者不是竞争关系，但解决的是不同场景下的不同痛点。

现在在哪个阶段？

核心功能已经在开发中，预计近期发布第一个可用版本。计划支持：

• Python SDK（本地零依赖运行）
• MCP Server（Claude Code 直接调用）
• REST API（任何语言一个 HTTP 请求接入）
• Web Widget（一行脚本嵌入任意产品）

发布时会同步上 PyPI 和 npm，开源协议 Apache 2.0。

最后。

如果你也觉得"AI 记忆应该是用户自己的东西"，欢迎关注这个项目。

发布前我会在评论区更新进度。如果你有具体的使用场景或者痛点想聊，我很乐意听，这也是我持续进步的动力。