实际迁移的内容
您的 AGENTS.md 内容，原封不动。 设置命令、样式、测试指令、约定。无需更改格式，无需添加 frontmatter。
嵌套目录文件，具有不同的优先级语义。 这两个工具都支持每个目录的指令文件。Codex “从根目录向下拼接文件，用空行连接”，并且 “更接近当前目录的文件会覆盖先前的指导，因为它们出现在组合提示词的后面”。Cursor 的嵌套 AGENTS.md 文件则是 “与父目录结合，更具体的指令具有更高的优先级”。实际效果类似，但并不完全相同——Codex 的排序效果是位置性的，而 Cursor 的效果则被表述为优先级。
除此之外别无他物，以下是具体清单。
AGENTS.override.md 没有 Cursor 等效项。 这是最容易让人踩坑的地方。在 Codex 中，系统会先检查每个目录中的 AGENTS.override.md，然后才是 AGENTS.md，并且 “Codex 每个目录最多包含一个文件”。因此，同时拥有这两个文件的目录，其 AGENTS.md 会被忽略。在 Cursor 中打开该仓库，覆盖文件名将毫无意义——Cursor 会读取 AGENTS.md，而这正是 Codex 刻意跳过的文件。您的实际指令在没有进行任何修改的情况下就发生了改变。
全局作用域移动到了不同的地方，并使用了不同的名称。 Codex 从您的 Codex 主目录（除非设置了 CODEX_HOME，否则为 ~/.codex）读取全局指导——如果存在 AGENTS.override.md 则采用它，否则采用 AGENTS.md，并且 “Codex 仅使用该层级的第一个非空文件”。Cursor 的等效项是 User Rules，被描述为 “在 Customize → Rules 中定义的、适用于所有项目的全局偏好设置”，并由 Agent (Chat) 使用。同样的工作，不同的归宿，而且它是一个设置面板，而不是一个您可以提交或同步的文件。
## Code Review Rules 部分将不再起任何作用。 在 Codex 中，您将该部分添加到最靠近其管辖代码的 AGENTS.md 中，它会驱动 GitHub 拉取请求（PR）和 GitLab 合并请求（MR）上的 Codex 代码审查，通过 @codex review 或 @codex security review 调用。Cursor 没有该部分的消费者。该文本仍将被读取为普通指令，这通常无害，但偶尔会令人困惑。
上限的量级完全不同。 Codex “一旦组合大小达到 project_doc_max_bytes（默认 32 KiB）定义的限制，就会停止添加文件”——这是整个链条的总预算。Cursor 的指导是针对单个规则的：“将规则保持在 500 行以下”，并将大型规则拆分为可组合的规则。如果您的文件接近 Codex 的 32 KiB 上限，您会想要进行拆分，而不是直接粘贴。
config.toml 或子代理（subagent）定义中的任何内容。 审批模式、沙箱设置以及 Codex 自身的子代理配置都是 Codex 的概念。重建其意图，而不是直接迁移文件。
手动迁移
步骤 1：在切换前扁平化覆盖文件
在 Codex 仍是您的单一事实来源时执行此操作，因为这一步可以防止行为发生默默的改变。
在您的仓库中查找 AGENTS.override.md。在同时拥有覆盖文件和 AGENTS.md 的每个目录中，请记住 Codex 一直只读取覆盖文件。决定您实际需要哪些内容，将其合并到 AGENTS.md 中，然后删除覆盖文件。对全局文件执行相同的操作：如果存在 ~/.codex/AGENTS.override.md，它就完全遮蔽了 ~/.codex/AGENTS.md。
在开始删除内容之前，有一种记录在档的方法可以确认 Codex 正在加载什么。在您关心的目录中运行以下命令：
codex --cd services/payments --ask-for-approval never "List the instruction sources you loaded."文档将预期输出描述为：Codex 首先报告全局文件，其次是仓库根目录的 AGENTS.md，最后是嵌套的覆盖文件。这为您提供了真实的链条，而不是您主观的假设。
步骤 2：重建全局层并在 Cursor 中选择您的规则格式
在 Cursor 端需要做两个决定。
全局偏好设置 → User Rules。 打开 Customize → Rules，并粘贴原本保存在 ~/.codex/AGENTS.md 中的内容。仅保留真正通用的偏好设置；它适用于您的所有项目。
仓库指令 → 保留 AGENTS.md，或转换为 .cursor/rules。 保留 AGENTS.md 是零工作量的选择，也是正确的默认设置。只有在您需要条件加载时才进行转换，因为这正是 .cursor/rules 增加的功能：通过 .mdc 文件的 frontmatter 来决定它们何时适用。Cursor 的四种规则类型是：Always Apply（始终应用）、Apply Intelligently（智能应用，“当 Agent 根据描述判定相关时”）、Apply to Specific Files（应用于特定文件，“当文件匹配指定模式时”）以及 Apply Manually（手动应用，“在聊天中被 @ 提及时代入”）。
如果您确实进行了转换，请注意一个与 Codex 无关的陷阱：“.cursor/rules 中的普通 .md 文件会被规则系统忽略，因为它没有 frontmatter 来指定 description、globs 和 alwaysApply。如果您更喜欢普通 markdown，请改用 AGENTS.md。” 将其重命名为 .mdc 并设置 frontmatter，或者继续使用 AGENTS.md。
并对规则的本质保持合理的预期。Cursor 官方的表述是：“大型语言模型在两次补全之间不会保留记忆。规则在提示词级别提供持久、可复用的上下文。” 规则是按请求提供的上下文——这与您的 AGENTS.md 链条是一样的。使其在不同会话之间保持生效的机制，请参阅跨会话携带 Cursor 上下文。
反过来，如果您最终会同时运行这两个工具一段时间，也值得了解：Codex 也可以从其他工具中拉取配置，这是Codex 可以从 Cursor 和 Claude 导入什么的主题。
更好的方法：将推理完全移出规则文件
您现在在新工具中拥有了相同的指令。但您还没有迁移的是让您的 Codex 设置在运行六个月后真正变得好用的东西：关于为什么的累积知识。
这两个工具都无法很好地保存这些内容，并且它们都通过其限制表明了这一点。Codex 默认将整个指令链限制在 32 KiB。Cursor 告诉您将规则保持在 500 行以下，并“引用文件而不是复制其内容——这可以保持规则简短，并防止它们随着代码更改而过时”。这些限制并非凭空制定；始终开启的内容会随着每个请求一起发送。
因此，您已经拒绝的决定、约束和方法在任何一个工具中都无处安放——这就是为什么即使文件完美迁移，更换工具也感觉像是一次记忆抹除。
这就是 MemoryLake 所承载的：您项目的持久知识，存在于一个您的工具可以读取的层中，无论您本季度使用的是哪款编辑器。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建 API 密钥。一个凭据即可跨您连接的所有工具使用。
步骤 2：上传您的第一批记忆
简短的条目，每条记录一个断言。在您对迁移记忆犹新时，可以写下这些内容：
带有强制约束的决策。 “由于只读副本在负载下存在延迟，迁移只能是渐进式的。” 规则可以陈述策略；但只有这样才能阻止下周再次提出相同的替代方案。
您在此代码库中已经拒绝的内容。 这一类别不存在于任何文件和任何提交信息中。每个新代理都会再次提出它。
您通过艰难教训学到的环境事实。 仅在 CI 中失败的测试、行为与文档不符的依赖项、文档中未提及的速率限制。
您纠正过多次的错误。 Cursor 自身的建议是，当您注意到 Agent 重复犯错时添加一条规则——将纠正的原因放在这里，紧挨着它。
步骤 3：连接您的 AI 和代理
连接您使用的工具。MemoryLake 可通过 MCP 和 API 访问，因此支持 MCP 的原生代理（包括 Claude Code、Codex 和 OpenClaw）可以通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。这意味着您无需完成切换即可开始受益：在您做决定时，两个工具都可以读取相同的层。
三个坦诚的限制。MemoryLake 不会编写您的 Cursor 规则或您的 AGENTS.md——这些是您引导每个工具的方式，您应该妥善设置它们。它只保存您或您的代理写入其中的内容，因此步骤 2 是手动的。而且规则是上下文，而不是强制配置；记忆层不会改变合规性。
这在实践中改变了什么
切换不再是“非全即无”的选择。 两个工具都读取相同的外部记忆，这意味着您可以运行 Cursor 一周，而无需放弃您的 Codex 设置。
扁平化覆盖文件变成了一次性的工作。 一旦合并，就再也没有被遮蔽的文件需要向新人解释——或者在十一月向您自己解释。
在新工具中，规则文件也保持简短。 您的 Codex 链条逐渐接近 32 KiB 的原因在于它承担了双重任务。一旦将它们拆分，任何一个上限都不会成为限制。
引入第三个工具几乎不需要任何成本。 整个生态系统中的大多数工具都会读取 AGENTS.md，而推理过程存在于任何支持 MCP 的原生代理都可以查询的层中。
“它不了解我的项目”有了一个真正的答案。不是“编写更多规则”，而是“知识从未存在于规则中”——这在为什么 RAG 不是记忆中有通用案例分析。
从 Codex 切换到 Cursor 的最佳实践
首先扁平化 AGENTS.override.md。 Cursor 无法识别该文件名，因此您遗忘的覆盖文件会变成您无意激活的指令。
在更改任何内容之前，导出已加载的链条。 让 Codex 列出它加载的指令来源，并以此为基础开展工作，而不是凭记忆。
检查 CODEX_HOME。 如果设置了该变量，您的全局文件就不在 ~/.codex 中，您会迁移错误的文件。
将全局偏好设置放在 User Rules 中，而不是仓库中。 Cursor 的 User Rules 适用于所有项目，这正是 ~/.codex/AGENTS.md 之前的作用。
除非您需要条件加载，否则请保留 AGENTS.md。 转换为 .cursor/rules 可以让您获得规则类型，但同时也带来了 frontmatter 的维护成本。
切勿在 .cursor/rules 中留下普通的 .md 文件。 它会被默默忽略。请使用带有 frontmatter 的 .mdc，或使用 AGENTS.md。
剥离或重新标记 ## Code Review Rules。 Cursor 中没有任何内容会消耗它，将其作为未标记的指令保留可能会让您和代理都感到困惑。
当您遇到上限时，选择拆分而不是粘贴。 这两个工具都指向同一个方向：嵌套的、可组合的文件，而不是一个长文件——这也是为什么 Cursor 会遗忘项目规则背后的原因。
结论
从 Codex 到 Cursor 是极少数文件本身不需要任何处理的迁移：这两个工具都读取 AGENTS.md，因此您的指令可以完好无损地送达。风险完全在于其周边的部分。AGENTS.override.md 是一个仅限 Codex 的概念，并且由于 Codex 每个目录最多包含一个文件，覆盖文件一直在隐藏 Cursor 现在将要读取的 AGENTS.md。全局指导从 ~/.codex 移动到 Cursor 的 User Rules 中。## Code Review Rules 不再与任何内容绑定。而原本容纳在 32 KiB 内的链条变成了每个都希望保持在 500 行以下的规则集。
扁平化覆盖文件，在编辑前导出真实的指令链，在 Customize → Rules 中重建全局层，除非您特别需要条件加载，否则保留 AGENTS.md。然后将决策、约束和被拒绝的方法放在这两个工具都可以查询的地方，这样下一次切换就只是偏好选择，而不是一个大工程。