哪些内容可以实际迁移
`AGENTS.md` 无需任何操作即可迁移。 两个工具都会读取它，且都采用最近优先的解析原则。如果你已经统一使用 AGENTS.md，只需在仓库中打开 Codex，你的指令就会立即生效。这是无论你本季度使用哪种智能体，都应该标准化使用该文件的最强有力理由。
`.github/copilot-instructions.md` 无法直接迁移，但可以干净地转换。 GitHub 将其描述为“适用于在仓库上下文中提出的所有请求”的指令。Codex 有一个完全对应的概念 —— 仓库根目录下的 AGENTS.md —— 因此这只需复制并重命名，然后通读一遍以删除过时的内容即可。
路径作用域的指令可以转换，但无法机械化完成。 Copilot 支持在 .github/instructions 下使用一个或多个 NAME.instructions.md 文件，每个文件都带有一个 applyTo frontmatter 字段，使用 glob 语法来声明它覆盖哪些文件或目录。Codex 没有 glob 机制。它唯一的范围限制工具是文件所在的位置：首先是 ~/.codex/AGENTS.md（或 $CODEX_HOME），然后是仓库根目录，接着是中间目录，最后是你的工作目录，自上而下组装，并以最近的文件为准。
因此，由 applyTo: "src/api/**" 限定范围的规则会变成 src/api/ 内部的 AGENTS.md。当你的 glob 匹配符合你的目录布局时，这种方法很有效；但如果不符合，就需要做出权衡 —— 比如像 **/*.test.ts 这样的 glob 跨越了整个目录树，没有单一的归宿。
组织级指令完全无法迁移。 GitHub 文档中定义了三层优先级：“个人指令优先级最高。仓库指令次之，组织指令优先级最低。”Codex 没有组织管理的指令层来接收这第三层。
注意这在实际中意味着什么：塑造你 Copilot 输出的部分指导原则可能是别人编写的，而你可能从未读过。在迁移之前，先弄清楚你的组织是否设置了指令，并获取一份副本。否则，你可能会花上几周时间纳闷，为什么 Codex 写出的代码跟你们团队的风格有微妙的差异。
`excludeAgent` 也没有对应的功能。 Copilot 的特定路径指令接受一个可选的 excludeAgent 字段，其值可以是 code-review 或 cloud-agent，这样就可以故意在某些界面中屏蔽某条规则。Codex 中没有任何机制可以表达这一点。一旦转换，你之前在代码审查中屏蔽的规则将应用于加载该文件的所有地方 —— 请特别检查这些规则。
个人指令会转换为你的全局文件。 GitHub 的个人指令适用于你的所有工作，且优先级最高；Codex 的对应文件是 ~/.codex/AGENTS.md。请保持其简短，因为它会在机器上的每个项目中加载。
在两个工具中，没有任何文件保存的内容。 GitHub 的自定义指令文档并未声称 Copilot 会在会话之间保留记忆，而 Codex 自身的记忆功能默认是关闭的。因此，你那些约定背后的推理过程 —— 故障事件、约束条件、被否决的替代方案 —— 都不在任何一个系统中，无法进行迁移。这就是为什么即使完全迁移了配置，系统感觉依然不了解你的项目，这也是Copilot 丢失代码库上下文这一抱怨背后的原因。
手动迁移步骤
Step 1: Inventory all four Copilot layers, including the one you didn't write
在开始使用 Codex 之前，先收集这些内容：
.github/copilot-instructions.md—— 仓库全局文件.github/instructions/下的所有内容，以及每个文件的applyTo模式和任何excludeAgent值- 仓库中已有的任何
AGENTS.md文件及其位置 - 你在 GitHub 设置中的个人指令
- 组织级指令，你需要向所有者或管理员索取
然后按来源进行分类整理，这种筛选方法能降低每次迁移的成本：源自仓库的（删除 —— Codex 会直接读取仓库）、由你编写且依然有效的（这就是需要迁移的内容）、已废弃的（现在就删掉，趁你还认得它们）。
在此过程中，请密切注意 applyTo 模式。它们不是摆设，而是每条规则在何时生效的唯一记录。如果复制规则时丢掉了它的作用域，它要么会在每次会话中变成噪音，要么会因为看起来无关紧要而被你删掉。
Step 2: Rebuild scope as directory position, and decide about the leftovers
将保留下来的每条规则放在 Codex 能够找到的地方：
- 仓库全局 → 仓库根目录下的
AGENTS.md，并提交。 - 路径作用域且符合目录结构 → 该目录内部的
AGENTS.md。例如applyTo: "src/api/**"变成src/api/AGENTS.md，现在其作用域是通过位置来强制执行的，而不是通过工具必须遵守的某种模式。 - 路径作用域且横切（跨目录） → 这需要你做出权衡。对于跨越十几个包匹配
**/*.test.ts的规则，有三种选择：如果它简短且重要，可以将其提升到根目录文件中；在测试实际存在的两三个目录中放置副本；或者直接丢弃它，转而依赖你的 linter。把所有内容都提升到根目录，会导致根文件膨胀到 600 行，最终没人再去遵守。 - 个人 →
~/.codex/AGENTS.md，保持简短。 - 组织级 → 放入仓库中，作为根目录
AGENTS.md中已提交的一个章节，因为 Codex 没有组织层级。在文件中注明它来自组织策略，这样就不会有人把它当作个人的偏好而删掉。 - 任何带有 `excludeAgent` 的内容 → 自觉决定它现在是否应该应用于所有地方，如果答案是否定的，就将其删除。
还有两点技术细节需要注意。Codex 不会读取 CLAUDE.md，所以如果你的仓库从其他工具那里继承了这样一个文件，它的内容也需要存在于 AGENTS.md 中。此外，Codex 的记忆功能是一个独立的决定：在“个性化”（Personalization）设置中启用它们，或者通过 [features] memories = true 启用，并清楚你将得到什么 —— 存储在 ~/.codex/memories/ 中的生成状态，它是全局的而非针对单个项目的，且仅存在于该机器上，适合作为便利层，但不适合作为记录。
然后一口气通读一遍组装好的完整结果。这是人们常常跳过的步骤，但正是在这里，你能抓出那条来自 2024 年、让智能体去使用你早已删除的包的陈旧规则。
更好的方法：统一的记忆层，适用于任何智能体
注意步骤 1 中的盘点到底是为了什么。四个层级、三种格式、一个必须向管理员申请的层级，而且没有一个字提到为什么。这些规则只是那些从未被记录下来的决策的压缩产物。
这才是值得重新安置的部分。将指令文件保留在仓库中供智能体读取，而将推理过程放在一个不属于任何厂商配置目录的存储库中。
MemoryLake 就是为此而生的记忆层 —— 它将你规则背后的决策、事故报告和源文档统一保存在一个存储库中，支持 MCP 的工具（如 Claude 和 Codex）可以直接读取，而 ChatGPT 则可以通过 API 进行读取。AGENTS.md 规定了要做什么；而存储库解释了为什么，并且下次迁移时无需再动它。
Step 1: Create an API key
生成一个密钥，并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中，而不是直接粘贴到会话中。
Step 2: Upload your first memories
放入你规则所源自的文档、图片和文件：架构决策记录、事故报告、API 契约、你组织指令所强制执行的安全要求，以及大家都同意的 RFC。上传这些源文件，而不是单行规则 —— 单行规则是你已经拥有的东西，而且总是会受到疑问。
Step 3: Connect your AI & agents
通过 MCP 或 API 授予 Claude、Codex、OpenClaw 和其他 AI 智能体访问记忆的权限。Codex 可以通过 MCP 直接读取该存储库，并与你的 AGENTS.md 文件协同工作。对于 ChatGPT，你可以通过 API 检索所需内容，并将其注入到提示词或调用模型的流中。
这在实践中带来了什么改变
第一个改变是，横切规则不再是一个两难的选择。匹配所有地方测试文件的规则不需要复制到六个目录中，也不需要塞进根文件中 —— 它可以在智能体处理测试时被检索出来，而在不处理测试时则不出现。
第二个改变是，组织策略层在迁移时不会再消失。管理员设置的规则曾是隐形的基础设施；一旦它们成为有据可查、可检索且附带原理解释的记录，无论更换工具还是更换管理员，它们都能保留下来。
第三个改变是，根目录的 AGENTS.md 可以保持足够简短，从而真正被遵守。每个在每次会话中加载的文件都会与请求竞争上下文。由检索来承载细节后，始终加载的文件只需保留那些“一旦违反就会导致答案出错”的硬性约束 —— 这样你就不必再在每次会话中重新向 AI 解释你的项目。
而且它能与 Codex 自身的记忆相结合。本地记忆会继续在机器上积累你的个人习惯；而共享存储库则保存你的团队成员和其他工具所需的内容。两者各司其职，这种划分可以防止多工具设置发生偏差。
切换编程智能体的最佳实践
Standardize on AGENTS.md before you need to
这次迁移中 AGENTS.md 层级之所以是免费的，是因为两个工具都会读取它。这一特性非常值得优化：凡是能用 AGENTS.md 表达、而不是用厂商特定文件表达的内容，你以后就再也不需要迁移了。
Get the organization instructions in writing
这是离开 Copilot 时最容易被忽视的一项。别人的规则曾在最低优先级层级上塑造着你的输出。去索取它们、阅读它们，并决定保留哪些 —— 不要等到六周后因为代码出现微妙的错误才发现它们缺失了。
Express scope with position, and accept that some rules lose precision
目录放置是 Codex 唯一的作用域机制，对于跨越目录树的 glob 模式来说，这确实是一种降级。针对每条规则明确权衡这种得失，而不是假装转换是无损的：要么提升、要么复制、要么丢弃。
Keep the always-loaded files small
根目录的 AGENTS.md 和 ~/.codex/AGENTS.md 会不断加载。只在其中放入硬性约束，不要放其他内容。冗长的指令文件不会报错，它们只是悄无声息地不再被遵守，这反而更糟糕。
Verify what actually loaded before you trust it
任何指令迁移后的失败模式都是静默的：智能体不会宣布它从未见过你的规则。放置好文件后，在仓库中打开一个会话，让 Codex 陈述它正在运行的指令，然后在子目录中工作并再次询问。如果你在某个子目录下工作时，该目录作用域的 AGENTS.md 没有显示出来，说明放置位置错了，你肯定希望在一分钟内发现这一点，而不是通过一个月里微妙偏差的 diff 才知道。
Don't confuse instructions with enforcement
这两个工具的指令文件都无法保证行为 —— 它们只是为提示词添加上下文。格式化、禁用的导入、受保护的文件和提交策略应该属于 linter、hook 和 CI。让指令文件解释原因，让工具来提供保证。
结论
从 GitHub Copilot 到 Codex 的迁移可以清晰地分为免费和非免费两部分。免费部分：AGENTS.md，两个工具都会在仓库的任何位置读取它，并遵循最近优先的优先级。非免费部分：仓库全局的 .github/copilot-instructions.md、路径作用域的 .instructions.md 文件（其 applyTo glob 必须转换为目录放置），以及 Codex 没有对应层级的组织级指令 —— 而且 /import 帮不上任何忙，因为它的目标是 Claude Code 和 Cursor。
因此，盘点所有四个层级（包括你管理员拥有的那个），手握删除键按来源进行分类筛选，将作用域重建为位置，并在信任它之前通读一遍组装好的结果。然后将这些规则背后的原因放入你的助手可以读取的统一存储库中，这样下一次切换就只是配置更改，而不是一次大动干戈的挖掘。如果你的目的地是 Cursor，Copilot 到 Cursor 的迁移路径涵盖了一个具有相反权衡的规则系统：真正的条件加载，以及它自身的转换成本。