用 MCP 让 Claude Code、Codex、Cursor 共享同一份记忆

换一个工具，就要重新自我介绍一遍

同时在用 Claude Code、Codex、Cursor 的人大多遇到过同一个别扭：每个工具、每个项目、每个新会话都是从零开始。你得反复说明"用中文回复""先读代码再下结论""这个项目不要擅自扩大改动范围"。规则少还能忍，规则一多，光是重述就要花掉好几分钟，而且每次说的还不完全一样。

于是有人做了个叫 Engram 的小工具：把身份、偏好、经验、决策存成本地 JSON，通过 MCP 暴露给支持 MCP 的 AI 工具读写，这样 Claude Code 里教过的东西，换到 Cursor 还在。围绕这个思路的讨论里，最有价值的部分不是工具本身，而是大家把"记忆到底该放在哪"这件事拆开了。

先把需求拆成两层

很多争论其实源于把两件不同的事混在一起：

• 静态配置：这个项目怎么构建、代码风格是什么、有哪些禁区。变化慢，适合写进文件。
• 动态积累：踩过的坑、做过的取舍、确认过的边界。变化快，需要能写入、能检索、能过期。

再叠一个维度：作用域。是 per-repo（每个仓库一份），还是 per-person（跟着你这个人走，跨项目跨工具）。

结论很清楚：静态配置用文件，动态经验用记忆层，两者不冲突。把所有东西都塞进 AGENTS.md，文件会越来越长，而每次会话都会把整份内容吃进上下文。

四种常见做法，分别适合谁

只保留一个主力工具

让 Claude Code 当主驾，Codex 只被调用去做 review 或翻译。这种情况下养好一份配置就够了，没必要引入额外服务。单工具单项目，AGENTS.md 加一个状态文件基本够用。

把 AGENTS.md 全局化

放到用户目录下，再在主配置文件里引用一下，能解决一部分跨项目问题。适用于规则不多、以静态偏好为主的场景。缺点是要逐个确认每个工具是否读取、读取顺序如何，换工具时容易漏。

用 Skill 加脚本自己维护

Skill 里可以跑脚本，脚本当然能写本地文件，理论上能做持久化。但格式定义、检索逻辑、去重、并发写入、过期清理都得自己写，投入不小。适合记忆结构非常个人化、不想引入第三方依赖的人。

本地记忆 + MCP 中间层

一份 JSON 存在本机，MCP Server 提供"写入经验""记录决策""检索知识"这类工具，各个客户端接同一个 Server。优点是跨工具、跨项目共享，写入和检索解耦，可以按需加载而不是全量注入。代价是多一个进程要维护，初期要花时间把记忆喂起来。

落地步骤：把记忆层跑起来

第 1 步：先决定记什么。 建议只记三类，其余不记：

1. 身份与偏好（语言、回复风格、审查习惯）
2. 项目级决策（为什么选这个方案、哪些边界不能碰）
3. 经验教训（踩过的坑、验证过的结论）

临时任务进度不要往里塞，那是任务记忆该管的事。

第 2 步：安装并确认数据目录。 这类工具通常通过包管理器安装，数据落在用户目录下的一个固定位置。装完先确认目录在哪、是否明文可读、能否直接用编辑器打开——能随时手改和 git 备份，是选本地存储的最大理由。

第 3 步：注册 MCP Server。 Claude Code、Cursor、Codex 都支持 stdio 类型的 MCP 服务，写法大同小异。下面是结构示意，具体命令和参数以项目 README 与各客户端文档为准：

{
  "mcpServers": {
    "memory": {
      "command": "<启动命令>",
      "args": ["<参数>"]
    }
  }
}

配完在客户端里确认工具列表能看到读写接口，再让 AI 实际调用一次，确认读得到内容。

第 4 步：冷启动。 空库没有价值。花十分钟手写前 20 条：三条语言与风格偏好、五条常用工作习惯、若干条跨项目的技术判断。这一步做完，体验差异立刻能感觉到。

第 5 步：建立写入习惯。 记忆不会自己长大。约定好什么时候写：一次架构取舍之后、一次被纠正的错误之后、一次范围争议之后。让 AI 主动调用写入接口，比指望它自己去编辑某个 Markdown 文件可靠得多。

第 6 步：定期体检。 每月看一遍：重复项合并、过期的删掉或标记、和当前项目实际做法冲突的修正。记忆库一旦腐烂，比没有更糟。

上线前检查清单

• 数据目录位置清楚，已加入备份或版本控制
• 各客户端都注册了同一个 Server，工具列表可见
• 读取是按需检索，不是每次会话全量注入
• 至少三条偏好、五条经验已完成冷启动
• 写入有确认环节，AI 不会直接把猜测写成事实
• 明确知道哪些内容不会被采集、是否开启遥测

几个必须提前想清楚的问题

上下文预算。 记忆越多，检索越重要。全量塞进提示词会挤占真正的工作空间，所以优先选支持关键词或语义检索、能只取回相关几条的实现。中文场景下还要留意分词：整句被当成一个 token，检索基本失效。

要不要审核。 AI 自动总结的"经验"经常似是而非。比较稳妥的设计是先进待审区，你确认后才转成长期记忆。这类机制会拖慢一点节奏，但能避免错误的偏好被反复强化。

过期与冲突。 同一条规则在新项目里可能恰好相反。记录时带上来源和日期，冲突时以项目内配置优先，全局记忆兜底。

隐私与部署。 本地明文 JSON 的好处是可控，坏处是别把密钥、内网地址、客户信息写进去。如果开启远程访问，务必确认鉴权方式和日志范围。遥测类功能建议默认关闭，需要时再显式打开。

常驻问题。 MCP Server 通常要跟着客户端跑。如果希望多台设备读到同一份记忆、又不被本地休眠打断，可以让它跑在一台长期在线的机器上——例如放在机房的远程 Mac，通过远程连接使用，重启和网络切换都不影响服务常驻。只是要注意远程访问本身的权限边界。

小结

如果你只用一款工具写代码，AGENTS.md 加上一个进度文件就够了，不必增加依赖。真正需要记忆层的是两种人：一是同时在用多款 AI 工具，苦于每次重述背景；二是积累了大量跨项目的判断和教训，希望按需取用而不是复制粘贴。

对后者，比较稳的路径是：先手动把最痛的三五条偏好写进全局配置，验证各工具是否真的读到；再引入 MCP 记忆层，从小样本开始，跑两周看检索命中率；最后才考虑开启语义检索、远程部署这类进阶能力。工具在快速迭代，安装方式和功能开关请以官方最新说明为准。