MemoryLake
返回全部文章
Tutorial2026 年 8 月 11 日·11 分钟阅读

如何将您的 Claude 记忆迁移到 Codex 且不丢失上下文 (2026)

您已经与 Claude 合作了几个月。它了解您的技术栈、您的评审标准、坚持使用英式拼写的客户,以及 3 月份出错的那次迁移。现在,您正在将开发工作转移到 Codex,却发现了一件奇怪的事:Codex 提供了一个导入器,只需一条命令就能吞下整个 Claude Code 配置——却拒绝了您真正想要迁移的东西。

直接的答案是:Codex 的 `/import` 适用于 Claude Code,而不适用于 Claude 应用程序。其官方文档直接指出——“标准的 Claude 聊天数据无法导入。”因此,Claude 建立的关于您的对话记忆没有迁移路径,而且 Claude 也没有针对它的结构化导出功能。您能做的是手动将其导出一次,以一种比原来更好的形式,并将其放在这两个工具都能读取的地方。

本文将介绍真正可以传输的内容、如何正确进行手动操作,以及如何在下次更换工具时避免重复这一过程。

真正可以传输的内容

Claude Code 配置可以整体传输。 如果您的知识存在于仓库中——CLAUDE.md、MCP 服务器、命令、子智能体、技能、设置——Codex 为其提供了一个真正的导入器。其文档描述了如何结转指令文件、config.tomlsettings.json、技能和插件、MCP 服务器配置、项目文件夹和记忆、钩子和斜杠命令、子智能体以及过去 30 天的聊天记录。这不是一种权宜之计,而是一条受支持的路径,具体在将 Claude Code 配置迁移到 Codex中单独介绍。

Claude 应用程序的记忆无法传输。 这种不对称性值得注意。同一个能够导入竞争对手 CLI 完整配置的导入器,却对来自同一供应商的消费级产品划清了界限:“标准的 Claude 聊天数据无法导入。”其文档还指出,ChatGPT 数据也无法导入。该导入器适用于开发人员配置,而不适用于聊天历史记录,无论尝试多少次都无法改变这一点。

关于您的 Claude 记忆,没有任何下载按钮。 在 Claude 应用程序中,您可以打开“设置”并按类别逐项查看和编辑它记住的内容——这是一个非常好的删除内容的控制界面。但您无法将其导出为文件。实际的替代方案是让 Claude 在对话中逐字写出它对您的记忆,然后您自己复制输出。还要注意 Claude 自身的“记忆导入”功能的方向:它是将记忆从其他助手导入 Claude 中,并且被标记为实验性的。目前还没有向外导出的等效功能。

Codex 在另一端等待的内容是真实的,但默认是关闭的。 Codex 记忆是存在的:用其文档的话来说,它们在 ~/.codex/memories/ 下存储“来自先前聊天的摘要、持久条目、最近的输入和支持证据”。它们默认也是禁用的——您可以在“个性化”下的“设置”中启用它们,或者在配置中设置 [features] memories = true。对于迁移来说,有三个属性很重要:它们是由 Codex 生成的,而不是由您编写的(文档称之为生成状态,旨在用于检查而不是手动编辑),它们是全局的而不是针对每个项目的,并且它们存在于该机器上。Codex 客户端保留自己的本地记忆存储;网页版 ChatGPT 则保留一个独立的存储。

两端都不存在的是持久性的东西。 Claude 的记忆是您对话的综合。Codex 的记忆是您与 Codex 聊天的综合。两者都不是您编写的记录,这就是为什么基于将一种综合复制到另一种综合的迁移方式是错误的——也是为什么下面的手动操作值得作为一次升级而不是简单的传输来进行。

手动迁移

步骤 1:导出您的 Claude 记忆并区分这两种类型

打开 Claude 的设置,按类别阅读它存储的关于您的内容。然后,在对话中,让它逐字写出它对您的记忆,包括它保留的任何与工作相关的内容。将该输出复制到一个临时文件中。

现在进行决定这次迁移是否有价值的部分。浏览列表,将每个项目分类到以下两个堆之一:

偏好。 语气、格式、语言、您需要多少解释、您喜欢哪个框架。这些内容很短,重新陈述的成本很低,而且基本上是可丢弃的——在与任何助手正常使用一周后,其中大部分都会重新生成。

约束和上下文。 因为合同要求使用英式拼写的客户。因为迁移顺序导致两次停机而绝不能共享数据库的服务。事出有因的命名规范。在这些项目中,Claude 存储的版本可能只是真实情况的压缩影子,因为记忆系统通常会保留结论而丢弃原因。

对于第二堆中的每个项目,把原因写回去。如果 Claude 存储了“偏好服务拥有的数据库”,您就写上“服务拥有自己的写入路径——共享模式迁移在 3 月份导致了两次停机,并且模式所有者不能限制每次部署”。这句话才是真正的资产。这也是任何导出器都无法为您生成的东西,因为它最初根本就没有被存储。

注意这种分类为您节省了什么:您不是在迁移一百个记忆条目。您是在迁移带有原因的八到十个条目,并故意放弃其余的条目。

步骤 2:将每一堆放在 Codex 真正会读取的地方

Codex 会读取 AGENTS.md 文件,其解析顺序已有文档记录:~/.codex/AGENTS.md(或 $CODEX_HOME),然后是仓库根目录,接着是中间目录,最后是您的工作目录——自上而下组装,最近的文件优先。它不读取 CLAUDE.md,也不读取 ChatGPT 的自定义指令。

这个层级结构就是您的归档系统:

  • 适用于所有地方的个人偏好放入 ~/.codex/AGENTS.md。保持简短。它会在您接触的每个项目中加载。
  • 项目约束放入该仓库根目录的 AGENTS.md 中并提交,这样您的团队成员也能获取它们。
  • 仅适用于部分代码库的约束放入该子目录内的 AGENTS.md 中,这样作用域就可以通过位置来表达,而不是寄希望于模型注意到限定符。
  • 不属于共享仓库的特定于客户的规则保留在您的个人文件中,或者保留在您保存在仓库之外并在相关时粘贴的文档中。

然后单独决定 Codex 记忆。启用它们是合理的——它们会积累与 Claude 建立的相同类型的偏好层,而无需您进行维护。只需清楚地了解您得到的是什么:生成状态、全局而非针对每个项目、在单台机器上、在短期会话中会被跳过,以及在您的速率限制余量不足时会暂停。这是一个便利层,而不是存放您 3 月份停机事件的地方。

在临时文件打开时,还有一件事值得做:其中任何读起来像是关于系统的客观事实,而不是关于您的偏好的内容,可能都应该作为文档放在仓库中,而不是放在助手的记忆中。版本控制中的决策记录是可评审的。而记忆条目则不然。

更好的方法:统一的记忆层,适用于任何助手

进行一次手动操作,您就会注意到您刚刚做了什么:您将供应商对您对话的综合转变成了附带原因的书面知识。这是一次升级。问题在于它现在存在于哪里——一半在只有 Codex 读取的 AGENTS.md 文件中,一半在临时文件中,而您仍将用于写作和思考的 Claude 应用程序却完全看不到它。

另一种选择是将持久性材料保存在两端都能读取的一个存储库中,并让每个工具的内置记忆充当其擅长充当的可丢弃便利层。

MemoryLake 就是为此设计的记忆层——将您的约束、决策和源文档集中在一个地方,可直接从支持 MCP 的工具(如 Claude 和 Codex)中读取,也可通过 API 从 ChatGPT 中读取。迁移工具不再意味着迁移知识。

步骤 1:创建 API 密钥

生成密钥并在大约 30 秒内发出您的第一次请求。将其保存在您的环境变量或机密管理器中,而不是粘贴到聊天窗口中。

创建 MemoryLake API 密钥
创建 MemoryLake API 密钥

步骤 2:上传您的第一批记忆

放入您刚刚写出的约束背后的文档、图像和文件:导致数据库规则的事件报告、客户的样式要求、架构决策记录、规范。上传源文件,而不是您对它们的摘要——您要迁移走的整个失败系统,正是那个保留了摘要却丢弃了原因的系统。

上传您的第一批记忆到 MemoryLake
上传您的第一批记忆到 MemoryLake

步骤 3:连接您的 AI 和智能体

通过 MCP 或 API 让 Claude、Codex、OpenClaw 和其他 AI 智能体访问记忆。Codex 和 Claude 都支持 MCP,因此它们可以直接读取相同的存储。对于 ChatGPT,通过 API 检索您需要的内容,并将其注入到提示词、自定义 GPT 的指令或调用模型的日常工作流中。

通过 MCP 连接您的 AI 和智能体
通过 MCP 连接您的 AI 和智能体

这在实践中改变了什么

第一个区别是,下一次更换工具只需要花一个下午进行设置,而不是花一个下午进行“考古”。当知识已经存在于某些清晰易读的地方时,编写 AGENTS.md 文件的成本很低;而当您需要从释义中重建原因时,其成本就会很高。

第二个区别是,Claude 和 Codex 不再对您的项目产生不同的认知。目前,您用于设计的助手和编写代码的 CLI 是分别从不同的对话中学习的,并且会产生偏差。读取相同的约束可以防止助手在没有项目上下文的情况下介入成为您需要针对每个工具重复解决的问题。

第三个区别是原因得以保留。这就是让记忆迁移感觉有损失的特定失败原因:被压缩为偏好的架构决策是可覆盖的,并且会被覆盖。而附带停机历史记录的存储文档则不会。

并且它与每个工具的原生功能相结合。Codex 记忆继续在本地学习您的习惯。Claude 继续记住您喜欢被如何对待。两者都不必成为记录系统,而这正是它们最不擅长的工作。

在助手之间迁移记忆的最佳实践

迁移原因,而非条目

人们很容易因为这 100 个记忆条目的存在而想要全部迁移它们。大多数都是可重新生成的偏好。有价值的少数是那些带有“因为”的条目——而这些条目在存储版本中往往缺失了“因为”。重写这些条目;放弃其余的。

保持始终加载的文件简短

~/.codex/AGENTS.md 会在您机器上的每个项目中加载,而根目录的 AGENTS.md 会在整个仓库中加载。冗长的文件会分散注意力,除了降低遵守度之外,不会减慢任何速度。将硬性约束放在那里,把其他所有内容留给检索或子目录中的作用域文件。

用位置表达作用域,而不是用形容词

Codex 按目录解析指令。仅适用于计费服务的规则应该放在 billing/AGENTS.md 中,而不是放在根文件中并冠以“仅用于计费”的前缀。位置是强制执行的;而限定符只是一种期望。

谨慎决定生成记忆

Codex 记忆默认关闭并非偶然,启用它们仍然是合理的。不合理的是将它们视为备份:它们是机器本地的、全局的而非针对每个项目的,并且是生成的。审查积累的内容,不要让任何您不愿失去的东西仅存在于那里。

在停止付费前进行导出

只要您还能访问 Claude,Claude 的记忆就是可见的。如果计划取消该订阅,手动复制出来的那一个小时是这次迁移中唯一不可逆的步骤。其他所有事情以后都可以重新做;但这一步不行。

结论

将您的 Claude 记忆迁移到 Codex 是一项手动工作,其原因已有文档记录,并非什么秘密:Codex 的导入器适用于 Claude Code,并且“标准的 Claude 聊天数据无法导入”。就 Claude 而言,它不提供结构化导出——只提供一个可以阅读其保留内容的设置页面,以及一个可以要求它写出这些内容的对话。

好消息是,如果您操作得当,手动迁移就是一次升级。将偏好与约束分开,将原因写回每个约束中,将它们归档到 Codex 真正读取的地方——按目录划分作用域的 AGENTS.md 层级结构——并启用 Codex 记忆作为便利层而不是记录。然后将持久的一半放在两个助手都能读取的一个存储库中,这样下次您更换工具时,唯一需要迁移的就是工具本身。

常见问题

Codex 可以自动导入我的 Claude 记忆吗?

不能。/import 是为 Claude Code 配置构建的——指令文件、MCP 服务器、技能、子智能体、命令、最近的聊天——其文档指出标准的 Claude 聊天数据无法导入。对于消费级应用程序的记忆,双向都没有自动化的路径。

我该如何查看 Claude 记住的关于我的所有内容?

打开 Claude 的设置并查看记忆控制,其中的条目按类别列出,可以单独编辑或删除。要获得可复制的版本,请在对话中让 Claude 逐字写出它对您的记忆,然后复制输出。没有文件下载功能。

Codex 到底有没有记忆功能?

有的,而且默认是关闭的。在“个性化”下的“设置”中启用它,或者使用 [features] memories = true。它在 ~/.codex/memories/ 中存储来自先前聊天的摘要、持久条目、最近的输入和支持证据。它是生成状态,而不是您创作的内容,它是全局的而非针对每个项目的,并且保留在该机器上——值得拥有,但不值得作为您的记录来依赖。

我应该把我的 Claude 记忆放入 AGENTS.md 吗?

约束可以放——连同它们的原因,归档在层级结构的正确级别。偏好则大多不放。AGENTS.md 在每次会话中都会加载到上下文中,因此一堆风格说明会降低对真正重要规则的遵守度。如果它会导致回答出错,它就属于该文件;如果它只会让回答不那么令人愉快,那就让助手重新学习它。

Codex 会读取我的 CLAUDE.md 文件吗?

不会。Codex 读取 AGENTS.md。如果您正在迁移 Claude Code 仓库,内容通常会原封不动地传输——您是在重命名文件并将其放置在 Codex 的加载路径中,而不是重写指令。从 Claude Code 到 Codex 的路径详细介绍了这种情况,包括导入器为您处理的内容。

如果我想继续同时使用两者呢?

那么就不要为您的知识选择单一的胜出者。Codex 将保留其本地记忆,Claude 将保留其对话记忆,而重要的约束应该存放在两者都能读取的一个存储库中——否则您将维护同一标准的两个不同版本,并在评审时重新发现差异。当每个工具分别学习您的项目时,这也是解决办法。