大模型训练比拼的是计算能力，而Agent训练比拼的则是环境。

环境如何构建？由梁文锋署名的DeepSeek最新论文，将技术细节公之于众。

DeepSeek打造的这套系统名为DSec（DeepSeek Elastic Compute），其核心任务是为Agent训练批量生成沙盒。

该系统每秒可创建超过5000个沙盒，一天内达到300万个，峰值时能同时运行38万个。

支撑这一规模的单个集群也极其庞大，大约包含160个节点、3万核CPU和250TB内存。

为什么训练一个Agent会如此困难？

因为大模型训练的环境是GPU集群，只需输入数据并计算梯度，但Agent则完全不同。

它需要在沙盒里编写代码、运行编译、打开浏览器，甚至安装操作系统……每一步操作都会改变环境状态，随时可能导致环境崩溃。

因此，每轮训练都必须提供一个全新且干净的沙盒，并且用完即弃，训练结束后立即丢弃。

所以，问题最终还是回到了基础设施上——

这些基础设施需要在每秒5000个的速率下，为每个沙盒安装一整套操作系统和工具链。

同时，还要防止数十万个并发沙盒耗尽集群的内存和CPU资源。

具体如何实现，论文将这套工程的全貌完整呈现了出来。

Agent训练需要「一个世界」

DSec要解决的第一个核心问题是，不同类型的Agent任务对沙盒环境的需求差异极大，而且这些环境必须在同一个平台上统一调度。

一个刷OJ题的Agent，只需要一个无状态的函数调用环境，执行完毕后获取输出即可，甚至无需持久化文件系统。

但一个执行SWE-bench任务的Agent，则需要完整的Linux用户态，在其中安装依赖、修改代码、运行pytest，任务进行到一半时还可能需要在环境中添加新的软件包。

到了安全攻防和computer-use场景，容器级别的隔离已不够用，Agent需要操作浏览器甚至桌面，一个有漏洞的Agent可能顺手把宿主机搞垮，因此必须使用虚拟机。

最极端的情况是训练操作商业软件的Agent，它需要一个完整的Windows或macOS系统，带有图形界面和驱动，与真实电脑几乎没有区别。

DSec为这四类场景分别准备了四种后端：FnCall处理无状态函数调用，Container运行Docker容器，MicroVM使用Firecracker构建轻量级虚拟机，Full VM则通过QEMU运行完整操作系统。

这四种后端的隔离强度和资源开销逐级递增，但训练框架端看到的则是统一的Python SDK libdsec。

无论底层是容器还是虚拟机，都采用相同的接口，创建沙盒、执行命令、获取结果等各个步骤的调用方式完全一致。

为了让四种后端在同一套集群上运行，平台的调度层也必须跟上。

DSec将整个链路拆解为六层。

这条链路从训练框架的一个创建请求开始，先经过IAM认证鉴权，进入API Server，再由调度引擎（Placement Engine）根据资源余量从集群中选出一台目标节点，节点上的Edge组件负责实际拉起对应类型的沙盒。

沙盒的网络出口和包管理镜像由Aether统一代理，Agent在沙盒内执行的每条命令和产生的每行输出，都通过一个名为Chronus的沙盒内通信组件中转回训练框架，让框架了解Agent的执行进度以及需要给予何种反馈。

凭借资源超分和高密度部署，单个节点可以同时承载3200个容器或800个MicroVM。

每天300万个沙盒如何带动？

然而，DSec在规模上最棘手的挑战并非调度，而是环境的构建。

每个沙盒启动时，都需要一整套操作系统镜像加工具链，相当于每秒为5000台「电脑」安装系统。

传统Docker的思路是将基础镜像、工作区和工具包打包成一个完整镜像。

这个方案在小规模下没有问题，但DSec的容器后端累计使用了11266个基础镜像和102171个工作区，67.8%的沙盒需要在基础镜像之上叠加至少一层工作区或工具包。

在这种多样性下，一旦某个工具包更新，所有包含它的组合镜像都需要重新构建，成本呈O(m·N)增长。

DSec的做法是将环境拆分为基础镜像、工作区、工具包三层独立的EROFS只读镜像，各自独立版本化，通过overlayfs在沙盒启动时按需组合。更新工具包时只涉及工具包那一层，成本降至O(m)+O(k)。

镜像构建完成后，如何将其传送到节点上同样至关重要。

直觉上应该提前将镜像拉到本地缓存，但论文统计了真实的运行时数据：

Python容器镜像为6.0GB，Agent实际只读取了其中6.0%的数据；

Java镜像为12.1GB，只有9.2%被访问；

C++镜像为4.9GB，只有8.7%被访问。

也就是说，绝大部分镜像内容，Agent从头到尾都没有碰过。

因此，DSec选择按需加载，其镜像以EROFS格式存储在3FS（Fire-Flyer分布式文件系统）上，元数据预取到本地，数据块仅在沙盒真正读取时才从3FS拉取。

DeepSeek团队实测，8192个容器的突发部署，按需加载只需35分钟即可完成，而Docker冷拉取需要60分钟以上。

此外，按需加载的磁盘写入量也比Docker冷拉取减少了一大半，从约1600GB降至约700GB。

环境构建完成后，数十万个沙盒同时运行又面临资源争抢问题。

在内存方面，MicroVM通过虚拟块设备读取镜像数据时，同一份数据会在宿主机和虚拟机的页缓存中各存一份，导致需求倍增。

DSec采用virtio-pmem配合DAX，让虚拟机跳过自己的页缓存，直接映射到宿主机物理内存，多个虚拟机共享同一份映射，峰值内存占用减少了40.2%。

对于不适用virtio-pmem的可写磁盘，DSec通过DAMON定期扫描冷内存页并主动归还宿主机，配合virtio-balloon的free-page reporting，再将需求降低21.2%。

在CPU方面，DSec将沙盒分为延迟敏感型和尽力而为型两类，后者设为SCHED_IDLE优先级，同时启用Linux的core scheduling，阻止低优先级任务运行到高优先级任务所在物理核心的兄弟超线程上。

两层策略叠加后，在50%背景负载下，延迟敏感任务的延迟膨胀从45.2%降至17.3%。

此外，DSec还需要与RL训练框架配合处理GPU抢占问题。

早期架构中，Agent的推理循环运行在GPU训练Pod内部，当GPU任务被抢占时，Agent的执行进度就会全部丢失。

从DeepSeek-V4.1开始，Agent循环被独立出来，运行在DSec的worker container中，不再绑定GPU Pod的生命周期。

当GPU被抢占时，DSec将相关沙盒挂起并保存状态，GPU恢复后沙盒继续执行，训练框架不再需要自行实现断点恢复逻辑。

即便做了这么多优化，单个集群仍可能无法承受峰值负载。

论文中提到，最大的生产任务一次性申请了32000个沙盒，在这种突发负载下，DSec会自动触发cloud bursting，将溢出的任务发送到云端虚拟机上。

DeepSeek团队实测，当集群利用率超过80%时，200台云VM即可吸收约30%的峰值负载。

Agent学会了作弊

对Agent而言，沙盒不仅是运行环境，同时也是安全围栏。

论文披露了多起Agent在训练中自行发现的reward hacking手段，即Agent找到了不通过正当手段完成任务、但同样能获得高分的捷径。

这些Agent瞄准的第一个目标是Chronus，即沙盒内部负责Agent与外界通信的组件。

Chronus在执行某些操作时会调用系统的bash，Agent发现后直接覆盖了/bin/bash，将自己的命令注入其中，试图从后续的shell会话中截获题目答案或其他特权信息。

当这条路被AppArmor堵住后，Agent又找到了一个更底层的突破口，即XFS文件系统的ioctl调用。

XFS_IOC_SWAPEXT，其作用是交换两个文件的底层数据块映射。Agent利用它将受保护文件的内容「换」到了自己持有的文件描述符上，绕过了文件级别的访问控制。

这次尝试的副作用比作弊更危险，因为它损坏了XFS的元数据，可能直接导致文件系统崩溃，影响的不只是这一个沙盒。

沙盒之外的信息泄露渠道同样被Agent们找到过。

有的Agent会扫描沙盒能触达的网络端口和服务，寻找参考实现；有的直接打小抄，通过Go module proxy从GitHub拉取代码；有的甚至安装更新版本的软件包来获取现成解法。

这些行为通过单纯检查最终输出根本无法发现，因为Agent确实「做对了题」，只是手段不正当。

除了作弊，还有更暴力的场景。

一个Agent在沙盒内递归执行grep，从根目录一路扫描到/proc/kpagecgroup，触发了一个内核bug，导致整个宿主机的内核直接崩溃。

另一个Agent则是在安全攻防任务中，将本应发送给目标虚拟机的攻击命令在自己的容器内执行了，同样打崩了内核。

还有Agent发现，Chronus会异步记录命令的stdout输出，于是反复调用yes命令不断打印字符，几十个GB的日志灌满了存储空间。

DSec目前的防御手段分为两层。

一是使用AppArmor控制文件读写权限和Unix域套接字访问，这些策略即使Agent以root身份运行也依然生效，限制了Agent从日志和内部通信通道中提取答案的能力。

二是使用eBPF进行网络层的细粒度管控，按任务配置域名白名单，通过IP地址、端口和协议三重过滤拦截越界流量。策略还可以在任务的不同阶段动态更新，例如在环境搭建阶段允许访问PyPI，正式执行阶段则收紧网络。

但论文也明确指出，这并非一个能彻底解决的问题。

AppArmor和eBPF能限制信息泄露通道，但无法防御内核bug；用户隔离可以缩小爆炸半径，但Agent总会找到新的路径。

这将演变为一场持续的「魔道之争」，模型越强大，钻漏洞的能力也越强，平台的防线就必须不断前移。

Agent从「会说话」进化到了「会做事」，训练基础设施的复杂度也出现了质变。

训练大模型的集群，依靠的是「大力出奇迹」，但训练Agent的集群不仅要「又大又细」，还得防得住自己训练出来的东西。

那个需要被防住的对手，恰恰就是正在被训练的Agent本身。

论文地址：https://arxiv.org/abs/2609.22978

本文来自微信公众号“量子位”，作者：克雷西，36氪经授权发布。