持久化 Coding Agent Session 的价值，不是让一个进程永远不停止，而是让下一次工作能够找回真正重要的状态。这里的“状态”并不只有一种：对话、已保存文件、正在运行的进程、Preview 和交接说明，各自都有不同的生命周期。
在 Agent.Space 中，Workspace 是持续保存项目的边界。Session、已保存文件、Preview 与团队上下文都归在同一个 Workspace 中，每个 Agent harness 则在自己的 Session 里工作。但“持久化”不表示所有进程都会永久运行，也不表示一个 Agent 会自动获得另一个 Agent 的隐藏推理。Agent.Space 如何让项目持续推进一文解释了这套基本结构。
“持久化”至少包含五种不同状态
判断 Coding Agent Session 能否恢复之前，先明确你真正要找回的是哪一种状态。
这些状态相互关联，却不能彼此替代。源文件已经保存，不代表开发服务器还在运行；Preview 可以打开，也不代表改动已经 Review；一段很长的对话，也不能代替一棵可检查的项目文件树。
Session、Workspace 与 Runtime 是三个不同层级
Session 用一个 Agent harness 承载一个持续任务。可见对话、请求和该 Agent 的具体工作会组织在这里。
Workspace 是共享的项目容器，保存成员、Session、已保存文件与工作上下文。在同一个 Workspace 里启动新 Session，下一位 Agent 可以直接检查当前项目，而不用先把文件搬到另一个容器。
Runtime 是任务执行时使用的运行环境。开发服务器、构建进程、内存缓存或其他实时进程都可能存在于其中。Runtime 停止后，已经成功保存的 Workspace 文件仍会保留；只存在于内存里的进程状态，则应视为临时状态，需要时重新启动。
由谁负责这个 Runtime，是另一个独立的架构选择。决定使用 Provider 托管还是自行运维前，可以先比较 Managed Agents 与自托管 Agent SDK。
分清这三层，可以避免两个常见误解：
- 看到进程停止，就误以为项目文件也消失了；
- 看到文件还在，就误以为所有进程、端口和临时值都会自动恢复。
可靠的事实源应当是已保存项目与可复现的启动说明，而不是某一个进程是否还活着。
工作环境发生变化时会怎样？
关闭浏览器
浏览器标签页不应该成为工作唯一的存放位置。重新打开 Workspace 后，应检查当前 Session、Queue、文件和 Preview 的真实状态，不要默认离开前最后看到的画面仍然是最新结果。
如果当时有 Turn 正在执行，先确认它现在的状态，再决定是否重新发送请求，避免重复任务。如果文件曾在尚未完成的操作中被编辑，也要确认预期版本是否真正保存。
Workspace Runtime 停止
已经成功保存的项目文件仍然可用；进程和监听服务可能需要重新启动。应记录工作目录、启动命令、必要配置，以及能够证明环境已恢复的 Health Check。
只存在于内存里的状态、未保存的编辑缓冲区、临时 Credentials 与本地进程输出，都应当视为不持久，除非工作流明确把它们安全地保存到了合适位置。
更换 Agent harness
在同一个 Workspace 中启动新 Session。新 Agent 可以检查已保存文件和明确的交接材料，但不会自动继承上一个 Agent 的私有推理，也不会把原 Session 直接变成“只是换了个名字的同一段对话”。
如果需要把已有本地任务带到云端，应使用单独的Codex 与 Claude Code 对话导入流程。导入后的对话仍与来源 Agent 绑定；导入并不是在不同 harness 之间传递隐藏上下文的通用手段。
团队成员接手
交接时要提供证据，而不只是留一句“差不多做完了”。Agent 之间接力时也一样。一份可靠的Coding Agent 团队交接应明确：改了什么、检查过什么、哪里仍不确定，以及下一步由谁负责。
长任务恢复检查清单
结束这次工作前，至少留下让下一位参与者无需猜测就能重新开始的材料。
- 保存目标项目文件。 确认重要产出已经进入 Workspace 文件树，而不是只停留在聊天回答或进程内存里。
- 说明当前结果。 用直白语言写清哪些已经完成，哪些只是建议或计划。
- 记录验证情况。 写明运行了哪些检查、结果如何，以及哪些内容尚未测试。
- 保存重启路径。 记录工作目录、启动命令、配置前提和成功信号。
- 标明被审阅的版本。 代码项目优先使用版本控制证据；其他项目则写清被检查的文件或产物。
- 列出风险与待决定事项。 未确认的产品选择和工程缺陷不是一回事，应分别标注。
- 指定一个有边界的下一步。 下一 Session 应只有一个明确任务，并带有完成标准。
一份简短的 HANDOFF.md、Task Brief 或结构化的 Session 结束说明，都可以承载这些信息。格式不是重点，重点是信息可检查、可理解，而且反映当前状态。
会话中途遇到额度限制或反复出错时，可以按切换 Agent 的交接方法继续：先停旧的写入者，保存未提交修改，再核对接收方交出的第一个结果。
不要假设这些内容会自动恢复
持久化 Coding Agent Session 不会消除正常的工程边界。不要默认：
- 所有后台进程都会无限期运行；
- 未保存改动会在 Runtime 重启后保留；
- 临时 Preview 等于稳定的正式发布；
- 新 Agent 能看到另一个 Session 的隐藏推理；
- 两个并行 Session 天然拥有隔离分支或自动冲突解决；
- Preview 能打开，就等于测试、权限、安全与发布检查都已通过；
- 一段对话就是项目的完整备份。
如果项目确实需要其中某项能力，就把它显式加入工作流：保存对应产物、使用版本控制、在合适时建立稳定 Release，并从下一位参与者的视角重新验证结果。
让 Workspace 成为中心，而不是某个运行中的进程
真正有用的持久化，不是“任何东西都不会停止”，而是项目可以从稳定、清楚的证据继续。把源文件、决定、验证与下一步放在一起；把 Runtime 进程当作可重现的执行环境；同时保持 Agent 边界清晰。
可以先在 Agent.Space Workspace 放入一个边界明确的任务。离开前问自己一个问题：另一段 Session 只看当前文件与说明，能不能恢复到现在的结果？如果答案是“能”，这项工作才算真正可以继续。