如果明天 Codex 账号突然用不了，手上的工作还能继续吗？
最近考虑账号风险时，我发现自己更在意几样东西：反复解释过的工作背景、已经确认的项目决策，以及做到一半的任务。换一个 AI 工具，文件也许还在，但这些信息需要重新组织。哪些是草案，哪些已经确定，下一步该做什么，都得再说一遍。
于是，我和 Agent 一起做了一次小实验：保存 Codex 的新会话与工作文件，通过 OpenViking 共享背景，再让另一套 Agent 运行工具 DeepSeek Harness 接着做。下面简称它为 DSH。
这套做法只能降低账号不可用后的损失和中断风险，不能降低被封号的概率。本文也不讨论封号原因。我想确认的是：换一个工具后，资料能恢复，工作能接上吗？
先分清要保住什么
最开始，很容易把“备份 AI”理解成导出聊天记录。
原始记录确实要保存。它能说明一个判断怎样形成，也能找回摘要里被省略的条件。但让新 Agent 重新读完所有聊天，成本很高。即使读过，它也未必分得清，前面某个方案后来是否被否定。
反过来，只保存记忆摘要，也有缺口。摘要经过筛选和压缩，适合快速理解背景，却不能代替原文，更不能凭一句“已经完成”判断实际文件是否交付。
我把这次方案分成三部分：
| 部分 | 保存什么 | 用什么结果验收 |
|---|---|---|
| 原始备份 | 会话原文、工作文件、交付产物 | 能在新目录恢复，并核对文件内容 |
| 共享记忆 | 偏好、项目背景、已确认决策及来源 | 新 Agent 能找回相关信息 |
| 任务交接 | 当前版本、已完成事项、下一步、阻塞项 | 接手者依据正确版本完成后续动作 |
这三个结果需要分别检查。记得项目背景，不等于知道最新进度；能读到任务摘要，也不等于拿到了原始文件。
图1：原始备份、共享记忆与任务交接，各自保存不同信息。
OpenViking 放在哪一部分
OpenViking 是面向 Agent 的上下文数据库，可以组织资料、记忆和技能，并提供检索。放到我的方案里，它主要负责让不同客户端找到需要的背景。
这里的“共享”也有两种来源。一种是主动放进去的项目资料，例如交接文件；另一种是从会话中提取的长期记忆。资料能够检索，不代表对应信息已经变成长期记忆。官方会话说明
Agent 接入同一个服务以后，仍要检索、读取，再把相关内容放进当前上下文。普通 MCP 连接提供可调用工具；每轮自动采集、启动时自动召回等行为，还依赖客户端插件和生命周期事件。官方接入能力对照
因此，不能只看工具列表里出现了 OpenViking，就认为备份和共享都已完成。
本次检查还发现，我的共享配置里，自动采集、自动召回和 MCP 当时处于关闭状态。实验是在独立配置中显式启用这些能力，没有修改全局设置。这意味着，下面的结果证明测试链路可行，不能据此宣称日常所有客户端已经自动同步。
我实际验证了哪些事情
这次只用新建的虚构测试项目，没有导入历史会话，也没有重放旧积压队列。Codex 和 DSH 使用隔离的状态与队列目录。
先看原始资料能不能恢复。
测试让 Codex 生成一份采购清单和交接文件。备份时，只读取允许清单中的文件，保存按日期区分的快照，并为每个文件记录 SHA-256 校验值。它可以用于比较恢复前后的字节是否一致。
随后，把原始目录暂时改名，让恢复程序无法从原位置取文件，再恢复到一个全新的目录。8 个文件全部通过校验，其中包括本次 Codex 原始会话和工作文件。
还做了反向检查：篡改副本中的样本文件后，恢复程序拒绝继续；目标目录已经存在时，也不会覆盖原内容。
这证明了本次快照能够独立恢复。它没有证明全部历史已备份，也没有模拟真实封号，更没有覆盖整台电脑损坏的情况。
再看新 Agent 能不能找回记忆。
我另开一次 Codex 会话，让它记录两项只属于测试项目的固定约定，包括一个专用校验短语。这些信息没有写进共享交接资料，也不是实际业务规则。
运行日志记录了 Codex 自动采集消息、在会话结束时提交。云端任务完成后，记忆变更审计确认新增了 1 条测试项目记忆。
接着启动全新 DSH 会话，只给项目名并询问约定，没有把答案放进提问。DSH 插件自动注入了对应记忆，它正确回答了两项内容；本轮工具调用为 0，没有读取本地文件。
这条证据比“模型说它记住了”更具体：信息被采集、提交、提取，最后进入另一客户端的新会话。DSH 本次使用的是 DeepSeek 账号模型路由，也没有继续调用 Codex 模型。
最后看它能不能继续完成任务。
虚构清单里有两项采购：6 本笔记本，每本 19 元；4 个收纳盒，每个 27 元。合计 222 元，预算 300 元。Codex 的 v1 交接写明，下一步是核对清单、计算余额并生成回执。
接手的 DSH 没有收到整段背景粘贴。它拿到的是资源位置、版本与校验信息，以及从备份恢复后传入的原始清单。
它通过 OpenViking 精确读取任务索引和交接正文，确认版本一致，再核对清单的 SHA-256，独立复算金额，生成了余额为 78 元的回执。随后，由维护脚本验收并把任务更新为 v2“已完成”，保留 v1 和原回执。
图2：原始清单经备份恢复传递，交接索引与正文通过 OpenViking 精确读取。
这次验收的是一个很小的接续任务，不能推导出复杂项目可以无损迁移。但它至少验证了：新 Agent 可以沿着明确的交接记录继续执行，而不只是复述背景。
两个容易被“成功”掩盖的问题
第一个问题出在记忆提取。
前面的采购任务已经自动提交，云端处理也完成了，但变更审计显示新增记忆为 0。后面专门记录固定约定的样本，才确认提取出新记忆。
所以，提交成功、处理完成、产生记忆，需要分别看证据。重要的已确认决策，我会保留明确的项目文档，不能把是否留下记录完全交给自动提取。官方提取与审计机制
第二个问题出在文件内容。
本次导入云端的 Markdown 和 JSON 被重新解析，检索副本的结构、排版与本地原件不同。因此，DSH 核对的采购原件来自恢复后的文件，没有用云端解析文本重新生成。
原始备份保留可追溯的字节，解析副本帮助查找和理解，两者需要保留来源关系。校验值能发现意外损坏；如果有人同时改写文件和校验清单，它并不能代替可信签名。
接续过程也有运行条件。本次使用的 DSH headless 配置模板默认禁用了部分凭证与授权服务。headless 指无界面的命令行运行模式。补齐隔离配置后，已有 DeepSeek 登录才正常工作。资料共享得再完整，接手方仍需要可用的模型、工具和执行权限。
先做一次小恢复，再扩大范围
如果要照着尝试，我建议先选一个不敏感、能检查结果的小任务，走完这条路径：
- 保存原始会话和产物，暂时让源目录不可用，再恢复并核对。
- 写一份交接记录，至少包括目标、版本、已确认决策、产物位置、下一步和未知项。
- 换一个全新客户端，让它读取指定版本，完成一个后续动作，再由人检查产物。
共享范围也要核对。OpenViking 区分共享资源、用户记忆和项目范围；连接同一个地址，不等于所有用户都能读到彼此的私人记忆。本次验证只涉及我自己的两个客户端，没有验收多人权限和并发任务协调。官方共享边界
目前，我还不能把这件事叫作完整的备份方案：独立存储副本没有完成，云端整库恢复没有验证，桌面端完整生命周期也没有覆盖。OpenViking 官方提供导出和备份机制，但具体云服务是否开放、恢复范围如何，需要另外实测，不能把文档中的能力当作自己的验收结果。官方备份说明
图3：本次小样本验证范围，以及仍需补齐的备份与运行条件。
这次自动运行的是会话采集、提交、记忆提取和上下文注入。备份、恢复、资料同步、原始文件传递及任务状态更新，仍由手动启动的脚本完成。
接下来，我会先补独立存储副本和日常运行验证，再逐步纳入真实项目。封号只是促使我检查这件事的一个原因。换平台或同时使用多个 Agent 时，也可以复用同样的交接过程；前提是每一步都能拿出恢复和接续的实际结果。