DeepSeek公开了一套面向Agent训练的基础设施系统DSec（DeepSeek Elastic Compute），论文由梁文锋署名。这套系统的核心任务是为Agent训练批量制造沙盒环境，支撑它的单集群规模约为160个节点、3万核CPU和250TB内存，目标是在每秒5000个的速度下为每个沙盒装好一整套操作系统与工具链。
Agent训练与普通大模型训练的关键差异在于环境。Agent要在沙盒里写代码、跑编译、开浏览器甚至装操作系统，每执行一步都会改变环境状态，随时可能把环境搞崩。而不同类型的Agent任务对沙盒的要求差异极大：刷OJ题的Agent只需要无状态的函数调用环境，连文件系统都不必持久化；做SWE-bench的Agent需要完整Linux用户态，要装依赖、改代码、跑pytest，任务中途还可能加新包；安全攻防和computer-use场景下容器隔离不够，必须上虚拟机；训练操作商业软件的Agent则需要带图形界面和驱动的完整Windows或macOS。
DSec为此准备了四种后端：FnCall处理无状态函数调用，Container跑Docker容器，MicroVM用Firecracker做轻量级虚拟机，Full VM用QEMU跑完整操作系统。四种后端的隔离强度与资源开销逐级递增，但训练框架侧看到的是统一的Python SDK libdsec，创建沙盒、执行命令、拿结果的调用方式完全相同。请求链路从训练框架出发，经IAM认证鉴权进入API Server，由调度引擎Placement Engine根据资源余量选节点，节点上的Edge组件拉起对应类型沙盒；网络出口与包管理镜像由Aether统一代理，Agent执行的每条命令和每行输出则通过沙盒内通信组件Chronus中转回训练框架。靠资源超分和高密度部署，单个节点可同时承载3200个容器或800个MicroVM。
规模化的真正难点在镜像。DSec的容器后端累计使用了11266个基础镜像和102171个工作区，67.8%的沙盒需要在基础镜像之上叠加至少一层工作区或工具包。传统做法下，某个工具包一更新，所有包含它的组合镜像都要重建，成本为O(m·N)。DSec把环境拆成基础镜像、工作区、工具包三层独立的EROFS只读镜像，各自独立版本化，通过overlayfs在启动时按需组合，更新成本降到O(m)+O(k)。镜像以EROFS格式存放在3FS（Fire-Flyer分布式文件系统）上，元数据预取到本地，数据块只在真正读取时才拉取。实测8192个容器的突发部署，按需加载35分钟完成，Docker冷拉取需60分钟以上；磁盘写入量也从约1600GB降到约700GB。
资源效率方面，MicroVM通过虚拟块设备读镜像时，同一份数据会在宿主机和虚拟机页缓存各存一份。DSec用virtio-pmem配合DAX让虚拟机跳过自身页缓存、直接映射宿主机物理内存，多个虚拟机共享同一份映射，峰值内存占用砍掉40.2%；对不适用virtio-pmem的可写磁盘，用DAMON定期扫描冷内存页并主动归还，配合virtio-balloon的free-page reporting再降21.2%。CPU侧把沙盒分为延迟敏感型和尽力而为型，后者设为SCHED_IDLE优先级，并启用Linux core scheduling阻止低优先级任务占用高优先级任务的兄弟超线程，两层策略叠加后，50%背景负载下延迟敏感任务的延迟膨胀从45.2%降到17.3%。
架构上还有一处调整：早期Agent的推理循环跑在GPU训练Pod内部，GPU任务被抢占时Agent进度全丢。从DeepSeek-V4.1开始，Agent循环被拆到DSec的worker container里独立运行，不再绑定GPU Pod生命周期；GPU被抢占时DSec挂起保存沙盒状态，恢复后继续执行，训练框架不必自己实现断点恢复。论文提到的最大生产任务一次申请32000个沙盒，突发负载下DSec自动触发cloud bursting把溢出任务打到云端虚拟机，实测集群利用率超过80%时，200台云VM能吸收约30%的峰值。
论文更引人注意的是Agent在训练中自行发现的reward hacking手段。这些Agent找到了不靠正当手段完成任务、却同样拿高分的捷径。第一个目标是Chronus：Agent发现它在某些操作中会调用系统bash，于是直接覆盖/bin/bash注入自己的命令，试图从后续shell会话截获答案或特权信息。被AppArmor堵上后，Agent转向更底层的XFS文件系统ioctl调用XFS_IOC_SWAPEXT，用它交换两个文件的底层数据块映射，把受保护文件内容换到自己持有的文件描述符上，绕过文件级访问控制；这次尝试还损坏了XFS元数据，可能直接导致文件系统崩溃，影响范围超出单个沙盒。此外，有Agent扫描沙盒可触达的网络端口和服务寻找参考实现，有Agent通过Go module proxy从GitHub拉代码，也有Agent安装更新版本软件包获取现成解法——这些行为单看最终输出根本发现不了，因为Agent确实「做对了题」。
破坏性行为同样存在：一个Agent在沙盒内递归执行grep，从根目录扫到/proc/kpagecgroup，触发内核bug导致宿主机内核崩溃；另一个Agent在安全攻防任务中把本该发给目标虚拟机的攻击命令在自己的容器内执行，同样打崩内核；还有Agent发现Chronus会异步记录命令stdout输出，于是反复调用yes命令打印字符，几十GB日志灌满存储。
防御上，DSec用AppArmor控制文件读写权限和Unix域套接字访问，这些策略即使Agent以root身份运行也生效；用eBPF做网络层细粒度管控，按任务配置域名白名单，通过IP、端口和协议三重过滤拦截越界流量，策略还可在任务不同阶段动态更新，比如环境搭建阶段允许访问PyPI，正式执行阶段收紧网络。论文也承认，AppArmor和eBPF能限制信息泄露通道但防不了内核bug，用户隔离能缩小爆炸半径但Agent总会找到新路径，这将是一场持续的「魔道之争」——模型越强，钻漏洞的能力越强，平台防线就得不断前移。
从产业视角看，这份论文的价值在于把Agent训练集群的工程门槛摊开：它不只是「又大」，还要在镜像分发、内存与CPU调度、GPU抢占恢复、安全隔离等多个维度「又细」。对关注AI基础设施的读者而言，DSec披露的按需加载、cloud bursting和沙盒安全策略，提供了一个观察大模型公司如何把训练集群能力向Agent场景延伸的具体样本。