Manus 的官方说明
您实际使用的时区对应的日期
Manus 公布了三种时区的转换，这非常贴心，以下是官方声明的具体时间。
备份窗口： 现已开启，持续至 2026 年 8 月 22 日晚上 7:59 (EDT) / 8 月 23 日凌晨 1:59 (CEST) / 8 月 23 日上午 7:59 (SGT)。
删除时间： “自 2026 年 8 月 23 日上午 8:00 至 8 月 24 日 (SGT) 期间。”
恢复入口开启时间： 2026 年 8 月 24 日晚上 8:00 (EDT) / 8 月 25 日凌晨 2:00 (CEST) / 8 月 25 日上午 8:00 (SGT)。
中间的间隔期是无法避免的。 “一旦备份窗口关闭，受影响的用户在数据恢复入口开启之前将无法访问其 Manus 账户。”Manus 预计“受影响的用户将失去访问权限两天 —— 从 2026 年 8 月 23 日至 8 月 24 日 (SGT)。”
谁会受到影响，以及您将如何收到通知
仅部分用户和部分数据受到影响：范围是“某些用户在 2025 年 12 月 29 日或之后产生的数据”。常见问题解答（FAQ）解释了这一日期 —— “2025 年 12 月 29 日，Meta 收购了 Manus。某些用户在 Meta 收购 Manus 之后产生的数据需要被删除，以遵守特定司法管辖区的监管要求。”
通知将通过 Manus 应用和电子邮件发送，但 Manus 自身也指出了一个特定的漏洞：“对于使用 Apple ID 或 Facebook 账户注册 Manus 的用户，请检查您的应用内通知，因为我们没有您的电子邮件地址。”如果您是通过这些方式注册的，电子邮件将无法送达。Manus 还表示，它将“在 8 月 23 日上午 7:59 (SGT) 之前向您发送多次提醒”，并提供了一份帮助中心指南，用于检查您自己的账户是否受到影响。
未受影响的用户：“未受影响的用户在此期间可以照常使用 Manus，无需采取任何行动。”他们不会收到电子邮件，只会收到一条应用内通知，确认他们未受影响。
备份工具的作用 —— 以及人们会忽略的细节
Manus 表示，它开发了“数据备份和恢复工具，以使受影响用户的这一过程尽可能简单”。重要的操作细节是：“备份工具支持多次备份。如果您在备份后产生了新的任务数据，请重新备份，以确保在 2026 年 8 月 23 日至 8 月 24 日 (SGT) 删除之前保存最新数据。”
因此，您今天运行的备份并不涵盖您明天的工作。如果您在窗口关闭前的几天里仍在积极使用 Manus，那么最后一个有用的操作就是再次备份。请在 8 月 22 日设置一个提醒。
Manus 在此窗口期间也免除了费用 —— “在数据备份期间（8 月 11 日至 8 月 23 日，SGT），我们不会向受影响的用户收费” —— 并表示将在“您恢复数据后提供欢迎回归奖励”。
这不是什么
这一点值得明确说明，因为关于计划删除数据的标题很容易让人产生误解。当被直接问及这是否由于数据泄露引起时，Manus 回答道：“不。这一措施源于 Manus 转型为独立运营并遵守监管要求。这并非任何安全事件的结果。”
关于此后数据的存放位置，Manus 表示其数据存储在美国和新加坡，并指向其信任中心以获取处理细节。
备份涵盖了什么，以及没有涵盖什么
该工具履行了它的职责：您的 Manus 数据被导出，并在 8 月 25 日之后重新导入。这为您带来的是账户的连续性 —— 您的任务和产出物（artifacts）会回到它们原本的位置。
但它无法带给您的是知识的可移植性。这会带来两个后果，而其中只有一个是关于本周的。
在为期两天的停机期内，工作并不会停止。 无论您的 Manus 智能体学到了关于您项目的什么知识 —— 限制条件、决策、您已经否决的方法 —— 都保存在一个您无法打开的账户中。如果您在这两天里使用其他工具继续工作，您将不得不从零开始，因为您的项目上下文和您的 Manus 账户是绑定在一起的。
而普遍情况才是重点。 旨在恢复到单一产品中的备份格式，从定义上讲，并不是任何其他产品都能读取的格式。每个助手都是如此，而不仅仅是 Manus：记忆在帮助您构建它的工具内部积累，因此工具的可用性就变成了您知识的可用性。本周只是恰好给这件事定了一个日期。如果您曾感受过这种体验的轻量版，这就是 Manus 遗忘项目历史 以及 Manus 遗忘研究笔记 在运行之间发生的原因。
人们会采取的替代方案
运行备份，并祈祷这两天相安无事。 这很合理，如果您的 Manus 工作本周不在关键路径上，这行得通。但在做出假设前，请先检查您的日历。
对重要任务进行截图。 速度很快，但它生成的图片无法被任何工具查询。对于两天的间隔期来说，这聊胜于无；但作为工作流程，它毫无用处。
在此期间向第二个助手重新解释一切。 这是大多数人实际会做的事。这是对您已经付出过一次成本的上下文进行完全重新推导，而且当 Manus 恢复时，这些努力就会被丢弃。
将结论复制到文档中。 直觉是对的，但载体错了。一个没有工具读取的文档只是一个归档；您最终还是需要手动将其重新读给聊天窗口。
永久迁移到另一个工具。 这对于一个有记录、有时间限制的过渡来说有些反应过度 —— Manus 已经明确说明了机制并承担了费用。如果您本来就在进行迁移，将 Manus 迁移到 ChatGPT 和 将 Manus 迁移到 Claude 涵盖了这些路线；但仅因为两天的维护窗口就迁移，理由并不充分。
解决方案：将知识保存在停机期无法波及的地方
进行官方备份 —— 这是必不可少的，这里没有任何内容可以替代它。然后花二十分钟做一件让下一次类似事件变得微不足道的事：写下您的智能体所知道的内容，并保存在不属于任何单一账户的地方。
这就是 MemoryLake 的作用：一个供您的助手读取的记忆层，保存您项目的持久知识，而不受今天哪个工具可用的影响。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建一个 API 密钥。一个凭证即可跨越您连接的所有工具 —— 并且刻意不与您当前正在备份的账户绑定。
步骤 2：上传您的第一批记忆
在您仍有访问权限时，梳理您活跃的 Manus 工作，写出知识而不是产出物。任务和输出是备份工具处理的内容；而它无法传递给其他任何工具的是推理过程。记录以下内容：
决策及其原因。 您最终决定了什么，以及使该决定成为答案的限制条件。
否决方案。 您在 Manus 中尝试过但没有成功的方法，以及原因。这是价值最高的一类，也是重新探索成本最高的一类 —— 每一个全新的智能体都会再次提出它。
看似随意的限制条件。 截止日期、数据限制、客户要求、限流方式与文档记录不同的 API。
您重复过的纠正。 任何您不得不对智能体说一次以上的内容，都是一个正在宣告其存在的缺失记忆条目。
保持条目简短 —— 每条只写一个断言，陈述清晰。花二十分钟做这件事，效果胜过花一个多小时去截图。
步骤 3：连接您的 AI 和智能体
连接您使用的工具。MemoryLake 可以通过 MCP 和 API 访问，因此原生支持 MCP 的智能体（包括 Claude Code、Codex 和 OpenClaw 等）可以通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。这样，这两天的间隔期就只是工具停机，而不是知识断档：您可以在其他地方使用相同的上下文继续工作，当 Manus 在 8 月 25 日恢复时，您可以无缝接轨。
三个坦诚的限制，它们在本周至关重要。MemoryLake 不是 Manus 备份工具 —— 它无法导出您的 Manus 任务，无法恢复它们，也不能替代在截止日期前运行官方备份。它只保存您或您的智能体写入其中的内容。此外，它也不是一个合规或数据保留系统。
这在实践中改变了什么
计划内的停机不再意味着工作停摆。 当上下文不在账户中时，两天没有账户也是可以度过的。
企业事件不再是您的问题。 收购、拆分、区域合规性变化、方案迁移 —— 这些都发生在整个行业中，且遵循别人的时间表。保存在任何单一供应商之外的知识不会受到这些事件的影响。
重新解释不再是备用方案。 应对中断的默认计划是凭记忆向第二个助手进行简要介绍。当这些介绍已经被写下来并且可以检索时，第二个助手在开始时就已经掌握了信息。
恢复日的速度更快。 8 月 25 日之后，您不必重建 22 日正在做的事情 —— 无论任务发生了什么，推理过程都已被记录下来。
工具选择重新变回一种偏好。 人们之所以觉得被绑定在某个助手上，是因为积累的上下文，而不是功能。将上下文移出，才能让下一次选择变得自由 —— 正如 知识工作者的跨工具记忆 中所描述的那样。
截止日期前的最佳实践
首先检查您是否受到影响。 Manus 为此提供了一份帮助中心指南。不要因为没有收到消息就默认未受影响 —— 特别是如果您是用 Apple ID 或 Facebook 注册的，因为 Manus 表示在这种情况下他们没有您的电子邮件地址。
现在备份，然后在 8 月 22 日再次备份。 该工具支持多次备份，且 Manus 明确要求您在生成新的任务数据时重新运行它。窗口关闭前的最后一次备份才是最重要的。
将截止日期设定为您自己的时区。 2026 年 8 月 22 日晚上 7:59 (EDT) / 8 月 23 日凌晨 1:59 (CEST) / 8 月 23 日上午 7:59 (SGT)。将其放入您的日历中，并留出两小时的缓冲时间。
规划好这两天，而不是到时候措手不及。 将任何依赖 Manus 的工作移出 8 月 23 日至 24 日 (SGT)，或者确保您可以在其他地方完成。
在失去访问权限之前写下推理过程，而不是之后。 任务会在 25 日恢复。但推理过程从未包含在任务中。
不要恐慌性迁移。 这是一个有记录、有时间限制的过渡，机制已公布，费用已免除，工具已提供。将其视为一次维护即可。
吸取教训，而不仅仅是采取行动。 一旦您将项目知识写在可移植的地方，这类事件就根本不再需要您做出任何应对。
结语
Manus 对此事的处理几乎可以说是被迫删除数据情况下最好的示范了：公布了三个时区的具体日期，构建了专门的备份和恢复工具，在窗口期内免除费用，多次发送提醒，并直接回答了这并非安全事件。如果您受到影响，请运行备份 —— 并在 8 月 22 日再次运行，因为自您上次备份以来的新工作将不被涵盖。
本周之后值得记住的是结构性的问题。备份是将您的数据恢复到 Manus 中，这意味着在这两天里，您项目积累的上下文的可用性完全取决于您的账户是否可用。这并不是 Manus 的缺陷，而是每个助手里记忆的运作方式。花二十分钟将决策、限制条件和否决方案写在可移植的地方，就能让下一次计划内的停机（无论发生在何处、哪个供应商）变成您只是在新闻中读到的事情，而不是您需要为此调整计划的麻烦。