大家是如何处理长时间运行的代理的状态的？无状态沙盒正在吞噬我的夜晚

好吧，我想知道是否只有我这样。我一直在本地用 qwen3 coder 在一个 4090 机器上运行编码代理，并配有一个远程沙盒来实际执行代码。每次沙盒挂了（空闲超时、宿主机重启等），我都会丢失整个工作目录、已安装的依赖项以及代理构建的任何进程状态。这不仅烦人，而且耗费实际时间。昨晚为一个代理已经迭代了两周的项目计时了一次恢复周期：pip install 仓库依赖：33 秒；模型预热和上下文重载：38 秒；从 S3 恢复工作目录（因为我不得不编写自己的检查点层）：17 秒；加上几秒的编排胶水代码。总共 91 秒，代理才能开始下一步。如果是新会话，这没问题。但对于一个长期运行项目的第 14 次恢复，这让我想把机器扔出窗外。直观的思路是把沙盒当作一个持久化的 Unix 机器，永远不让它死掉。但我看过的每个提供商都有某种超时机制。e2b 暂停的沙盒会在 30 天后删除，暂停时间大约每 GB 内存 4 秒。Modal 的内存快照 7 天后过期，而且仍处于 alpha 阶段。Daytona 在 30 天后存档。Fly Machines 的停止更接近我真正想要的，但恢复时冷启动的代价又出现了。blaxel.ai 声称无限待机且恢复时间低于 25 毫秒，但我还没有压力测试超过一周。有没有人真正解决了这个问题，而无需在 S3 和状态机之上构建自己的检查点层？你的设置是什么？全部放在一个持久化的虚拟机里，承担空闲成本？只对文件系统做快照，接受进程被干掉？还是用 Temporal 作为持久执行层来包裹沙盒提供商？我特别好奇那些使用本地大语言模型的人是怎么做的，因为每次沙盒恢复时冷加载一个 32b 量化模型实在太痛苦了。