DeltaBox：面向 AI Agent 的毫秒级沙箱状态快照与回滚

论文概览

当 AI Agent 执行软件工程任务时，每一次代码修改、包安装、测试运行都会产生不可逆的沙箱状态变更。MCTS 树搜索需要在每个节点做 checkpoint，在回溯时快速 rollback——但现有的 Docker commit、文件复制、VM 快照等手段，延迟都在百毫秒到秒级，严重拖累搜索深度和 RL 训练吞吐。

这篇来自上海交大 IPADS 实验室和华为的工作提出了 DeltaBox，核心洞察是：Agent 相邻 checkpoint 之间的状态变化极小，完全没必要全量复制。基于这一洞察，DeltaBox 引入了一个新的 OS 抽象 DeltaState，并设计了两个协同的 OS 级机制：DeltaFS（仅复制文件系统增量）和 DeltaCR（增量进程内存快照 + 模板 fork 快速恢复），将 C/R 延迟压缩到了毫秒级。

核心创新

1. DeltaFS：运行时热切换的 OverlayFS

传统 Linux overlayfs 的层栈在 mount 时冻结，修改需要 umount/mount，涉及 dentry/inode 缓存刷新，单次开销数十毫秒。DeltaBox 直接扩展了 overlayfs 内核模块，新增一个自定义 ioctl 实现无需 umount 的运行时层切换：

• hot layer switching：checkpoint 时原子性地冻结当前 writable layer 为 read-only lower，插入新的 writable layer，操作本身仅涉及元数据（指针交换 + 计数器 bump），耗时不到 2ms
• lazy file descriptor redirection：通过 per-filesystem 的 checkpoint_gen 计数器，写路径上检测到 generation mismatch 时延迟重新解析 inode，避免对打开文件的影响
• XFS reflink CoW：底层文件系统使用 XFS reflink，copy-up 操作通过 vfs_clone_file_range 只克隆 extent 引用，写放大恒定为 4KB 块粒度

这意味着 checkpoint 的文件系统维度开销从原先的百毫秒级压缩到了元数据操作级别，而与工作目录大小无关。

2. DeltaCR：双路径进程 C/R + 模板 fork

进程状态的 C/R 比文件系统更棘手——Python Agent 进程可能持有 50MB+ RSS、多个线程、打开的 socket 和 LLM SDK 连接池。DeltaCR 在 CRIU 基础上做了三项关键扩展：

双路径 checkpoint：每次 checkpoint 同时执行 (a) 异步 CRIU 增量 dump（写入 tmpfs，作为持久化兜底）和 (b) 模板创建 fork()（父进程 SIGSTOP 冻结为 template，子进程继续作为活跃 agent）。两者的执行时间完全隐藏于 LLM 推理窗口内（inference-masked checkpointing），对关键路径近乎零开销。

模板池 + fork 快速恢复：维护一个有界模板池（LRU 驱逐），restore 命中时直接 fork() 模板——由于 fork 只复制页表、不复制物理内存，延迟与进程 RSS 无关，实测 ~3.75ms。若模板已被驱逐，则回退到 CRIU lazy-pages 慢路径（~8ms），不影响正确性。

async-warm 线程：fork 后父子进程共享所有页（CoW），子进程首次写入任何共享页都会触发同步缺页。DeltaCR 在 GSD 侧启动一个后台 async-warm 线程，遍历子进程的匿名可写 VMA，逐页读-重写一份（保持内容不变），强迫 CoW 物理拷贝在后台完成。效果是 Agent 恢复后的首次写入不再卡在缺页处理上。

另一个精妙设计是 Network Proxy Daemon (NPD)：将 LLM SDK 的 HTTP/2 连接池从 Agent 地址空间中彻底剥离到一个独立进程。Agent 通过 FIFO + 共享内存与 NPD 通信——这个分离让 Agent 模板不含任何持久 socket 或工作线程，确保 fork() 安全，同时 NPD 在 checkpoint 期间继续缓冲 API 响应。

3. StateManager 一致性协议

StateManager 强制执行一个核心不变式：每个 checkpoint 必须是 (filesystem, memory) 的一致性对。checkpoint 时，CRIU 的 SIGSTOP 屏障同时冻结文件 I/O 和内存变更，确保 dump 的快照瞬时一致性；restore 时，DeltaFS ioctl 先切换文件层栈，再恢复进程——杜绝 agent 在错配的文件/内存组合上执行。

方法论

DeltaBox 的四层架构清晰反映了 OS 设计的经典分层思想：

deltaCheckpoint 流程：Search Strategy 发起请求 → GSD 异步提交 CRIU 增量 dump → GSD 同步执行 DeltaFS ioctl（原子性地推进层栈）→ 等待 dump 完成后，Agent 在静默点自 fork，父进程入模板池 → StateManager 注册。

deltaRestore 流程：Search Strategy 发起请求 → SIGKILL 当前 agent → DeltaFS ioctl 切换层栈 → 若模板命中，模板 fork() + async-warm；若 miss，CRIU lazy-pages 恢复。

一个值得注意的细节是 MCTS 感知的垃圾回收：MCTS 可能在任意时刻通过 UCT 重新选择历史上已扩展的非终节点，因此不能简单按 LRU 或访问次数回收快照存储。DeltaBox 提出了一种 reachability-aware keep rule——每次 GC 时计算 MCTS 可达节点集合（UCT 选择规则仍可能返回的节点），仅回收确定不可达的快照，保证正确性。

实验结果

C/R 延迟（Table 2）

在 SWE-bench 的三种典型 workload（Django / Astropy / SymPy）上：

DeltaBox 比最快的 docker baseline 在 restore 上快了两个数量级（~5ms vs ~1350ms），且在纯读操作（grep/cat/find）上通过语义分类器触发轻量级跳过路径，checkpoint 进一步降至 1-2ms。

端到端 MCTS（Fig 7）

在 Qwen3-Coder-30B 的 100-iteration MCTS 轨迹回放中（中位 LLM RTT ~2s），DeltaBox 将状态管理开销控制在 LLM-only 耗时的 1.03-1.06 倍（即 3-6%），而 Firecracker Diff+dm 为 1.87-3.84 倍，CubeSandbox+dm 为 2.62-4.29 倍。

RL 训练 fan-out（Fig 8）

在 Qwen2.5-7B LoRA 训练的 sync 模式下，DeltaBox 的 GPU 利用率达到 93-99%（N=16-64），而 copytree 仅 51-61%，docker 仅 54-63%。随着 batch size 增大到 64、多 GPU FSDP 训练加速，相对差距进一步拉大。

关键消融

• 模板 fork vs RSS：fork 复制仅页表（~3.75ms），延迟与进程 RSS（15MB vs 100MB）无关，实测确认
• async-warm 效果：后台线程在 Agent 恢复后首次写入前已完成大部分 CoW 缺页处理，将关键路径上的缺页数压缩到个位数
• 写放大：XFS reflink 将写放大恒定为 4KB 块粒度，不受文件大小或 checkpoint 次数影响

启示与思考

DeltaBox 给我的最大启发是：Agent 基础设施的性能瓶颈往往不在 AI 侧，而在 OS 侧。当业界热衷于优化 LLM 推理延迟（从秒级压到亚秒级）时，沙箱 C/R 的百毫秒开销反而成了搜索深度和训练吞吐的硬上限。DeltaBox 用经典 OS 技术（overlayfs、fork、CRIU、CoW）的组合创新，将这个问题解决得干净利落。

更值得深思的是论文对 inference-masked checkpointing 的利用——将 C/R 开销隐藏在 LLM 推理的 I/O 窗口内，这是 Agent 场景特有的优化机会：Agent 在等待 LLM 响应时本来就 idle，为什么不利用这段时间做 checkpoint？这个思路在传统 serverless 场景（checkpoint 总是离线做）中不存在，但在 Agent 场景中却极为自然。

此外，DeltaBox 与 LangGraph Checkpointer 的互补关系也很有启发性：前者管物理状态（文件系统 + 进程内存），后者管逻辑状态（graph state）。两者叠加才能实现完整的 Agent 状态管理——这也是为什么 "Git stash 只能回溯文件但不能回溯进程内存" 在实际中会出 bug 的原因。

当然，DeltaBox 目前还不支持网络 I/O 的回滚（side effect 无法撤销），且模板池大小需要在内存开销和恢复延迟之间权衡。但无论如何，14ms checkpoint + 5ms restore 的数字已经是 Agent 沙箱基础设施的一个新基线。

深度分析：未来演进方向

重新精读全文后，我认为 DeltaBox 有几个值得关注的演进方向，既有论文已明确的局限性，也有我基于系统设计推演的延伸思考。

1. 网络 I/O 回滚：最大的未解问题

论文多次坦承"DeltaBox does not currently support network I/O rollback, which may incur external side effects"。这不是一个小缺陷——当 Agent 执行 pip install、git push、发送 webhook 或调用第三方 API 时，这些外部副作用无法通过 C/R 撤销。NPD 的设计精妙之处在于把 LLM I/O 剥离到独立进程来保证 fork 安全，但它只能保证"checkpoint 期间 LLM 响应不丢失"，而不能保证"rollback 后外部世界状态恢复"。

一个可能的演进路径是引入 undo log 机制：对确定性的网络操作（如 HTTP GET）不需要回滚，但对有副作用的操作（POST/DELETE/rpc），NPD 可以记录请求内容并在 rollback 时发送补偿请求。这类似于数据库事务的 undo log，但面向网络层。更激进的方案是把 NPD 升级为完整的 network proxy replay engine，将所有出站流量录包，rollback 时重放到一致的截断点。

2. 容器原生部署：从 Firecracker 到 Docker/K8s

DeltaBox 当前的部署模型依赖 Firecracker microVM + 自定义 Linux 6.8 内核（集成 DeltaFS 模块），门槛极高。论文虽然提到"key optimizations can also be used by container-based systems"，但并未给出容器化的性能数据。

一个自然的演进是 DeltaFS-as-a-container-volume-plugin：把 DeltaFS 的 hot layer switching 包装为 Docker volume driver 或 Kubernetes CSI 插件，让标准容器也能获得毫秒级文件系统 C/R。DeltaCR 的模板 fork 本身不需要 microVM——它在普通 Linux 进程上就能工作。如果能解耦 DeltaBox 和 Firecracker 的绑定关系，将大大降低部署门槛，使其能嵌入到 E2B、Daytona、OpenHands 等主流平台。

这也是和 ZeroBoot（KVM 级 CoW 内存 fork）直接竞争的方向。ZeroBoot 的优势是无需内核补丁，劣势是每个分支仍是完整 VM，而 DeltaBox 在单 VM 内做多分支的开销更低。如果 DeltaBox 能去掉内核模块依赖（比如用 FUSE 或 eBPF 实现 DeltaFS），将是一个决定性的工程改进。

3. 分布式 DeltaState：跨节点 MCTS

当前设计是单 VM 内的 DeltaState 管理。对于大规模 RL 训练（论文验证到 N=64）或跨节点的 MCTS 搜索，每个节点独立管理自己的快照，缺乏全局协调。

分布式场景下需要解决的问题是：如何跨节点共享模板和增量快照？ 一个思路是利用 CXL 内存池（论文 related work 中 TrEnv-X 的方向）或 RDMA 远程内存映射，让不同节点的 DeltaBox 实例共享同一组底层 overlayfs 层。checkpoint 增量通过 RDMA 直接传输到远端节点的 tmpfs，避免走网络文件系统的开销。这与论文 Fig.8 中 Topology A（单 VM 多子进程）的思路一致，只是从 intra-VM 扩展到了 inter-node。

4. GPU 状态快照：面向本地推理 Agent

论文的实验全部基于远程 LLM API 调用（通过 NPD 代理），Agent 本身不持有 GPU 状态。但随着 local inference 的兴起（DeepSeek-R1-Distill、Gemma-3-1B 等可在消费级 GPU 上运行的模型），Agent 可能需要本地 GPU 来运行推理或代码执行加速。

GPU 内存（VRAM）的 C/R 是一个极其困难的系统问题。CUDA/OpenCL 的上下文包含设备状态、内核调度器和 DMA 缓冲区，无法通过 CRIU 的 soft-dirty 页追踪来捕获。NVIDIA 的 checkpoint 库（nccl/cuda checkpoint）可以序列化模型权重，但无法序列化中间计算状态。

一个务实的演进方向是 GPU state offloading at checkpoint：checkpoint 时将 GPU 模型权重卸载到 CPU 内存（NPD 可以代理这个过程），restore 时重新加载。代价是 checkpoint/restore 延迟从毫秒级退化到百毫秒级（取决于模型大小），但对于本地推理 Agent 来说仍然比重建整个推理环境快得多。

5. 自适应模板池与压缩

当前模板池使用固定大小 N_tpl + LRU 驱逐策略。但在不同搜索阶段，快照的重要性差异巨大——MCTS 根节点附近的快照几乎不会被回溯（因为 UCT 几乎不会选择回退到根），而深度未展开节点的快照是高价值目标。

一个更好的方案是 search-aware adaptive pool sizing：根据搜索树拓扑动态分配模板槽位——将有限的内存预算集中用于"UCT 选择概率 > 阈值"的节点，而非均匀分配。同时，CRIU 增量 dump 存储在 tmpfs 中（Fig.13 显示可达 43-69MB），可以考虑引入 zstd 流式压缩，将存储开销降低 3-5 倍，代价是 restore 时增加 ~1ms 的解压延迟。

6. 多进程与多语言 Agent 支持

当前设计假设 Agent 是单主线程 Python 进程（fork 只复制调用线程，避免多线程 fork 死锁）。但实际 Agent 可能启动子进程（如 pytest --forked）、运行数据库服务（如测试 Django 需要启动 SQLite）、或使用多线程 Worker（如 web 搜索工具的并行抓取）。

对于多语言场景——Node.js Agent 使用 libuv 事件循环 + 多线程 Worker Pool，Go Agent 使用 goroutine + runtime 调度器——CRIU 的兼容性也是挑战。CRIU 对 Go runtime 的支持有限（需要 cgroups v2 + 特定版本），对 Node.js 的 libuv 支持更差。如果 DeltaBox 要成为通用 Agent 沙箱，多语言兼容性是必须解决的工程问题。

演进路线总结

我认为短期内最高优先级是 网络 I/O 回滚和容器原生部署——前者补全了"完整状态管理"的最后一块拼图，后者决定了 DeltaBox 能否从学术原型走向工程落地。

参考信息

• 论文链接：arXiv 2605.22781
• 作者单位：上海交通大学 IPADS / 华为技术有限公司
• 项目主页：未公开（论文发表于 2026 年 5 月）
• 代码仓库：尚未开源（截至论文发表）