存读档延迟首次压到毫秒级！上交华为推出智能体沙箱系统

一水 整理自 凹非寺
量子位 | 公众号 QbitAI

玩过《黑神话》的朋友都知道，面对强大的BOSS，普通人能通关的唯一秘诀就是：

不停地死，不停地读档重来。

每一个复杂的动作和操作，都是在成百上千次“存读档”的挫败中，生硬摸索出来的。

对如今大火的AI Agent来说，也是同样的道理。

让Agent去自主修复一个大型软件工程的Bug，或者在操作系统里完成一段复杂的自动化指令，本质上就是一场高难度通关游戏。

它必须在安全沙箱里不断试错：写一段代码、跑一次测试、发现报错、回滚、再换个思路。

然而在今天，这个看似理所当然的「读档（Rollback）」动作，却成为了封死AI Agent向更深、更智能维度演进的物理瓶颈。

因为今天的操作系统沙箱，存读档一次实在太慢了——快则几百毫秒，慢则数秒。

这直接堵死了Agent进行复杂深层探索的道路。

为了打破这个紧箍咒，上海交通大学并行与分布式系统研究所（IPADS）与鲲鹏团队联合出手了。

他们提出了一种全新的操作系统底层抽象DeltaState，并基于此实现了一套软硬件协同的智能体沙箱原型系统：

DeltaBox。

DeltaBox首次将沙箱的存读档操作的延迟压到了毫秒级（11毫秒存档、2毫秒读档回滚）。

DeltaBox不仅让蒙特卡洛树搜索（MCTS）这类极度依赖试错的算法在Agent工程上真正变得可行，多款大模型也借此在SWE-bench上拿到了明显更高的通过率。

联合团队还面向国产硬件平台鲲鹏，设计了定制化的优化，实现国产平台智能体沙箱的极致性能表现。

为什么Agent想吃一粒后悔药这么难？

要理解DeltaBox为什么厉害，得先看看传统的沙箱存档和读档为什么能把人急死。

在早期的纯文本Agent任务中（比如做选择题、快问快答），回滚几乎是零成本的：只需要把Prompt历史里后面那段删掉，假装没发生过就行。

但当Agent走进真实世界，去写代码、装包、删文件时，它的每一个动作都会产生不可逆的物理副作用：

• 用rm -rf删掉了一个文件。
• 用pip install强行修改了系统全局的依赖包。
• 修改了Python进程堆内存里的某个全局变量。

这时候，Agent要想后悔，就必须实现文件系统和进程内存的原子级同步回滚。

只回滚文件系统是不行的，进程里的Python解释器还保留着先前的状态，记忆和现实对不上，行为立刻紊乱。 只回滚进程内存也是不行的，磁盘上的代码已经被改得面目全非。

两手都要抓，两手都要硬。

但在现有的系统架构下，这是一个代价巨大的任务，毕竟每次存档和读档都要涉及大量的操作系统状态。

存读档太慢，直接导致了今天所有的主流Agent框架（如OpenHands、Aider、SWE-Agent）都在做妥协。

它们放弃了真正的中途回滚，失败了就只能顺着错路继续往下硬撑，或者彻底放弃、从头重来。这就好比玩游戏不能随时存档，死一次就得重新建号。

特别是在推理模型爆发的今天，模型本身就自带极长的思考链。

如果底层沙箱回滚一次要等几秒钟，那么MCTS这种动辄需要推演成百上千个分支的复杂但有效的探索算法，在工程上根本无法落地。

DeltaBox的思路：相邻状态高度相似，能否只存变化？

面对这个难题，上海交大IPADS与华为团队提出了一个直击要害的洞察：Agent在连续两次试错步骤之间，产生的状态变化其实是很小的。

可能只是修改了1KB的代码文件，运行了一次只消耗几十个内存页的测试。

既然如此，为什么每次都要傻傻地去保存那好几百MB、甚至上GB的完整状态？

我们为什么不能只对增量（Delta）进行存盘和回滚？

基于这个想法，团队提出了全新的操作系统级抽象：DeltaState。

它就像是一个精密的耦合齿轮，将文件系统和进程内存的变化量死死绑定在一起。

DeltaBox的毫秒级神话的存读档能力，是由两个在内核和用户态高度协同的黑科技来实现的：

DeltaFS：智能体文件的增量存读档管理

熟悉容器技术的朋友对OverlayFS一定不陌生，它就是Docker分层镜像的基石。

但传统的OverlayFS有个致命缺点：它的层级关系是在挂载那一刻死死固定的。

如果想在运行途中插入一个新的只读层、改写可写层，就必须先umount再重新mount。这一卸载一挂载，所有打开的文件句柄全部失效，进程必须重启，几十毫秒又没了。

DeltaBox团队直接在操作系统内核动了刀子，基于Linux OverlayFS，构建了全新的DeltaFS智能体文件系统，引入了运行时热层切换（Runtime hot layer switching）的能力。

现在，Agent每前进一步：

• DeltaFS在不卸载的前提下，瞬间将当前的可写层冻结为只读层，并在其上无缝插入一个新的空白可写层。
• 配合底层的XFS reflink技术，文件复制优化成了极轻量的“引用指向”，物理块只在真正发生改写时（4KB粒度）才会发生写时复制。
• 进程此前打开的文件描述符，通过设计独特的延迟更新机制，按需透明地重定向到新层，整个过程应用完全无感。

在DeltaFS看来，存盘只是插一张活页，回滚只是抽掉几张活页。

DeltaCR：进程克隆术

进程内存的备份，DeltaBox采用了双轨制：

• 慢路径（用于兜底备份）：利用CRIU进行的Dump，把修改过的内存页异步写入极快的内存文件系统。
• 快路径（用于极速读档）：在存盘瞬间，让Agent进程直接在原地调用一次轻量级的fork()。

这个巧妙的fork()会分化出两个一模一样的进程。

子进程直接被冻结，留在原地充当这个时间节点的进程模板；而父进程继续向前冲锋、执行后续的Agent任务。

当Agent需要回滚到这个节点时，DeltaBox根本不需要费劲去读盘、还原内存链条，而是直接把那个冻结的子进程模板再fork()一次，分裂出一个崭新的活跃进程。

由于fork()只需要复制页表而不需要拷贝实际的物理内存，这个过程快到了极致 ，最快能到亚毫秒级。

同时，为了防止冻结的进程模板太多撑爆内存，DeltaBox设计了基于LRU淘汰的模板池。

被淘汰的模板会被销毁，其状态回落到CRIU快照的慢路径。

降维打击，Agent终于不用干等了

研究团队在包含Django、SymPy、Scientific、Tools/Small repos等经典项目的SWE-bench任务上，在服务器上对DeltaBox进行了全方位的评测。

在与各类主流方案的对比中，DeltaBox展现出了统治级的速度：

• 存盘（Checkpoint）：Agent感知的阻塞开销为0毫秒（实际耗时10.83毫秒被LLM等待时间完全吸收）。
• 读档（Restore）：快路径（模板命中）仅需1.86毫秒，即使模板淘汰不幸触发了慢路径（优化后的CRIU恢复），也仅需9.29毫秒。

作为对比，回滚一次E2B沙箱需从快照恢复整个虚拟机内存,实测约0.9秒。

DeltaBox直接快了近500倍。

在约26次扩展、28次回滚的典型MCTS任务评测中：

对于E2B这类商用沙箱，即便沙箱内部署常驻守护进程，仍必须依赖microVM级存档和读档，这部分真实开销吃掉总时间的约23%~48%。

也就是说，Agent相当一部分时间都在等沙箱做重置。

而在DeltaBox下，这个开销被压缩到了微乎其微的1%至2%。

写在最后：智能体时代下的操作系统创新

在云计算的黄金十年里，整个工业界都在卷一件事：

如何把一台机器、一个容器的启动速度，从几分钟优化到几十毫秒。

因为启动越快，计算就越像自来水一样无处不在、即开即用。

而当大模型开始像人类一样学会深思熟虑，开始在复杂的现实世界里自主做决策、写代码、操作电脑时，AI Agent 的时代对底层系统提出了全新的挑战：

我们必须把一个进程、一个完整物理环境的回滚和分叉，同样做到几毫秒。

DeltaBox的诞生，正是在智能体时代对该挑战的一个正面回应。

在大模型狂飙突进的同时，操作系统这个看似传统的底层基石也必须做出改变。它不仅要学会如何更高效地计算，更要学会如何更轻快地遗忘、更廉价地试错。

当AI Agent可以像在单机游戏里一样，无心理负担地随时存档、随时读档，它们才能真正大胆地走向那些未知的、布满迷雾的、高难度的解空间。

而通往这一切的钥匙，就藏在这毫秒之间。

arXiv论文链接：https://arxiv.org/abs/2605.22781