沙箱不只是为了关住 Agent

早期谈 Agent 沙箱，重点通常是安全：别让模型乱删文件、别让工具访问宿主机、别让依赖污染系统。DeltaBox 的视角更进一步：沙箱还应该支持高频试错。

一个长程 coding agent 的工作路径很少是线性的。它可能先安装依赖，跑一组测试，改一个文件，再发现方向错了；也可能同时探索两个修复方案，最后保留更好的分支。没有 checkpoint 和 rollback，每次探索都会把环境弄脏。

这时沙箱如果只负责隔离，还不够。它必须让系统便宜地回到某个执行点。否则 Agent 越长程，失败成本越高。

论文解决的具体问题

DeltaBox 面向 stateful AI agents，讨论毫秒级 sandbox checkpoint 和 rollback。它关注的重点是 Agent 执行过程中频繁保存和恢复状态。

论文思路是对文件系统和进程状态做增量处理，避免每次都复制完整环境。这样 Agent 可以在关键步骤前打 checkpoint，试错失败后快速回滚，而不是重新创建一套环境。

这对实际系统很关键。长程任务中，环境状态包括文件变化、临时目录、进程、安装过的包、测试缓存和工具输出。只保存聊天历史并不能恢复这些现场。

为什么它会影响 Agent 产品形态

有了低成本回滚，Agent 产品可以从「单路径执行器」变成「可探索系统」。它可以尝试多个补丁，比较测试结果；可以在高风险工具调用前保存状态；可以把失败分支保留下来用于诊断；也可以把回滚作为用户可见能力。

这会改变用户体验。今天很多 Agent 一旦跑坏环境，用户只能重开任务或手动修。更成熟的界面应该能显示执行分支、checkpoint、失败原因和可恢复点。

对企业部署来说，回滚还关系到成本。重新拉代码、装依赖、跑初始化脚本，很可能比模型生成本身更慢。运行时如果不能降低环境恢复成本，Agent 的吞吐和价格都会被拖住。

不要把回滚神化

DeltaBox 解决的是运行时状态恢复，不是任务正确性本身。回滚能让 Agent 更敢试，但不能保证它知道该试什么，也不能替代权限控制。

另外，毫秒级回滚在论文环境里成立，到了复杂企业环境可能会遇到外部副作用：发出的邮件、创建的云资源、写入的远程数据库，都不是本地沙箱能自动撤销的。生产系统还需要副作用登记、补偿动作和审批边界。

所以这篇论文最稳的结论是：长程 Agent 的基础设施要从「能跑」升级到「能恢复」。恢复能力越强，Agent 才越可能承担真实工作。