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

文件名和内容完全迁移。 Codex “在执行任何工作之前读取 AGENTS.md 文件”。Warp 的 Project Rules 存在于“AGENTS.md 文件中（或为了向后兼容而使用 WARP.md）”。相同的文件名，相同的 markdown，无需转换。

如果您不够严谨，一个文件名细节会给您带来麻烦。 Warp 的文档中有一项明确的警告：“文件名必须全部大写，Warp 才能识别它（例如 AGENTS.md，而不是 agents.md 或 Agents.md）”。Codex 在另一方面同样严格——其备用列表是精确的，并且“不在该列表中的文件名在指令发现时会被忽略”。如果您通过 project_doc_fallback_filenames 注册了小写或自定义名称，Warp 将无法识别它。

嵌套有效，但堆叠取代了覆盖。 这是实质性的变化。

Codex 的模式：“从项目根目录（通常是 Git 根目录）开始，Codex 向下遍历到您当前的工作目录……在路径上的每个目录中，它会检查 AGENTS.override.md，然后是 AGENTS.md，接着是 project_doc_fallback_filenames 中的任何备用名称。Codex 在每个目录下最多包含一个文件。”然后它进行合并：“Codex 从根目录向下拼接文件……由于较靠近当前目录的文件在组合提示词中出现得较晚，因此它们会覆盖先前的指导。”

Warp 的模式：“Warp 会自动应用根目录和当前目录中的 AGENTS.md（或 WARP.md）”，并且“如果您编辑另一个子目录中的文件，Warp 会尽最大努力尝试同时包含该子目录的规则文件”。冲突通过规定的优先级解决：“1. 当前子目录的项目规则文件中的规则 2. 根目录的项目规则文件中的规则 3. 全局规则（Global Rules）。”

两者最终都倾向于具体规则而非通用规则。区别在于您希望消除的指导会发生什么。在 Codex 中，目录中的 AGENTS.override.md 意味着同级 AGENTS.md 完全不会被读取——您可以真正地进行替换。而在 Warp 中，优先级决定了冲突的解决，但根文件仍然会被应用。根文件声明而您的子目录从未提及的规则将继续生效。

因此，使用覆盖来排除异常情况的 Codex 配置，需要将这些异常情况在子目录文件中重新表述为明确的矛盾点，而不是直接留空。

字节上限消失了，这确实令人松了一口气。 Codex “会跳过空文件，并且一旦合并大小达到 project_doc_max_bytes（默认 32 KiB）定义的限制，就会停止添加文件”，其解决方法是“在达到上限时提高限制或将指令拆分到嵌套目录中”。Warp 的规则文档中没有说明等效的上限。如果您之前为了保持在 32 KiB 以下而拆分文件，那么该限制现在已经不复存在——尽管“因为可以”并不是重新合并它们的合理理由。

全局作用域从文件变为了 UI。 Codex 将全局指导保存在 ~/.codex/AGENTS.md（或 AGENTS.override.md，因为“Codex 在此级别仅使用第一个非空文件”），并可通过 CODEX_HOME 进行重定位。Warp 的全局规则（Global Rules）“适用于所有项目和上下文”，并在 Warp Drive Rules 面板中进行管理，其中每条规则都可以包含名称和“描述（规则的作用以及何时应用）”。

这是一个不同的产物。您的全局文件变成了一组单独描述的规则，而不是一个文档——除非您在某处保留副本，否则它将不再处于版本控制中。

验证工具发生了变化，但两者都很优秀。 Codex 为您提供了以下命令：codex --ask-for-approval never "Summarize the current instructions."、用于嵌套行为的 --cd subdir 变体，以及通过“带有 codex -c log_dir=./.codex-log 的纯文本 TUI 日志”进行完整审计。它也没有需要清理的缓存——“Codex 在每次运行（以及每个 TUI 会话开始时）都会重建指令链，因此无需手动清除缓存。”

在 Warp 中，生效的规则会呈现在对话中：“交互中使用的规则将显示在对话的 References 下，或标记为源自特定规则。”机制不同，目的相同，值得在第一周就加以利用，而不是凭空假设。

代码库索引是新功能，且在本地进行。 Codex 按需读取文件。Warp 维护一个索引：“Warp 会索引您受 Git 跟踪的代码库，以帮助 Agent 理解您的代码并生成准确、感知上下文的回复。Warp 服务器上不会存储任何代码。”您会看到各种状态——Synced（已同步）、Discovering files（正在发现文件）、Failed（失败）、Codebase too large（代码库过大）——以及用于控制的 .warpindexingignore，并且所有方案都支持“每个代码库至少 5,000 个文件”。

这里没有什么需要迁移的。这是您获得的一项新能力，但您现在需要考虑同步问题：“如果修改了许多文件或网络较慢，同步可能无法在 Agent 尝试访问上下文之前完成。”

Agent Memory 是其优势所在，但有三个条件。 Warp 的 Agent Memory “为 Warp 中的 agent 提供了跨支持的 harness（包括 Warp Agent、Claude Code 和 Codex）的持久化记忆”。这是一个严谨的系统：个人、agent 和团队存储；自动提取，其中“新知识会与现有记忆合并，或在冲突时取而之”；每个存储的只读或读写权限以及每个存储的指令；可追溯性，其中“每条记忆都会记录其来源”；以及可审计性，其中“对记忆的每次更改都会被记录”。

现在来看这三个条件，它们都已记录在文档中，且都至关重要。它“处于研究预览（research preview）阶段，并针对设计合作伙伴按团队启用”，且设有候补名单。对第三方 harness 的支持适用于它们作为云端 agent 运行的情况——“在研究预览期间，不支持在本地运行第三方 harness。”并且它存在于 Warp 上：“记忆始终与其所有者（用户、agent 或团队）绑定，与读取或写入的 harness 无关。”

因此，坦白地说：如果您的团队是设计合作伙伴，并且您将 Codex 作为 Warp 云端 agent 运行，您将获得一个托管的记忆层。如果您不是，或者您在自己的终端中本地运行 Codex，则无法获得——而 Codex 自身的本地记忆（默认关闭，在开启 Codex 的本地记忆中有所介绍）仍将保留在您的机器上。

步骤 1：移动文件，然后将每个覆盖重新表述为矛盾点

将每个 AGENTS.md 复制到相同的路径。内容无需任何更改。

然后处理覆盖，这是需要权衡的部分。对于目录树中的每个 AGENTS.override.md，思考它之前抑制了什么。如果它的存在是为了替换根规则——例如“使用 make test-payments 代替 npm test”——请在该目录的 AGENTS.md 中将其重新表述为明确的指令，因为在 Warp 中，根规则仍会被应用，而优先级仅在两者直接冲突时起作用。如果它的存在是为了抑制根规则而不提供替代方案，您需要用一句话明确说明，因为沉默不再能抑制任何内容。

在此期间，检查您的全局文件。将 ~/.codex/AGENTS.md 拆分为带有描述的单个全局规则（Global Rules），如果您介意审查其更改历史，请在版本控制中保留一份副本——Warp Drive 面板是一个很好的编辑界面，但它不是 git 历史记录。

如果您的仓库通过 project_doc_fallback_filenames 使用了自定义文件名，请在相应路径下将它们重命名为 AGENTS.md（全部大写）。Warp 的 /init 也可以链接现有的外部规则文件，文档中列出的列表非常具体：“CLAUDE.md、.cursorrules、AGENT.md、GEMINI.md、.clinerules、.windsurfrules、.github/copilot-instructions.md”。请注意该列表中的单数 AGENT.md；复数 AGENTS.md 是原生读取的。

步骤 2：坦率地决定是否使用 Agent Memory，然后进行索引和验证

在围绕 Agent Memory 制定任何计划之前，请先回答两个问题：您的团队是否启用了研究预览？您是否会将 Codex 作为 Warp 云端 agent 运行，而不是在本地运行？如果其中任何一个回答为“否”，请将 Agent Memory 视为未来的功能，并假设其不存在来进行设计。

这并不是对该功能的批评。这是文档中的说明，而在您未加入的研究预览上构建工作流，会导致团队在三周后发现上下文断层。

然后设置您肯定能获得的功能。在 Warp 中打开您的仓库以启动索引，并在 Settings > Code > Indexing and projects 下检查状态，直到显示为 Synced。如果仓库较大，请添加 .warpindexingignore。然后运行一次 Agent 对话，并查看 References 部分以确认实际引入了哪些规则——这与运行 Codex 的 summarize-instructions 命令直觉相同，而 为什么 agent 会忽略您的指令文件 通常是发现问题，而不是理解问题。

文件迁移只是复制加上覆盖审计。这一举动暴露了您持久的项目知识一直依赖于您恰好使用的工具——某台机器上的 Codex 本地记忆，或者如果您已加入并在云端运行，则是 Warp 的 Agent Memory。

两者都是真实存在的功能。但无论加入状态、机器或 agent 在何处执行，它们都不适合存放您所需的知识。该层根本不应该属于 harness 的属性。

将其置于外部，计算就会变得简单：您迁移规则，获得代码库索引，而您的 agent 所需的事实已经在首次运行时准备就绪。MemoryLake 的设置只需三个步骤。

步骤 1：创建 API 密钥

登录并从您的仪表板生成一个 API 密钥。它不依赖于研究预览的加入状态，也不取决于 agent 是在本地运行还是作为云端 agent 运行，而这恰恰是本次迁移引入的模糊地带。

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

放入规则文件和索引都无法提供的内容：架构决策及其背后的原因、为什么某个已弃用的服务仍然存在、领域词汇、所有权以及附带原因的约束条件。

将行为保留在 AGENTS.md 中，现在无需再与 32 KiB 的上限作斗争——这是一个让这些文件保持简短的好理由，是出于主动设计，而不是被迫为之。

步骤 3：连接您的 AI 和 agent

将 Warp 指向该存储，在同时运行两者时也将 Codex 指向它。分阶段迁移正是共享层发挥作用的时候，因为另一种选择是使用两个工具，各自拥有不完整的视图——正如跨工具共享同一个记忆中所阐述的那样。

第一个变化是，覆盖审计是一次性成本，而不是反复出现的意外。一旦异常情况被明确表述而非隐式表达，它们在迁移到下一个工具时也能保留下来。

第二个变化是，失去字节上限并不意味着失去纪律。32 KiB 是一个任意设定的上限；简短的指令文件仍然比冗长的文件更容易被遵循，而过去争夺该预算的事实现在存在于其他地方。

第三个变化是，Agent Memory 变成了附加福利，而不是依赖项。如果您的团队加入了该计划，它会在您已有的基础上增加可追溯、可审计、团队共享的记忆。如果没有加入，您的配置中也没有任何内容依赖它——这就是保持团队 AI 上下文独立于任何单一工具的意义所在。

• 保持文件名全部大写。 Warp 要求这样做；在 Codex 中注册的小写和自定义名称将无法被识别。
• 审计每个 AGENTS.override.md。 Warp 会同时应用根目录和当前目录，因此留空不再起抑制作用。
• 明确重新表述抑制规则。 您希望消除的规则需要用一句话说明，而不是直接省略。
• 将全局文件拆分为带有描述的规则。 如果您需要变更历史记录，请保留一份受版本控制的副本。
• 在评估质量之前让索引完成。 留意 Synced 状态，并在大型仓库中使用 .warpindexingignore。
• 阅读 References 部分。 这是 Warp 对 Codex 的 summarize-instructions 命令的对应功能。
• 除非您已加入，否则不要围绕 Agent Memory 制定计划。 研究预览阶段，仅针对设计合作伙伴按团队启用，且在预览期间仅支持云端 agent。
• 无论如何都要保持指令文件简短。 32 KiB 的上限虽然消失了，但保持简短的原因依然存在。

这次迁移中关于文件的部分只是复制，而两个真正的收获——代码库索引和无字节上限——无需任何工作即可获得。

需要刻意处理的两件事是覆盖语义（在迁移后无法保留）和 Agent Memory（非常出色，但受文档中记录的三个条件限制）。重新表述您的异常情况，将持久的事实保存在两个工具都不拥有的层中，这样切换只会花费您一个下午的时间，而不是花上一个季度去重新发现您的 agent 过去所知道的事情。