一个似曾相识的场景#

你打开 Codex，开始一个新任务。你明明上周已经跟它讨论过数据库迁移策略，花了半小时解释为什么不用 Prisma 的 db push --force-reset，还让它记住了你团队的代码规范。

但今天，它什么都不记得了。

你换了个项目，之前的偏好设置全部归零。你切到 Claude Code 帮你调试一段前端代码，那边的 Codex 又是从头开始，像个失忆的新同事。

这种感觉，每个同时使用多个 AI 编程工具的开发者都不陌生。Codex 在 2026 年 4 月已经突破 300 万周活跃用户，相比 1 月增长了 5 倍，月环比增速高达 70%。它有 Web 版、桌面版（macOS 和 Windows）、ChatGPT iOS 内嵌版、CLI 命令行版、VS Code 扩展版，五个入口，一个账号，背后是同一个模型。

听起来很美好，对吧？但当你在这些入口之间切换时，记忆并不会无缝跟随。

记忆的三个层次#

在讨论解决方案之前，先搞清楚「记忆」到底意味着什么。大多数开发者说「我希望 Codex 记得我」，其实包含三层完全不同的诉求。

第一层：会话记忆。 在一次对话中，模型能不能记住三轮前说过的话？这个问题在 2023 年还很头疼，现在已经解决了。上下文窗口足够大，短期内的记忆不是问题。

第二层：项目记忆。 跨越多次会话，模型能不能记住这个代码库的技术栈、团队成员、上周做过的架构决策？Codex 在 4 月 16 日更新后加入了持久化记忆功能，但它是按项目隔离的。你在一个 Codex 项目里配置的偏好，换个项目就失效了。如果你的一半工作在 Claude Code 里完成，那 Codex 的项目记忆对你来说形同虚设。

第三层：操作者记忆。 跨越你使用的所有 AI 工具，模型能不能记住你是谁、你在做什么产品、你的客户关心什么、你踩过哪些坑？这是最高层次的记忆，也是没有任何模型提供商真心想帮你解决的问题。原因很简单，他们更希望你被锁在自己的生态里。

Codex 的内置记忆只解决了第二层的一部分。下面三种方案，分别针对第二层和第三层的完整需求。

方案一：用好 Codex 自带的记忆功能#

Codex 提供了两种内置记忆机制，对于完全在 Codex 内部工作的团队来说已经够用。

AGENTS.md 文件是第一种。在代码仓库根目录创建一个 AGENTS.md，Codex 每次执行任务时都会自动读取它。这和 Anthropic 的 CLAUDE.md 模式类似，是告诉 AI「我们团队怎么写代码」的标准方式。

一个典型的 AGENTS.md 长这样：

# AGENTS.md

## 技术栈
Next.js 15, TypeScript strict, Prisma, Postgres (端口 5433)

## 编码规范
- 优先用 Server Actions，少用 API routes
- 样式用 Tailwind，不用 CSS modules
- 单元测试用 Vitest，端到端测试用 Playwright

## 禁止事项
- 任何分支上都不允许 `prisma db push --force-reset`
- 跳过 read-before-edit hook
- 未跑 `pnpm typecheck` 就推代码到 main

Memories 面板是第二种。在 Codex 设置里，你可以配置跨项目的个人偏好，比如「回复要简洁，先给代码再解释」「引用代码时必须附上行号」。

这套方案的限制很明确：它只在 Codex 内部生效。你用 Claude Code 的时候，这些记忆完全不可见。如果你的工具链只用 Codex，这方案就足够了。如果你是多工具用户，继续往下看。

方案二：MCP 记忆服务器，30 秒打通所有工具#

这是最值得推荐的方案，也是原文作者实际在用的方案。

Codex 从 3 月底的更新开始原生支持 MCP（Model Context Protocol）服务器。你只需要在 ~/.codex/config.toml 里加几行配置：

[mcp_servers.memory]
url = "https://memory.example.com/mcp"
type = "http"

重启 Codex，运行任何涉及记忆的工具，浏览器会弹出一个 OAuth 登录页面。输入邮箱，点击邮件里的链接，授权完成。从此，Codex 就接入了和 Claude Code、Cursor、Claude Desktop 等工具共享的同一套记忆存储。

从「打开配置文件」到「Codex 能查询记忆」，整个过程大约 30 秒。

接入之后，你可以这样跟 Codex 对话：

  • 「搜索我过去关于认证方案的决策记录」
  • 「上个月我对限流器做了什么决定？」
  • 「记住我偏好小批量提交」
  • 「4 月份我对接了哪些客户？」

模型会从共享记忆后端读取和写入事实。如果你周二在 Claude Code 里改了限流器的设计，周三 Codex 就能看到这个新决策。

已知问题：桌面版内存泄漏#

需要提醒的是，Codex 桌面版目前存在一个已知 bug：每个聊天窗口都会生成完整的 MCP 进程栈。如果你同时开 10 个以上的 Codex 标签页，内存会线性增长，最终拖垮系统。

解决方案： 使用 HTTP 传输协议的 MCP 服务器（如上面示例），而不是 stdio 类型的。HTTP 服务器在网络上只运行一次，而不是每个标签页一个实例。这个问题在 GitHub Issues 11324、14548、18333、20980 上都有跟踪。

方案三：混合架构，大多数团队的最优解#

如果你的团队既用 Codex 处理有合规要求的客户代码，又用它做内部项目和个人实验，那你需要的是混合方案。

核心思路是让三种记忆机制各司其职：

记忆类型载体作用范围
个人偏好Codex Memories 面板所有项目
项目规范AGENTS.md 文件单个代码库
操作者记忆MCP 记忆服务器所有 AI 工具

在一个团队的实际配置中，MCP 记忆服务器存储的内容包括：之前会话的经验教训、架构决策记录、客户画像、部署模式，以及「永远不要再犯」的警告。AGENTS.md 存储项目专属的技术栈和规则。Memories 面板存储个人沟通偏好。

当 Codex 启动一个任务时，它能同时访问这三层信息。三者之间不冲突，覆盖不同维度。

诚实地说说局限性#

MCP 记忆方案并非银弹，有几个现实问题需要提前了解。

后端质量参差不齐。 市面上的记忆后端有 Mem0、Letta、Zep、MemNexus 等多个选择，每个对「存什么、怎么检索、怎么收费」都有不同的设计哲学。建议至少试用两个再做决定。

检索质量不是免费的。 一个糟糕的记忆后端会把陈旧或无关的上下文塞给 Codex，反而降低输出质量。选择支持语义搜索（向量检索）、全文检索和知识图谱的后端，单模态检索太脆弱。

OpenAI 的内置记忆在快速迭代。 按照目前的节奏，到 2026 年底 Codex 的内置记忆功能大概率会追上 MCP 后端的能力。如果你在做长期技术选型，关键问题不是「现在哪个更强」，而是「当格局变化时，哪个方案能带走」。MCP 记忆是跨提供商可移植的，OpenAI 的内置记忆不是。

对开发者的实际意义#

300 万 Codex 周活用户大致分成两个群体。

第一个群体对内置记忆很满意，从不考虑 MCP。他们只用 Codex，AGENTS.md 加 Memories 面板就覆盖了所有需求。

第二个群体的 AI 工作流横跨多个工具。他们用 Claude 写某些代码，用 Codex 做另一些，用 Cursor 编辑，用 ChatGPT 做研究。对这个群体来说，MCP 记忆是让多工具工作流从碎片化变得连贯的关键拼图。

如果你属于第一类，现在的方案就够用了。

如果你属于第二类，花 30 秒配置 MCP 记忆服务器，是 2026 年剩余时间里回报率最高的一个操作。记忆是上下文存活的地方。一旦接通，你将来添加的每一个新 AI 工具，都能从已有的上下文开始工作，而不是从零开始。

选择记忆后端的关键考量#

在决定用哪个 MCP 记忆后端之前，有一个容易被忽略的判断标准：可移植性。

记忆层的锁定不在协议层面，MCP 是开放标准，任何符合规范的服务器都能接入。真正的锁定在模型层面。你选择的 AI 工具决定了记忆的写入格式和检索方式。所以，与其纠结「哪个后端功能最强」，不如问「当我换工具时，这些记忆能不能带走」。

这和选择数据库的逻辑类似：功能可以迭代，数据迁移成本才是真正的赌注。

参考来源：StudioMeyer, “Codex Has No Real Memory: Three Ways to Fix It, One in 30 Seconds”, dev.to, 2026-05-20