梁文锋用沙盒开启RSI
DeepSeek联合清华大学发布了一篇论文，梁文锋作为最后一位署名作者。
表面看，这篇论文讨论的是DeepSeek训练Agent所用的沙盒，但读到第6节时，内容逐渐显露出深意。字里行间透露出三个英文字母：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像外卖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状态不丢失。
简单说，就是让骑手共用同一张地图和货架，车里压仓的冷货随手退回仓库，加急单和普通单分道行驶、互不干扰。
藏在第6节的RSI
论文中最易被忽略的一句话，不在摘要，而在第6节的小标题中：Build environments of Agents, by Agents, for Agents。意为由Agent建造、为Agent服务、属于Agent的环境。
这句话等于DeepSeek悄悄透露了一件大事，DeepSeek已部分实现RSI。
论文第6.1节提到，手工构建Agent强化学习所需的大量环境已“不现实”（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强化学习的每一代都需要新任务、新沙盒、新服务依赖，人工构建环境才是真正的限制。
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氪经授权发布。