梁文锋署名，DeepSeek发新论文，剑指大规模Agent训练
智东西9月23日报道，就在刚刚，DeepSeek创始人梁文锋署名的最新论文对外公开，首次系统披露了DeepSeek的Agent训练沙盒平台DSec（DeepSeek Elastic Compute）的技术细节。论文提交日期为9月19日，作者名单超过130人，梁文锋位列其中。
论文地址：https://arxiv.org/pdf/2609.22978
DSec平台最初在DeepSeek V4技术报告中亮相，其核心功能是为Agent训练提供沙盒环境，确保大规模Agent训练的稳定运行。论文明确指出，从DeepSeek V3.2到V4.1的强化学习训练与评测，所有沙盒负载均在DSec上执行。如今公开技术细节，相当于将核心机制公之于众。
论文显示，DSec平台规模极为庞大，其中一个生产单元由约160个CPU节点、3万核、250TB内存构成，并托管PB级镜像。
在能力方面，DSec平台单日服务约300万个沙盒，峰值并发超过38万个，创建速度超过每秒5000个，单个训练任务最多能一次性拉起3.2万个沙盒。
那么，为何Agent训练需要如此巨量的沙盒？面对复杂的执行环境，DSec又是如何应对规模、调度和资源管理挑战的？
01.
Agent强化学习天然需要海量沙盒
训练环境成为发展瓶颈
传统大语言模型训练中的强化学习，通常围绕静态的输入、输出和奖励信号展开。但Agent训练截然不同，它需要真正进入真实环境，实际执行检查代码、调用工具、执行命令、修改文件等任务。模型每执行一步，都可能引发环境状态的变化，而下一步执行又依赖于前一步的结果。
这意味着，Agent训练过程中，除了模型和数据，研究人员还需维护大量“工作现场”。这些环境必须足够接近真实机器，能安装依赖、运行软件，并在任务结束后恢复到干净状态，供下一轮rollout继续使用。
问题在于，这些沙盒数量庞大且不轻便。论文显示，训练过程中一次任务曾同时拉起3.2万个沙盒。这些沙盒并非始终满载运行，在Agent执行任务时，沙盒常处于等待下一步操作的状态，CPU利用率不高。但CPU空闲并不意味着资源已释放，内存和可写状态仍需持续保留。
因此，传统的“启动一个容器、运行一个任务”的思路难以持续。DSec平台诞生的目的，就是同时解决沙盒的批量创建、资源调度、环境复制、状态保存、暂停恢复和安全隔离。
02.
四大环境需求：一套SDK同时管理
函数、容器和虚拟机
随着Agent任务日益复杂，背后的工作环境也难以再用统一规格应对。
最轻量的任务可能只需一次函数调用，执行代码并返回结果；软件工程任务则需要完整的Linux用户态，能安装依赖、修改代码、运行测试；安全攻防和Computer-use对隔离要求更高；而操作商业软件时，所需环境甚至接近一台完整计算机。
DSec提供四种后端：FnCall、容器、Firecracker microVM和完整虚拟机，分别覆盖从短时函数调用、软件工程，到安全敏感任务和完整OS环境的不同需求。训练框架无需关心底层是容器还是虚拟机，通过Python SDK（libdsec），就能直接完成沙盒创建、命令执行和结果获取。
DSec的四种后端由同一平台统一调度。训练框架发起请求后，平台先进行身份和权限校验，再根据集群负载选择合适节点，由节点上的Edge负责创建沙盒。沙盒启动后，Aether和Chronus负责连接平台与沙盒内部的执行过程，镜像数据则由3FS按需提供。
但当这些环境从几种类型扩展到成千上万个实例，新问题随之出现：如何快速复制出数量庞大且种类不同的环境。
03.
环境越多，复制越难：
DeepSeek如何快速部署几万个沙盒
如前所述，Agent训练的环境不仅数量多，组合也很复杂。
论文统计了一个生产周的数据：容器后端涉及11266个基础镜像、102171个工作区和103个工具包。实际运行时，67.8%的沙盒还会在基础镜像上叠加工作区或工具包。DeepSeek Harness就是其中需要频繁更新的一类组件。
如果将这些组件全部放入一个完整镜像，任何一层发生变化，都需重新构建和分发整个镜像。环境数量一多，镜像维护和部署成本随之上升。
DSec将基础镜像、工作区和工具包拆分为三个独立版本的只读EROFS层，沙盒启动时通过overlayfs组合。这样，哪个组件变化，就只更新对应层，无需重新处理整个镜像。
镜像分发采用按需加载。论文发现，沙盒运行过程中实际读取的数据，仅占完整镜像的4.2%到13.3%。因此，DSec将镜像数据放在3FS上，运行时按需读取，同时将元数据预取到本地，写入则保留在节点本地盘。考虑到3FS更适合大块、连续读取，这种方式也能避开小块随机I/O带来的效率问题。
实际效果显示，当8192个容器同时突发部署时，按需加载耗时35分钟，而Docker冷拉取则超过60分钟，单节点累计磁盘写入量也从约1600GB降至约700GB。
论文表明，DSec平台中环境的构建也可由Agent完成。通过pack_diff，Agent配置好环境后生成增量快照，之后就能恢复成新的沙盒。
04.
rollout搬出GPU：
训练和执行分开
早期方案中，Agent的推理和rollout与模型训练共用GPU Pod。GPU任务一旦被抢占，正在执行的rollout也会被迫中断。
从V4.1开始，DeepSeek将rollout从GPU训练环境中拆分出来，交给DSec平台独立运行。Agent sandbox负责运行DeepSeek Harness等执行环境，worker container负责具体任务，两者都不再依赖GPU资源。这样，GPU训练被抢占时，rollout状态就能独立保留。
如果集群容量不足，DSec还支持向云端扩容。例如集群利用率超过80%后，符合条件的沙盒可转移到云端虚拟机；为减少云端重新拉取镜像的开销，DeepSeek提前准备了约30TB的去重镜像集，其中约70%的文件会被容器任务实际访问。生产环境中，200台云VM可承接约30%的峰值负载。
05.
环境越真实
Agent的操作带来的风险也越大
DSec解决了规模和效率问题，但真实环境还存在其他风险，例如Agent不一定会按预期路径完成任务。
论文记录了多种异常行为，有Agent会翻查日志、伪造RPC请求，甚至修改/bin/bash，试图绕过正常任务流程。还有Agent会扫描可达服务、拉取外部代码，通过评测之外的路径寻找答案。
更麻烦的是，Agent有时还会破坏环境本身。论文记录了递归扫描系统文件导致内核崩溃的案例，甚至一个简单的yes命令，都可能让日志迅速膨胀到几十GB。
针对这些风险，DSec主要通过AppArmor和eBPF限制Agent的操作范围，前者控制文件和socket访问，后者限制网络访问，并可根据任务阶段动态调整规则。
不过，这些措施目前只能覆盖部分风险，内核层漏洞仍难以完全防住。
06.
结语：DSec平台能力
成为Agent规模化训练的关键一环
DSec展示了一套面向大规模Agent训练的基础设施方案。从沙盒创建、环境复用，到rollout调度、状态保存和安全隔离，Agent训练正在形成一套独立的基础设施需求。
随着Agent任务持续变长、交互过程不断增加，执行环境的规模也会进一步扩大。如何让数万个甚至更多沙盒稳定运行，同时控制资源成本和安全风险，将成为Agent训练继续扩展需要解决的问题。
对于DeepSeek的Agent训练来说，模型能力持续提升的同时，承载这些任务的执行平台也需要跟上。DSec给出的这套工程方案，或许正是这一阶段Agent基础设施演进的一个切面。在爱游戏体育的视角下，这类技术突破也展现了人工智能基础设施的持续进化。
本文来自微信公众号“智东西”（ID：zhidxcom），作者：毕伟豪，编辑：李水青，36氪经授权发布。