一台测试用 DGX Spark 要归还给提供方。它不是自己的正式设备，不能把整套系统当成个人机器随手恢复出厂；但也不能带着自己的会话、配置和凭据痕迹还回去。更麻烦的是，之后可能还会采购同样机型，当前这段工作现场最好能在新机器上接回来。
所以这次要做的不是“清空一台机器”，而是先把用户态工作现场带走，再把原机上和自己有关的痕迹清干净。备份只覆盖可迁移的工作上下文、配置、脚本和必要凭据材料，不试图复制整套系统。
用户态备份不是复制整机，而是把可验证的工作现场、归档链和清理边界留住。
如果只求省事，恢复出厂当然最简单。但这样会把后续恢复所需的线索一起抹掉。后面真拿到同型号机器时，重建现场只能靠印象：哪些配置改过，哪些东西跑通过，哪些材料要迁，哪些东西其实不用搬。最麻烦的不是少一个文件，而是不知道少了什么。
留现场，不留整机
这次没有做全盘备份。
全盘备份看起来完整，但在这个场景里会把事情弄混。DGX Spark 上的驱动、容器、模型、服务、环境和系统组件，很多都属于基础设施。它们和硬件、系统版本、安装顺序绑得很紧，体积也不小。把它们全塞进备份包，会让包看起来可靠，未来恢复时却更难判断：现在是在恢复用户工作，还是在试图复制一台旧机器？
用户态备份的目标更窄：留下“这段工作如何继续”的材料。
进包的是近期工作和用户态上下文：AI 工具和编辑器配置、必要的项目材料、会话与凭据相关材料，以及 manifest、清理脚本、验收脚本和恢复说明。
不进包的是基础设施和可重建的大块内容：模型、服务本体、虚拟环境、依赖目录、构建产物和通用缓存。未来新机要先把底座搭起来，再把用户工作接回去。
划这条边界不是为省空间。目的是让恢复时知道自己到底在做什么。
先带走，再清理
交还机器最容易出问题的地方，是备份和清理互相抢跑。
备份还没离开原机，就开始删用户目录，这是赌。备份文件复制走了，但没校验，也还是赌。归档能解密，但没看目录，仍然不够。真正能让人放心的顺序应该更慢一点：备份包先离开原机；在另一台机器上校验；确认能只读列出目录；再回到测试机做清理。
这一步并不华丽，但很要紧。它把“我大概备份好了”变成几个可以停下来的检查点。通过之后，再谈删除，心理负担会小很多。
Plan Mode：人机对齐再动手
准备阶段用的是 Plan Mode。不是为了显得正式，而是因为这件事一开始就不该直接执行。
当时的互动不是“Codex 给出计划，我照做”。更像两个人在一张危险操作清单前互相挑错。
Codex 先把任务拆成几段：确认要保留什么，生成备份，生成 manifest，准备清理脚本，准备验收脚本，再写恢复提示。这个方向是对的，但我很快提醒了一次：如果清理动作把 Codex 自己的会话、配置或运行环境先干掉，后面的验证脚本可能就没法继续在原机上执行。也就是说，agent 不能只盯着“清理干净”，还要考虑自己会不会破坏后续验证链。
这个提醒让计划收紧了一层：Codex 可以生成脚本，可以做清理前验证，可以把验收逻辑写好，但不能把自己放到“清理后还必须继续工作”的位置上。清理包要能独立存在，普通终端要能执行，验收脚本也要能脱离 Codex 会话跑完。
后来我又提醒了一次：清理脚本真正执行时，应该由人来跑，不应该由 Codex 直接在会话里运行。原因很朴素，删除动作不可逆。Codex 可以把 dry-run 设计得清楚，把将要删除的路径和进程打印出来，也可以解释这些输出；但从 dry-run 进入真正执行，应该回到普通终端，由人确认备份已经验证，再手动敲下去。
几轮来回之后，计划才真正落地。Codex 负责把边界和证据链写完整，人负责在危险动作前踩住刹车。
Codex 的角色：划清边界
这次 Codex 做得最有价值的，不是某一条命令。
它适合把边界写清楚。
哪些目录是近期工作，哪些是基础设施，哪些是敏感凭据，哪些只是大型缓存。这些判断人也能做，但现场细节一多，边界就容易被反复打断。基础设施从一开始就排除在备份之外；真正需要细看的，是会话材料、项目状态和凭据痕迹这些用户态内容。最后如果没有清单约束，备份边界和清理边界都会慢慢变糊。
Codex 的作用，是把这些判断写成可检查的材料。manifest 说明包里有什么，清理脚本说明哪些痕迹要删，验收脚本反过来检查这些痕迹是否还在。三者互相咬合，才不容易靠记忆硬撑。
它也适合维护证据链。归档、校验文件、清理包、恢复说明，不是散落的几个文件，而是一组互相证明的材料。清理前必须能回答：备份是否已经离开原机，校验是否通过，是否能只读看见目录，清理脚本默认是否只是 dry-run，验收脚本是否能检查残留。
这些细节不难，但归还时最容易漏。
恢复不是覆盖
备份-恢复脚本默认的场景，是之后拿到一台足够同构的新机器：同样的硬件平台，接近的系统版本，用户名和目录结构也一致。这个前提下，恢复说明可以写得更直接，目标是把用户态工作现场接回原来的位置。
即便如此，恢复也不应该一上来就覆盖。备份包里包含工具配置、登录凭据、会话资料和部分自动化环境，应该先当成敏感包处理。先校验，再解到 staging 目录，看 manifest，确认要接回哪些材料；等新机的基础设施已经重建，再选择性同步到用户目录。
如果之后拿到的新机器不是严格同构，也可以走更保守的方式：只把 staging 当作素材库。需要哪个项目、哪段配置、哪份脚本，就单独拿出来检查和合并。这样慢一点，但不会把旧机器上的假设整包带到新环境里。
用户态备份的好处就在这里。它不是把旧机器整个压到新机器上，而是给未来的自己留一份可以挑选、可以审计、可以接续的工作现场。
离场方式比备份包更重要
Agentic Ops 不该只看“agent 能自动做多少事”。这次真正有价值的，是 Codex 被放在合适的位置上：它整理现场、生成材料、维护约束，但不替人完成最终删除。
它把模糊的交还焦虑拆成边界、文件、脚本、校验和人工确认点。备份、清理、验证三份材料要互相能对上。恢复说明要和归档格式一致。敏感材料要始终留在加密和受控的流程里。
我做的其实是反复挑刺，Codex 负责把每次提醒变成计划里的约束。提醒它不要把自己清掉，提醒它真正清理要由人执行，提醒它凭据材料不能脱离受控流程。每提醒一次，计划就多一层实际操作该有的限制。
最后留下的核心是离场顺序：保现场，再清机器；只读验证通过，再删除；未来先 staging，再恢复。机器可以归还，第一现场的 Codex 会话也可以消失，但这套流程还能被下一台机器接住。