MemoryLake
返回全部文章
Tutorial2026 年 9 月 2 日·10 分钟阅读

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

从 Manus 迁移到 Codex 在文件复制层面上并不困难。之所以困难,是因为数据形式的问题:Manus 生成的数据恰好有两种形式,而这两种形式都不是 Codex 能够读取的。

一种形式是可读的,但无法恢复。另一种形式可以恢复,但只能由 Manus 恢复到 Manus 中。这中间没有任何东西能承载你真正怀念的东西——你工作方式的累积上下文、你的项目是什么,以及已经做出了哪些决定。

本指南将坦诚地引导你完成这次迁移。哪些内容可以真正传输,哪些必须手动重写,Codex 会在何处以及何时提取(或不提取)这些内容,以及如何处理这两个工具都未设计用于移动的层。

需要明确的是:这是关于离开的指南。如果你在当前的系统服务变更期间尝试将数据导回 Manus,那是另一个具有不同风险的流程——请参阅 Manus 数据恢复没有截止日期但只有一次尝试。这里的任何内容都不会向 Manus 恢复任何数据。

实际传输的内容

首先来看看 Manus 给你提供了什么,用 Manus 自己的话来说。

可读的形式是纯文本导出。帮助中心对其限制的描述异常直接:“团队成员可以通过纯文本导出导出其任务数据的可读副本,但这与备份不同,不能用于导入或恢复任务数据。”

可恢复的形式是备份包。任务数据备份(Task Data Backup)“包含您的任务、生成的文件(如网站和幻灯片)以及配置数据”。它在您创建它的那一刻就被冻结了:“备份仅捕获生成那一刻的数据快照,不会自动同步新任务。”而且它是一个仅限 Manus 的产物——恢复路径会将其放回 Manus,而不是其他工具。

因此,真实的清单如下:

干净利落地传输。 您生成的文件——文档、幻灯片、网站、数据集。任何您可以阅读、复制和粘贴的内容。您自己编写的指令(如果您将它们保存在您控制的地方)。

只有重写才能传输。 您的知识库条目。您在数月内提供给 Manus 的常设偏好。Manus 从长任务线程中吸收的项目背景。所有这些都以可读形式存在,但没有一个以可导入的形式存在。

完全无法传输。 作为结构化状态的任务历史记录。已授权的连接器配置(文档称您必须手动重新启用)。Manus 推断出的任何内容,而不是被告知的内容。

在 Codex 方面,有一个真正免费的优势,以及一个在您寄希望于它之前值得了解的事情。

免费的优势是 AGENTS.md。Codex 在进行任何工作之前都会读取它,并且它是纯 Markdown 格式,因此您在文本编辑器中编写的任何内容都是 Codex 会读取的内容。这就是您必须重写的所有内容的落地平台。

需要了解的是:Codex 有一个导入器,而 Manus 不是其来源之一。根据文档,“桌面应用可以从 Claude CodeClaude CoworkCursor 导入。Codex CLI 可以从 Claude CodeCursor 导入。”如果您是从 Manus 迁移过来的,导入器并不是一个可以跳过的步骤。您的迁移在设计上就是手动的,这就是为什么值得深思熟虑地进行,而不是匆忙行事。

手动迁移

分为两个步骤,顺序很重要。在还能导出的时候,先把你的资料从 Manus 中拿出来,然后根据 Codex 实际组装指令的方式对其进行塑造。

步骤 1:导出一个可读的副本,并将其视为源材料而非备份

将您的任务数据导出为纯文本,并下载您仍然关心的生成文件。然后带着一个具体的问题阅读您获得的内容:这里哪些句子是指令,哪些是产物

产物是输出结果。将它们保存在您团队保存文件的任何地方。它们不是上下文。

指令是埋藏在您跨越数十个任务的提示词中的句子——您不断重复的纠正、您不断重申的约定、那些“不,我们总是这样做”的转折。这些才是迁移的核心。没有人有提取它们的工具,所以需要您自己去阅读并寻找。

两个注意事项。首先,如果您还在 Manus 的知识库中保留了条目,请单独导出这些条目,并将它们与您的导出进行核对,而不是假设它们包含在其中;知识库限制意味着许多团队随着时间的推移修剪了条目,不再记得里面有什么。其次,如果注销账户是您计划的一部分,请在按下任何按钮之前了解恢复机制——当前服务变更中的恢复没有截止日期但只有一次尝试机会,并且纯文本导出不能替代备份包。如果您还没有阅读,请阅读在注销前备份 Manus 数据

步骤 2:将其写入 Codex 实际读取的层,并按照 Codex 读取的顺序排列

Codex 从文件中组装指令,组装规则非常具体,以至于放置不当的文件根本不会被使用。

在全局级别,“在您的 Codex 主目录中(默认为 ~/.codex,除非您设置了 CODEX_HOME),如果存在 AGENTS.override.md,Codex 会读取它。否则,Codex 会读取 AGENTS.md。Codex 在此级别仅使用第一个非空文件。”这是一个文件,而不是它们的目录。

在项目级别,“从项目根目录(通常是 Git 根目录)开始,Codex 会向下遍历到您当前的工作目录。在路径上的每个目录中,它会检查 AGENTS.override.md,然后是 AGENTS.md,然后是 project_doc_fallback_filenames 中的任何备用名称。Codex 在每个目录中最多包含一个文件。”

然后它进行合并:“Codex 从根目录向下拼接文件,用空行连接它们。更接近您当前目录的文件会覆盖先前的指导,因为它们出现在组合提示词的后面。”

这给迁移带来了两个实际影响。第一,将通用的 Manus 时代约定放在根目录,将具体的约定放在更深的地方,因为更深层的约定会胜出。第二,注意上限:“Codex 会跳过空文件,并且一旦合并大小达到 project_doc_max_bytes(默认 32 KiB)定义的限制,就会停止添加文件。”如果一个团队将一年积累的 Manus 上下文全部倾倒进一个根目录的 AGENTS.md 中,可能会在无意中将后面的文件推到上限之外。文档本身的建议是“在达到上限时提高限制或将指令拆分到嵌套目录中”。

最后,决定如何处理 Codex 自身的记忆。它们确实存在,并且是选择性开启的:“本地 Codex 记忆默认关闭。”开启它们会在 ~/.codex/memories/ 下生成文件,这些文件“包括摘要、持久条目、最近的输入以及来自先前聊天的支持证据”。这很有用——但文档明确说明了它们不是什么:“将这些文件视为生成的临时状态。您可以在排除故障或共享 Codex 主目录之前检查它们,但不要依赖手动编辑它们作为您的主要控制界面。”并且指南明确指出了必需的规则属于哪里:“将必需的团队指导保存在 AGENTS.md 或签入的文档中。将记忆视为一个有用的辅助召回层,而不是必须始终适用的规则的唯一来源。”

换句话说,Codex 的记忆并不是您迁移的 Manus 上下文的归宿。AGENTS.md 才是。

更好的方法:将上下文保存在两个工具都不拥有的层中

步骤 1 和 步骤 2 可以帮您搭建起一个可运行的 Codex 环境。但它们也给您留下了一个您已经经历过一次的结构性问题:您刚刚重写的所有内容现在都存储在特定工具的文件约定中、特定的仓库中,而下一次迁移将是又一次手动重写。

这就是 Manus 导出的真实教训。迁移之所以痛苦,并不是因为 Manus 小气——文档很周详,导出也是真实的。而是因为“工具学到的东西”没有可移植的形式,所以它永远只能被阅读,而无法被移动。一个独立于这两个工具之外的记忆层正是赋予其可移植性的关键。MemoryLake 的设置只需三个步骤。

步骤 1:创建 API 密钥

登录并在您的控制面板中生成一个 API 密钥。这是您的智能体用于读取和写入记忆的凭证。它不绑定到 Manus 或 Codex,这正是关键所在:这个存储库的生命周期比当前摆在它面前的任何工具都要长。

在从 Manus 迁移到 Codex 时创建 MemoryLake API 密钥
在从 Manus 迁移到 Codex 时创建 MemoryLake API 密钥

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

这是手动迁移步骤 1 中的材料去往的地方。项目背景、常设约定、决策及其背后的推理、您团队使用的定义和名称。您从纯文本导出中提取的、属于指令而非产物的所有内容。

将 Manus 导出无法恢复的上下文上传到 MemoryLake 工作区
将 Manus 导出无法恢复的上下文上传到 MemoryLake 工作区

这样做,而不是将所有内容粘贴到根目录的 AGENTS.md 中。将 AGENTS.md 留给必须始终适用的规则,并将不断累积、增长的上下文主体放在这里——在这里它不会去竞争 32 KiB 的预算。

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

将 Codex 指向该存储库,无论您接下来使用什么,都可以获得相同的知识。如果您的部分团队在过渡期间留在 Manus 上——这是一个常见且合理的安排——双方都会读取相同的层,而不是在某个季度内渐行渐远。

通过 MCP 和 API 将 Codex 及其他智能体连接到一个共享记忆层
通过 MCP 和 API 将 Codex 及其他智能体连接到一个共享记忆层

这在实践中改变了什么

第一个差异会在第二周显现。在纯手动的迁移中,第二周是您发现自己忘记写下某些约定的时候,因为 Codex 做了旧配置从未做过的事情。而有了外部层,第二周就是您添加遗漏的三个约定,然后每个人都能获取它们的时候,而不是每个人都去修补自己的本地文件。

第二个差异是大小上限。AGENTS.md 文件非常出色,但也是有限的。必须始终适用的指令属于那里。而长尾内容——客户细节、过去的决策、词汇表术语、存在奇怪变通方法的原因——会无限制地增长,不应该放在一个会被拼接进每个提示词的文件中。

第三个差异是下一次迁移。Codex 不会是您团队使用的最后一个工具。您今天所做的迁移之所以代价高昂,是因为上下文被锁定在了一个无人能移动的形式中。下一次从存储库而不是从纯文本导出中进行迁移,其差别就像是一个庞大的项目与一个下午的工作。

从 Manus 迁移到 Codex 的最佳实践

  • 在更改其他任何内容之前先导出。 纯文本导出第一,产物第二,注销决定最后。导出是可读的,而不是可恢复的,所以它是一个工作副本——而不是安全网。
  • 阅读您的导出以寻找指令,而不是内容。 价值在于您纠正 Manus 的句子中,而不是它产生的输出中。
  • 根目录 AGENTS.md 用于始终适用的规则;嵌套文件用于特定规则。 更深层的文件出现得更晚,并且会覆盖先前的指导。
  • 注意 project_doc_max_bytes 32 KiB 的默认值很宽裕,直到您粘贴进一年的上下文。请刻意提高它或跨目录拆分。
  • 不要将 Codex 记忆视为您的控制界面。 根据厂商自己的描述,它们是生成的临时状态;必需的规则属于 AGENTS.md 或签入的文档。
  • 手动重新启用连接器并验证每一个。 Manus 的文档明确指出,已授权的连接器不会自动恢复,您接入 Codex 的任何内容也是如此。
  • 在两个工具之外保留一份项目知识的规范副本。 如果您发现自己将同一段落粘贴到两个仓库的两个文件中,那么该段落应该放在其他地方。将项目文档转化为 AI 记忆介绍了其机制。

结论

从 Manus 到 Codex 的迁移是手动的,本季度任何工具都无法改变这一点:Codex 的导入器读取的是 Claude Code、Claude Cowork 和 Cursor,而 Manus 的导出在设计上是可读的,而不是可导入的。

您可以改变的是您是否还要再经历一次。一旦您重写了它们,文件可以传输,产物可以传输,指令也可以传输。累积的上下文才是昂贵的部分——而停止为此重复买单的唯一方法,就是停止将其存储在当前恰好在使用的任何工具内部。

常见问题

我可以直接将我的 Manus 数据导入 Codex 吗?

不可以。Codex 的导入器在桌面应用中支持 Claude Code、Claude Cowork 和 Cursor,在 CLI 中支持 Claude Code 或 Cursor。Manus 不是其来源,且 Manus 自己的文档指出,纯文本导出“不能用于导入或恢复任务数据”。请计划手动重写到 AGENTS.md 中。

Manus 备份包对这次迁移有用吗?

对于迁移到 Codex 来说没有用。任务数据备份会恢复到 Manus 中,并包含任务、生成的文件和配置数据。对于迁移,您需要的是纯文本导出,因为它是可读的。如果注销账户是您计划的一部分,无论如何请保留备份——这是一个独立的决定,有其自己的一次性尝试恢复机制。

我应该开启 Codex 的本地记忆吗?

它们很有用,且默认关闭,因此这是一个刻意的选择。为了召回的便利性可以开启它们,但不要将您的 Manus 上下文迁移到其中。文档将这些文件描述为生成的临时状态,并建议将必需的团队指导保存在 AGENTS.md 或签入的文档中。

在 AGENTS.md 停止工作之前,我可以放入多少内容?

一旦合并大小达到 project_doc_max_bytes(默认 32 KiB),Codex 就会停止添加文件。这是在整个拼接链中针对每次对话计算的,因此一个非常大的根文件可能会挤占嵌套文件。请在配置中提高限制,或跨嵌套目录拆分指令。

我的 Manus 知识库条目会怎么样?

它们可以通过导出进行阅读,但没有导入 Codex 的路径。将它们视为您需要重写的源文本。由于许多团队在达到知识库限制时修剪了条目,请检查里面实际有什么,而不是假设您的导出涵盖了它。

Codex 会记住我在过渡期间做出的纠正吗?

只有在您告诉它,或者您启用了本地记忆的情况下才会记住——而且在任何一种情况下,必须始终适用的纠正都属于 AGENTS.md,而不是召回层。如果您希望它们在您下一次更换工具时也能保留下来,请将它们保存在不绑定到单一厂商文件约定的存储库中。请参阅编码智能体实际读取的内容以了解这些层是如何对比的。