# DeepSeek 发表 DSec 论文公开 Agent 训练沙盒基础设施，梁文锋署名

- 来源：IT之家（RSS）
- 发布时间：2026-09-23 11:37
- AIHOT 分数：73
- AIHOT 链接：https://aihot.news/items/cmudlo7770fmerogg4hhbdvhq
- 原文链接：https://www.ithome.com/1/006/148.htm

## AI 摘要

DeepSeek 发布 DSec（DeepSeek Elastic Compute）论文并署名梁文锋，公开用于 Agent 训练的沙盒基础设施技术细节。

## 正文

大模型训练拼的是算力，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

本文来自微信公众号：量子位（ID：QbitAI），作者：克雷西，原标题《DeepSeek 新论文公开 Agent 训练！梁文锋署名》