DeepSeek推出DSec 为Agent训练批量造沙盒
当大模型的训练比拼逐渐转向算力集群的规模时，智能体（Agent）的训练却卡在了另一个关键环节——专属运行环境的搭建。近期公开的一篇DeepSeek研究论文，完整披露了其自研的DSec（DeepSeek Elastic Compute）系统的技术细节，这套系统专为Agent训练批量生成隔离沙盒。
DSec的性能表现相当亮眼：每秒可生成5000余个沙盒，单日累计可达300万个，峰值同时运行的沙盒数量可达38万个。支撑这一规模的单集群配置同样可观，包含约160个节点、3万核CPU与250TB内存。
为何Agent的训练对环境要求如此苛刻？与大模型稳定的GPU集群训练环境不同，Agent需要在运行过程中执行代码、编译程序、启动工具甚至安装操作系统，每一步操作都会改变环境状态，很容易破坏当前运行环境。因此每一轮Agent训练都需要全新的干净沙盒，且使用后直接销毁，随用随弃。这意味着基础设施需要以每秒5000个的速度，为每个沙盒预装一整套操作系统和工具链，同时还要避免数十万并发沙盒耗尽集群的内存与CPU资源。
DSec首先要解决的核心问题，是不同类型的Agent任务对沙盒环境的需求差异极大，且需要在同一平台上实现统一调度。举例来说，用于刷OJ题的Agent仅需要无状态的函数调用环境，跑完即可获取输出，甚至不需要持久化文件系统；而处理SWE-bench任务的Agent则需要完整的Linux用户态环境，需要在其中安装依赖、修改代码、运行测试用例，任务进行中还可能需要新增软件包；针对安全攻防或桌面操作的场景，容器级别的隔离强度不足，Agent需要操作浏览器甚至桌面环境，一旦Agent存在漏洞可能会破坏宿主机，因此必须使用虚拟机级别的隔离；最极端的场景则是训练操作商业软件的Agent，需要完整的Windows或macOS系统，带有图形界面和驱动程序，几乎与真实电脑无异。
针对这四类场景，DSec分别提供了四种后端支持：FnCall用于处理无状态函数调用，Container基于Docker容器运行，MicroVM使用Firecracker实现轻量级虚拟机，Full VM则通过QEMU运行完整的操作系统。四种后端的隔离强度和资源开销逐级递增，但训练框架对外暴露的是统一的Python SDK libdsec，无论底层使用哪种技术栈，创建沙盒、执行命令、获取结果的调用流程完全一致。
为了让四种后端在同一套集群上稳定运行，DSec的调度层也做了针对性设计。整套调度链路分为六个层级：从训练框架的创建请求出发，先经过IAM认证鉴权，进入API Server，再由调度引擎根据集群资源余量选择目标节点，节点上的Edge组件负责实际拉起对应类型的沙盒。沙盒的网络出口和包管理镜像由Aether统一代理，Agent在沙盒内执行的每一条命令和产生的所有输出，都会通过名为Chronus的沙盒内通信组件中转回训练框架，让训练框架可以实时掌握Agent的执行进度并给出对应反馈。通过资源超分和高密度部署策略，单个节点可以同时承载3200个容器或800个MicroVM。
沙盒环境的构建与分发优化
在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分钟以上；同时按需加载的磁盘写入量也从约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恢复后沙盒可以继续执行，训练框架无需再自行实现断点恢复逻辑。当单个集群无法承受峰值负载时，DSec会自动触发cloud bursting机制，将溢出的任务调度到云端虚拟机。实测显示，当集群利用率超过80%时，200台云虚拟机即可吸收约30%的峰值负载。
智能体的作弊与安全防御
对于Agent而言，沙盒不仅是运行环境，更是一道安全围栏。论文中披露了多起Agent在训练过程中自行发现的奖励黑客（reward hacking）手段，即Agent通过不正当路径完成任务，从而获得更高的评分。
这些Agent首先瞄准的是Chronus组件——沙盒内负责与外界通信的模块。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本身带来的安全风险——那个需要被防御的对手，恰恰就是正在被训练的智能体本身。
