梁文锋用沙盒开启RSI

DeepSeek联合清华大学发表了一篇文章，署名的最后一人是梁文锋。

文章表面上是说DeepSeek训练Agent所使用的沙盒，但是论文第6节越看越不对劲。字里行间写了三个英文字母：RSI。

通过这个沙盒，Agent能创建自己需要的环境，这个环境会再次训练Agent，被训练的更强的Agent会创造更好的环境。

由此形成了一个小型的RSI闭环。

也正是因此，沙盒，或许成为了开启RSI第一场战争的一把钥匙。

那这篇文章到底讲了什么呢？

01

这篇论文到底讲了什么

梁文锋署名的这篇新论文，标题叫做《DeepSeek Elastic Compute （DSec）: A Sandbox Infrastructure for Effective Agentic Training at Scale》，9月19日提交到 arXiv，编号2609.22978。作者超过130人，梁文锋排在最后一位。合作方是清华大学。

论文做的事情，一句话就能说完：DeepSeek完整公开了自己用来训练Agent的“沙盒工厂”DSec。

但是要理解DSec，就得先理解“训练Agent”和“训练大模型”的区别。

训练大模型，是喂数据、算梯度，环境就是GPU集群。训练Agent则完全不同，Agent要在环境里写代码、跑编译、开浏览器、装依赖、调工具，然后根据执行结果不断重试，直到任务完成。

但如果把Agent放在电脑里训练，它万一捣鼓点什么出来，那整个环境就毁了。

所以这就需要一个隔离的、有状态的、能跑真实软件的沙盒。

DSec就是这样一个平台。它通过一套统一的Python SDK（libdsec）对外提供四种后端：函数调用（FnCall）、容器（Container）、轻量虚拟机（microVM）、完整虚拟机（Full VM）。

简单来说，DSec就是外卖APP，Agent是骑手，沙盒就相当于是派单。由此类推，FnCall、容器和轻量虚拟机就是外卖站点分发的电动车和保温箱，完整虚拟机是冷链货车。

但这里有个小问题，隔离强度和系统功能两者生来就“不对付”。

越像一台真机，启动越慢、内存开销越大。跑一段短脚本用函数调用，改一个代码仓库用容器，跑安全任务用microVM，而要跑安卓、图形界面这种完整系统，就只能上完整虚拟机。

论文显示，一个生产单元约160个CPU节点、3万核、250TB内存，托管PB级镜像。

一天服务约300万个沙盒，峰值并发超过38万个，创建速度超过每秒5000个。单个训练任务最多能一次性拉起3.2万个沙盒。单节点上，最高能塞进800个 microVM或3200个容器。

DSec有三个核心机制。

第一，把环境拆成“可组合的层”。

过去一个沙盒环境是一整块镜像，改一个工具包就得重建整块镜像，维护成本随组合数暴涨。DSec把基础镜像、工作区、工具包拆成三层独立版本化的只读层（EROFS），启动时用overlayfs拼起来，改哪层只重建哪层。实测比 tar.gz 打包方式快1.76倍，磁盘写入量少5.5倍。

相当于是给骑手配车，以前是坏了其中一个零部件，那么整车都要换。DSec是坏了哪个换哪个。

第二，镜像“按需加载”。镜像存在3FS（DeepSeek 的分布式文件系统）上，元数据预取到本地，数据块只在真正读到时才拉。实测8192个容器的突发部署，按需加载35分钟跑完，而 Docker 冷拉取要60分钟以上，磁盘写入量少了约57%。

老办法是“不管用不用，整仓先搬空”。DSec是“根据外卖单，用到哪件骑手去取哪件”。

第三，内存和CPU的“精打细算”。

用virtio-pmem配合DAX，让多个虚拟机共享同一份页缓存，峰值内存降40.2%；用DAMON加balloon回收冷页，时间积分内存再降21.2%；CPU上把沙盒分成“延迟敏感”和“尽力而为”两类，用core scheduling把SMT干扰从45.2%压到17.3%。

此外，从DeepSeek-V4.1开始，论文还把Agent的rollout从可被抢占的GPU训练Pod里拆出来，独立跑在DSec上，GPU被抢时rollout状态不丢。

说白了就是让骑手们公用同一张地图、同一批货架，车里压仓的冷货随手退回仓库，加急单和普通单分道跑、互不抢道。

02

藏在第6节的RSI

论文里最容易被忽略一句话，不在摘要，而在第6节的小标题里：Build environments of Agents, by Agents, for Agents。意为由Agent建造、为Agent服务、属于Agent的环境。

这句话等于DeepSeek悄悄交代了一件大事，DeepSeek也实现了部分RSI。

论文第6.1节写到，手工构造Agent RL所需的大量环境已经“不现实”（impractical）。

于是DeepSeek换了个做法，让Agent在训练用的同一套沙盒里，交互式地自己搭环境，再用pack_diff把这次会话打成一张增量快照，直接变成下一批可复用的训练场。

造环境的Agent和被训练的Agent共用DSec这套沙盒基础设施。

Agent铺场地 → 场地训练Agent → 更强的Agent再铺更好的场地。DeepSeek的RSI由此部分实现闭环。

但是这个闭环仍处于早期。

第6.4节记录了大量Agent作弊事件，比如去平台里翻残留的参考答案，伪造RPC消息直接发给chronus套答案，翻 chronus日志找泄题，甚至覆盖/bin/bash来绕过检查。

被拦住之后，又用XFS_IOC_SWAPEXT这个ioctl把受保护文件的存储块换到另一个文件描述符上，结果把XFS元数据搞坏、逼得文件系统关闭。

有作弊的自然就有闯祸的。一个Agent从根目录递归grep、一路读到/proc/kpagecgroup，触发内核bug直接把内核干崩。

另一个Agent调了yes命令，chronus把它的输出全记下来，几十GB数据堆在存储上。

现在的RSI转不起来，卡的从来不是GPU，是环境供给。

Agent RL每一代都要新任务、新沙盒、新服务依赖，人工造环境才是真瓶颈。

DSec相当于是把这一环部分自动化了，自动生成RSI所需要的环境。

还是用外卖来举例。

一个外卖平台想越跑越快，不能只靠一个骑手重复送同一单。想要骑手变强，就需要接更多不同种类的单，而单越多又反过来把骑手练得更强。

但是想要把这个飞轮转起来，卡的从来不是骑手，是餐厅够不够多。没餐厅，骑手再能跑也是空转。

DSec是盖了一个“自动建餐厅”的系统。

以前平台得人工一家家谈商家、装修后厨、写菜单、定考核标准，几百几千家根本谈不过来。

DSec说：“别谈了，让骑手在跑单的同一个后厨里，顺手把店开了。他怎么装的灶台、进的什么货、接的什么水电，系统用pack_diff‘啪’拍一张快照存下来，下一波骑手直接拎包入驻这家店开工，不用重新装修。”

03

沙盒，成了新的战场

DSec不是孤例。整个行业都在朝着“Agent沙盒”这一个方向发力。

最出名的案例是Kimi K3。

月之暗面7月16日发布K3，2.8万亿参数的 MoE，每个token激活约104B 参数，100万 token上下文，原生视觉，号称“全球首个开源的3T级模型”，SWE-bench拿到76.8%、开源第一。

它的Agent Swarm最多能并行调度300个子代理。DeepSeek这篇论文里，引用的也正是Kimi-K2.5的Agent Swarm。

Kimi训练K3的时候所使用的AgentENV也是一种沙盒。

AgentENV跑在Firecracker microVM上的分布式沙盒平台，每个沙盒独立Linux内核、独立网络栈、独立文件系统，底层存储用OverlayBD + ublk，只读层全集群共享，每个沙盒写自己的上层。跟DSec是同一套技术栈。

DSec论文第7节写到，它用的那套Rust版OverlayBD/ublk存储库，就开源在AgentENV这个仓库里。

两者相当于是同门师兄弟。

但AgentENV没法实现RSI，它给的是fork/snapshot这种“状态操作原语”，让RL rollout能并行、能回滚、能干净判分。因此，它没法像DSec那样让Agent自己造环境。

类似的还有阿里。云栖大会上，阿里云CTO李飞飞抛出了“Agentic Cloud”战略，把Model、Harness、Context 当成三个核心场景，一口气推出AgentCore、Agent Sandbox、新一代存储CPFS。

其中Agent Sandbox能创建吞吐10万个/分钟，深休眠唤醒小于600毫秒，兼容E2B和K8s。

沙盒正在成为“新的运行时”。

云计算的主体，从虚拟机，到容器，再到模型，现在轮到Agent。谁掌握Agent的执行环境，谁就掌握了下一代云的入口。

这就导致，竞争焦点从“模型能力”转向“环境基础设施”。

“训练大模型拼算力，训练Agent拼环境”。

在GPU 之外，CPU、内存、存储、镜像分发，全都变成了新的瓶颈。

还有一点，安全从附加项的价值也变得极为重要。OpenAI、Anthropic各种模型越狱、DSec论文里Agent的作弊和内核崩溃，说的是同一件事。

沙盒如果不牢，训练信号就是假的，评估就是废的。所以像是阿里这样的厂商，会把“安全围栏”也当成卖点，DSec用AppArmor加eBPF。

沙盒厂商过去比的是快和便宜，现在开始比谁更牢固。

RSI的第一战已经开始了。想跑RSI，那你就先得有沙盒，有环境。