2026 年 9 月 19 日，DeepSeek 在预印本平台 arXiv 上传了一篇题为《DeepSeek Elastic Compute（DSec）：面向大规模 Agent 训练的沙盒基础设施》的技术论文。这篇论文的提交日期是 9 月 19 日，作者名单超过 130 人，DeepSeek 创始人梁文锋位列最后一位。论文首次系统披露了 DeepSeek 用于大规模 Agent 强化学习与评测的生产级沙盒基础设施 DSec，把过去一年多里支撑其 V3.2 到 V4.1 全系列 RL 训练与评测的底层工程体系完整摊开。
要理解这篇论文的分量，需要先看清一个正在发生的范式转移：大模型训练的主战场，正在从“生成 Token”转向“执行任务”。而在 Agent 训练中，真正的瓶颈可能不在 GPU，而在环境。
一、Agent 训练为什么需要“一个世界”
传统大语言模型的强化学习，很多时候可以围绕静态的输入、输出和奖励信号展开。模型生成一段文本，奖励模型打一个分，梯度回传，一轮结束。但 Agent 训练的逻辑完全不同。
论文指出，Agent 需要真正进入一个可交互的执行环境，实际执行检查代码、调用工具、运行命令、修改文件等操作。以编程智能体为例，它可能需要读取代码库、修改文件、安装依赖、执行 Shell 命令、运行测试、读取报错，再继续决策。模型每执行一步，都可能触发环境状态的变化，而下一步的执行又建立在前面的结果之上。
这意味着，Agent 训练中除了模型和数据，研究人员还需要维护一大批“工作现场”。这些环境得足够接近真实机器，可以安装依赖、运行软件，还要能在一次任务结束后恢复干净状态，交给下一轮 rollout 继续使用。问题在于，这些沙盒既多又不轻。论文披露，训练过程中一次任务曾同时拉起 3.2 万个沙盒。而这些沙盒并不会跑满——在 Agent 执行任务时，沙盒经常处于等待下一步操作的状态，CPU 利用率并不高，但内存和可写状态仍然需要持续保留。
“起一个容器、跑完一个任务”的传统思路，在这种规模下很难继续撑下去。DSec 要同时解决的，就是沙盒的批量创建、资源调度、环境复制、状态保存、暂停恢复和安全隔离这一整串问题。
二、四种后端与统一接口：从函数调用到完整操作系统
不同类型 Agent 任务对沙盒环境的要求差异极大，这一点在论文中被系统性地梳理出来。
最轻的任务可能只需要一次函数调用，执行代码、返回结果即可，连文件系统都不需要持久化。软件工程任务则需要完整的 Linux 用户态，能装依赖、改代码、跑测试。安全攻防和 Computer-use 场景对隔离要求更高，一个有漏洞的 Agent 可能顺手把宿主机搞挂，必须上虚拟机。最极端的情况是训练操作商业软件的 Agent，它需要一个完整的 Windows 或 macOS 系统，带图形界面、带驱动，跟真实电脑几乎没区别。
DSec 为此提供了四种后端：FnCall 处理无状态函数调用，Container 跑 Docker 容器，MicroVM 用 Firecracker 做轻量级虚拟机，Full VM 用 QEMU 跑完整操作系统。四种后端的隔离强度和资源开销逐级递增，但训练框架那边看到的是统一的 Python SDK（libdsec）。不管底层是容器还是虚拟机，创建沙盒、执行命令、拿结果的调用方式完全相同，训练框架不需要为每种环境类型单独适配。
这种设计的工程含义在于：上层 RL 框架可以用同一套代码逻辑调度从“刷 OJ 题”到“操作商业软件”的所有任务类型，而底层的隔离、资源管理和生命周期控制全部交给 DSec 平台处理。
三、规模意味着什么：每天 300 万个沙盒的工程现实
论文披露的生产环境数据，是理解 DSec 复杂度的关键锚点。
一个生产级 DSec 规模单元约由 160 个节点组成，拥有约 3 万个 CPU 核心和 250TB 内存，托管 PB 级镜像。这个集群每天服务约 300 万个沙盒，峰值支持同时运行超过 38 万个沙盒，并维持每秒超过 5000 个沙盒的创建速率。单个训练任务最多可以一次性拉起 3.2 万个沙盒。
每秒创建 5000 个沙盒，意味着每秒要给 5000 台“电脑”装好一整套操作系统镜像和工具链。这还不算完，这些沙盒的环境组合极其复杂。论文统计了一个生产周的数据：容器后端涉及 11266 个基础镜像、102171 个工作区和 103 个工具包，实际运行时 67.8% 的沙盒还会在基础镜像上叠加工作区或工具包。
如果按照传统 Docker 的思路，把基础镜像、工作区和工具包打成一个完整镜像，那么一旦某个工具包更新，所有包含它的组合镜像都需要重新构建和分发，成本随镜像数量和工具包数量的乘积增长，论文将其描述为 O(m·N) 的复杂度。DSec 的解法是把环境拆成三个独立的 EROFS 只读镜像层——基础镜像、工作区和工具包，通过共享和按需组合来避免重复构建与分发。
四、与 RL 框架的协同设计：把“工作现场”存起来
DSec 论文中一个容易被忽略但至关重要的细节，是它与 DeepSeek 强化学习框架的协同设计。
论文写道，DSec 将 Agent 有状态的任务执行与可抢占的 GPU 训练解耦。也就是说，即使 GPU 训练任务被暂停或重新调度，Agent 已经执行到一半的任务状态仍然可以保留下来，待 GPU 资源恢复后继续执行。
这一点在 Agent RL 的语境下意义重大。传统的训练基础设施设计中，计算任务和环境状态是绑定的，GPU 停了，环境也就丢了。但 Agent 训练的特殊性在于，沙盒中的执行过程是有状态的——Agent 已经改了哪些文件、装了什么依赖、执行到哪一步，这些状态丢失意味着这一轮 rollout 的前功尽弃。DSec 把状态保存和恢复做进了基础设施层，使得 GPU 调度和环境生命周期可以独立管理。澎湃新闻的报道用了一个通俗的比喻：能在 GPU 被抢的时候把教室打包封存，等 GPU 回来了再接着用。
五、Agent 会“作弊”：当安全隔离成为训练基础设施的一部分
论文中一个值得特别注意的发现是，DeepSeek 在训练中观察到 Agent 会主动寻找漏洞和“作弊”。
论文列举了智能体异常行为的例子：Agent 可能没有按照预期方式解决任务，而是通过“非预期渠道”获取答案；另一些行为则会直接破坏运行环境。随着 Agent 能力增强，防作弊和行为约束本身正在成为 Agent 训练基础设施的一部分。论文写道：“没有任何单一机制能够防止所有智能体异常行为和系统故障，因此我们将强化系统可观测性，以发现新出现的问题，并随着模型不断演进持续加强 DSec。”
这意味着，DSec 的设计目标不只是“让沙盒跑起来”，还要在数十万并发沙盒中实时监控异常行为、隔离恶意或投机操作、处理模型普通操作错误可能造成的系统级故障。安全隔离在这里不是附加功能，而是训练能否有效进行的前提条件——如果 Agent 可以通过非预期渠道“骗”到奖励，那么 RL 训练就是在优化一个被污染的目标。
六、梁文锋署名的意义与这篇论文的定位
梁文锋在这篇论文中的署名位置是最后一位。在学术论文的署名惯例中，最后一位通常对应资深作者或通讯作者角色。超过 130 人的作者名单，说明这是一项涉及基础设施、系统、算法、安全等多个团队的工程协作成果，而非单一研究小组的工作。
论文的定位也很清楚：它不是一篇提出新模型或新算法的研究论文，而是一份生产级基础设施的系统性披露。论文明确写道，从 DeepSeek V3.2 到 V4.1 的 RL 训练与评测，所有沙盒负载都运行在 DSec 上。这意味着论文中描述的不是原型系统或实验结果，而是已经在生产环境中经受住每天 300 万沙盒负载考验的工程体系。
对于关注 AI 基础设施的人来说，这篇论文的价值在于它把 Agent 训练中一个被长期低估的工程问题摆到了台面上：当模型从“生成文本”走向“执行任务”，训练基础设施的重心也在发生结构性转移。GPU 集群仍然是算力核心，但环境层的规模、复杂度和工程挑战，正在以独立基础设施的形态浮现出来。
论文最后提到，随着 Agent 任务持续变长、交互过程不断增加，执行环境的规模也会进一步扩大。如何让数十万个甚至更多沙盒稳定运行，同时控制资源成本和安全风险，将成为 Agent 训练继续扩展需要解决的问题。DSec 是 DeepSeek 对这个问题的当前答案，而它揭示的，可能只是 Agent 训练基础设施竞争的一个开端。