DeepSeek 公开训练智能体的沙箱平台；报告里写的「失范」，指的是智能体在偷答案

彭博在北京时间 9 月 24 日零点 25 分发了一条两段的消息，标题是《DeepSeek Tests Efficient, Safer Method for Training AI Agents》1。

第一段写，DeepSeek 详细描述了一种训练 AI 智能体的创新方法，可能让它们学得更高效，同时把引发全球担忧的失范行为压到最低1。

第二段给了两个细节：论文约一万词、约 130 位共同作者，其中包括创始人梁文锋；发布在 arXiv 上，那里登的论文通常还没经过同行评审1。

彭博报的就是这一篇。论文 9 月 19 日已经挂在 arXiv 上，标题是《DeepSeek Elastic Compute (DSec)：面向大规模智能体训练的有效沙箱基础设施》，arXiv 页面标的是 31 页、13 张图2。

它归在分布式与并行计算之下，报告注明一份两页的扩展摘要曾进入 ACM SIGOPS ATC 2026 操作系统赛道的第一轮评审2。

彭博那两个形容词——更高效、更安全——在报告里各自对应着可以逐项核对的段落和数字。

报告标题里的「沙箱」，指的是智能体训练时待着的那个隔离环境。

在这个环境里，模型自己读代码仓库、调工具、执行命令、看输出，一步一步把任务做完2。一次训练要同时开着几万个这样的环境，每个环境里跑的是不同的代码仓库、依赖和服务。

DSec 是负责把这些环境造出来、管起来、用完收回的那层平台2。

它给调用方四种后端：最轻的 FnCall 跑短小的无状态脚本，容器跑软件工程和工具调用任务，Firecracker 微虚拟机留给安全敏感的任务，最重的完整虚拟机用来跑安卓这类需要一整个操作系统的负载2。

规模写在报告第 2.4 节。一个生产单元有近 160 个 CPU 节点、3 万个核心、约 250 TB 内存，管着 PB 级的镜像；一天服务约 300 万个沙箱实例，峰值并发约 38 万，创建速度每秒超过 5000 个2。

单个训练作业一次最多申请 3.2 万个沙箱2。

报告第 6 章开头写着，DSec 承接了从 DeepSeek V3.2 到 V4.1 的全部强化学习训练与评估沙箱负载2。

这套东西也不是第一次露面。4 月 26 日上传的 V4 技术报告里，5.2.5 节的标题是「Sandbox Infrastructure for Agentic AI」，正文用几百字介绍了 DSec 的三个 Rust 组件、四种执行底座、分层镜像加载和密度优化3。

9 月 17 日上传的 V4.1-Flash 报告里，它被写成了 5.1.3 节，标题叫「Running Agents at Massive Scale」4。

9 月 19 日这份，是把那一节展开成了 31 页。

彭博标题里的 efficient，落在报告第 8 章的四组实验上。

四组实验针对的是同一件事：几万个沙箱同时开着，怎么才不把 CPU、内存和存储吃光。

第一组是镜像加载。沙箱启动前要把镜像备好，通行做法是先把整个镜像拉下来解包。DSec 改成按需读取，只取沙箱真正用到的那部分。在一台十节点集群上发起 8192 个容器的突发请求，按需加载约 35 分钟跑完，全量拉取要 60 分钟以上，是前者的 1.71 倍；累计写盘量，按需加载比全量拉取少 57%2。

能这么做的前提写在报告第 4 章：运行时真正读到的数据，只占镜像体积的 4.2% 到 13.3%2。

第二组是把环境拆成能各自升级的层。基础镜像、任务代码仓库、工具包分头打包，启动时叠在一起。同一份工作区，用 tar 包解压的方式跑完要 79 分钟，用只读文件系统层直接挂载只要 45 分钟2。

第三组是内存。微虚拟机里，同一份镜像数据会在宿主和客户机各缓存一份，客户机里的空闲页也不会主动还回去。DSec 把只读层直接映射成宿主页，再用内核的访问监控回收冷页，峰值宿主内存降了 40.2%，按时间积分的内存消耗降了 21.2%2。

第四组是 CPU。一部分任务有严格的单步延迟预算，比如每步限时的棋类智能体。只调低后台任务的调度优先级，延迟最多改善 3.4%；再加上核心调度，同核超线程带来的延迟膨胀从 45.2% 压到 17.3%2。

这些数字换来的是单节点密度：生产环境里一个节点稳定跑 3200 个容器或 800 个微虚拟机2。

V4.1-Flash 报告里有一个可比的对照：做完子 NUMA 分区并把每个工作虚拟机绑到独立 NUMA 域之后，单节点支持的并发容器从约 1000 个提高到 2500 个以上4。

省下来的为什么是这几处，报告第 4 章给了原因。约 90% 的容器和微虚拟机沙箱，平均只用掉申请 CPU 的 5%；容器的中位寿命 17.4 分钟、微虚拟机 15.5 分钟，两者的 p99 都超过三小时2。计算几乎不用，内存却一直占着。

彭博标题里那个 safer，是这条消息里最容易被读过去的一个词。

报告摘要里对应的地方只有一处：DSec 与强化学习框架协同设计，把有状态的 rollout 执行和可抢占的 GPU 训练解耦，并且 mitigates agent misbehavior such as reward hacking——缓解奖励作弊这类智能体失范行为2。

报告第 6.5 节给这句话配了两个引用：Amodei 等人 2016 年的《Concrete Problems in AI Safety》5，和 Skalse 等人 2022 年的《Defining and Characterizing Reward Hacking》6。

后一篇把奖励作弊定义为：优化一个不完美的代理奖励函数，导致在真正的奖励函数上表现变差。换句话说，模型学会了拿高分，任务本身并没有完成。

报告第 6.4 节把这件事写成了生产记录，分成两类。

第一类是智能体在找答案。报告写，沙箱里的智能体会去翻平台管理的文件和通信通道，找残留的答案。

每个沙箱里都有一个叫 chronus 的组件，负责执行命令、读写文件。智能体就从它这里下手：往它的 socket 直接发构造好的 RPC 消息、冒充用户请求；翻它的日志找泄漏出来的答案；因为 chronus 有些操作会调用 bash，它们试过覆写 /bin/bash 绕过检查，或者往后面的 shell 会话里注入命令2。

加上文件读写和 socket 访问控制之后，报告写，有一个智能体改用 XFS_IOC_SWAPEXT 这个 ioctl 去交换两个文件的数据区映射，想把受保护文件的内容从另一个文件描述符里读出来。这次尝试破坏了 XFS 元数据，文件系统被迫关闭2。

沙箱外面，同样是智能体在找答案。它们扫描端口和服务，找可达的镜像站；用 Go 模块代理去取 GitHub 上的代码；装更新的软件包版本，找现成的实现2。

第二类是把运行环境弄坏。一个智能体从根目录递归跑 grep，穿过 /proc，读到 /proc/kpagecgroup，触发内核 bug，把内核搞崩了。另一次，一个漏洞利用任务里本该转发到另一台目标虚拟机的攻击命令，被打进了智能体自己的容器，同样崩掉自己的内核2。

还有一个智能体跑了 yes，连续输出被 chronus 记录下来，在存储上堆了几十 GB2。

同一件事在 V4.1-Flash 报告里写得更直接：During RL training, we frequently observe agents attempting to perform reward hacking or unintentionally crashing the environment.——在强化学习训练中，我们频繁观察到智能体试图进行奖励作弊，或者无意中把环境搞崩4。

那份报告列了智能体用到的具体漏洞：XFS 驱动的权限问题、AppArmor 的非法内存访问、镜像服务泄题4。它还承认，为了压住代码智能体的奖励作弊，他们限制联网、从环境里删掉 Git 历史，并自动清理 Go 模块缓存、node_modules、编译出的 jar 包和 Python 的 pycache 目录；即便如此，测试中仍然出现钻空子的行为，比如把 Ubuntu 的核心软件包反编译去找 CyberGym 的漏洞4。

它把这件事归到规模和模型能力上。V4.1-Flash 报告写，训练规模涨到数百万个并发沙箱之后，主要瓶颈里多了一条：containment of misbehavior by increasingly capable agents，管住越来越能干的智能体的失范行为4。

报告的 Related Work 一节，把它周围的工作分成了三类。

推理侧提供代码执行沙箱的，是 OpenAI 的 Code Interpreter 和 E2B 这类产品；月之暗面的 Kimi K2.5 把这类能力做成了 Agent Swarm2。

训练侧，小米的 MiMo-V2-Flash 和 ComputerRL 都提到了自己的执行环境，但报告说它们的重点在模型和训练设计2。

再往外一层是强化学习框架。智谱的 Slime、字节的 veRL、OpenRLHF、清华的 Seer，解决的是 GPU 调度、通信和样本吞吐2。

报告对这一层的评价只有一句：They treat the execution environment as a black box, assuming that sandboxes are available and correctly configured.——它们把执行环境当成黑箱，默认沙箱是现成的、配置是对的2。

DSec 要占的就是这个位置。而它并不是唯一一家走到这里的中国公司。

月之暗面的 Kimi K3 技术报告里，5.3 节叫「Infra for 1M Agentic RL」，5.3.2 节的标题就是「Sandbox Infrastructure」。报告写，他们同时用传统容器运行时、GPU 沙箱运行时，以及最重要的、自研的 microVM 沙箱运行时 AgentENV；训练与评测期间一共创建了 5121 万 9741 个沙箱，跨 150 万 5678 个镜像，内存超卖比最高到 6.5 倍7。

AgentENV 的仓库是公开的，MIT 许可，最近一次提交在 9 月 21 日8。

这里有一处值得停一下。DSec 报告第 7 章说，它用的 Rust 版 OverlayBD 和自研的 ublk 用户态库已经开源，地址指的就是 kvcache-ai/AgentENV 仓库下的 storage/overlaybd 目录2。而这个仓库 README 的第一句是：AgentENV (AENV) is a platform for running agent environments at scale, powering agentic RL training for Kimi K3.8

DSec 报告只说它对 Rust 版 OverlayBD「有贡献」。两家公司的公开材料里，都没有解释这层关系。

可以确认的是，中国公司在这一层用的镜像格式与块存储组件，出处是同一个仓库。

第三家是智谱。它的 GLM-5 技术报告把 slime 写成统一的后训练基建，并且记下了沙箱层的另一种故障：沙箱本身不稳定，会因为与模型无关的原因失败。报告写，Such failures introduce noisy training signals because they reflect environment instability rather than the model's capability.——这类失败会引入噪声训练信号，因为它反映的是环境不稳，而不是模型的能力。他们的处理方式是逐样本记录失败原因，把环境崩溃的样本剔掉9。

再往下是已经商品化的路。阿里云的 Agent Sandbox 把「AgentRL 场景」写在应用场景的第一条，公开的创建速度是「大规模创建可达 15K Sandbox/分钟」，按秒计费10。

美国这一侧的公开材料，停在另一个位置。

另外三家写的是别的东西。Anthropic 写的是产品侧沙箱怎么同时隔离文件系统和网络11；Google DeepMind 写的是自动评估器怎么给生成的程序打分12；Meta 在 CWM 论文里只提了一句，训练轨迹来自 Python 解释器和「agentic Docker environments」13。三家都没有给出训练沙箱的节点数、并发数或创建速率。

OpenAI 在 8 月 26 日的事件复盘里写：For certain training and evaluation datasets, we use "sandboxes"—isolated virtual computers in the cloud—that execute the actions a model wants to take.——训练和评测的某些数据集里，他们用云上的隔离虚拟计算机当沙箱，沙箱限制模型能跑什么代码、能不能影响外面的世界14。

同一篇复盘承认，这些沙箱在这轮训练和评测里被内部模型突破了。独立调查机构 METR 的核算是：大约 1200 个本该彼此隔离的智能体找到了一个未经批准的信息板互相通信，发出七万多条消息和文件，其中 700 个参与了后续对 Hugging Face 的攻击15。

OpenAI 自己把这件事称作对全世界的「warning shot」14。

把五家在这一层公开的东西排在一起，是这样的。