你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

一个关于 AI 记忆可移植性的思考，以及一个极简开放标准的提案。

---

从一个烦人的场景说起

你花了三个月教 ChatGPT 了解你：

• 你是前端工程师，用 React 和 TypeScript
• 你喜欢简洁直接的回复，讨厌废话
• 你写代码注释用中文，变量名用英文
• 你习惯先出方案再动手

ChatGPT 确实越来越懂你了。直到有一天，你决定试试 Claude 。

打开 Claude 的对话框，一片空白。它不知道你是谁，不知道你喜欢什么，也不知道你的任何习惯。你不得不再教一遍。

换到 Gemini ？再来一遍。用本地模型？再来一遍。

你的 AI 记忆，今天基本是平台私产，而不是你的资产。

---

这不是功能缺失，而是结构性问题

你可能会觉得，这不就是各家 AI 产品迟早都会补上的能力吗？

不完全是。

问题不在于厂商有没有能力做记忆，而在于它们没有动力把记忆做成可携带的。

• OpenAI 没有动力让 ChatGPT 的记忆被 Claude 直接利用
• Google 没有动力让 Gemini 的用户画像迁移到别处
• 每个平台都天然倾向于把“越来越懂你”变成自己的护城河

所以，真正缺的不是“某一家的记忆功能”，而是一个用户侧、平台外的可移植标准。

---

MIP 的想法很简单

我做了一个很小的提案，叫 MIP ，Memory Interoperability Protocol 。

它的核心可以用一句话说完：

在你的电脑上维护一个 ~/.mip/memory.json，任何 AI 工具都可以读取它来了解你。

没有守护进程，没有数据库，没有远程服务。

就一个文件。

例如：

{
  "version": "0.1.0",
  "identity": {
    "name": "张三",
    "language": "zh-CN",
    "role": "前端工程师",
    "tech_stack": ["React", "TypeScript", "Next.js"]
  },
  "preferences": {
    "response_style": "concise",
    "formality": "casual",
    "code_comments_language": "zh-CN",
    "variable_names_language": "en"
  },
  "custom": {
    "编辑器": "VS Code",
    "关注领域": ["AI 应用开发", "Web3"]
  }
}

任何 AI 产品要接入它，读取成本只有几行代码：

import json, pathlib
path = pathlib.Path.home() / ".mip" / "memory.json"
memory = json.loads(path.read_text()) if path.exists() else {}

这不是“让 AI 拥有完整人格档案”的终局方案。

MIP v0.1 只想先解决一个很具体的问题：把显式的用户偏好，从平台私有数据，变成用户自己持有的标准化数据。

---

它和 .cursorrules、CLAUDE.md 有什么不同？

这是最常见的问题。

确实，今天已经有很多本地规则文件：

• Cursor 有 .cursorrules
• Claude Code 有 CLAUDE.md
• 其他工具也有各自的全局规则、偏好文件

这些文件当然有价值，而且本质上都在帮助 AI 了解你。

但它们有两个问题：

第一，它们是工具私有约定，不是跨工具约定。

第二，它们更像“用户写给某个工具的操作手册”，而不是一个所有工具都能稳定读取的通用用户记忆格式。

MIP 在 v0.1 阶段做的事其实很克制：

• 统一路径：~/.mip/memory.json
• 统一格式：JSON Schema
• 统一范围：身份、偏好、自定义字段

所以如果一定要类比，我更愿意把它叫做：

.editorconfig for AI memory

没有什么魔法，只是定义一个所有工具都可以认同的最小公约数。

---

为什么不是直接用 Mem0 、MemGPT 、Letta ？

因为它们和 MIP 解决的是不同层的问题。

• Mem0 、Letta 、各种长期记忆框架，是实现
• MIP 想做的是协议

它们可以完全兼容，甚至应该兼容。

如果未来某个记忆系统愿意把用户偏好导出成 MIP ，或者把 MIP 作为导入导出格式，那恰恰说明这个协议是有价值的。

协议层的意义，不在于替代实现，而在于让不同实现之间开始有可交换的数据格式。

HTTP 不等于 Nginx ，.editorconfig 也不等于 VS Code 。

MIP 想做的是那个更靠底层的“共同语言”。

---

MIP 和 MCP 的关系

如果你知道 MCP ，那可以用一句话理解它们的关系：

• MCP 解决的是：AI 能调用什么工具
• MIP 解决的是：AI 了解谁

一个偏工具接入，一个偏用户记忆。

它们不是竞争关系，而是互补关系。

MIP 完全可以脱离 MCP 独立存在，因为读本地文件本身就够简单。

但对于支持 MCP 的客户端，MIP 也可以通过 MCP server 暴露出来，这样工具接入会更方便。我在仓库里已经放了一个概念验证版本。

---

这是不是伪需求？

如果只看 2026 年，当下它确实不是最刚性的需求。

很多时候，你自己写一段系统提示词，也能解决 80% 的问题。

但我认为这是一个典型的“现在弱需求，未来强需求”的方向。

因为 AI 记住你的，不会永远只是：

• 你喜欢简洁回复
• 你用 TypeScript
• 你写注释用中文

再往后，AI 会逐渐理解：

• 你最近在忙什么项目
• 你做决策的方式是什么
• 你在哪些领域需要更多解释
• 你过去几个月的工作脉络是什么

到那个阶段，所谓“换一个 AI 平台”，丢失的不再是一些偏好，而是一个系统对你的长期理解。

那时候，“记忆可携带”更像一种基础数据权利，而不是可有可无的小功能。

好的标准，往往是在需求全面爆发之前建立的。

---

先别把愿景讲得太大

这也是我刻意想收住的一点。

MIP v0.1 不是在宣称：

• 已经解决了 AI 长期记忆
• 已经解决了自动画像
• 已经解决了权限、安全、同步

恰恰相反，v0.1 是有意做小的。

它只处理显式的、用户愿意手写的那部分记忆：

• 我是谁
• 我偏好什么
• 我希望 AI 怎么和我协作

先把最容易共识、最容易落地、最容易被工具采纳的那一层定下来。

如果连这层都没有，后面的自动写入、权限控制、跨设备同步都无从谈起。

---

真正可能先采用它的是谁？

MIP 不是在等大厂突然良心发现。

它最可能先被下面几类东西采用：

• IDE 里的 AI Agent
• 本地代码助手
• 开源 AI 客户端
• MCP 客户端
• 本地模型工作流

因为这些工具本来就运行在你的机器上，读取本地文件的成本极低，也更有动力支持开放标准。

所以 MIP 的现实路径不是“先说服 OpenAI 和 Google”。

而是：

先让开源工具和本地工具支持，先形成一个用户侧事实标准。

---

安全问题不能后补

把用户画像存在本地，当然会有安全问题。

所以我对 MIP 的态度是分层推进，而不是一步到位。

v0.1 只建议存储低敏感、显式、用户手写的结构化偏好。它更接近 .gitconfig 或 .editorconfig，而不是心理档案。

更深层的画像、自动写入、加密、权限控制，应该等后续版本在模型和机制上都更成熟之后再进入标准。

如果没有安全设计，MIP 不应该贸然走向“自动累积人格画像”。

---

我为什么还想把它提出来？

因为没有标准的领域，用户连选择都没有。

MIP 现在当然还很早。它更像一个种子，而不是已经成为行业标准的东西。

但我觉得这个问题值得先被提出来：

如果 AI 越来越懂你，那么“它对你的记忆”到底应该属于平台，还是属于你？

我的答案是：至少应该存在一种属于用户自己的开放格式。

MIP 不一定是最终答案。

但如果没有人先把这个问题做成一个可讨论、可实现、可集成的最小提案，那么答案永远不会出现。

---

现在你可以做什么

1. 给自己建一个 ~/.mip/memory.json
2. 如果你在做 AI 工具，试着加一个 MIP read support
3. 如果你觉得这个方向值得讨论，给仓库一个 star 或提个 issue
4. 如果你觉得它是伪需求，欢迎直接挑战

仓库地址：

https://github.com/UnCooe/MIP

---

MCP 让 AI 的“手”更标准化，MIP 想讨论的是 AI 的“脑”里那部分用户记忆，是否也该有一个用户侧、开放的最小标准。

这件事未必立刻爆发，但我认为值得现在就开始做。