如何在不丢失上下文的情况下从 Amp 迁移到 Codex (2026)

你的 AGENTS.md 内容可以干净地迁移。 这两个工具都读取没有强制结构的纯 Markdown。Amp 的文档描述其在 AGENTS.md 文件中寻找“关于代码库结构、构建/测试命令和规范的指导”；Codex 的文档则称它“在执行任何工作之前读取 AGENTS.md 文件”。正文内容无需做任何修改。

根目录级别的指导可以迁移。 位于代码仓库根目录的单个 AGENTS.md 是这两个工具处理方式完全相同的唯一配置。

嵌套的 AGENTS.md 文件可以迁移，但生效时机不同。 Amp 会在“智能体读取子树中的文件时”引入“子树 AGENTS.md 文件”——这是延迟加载的，由文件访问触发。而 Codex 则会提前组装其指令链：它“在启动时构建指令链（每次运行一次；在 TUI 中这通常意味着每个启动的会话一次）”，从项目根目录向下遍历到你的当前工作目录（cwd）。相同的文件，不同的时刻，而且在 Codex 的情况下，只有从根目录到当前工作目录路径上的目录才会被包含。

代码仓库之上的指导无法迁移。 这是第一个真正的断层。Amp 总是会引入“当前工作目录（或编辑器工作区根目录）以及父目录（一直向上到 $HOME）”中的 AGENTS.md 文件，外加 $HOME/.config/amp/AGENTS.md、$HOME/.config/AGENTS.md 以及系统级文件。而 Codex 的项目范围始于项目根目录——“通常是 Git 根目录”——并向下遍历。你保存在代码仓库之上父文件夹中的任何内容，根本不在 Codex 的路径上。Codex 确实有一个全局范围，但它是一个特定的位置：你 Codex 家目录中的 AGENTS.override.md 或 AGENTS.md，并且它“仅使用该级别下的第一个非空文件”。

你的 CLAUDE.md 备用文件默认不会迁移。 Amp 的规则非常明确：“如果目录中不存在 AGENTS.md，但存在名为 AGENT.md（没有 S）或 CLAUDE.md 的文件，则该文件将被包含。”Codex 没有这种隐式的备用机制。它会检查 AGENTS.override.md，然后是 AGENTS.md，接着是你列在 project_doc_fallback_filenames 中的任何文件，文档对其余部分直言不讳：“不在该列表中的文件名在指令发现中将被忽略。”如果你的仓库中的某个目录一直依赖 CLAUDE.md 运行，那么迁移到 Codex 会静默地将其关闭。

Glob 范围的指导无法迁移。 这是最大的差距，而且 Codex 文档中记录的范围界定机制完全在另一个维度上工作。Amp 允许根目录的 AGENTS.md 通过 @ 提及其他文件，这些被提及的文件可以在 YAML 前言（front matter）中携带 globs：“只有当 Amp 读取了与任何 glob 匹配的文件时，带有 globs 的被提及文件才会被包含”，其中 glob “除非以 ../ 或 ./ 开头，否则会隐式地加上 **/ 前缀”。这为你提供了条件式的、始终扁平的指导——例如，当读取 TypeScript 文件时，docs/typescript-conventions.md 就会激活，否则就不会干扰。如果你已经构建了这种模式，我们在将 Amp 的指令范围限制在适用的文件上中描述过这种模式。

Codex 文档中记录的范围界定机制是目录嵌套。对于 glob 条件式引入，并没有文档记录的对应功能。因此，这些限定范围的文件要么必须变成其所管辖目录中嵌套的 AGENTS.md，要么变成父文件中的无条件文本——而无条件文本会占用容量上限，这就是下一个问题。

你的 AGENTS.md 大小现在可能变得很重要。 Amp 的智能体文件文档没有指定合并大小限制。而 Codex 指定了：它“跳过空文件，并且一旦合并大小达到 project_doc_max_bytes（默认 32 KiB）定义的限制，就会停止添加文件”。这种失效并不是报错，而是指导规则不再被包含。将一组受 glob 范围限制的文件合并为一个始终开启的文件，正是让原本舒适的配置超出这一限制的罪魁祸首。

Amp 没有而 Codex 拥有的功能。 Amp 文档中记录的持久化机制是你编写的 AGENTS.md 文件，外加线程。在 Amp 中，没有文档记录的、能够从之前的会话中自动写入的存储库对应物。而 Codex 有一个：“记忆（Memories）让 ChatGPT 和 Codex 能够将早期工作中有用的上下文带入未来的工作中。”在依赖它之前，有必要精确了解它究竟是什么，下一节将对此进行介绍。

步骤 1：重建向下遍历的发现树

首先从 Amp 的命令面板运行 agents-md list。这将为你提供 Amp 当前实际使用的文件集，这几乎总是比你记得自己编写的文件集要大。

然后将该列表整理成四个组。

位于或低于代码仓库根目录、且处于你通常工作路径目录中的文件，无需更改。Codex 会找到它们。

位于代码仓库之上父目录中的文件需要做出决定。如果内容是个人内容——特定于设备的命令、你正在测试的偏好设置——它应该放在 ~/.codex/AGENTS.md 中，即 Codex 的全局范围。如果是恰好位于仓库之上的项目内容，请将其移入仓库中。留在原处它是不会被发现的。

Amp 一直在默默提升的 CLAUDE.md 和 AGENT.md 文件需要明确化。要么将它们重命名为 AGENTS.md（这是更干净的结果，我们在将 CLAUDE.md 迁移到 AGENTS.md中进行了详细介绍），要么将它们添加到 ~/.codex/config.toml 中的 project_doc_fallback_filenames，以便 Codex 将它们视为指令文件。如果你已经离开了 Amp，重命名会更好；如果一些团队成员仍在使用 Amp 并期望使用旧名称，那么使用备用列表会更好。

受 glob 范围限制的 @ 提及文件需要重新定位到它们所管辖的目录。一个 glob 为 src/components/** 和 **/*.tsx 的文件将变成 src/components/AGENTS.md。一个 glob 跨越无关树的文件则必须进行拆分，或者提升为始终开启并计入容量预算。

在执行此操作时，请记住 Codex 的两个行为。每个目录仅使用一个文件——“Codex 每个目录最多包含一个文件”——并且在同一个目录中，AGENTS.override.md 优于 AGENTS.md，同级文件会被完全忽略。合并顺序是从根目录向下：“更接近你当前目录的文件会覆盖先前的指导，因为它们在合并后的提示词中出现得更晚。”因此，特异性来自于深度，而不是规则类型。

通过从嵌套目录启动 Codex 并要求它列出其加载的指令源来进行验证。如果缺少你期望的文件，通常的原因是它位于项目根目录之上、同级覆盖抑制了它，或者指令链达到了字节上限。相关的发现失败在为什么 Codex 会跳过你的 AGENTS.md 规则中有所提及，如果你是从 Copilot 而不是 Amp 迁移过来的，也适用相同的发现模型。

步骤 2：决定允许 Codex Memories 负责什么

Codex 的记忆层默认是关闭的；你可以在 Settings > Personalization（设置 > 个性化）中启用它。启用后，“Codex 可以将符合条件的先前对话中有用的上下文转化为本地记忆文件。”它“会跳过活跃或短暂的会话，从生成的记忆字段中脱敏敏感信息，并在后台更新记忆，而不是在每次对话结束时立即更新”。这些文件保存在 ~/.codex/memories/ 下，并且“包括摘要、持久条目、最近的输入以及来自先前对话的支持性证据”。在每次对话中，/memories 控制当前对话是否可以读取现有记忆或为未来的记忆提供素材，并且“对话级别的选择不会改变你的全局记忆设置”。

在决定对该功能寄予多少厚望之前，请先阅读 OpenAI 自己的指导建议：“将团队必需的指导保留在 AGENTS.md 或已提交的文档中。将记忆视为一个有用的召回层，而不是必须始终适用的规则的唯一来源。”

这是正确的界限，值得用你自己的话重新表述。Codex Memories 是一个本地的、基于单次安装生成的召回层。文档建议“将这些文件视为生成的状态”，不要“依赖手动编辑它们作为你的主要控制手段”。它不会与团队成员共享，它绑定到 Codex 家目录，并且当你接近速率限制时，可能会跳过生成。在减少你自己机器上的重复劳动方面，它确实非常有用。但它绝不是存放团队决策的地方。

这就留下了与你在 Amp 上遇到的相同的空白，只是现在它的轮廓更加清晰：你的团队在工作时确立的事情——例如为什么放弃流式解析器、针对不稳定的测试已经失败了哪两个修复方案、客户要求的命名规范——既不属于指令文件，也不属于每台笔记本电脑上生成的本地存储。正是这一空白，使得在会话之间共享上下文在所有这些工具中都成为了一个未解决的问题。

这次迁移之所以繁琐，是因为这两个工具都在解决“智能体应该始终知道什么”，而没有一个在解决“我们学到了什么”。按照设计，指令文件在每次运行时都会重新发送。而生成的本地存储按照设计是单机独享的。团队知识两者都不是。

MemoryLake 独立于两者之外。它保存发现的事实，通过 MCP 和 API 将其公开，并且不在乎本周的客户端是 Amp、Codex，还是你尚未采用的其他工具。这也让下一次迁移变得索然无味，而这正是我们的实际目标。

步骤 1：创建 API 密钥

生成一个密钥，并在大约 30 秒内发出你的第一次请求。一个密钥，可从你团队使用的每个界面进行读取，正是防止知识变成某个编辑器配置目录私有财产的关键。

步骤 2：上传你的第一批记忆

放入已经承载了你既定决策的文档、图像和文件——架构说明、当前重试策略背后的事件记录、没人想重复的设计评审。从你厌倦了反复解释的内容开始。

步骤 3：连接你的 AI 和智能体

允许 Claude、Codex、OpenClaw 和其他智能体通过 MCP 或 API 进行访问。在实践中，在任务开始时读取相关的记忆，并在任务期间写回你所做的修正，这样修正的生命周期就会超出它发生时的会话。

迁移不再具有风险。一旦重建了发现树，并且团队知识脱离了这两个工具，未来工具的更换唯一会触及的就只有指令文件语法——这只需要一个下午，而不是一个重新探索的项目。

你的 AGENTS.md 文件会变得更小、更好。大多数臃肿的指令文件之所以臃肿，是因为它们累积了无处可去的发现事实。将这些事实移出可以让你轻松保持在 32 KiB 的上限之内，而且更有用的是，让剩余的内容真正专注于如何在代码仓库中工作。

启用 Codex Memories 变得安全。一旦必需的规则存在于已提交的文件中，且团队知识存在于共享存储库中，本地召回层就纯粹是一种便利，不承担关键作用。这正是 OpenAI 文档所推荐的态度。

而且过去属于“部落传统”（口耳相传）的东西不再是秘密。新工程师的 Codex 在执行第一个任务时就能读取与其他人相同的既定决策，而不需要花三个月时间通过不断被纠正来吸收这些知识。

在信任它之前，先重建树。 从你最深的工作目录启动 Codex，并询问它加载了什么。深度会改变答案，而在 Amp 上并非如此。

相比备用列表，更推荐重命名。 project_doc_fallback_filenames 虽然有效，但它是一个本地配置文件。重命名后的 AGENTS.md 存在于仓库中，对每个人都有效。

将覆盖文件放在靠近工作的地方。 Codex 自己的建议：“将覆盖文件尽可能放在靠近专门工作的地方”，因为遍历会在你当前的目录停止。

扁平化 glob 时要注意容量上限。 每一个变成始终开启文本的、受 glob 范围限制的 Amp 文件，现在都在竞争 32 KiB 的空间。嵌套比提高限制更划算。

保持 ## Code Review Rules 的范围限定。 Codex 会从最靠近其管辖代码的 AGENTS.md 中读取该部分，因此根目录级别的检查放在根目录，而特定于服务的检查放在嵌套文件中。

不要在记忆中放入敏感信息。 Codex 会从生成的字段中脱敏敏感信息，但其文档仍然建议你在共享 Codex 家目录之前检查这些文件。这两点都是事实；将脱敏视为最后一道防线，而不是可以随意放行的许可。

Amp and Codex 读取相同的文件格式，但在寻找该文件的位置方面，几乎在所有其他方面都存在分歧。Amp 向上搜索并慷慨地引入；Codex 向下组装一条链，每个目录获取一个文件，并在达到字节上限时停止。这两种方法都没有错，而且这些工具对自身行为的记录足够清晰，一旦你不再假设文件兼容性意味着行为兼容性，迁移就成了一项机械化的工作。

非机械化的部分是这两个工具都没有声称拥有的部分。Codex 自己的文档为你划定了界限——记忆是“一个有用的召回层，而不是……必须始终适用的规则的唯一来源”——其推论是存在第三个类别：你的团队摸索出来的东西，这些东西对于指令文件来说过于具体，而对于每台笔记本电脑的本地存储来说又过于共享。将这些内容放在两个工具都能读取的地方，重建向下遍历的发现树，迁移工作只需一个下午即可一劳永逸地完成。