梁文锋用沙盒开启RSI

DeepSeek与清华大学合作发表了一篇研究论文，梁文锋作为最后一位署名作者出现。

文章表面上聚焦于DeepSeek训练Agent所用的沙盒，但论文第六节内容逐渐显露出不同寻常之处。字里行间隐含了三个英文字母：RSI。

借助这款沙盒，Agent能自主构建所需环境，该环境反过来会训练Agent，而经过训练的更强Agent能创造更优的环境。

这便形成了一个小规模的RSI闭环。

正因如此，沙盒或许成了开启RSI首场战役的关键钥匙。

那么，这篇论文到底阐述了什么？

这篇论文的具体内容

梁文锋署名的这篇新论文标题为《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好比外卖平台，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倍。

这好比给骑手配车，以前坏了一个零件需换整车，现在只需更换损坏的零件。

其次，镜像支持“按需加载”。镜像存储在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状态不丢失。

简单来说，就是让骑手共享同一张地图和同一批货架，车内积压的冷货可随时退回仓库，加急单与普通单分道而行，互不干扰。

隐藏在第六节的RSI

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

这句话相当于DeepSeek悄然透露了一件大事：DeepSeek已部分实现了RSI。

论文第6.1节指出，手工构建Agent强化学习所需的大量环境已变得“不现实”。

因此，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强化学习的每一代都需要新任务、新沙盒、新服务依赖，人工构建环境才是真正的限制因素。

DSec相当于将这一环节部分自动化，自动生成RSI所需的环境。

仍以外卖为例。

一个外卖平台想越跑越快，不能仅靠一个骑手重复送同一单。要让骑手变强，需要接更多不同类型的订单，而订单越多，反过来又能将骑手训练得更强。

但要推动这个飞轮，瓶颈从来不是骑手，而是餐厅数量是否足够。没有餐厅，骑手再能干也只是空转。

DSec相当于建造了一个“自动开设餐厅”的系统。

过去，平台需人工逐一与商家洽谈、装修后厨、制定菜单、设定考核标准，几百上千家根本难以覆盖。

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

沙盒成为新的战场

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，必须先拥有沙盒和环境。

本文来自微信公众号“字母AI”，作者：苗正，36氪经授权发布。