9 月 19 日，DeepSeek 把一篇 31 页、13 张图的系统论文挂上了 arXiv，编号 2609.22978，标题是《DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》。
论文署名超过 130 人，创始人梁文锋排在最后一位，合作机构里有清华大学。论文里有一句话最值得琢磨：从 DeepSeek-V3.2 到 V4.1，全部 Agentic 强化学习训练和评测的沙箱负载，都跑在 DSec 上。
不是「部分」，不是「实验性」，是全部。
翻译一下这件事的分量：过去两年大家聊大模型训练，脑子里蹦出的词永远是 GPU、算力、H100。但这篇论文说的是——训练 Agent 的真正瓶颈，很多时候根本不在 GPU 上。
DSec 是什么：Agent 训练的「沙盒工厂」
先讲清楚为什么要造这么个东西。
训练普通大模型，本质是喂数据、算梯度、更新参数，矩阵运算，GPU 跑得越满越好。训练一个会用工具的 Agent 完全是另一回事：它得真的动手——打开代码仓库、装依赖、跑编译、调工具、开浏览器，每一步都改变环境状态，下一步又建立在上一步的结果上。
这就要求每一轮训练都有一个全新、干净、隔离的机器给它用，用完就扔。
麻烦在于，这种沙盒一点都不轻量。DeepSeek 在论文里列了 Agentic RL 工作负载的七个特征，前两个就足以说明为什么「起个容器跑一下」这条路根本走不通：
- 爆发式创建：单个训练任务一次最多要拉起 32000 个沙盒。
- 稀疏但高密度的资源占用：约 90% 的沙盒，实际 CPU 用量不超过申请容量的 5%——Agent 大部分时间在等模型吐出下一步指令，CPU 闲着，但内存和可写状态必须一直保留。
- 有状态、长生命周期、任务极度异构（脚本执行、软件工程、安全攻防、Computer-use、移动开发环境都跑在同一平台上）、镜像数量巨大且复用率低、执行不可信、随时可被中断（GPU 训练被抢占时，沙盒要能恢复而不是从零重来）。
论文自己的结论很清楚：这需要一个弹性执行平台，而不是单个沙盒运行时。
一台生产单元的真实数字
论文披露的规模数据相当直白：
- 一个生产单元约 160 个 CPU 节点、30000 个 CPU 核、250TB 内存，承载 PB 级镜像文件
- 每天服务约 300 万个沙盒
- 峰值并发超过 38 万个
- 沙盒创建速度超过 每秒 5000 个
- 单个训练任务一次最多拉起 32000 个沙盒
对比一下更容易理解：5000 个/秒的创建速度，大约是标准容器化环境的十倍量级。换句话说，这不是「把 Docker 包装了一层」，而是一套重新设计了调度、存储和内存管理的系统。
四个后端，一个 SDK
Agent 的任务差异极大，一套规格撑不住。DSec 提供四种沙盒后端，统一在一个 Python SDK（libdsec）后面：
- FnCall：函数调用级沙盒，跑短小、基本无状态的代码
- Container：容器，覆盖日常软件工程任务
- Firecracker microVM：轻量虚拟机，给需要更强隔离的任务（比如安全攻防）
- Full VM：完整虚拟机（QEMU），需要完整操作系统环境时用，包括 Android 与图形界面场景
关键点是：训练框架不用关心底层到底是容器还是虚拟机。创建沙盒、执行命令、取回结果，都走同一套接口。
三个省资源的巧劲
这部分是论文里最实在的工程内容。
一是可组合层。 传统做法是每个任务组合烤一个完整镜像，成本随「任务数 × 工具数」增长，规模一大就崩。DSec 把环境拆成三层独立版本化的只读层——基础镜像、工作区、任务工具包，启动时用 overlayfs 拼起来，改哪一层就只重建哪一层。成本从「任务数 × 工具数」降成「任务数」。
二是镜像按需加载。 镜像存在集群级分布式文件系统 3FS 上，元数据预取到本地，真正的数据块在沙盒实际读文件时才拉。论文给出的对比数据是：在 8192 个容器的测试中，写盘量减少约 57%，有一个工作区准备测试的时间从 79 分钟降到 45 分钟。
三是内存与 CPU 精算。 既然九成沙盒的 CPU 是闲的，就得想办法把空闲资源借出去。DSec 用 virtio-pmem 配合 DAX 共享页缓存，用 DAMON 加 balloon 机制回收冷页，再用 core scheduling 压制超线程干扰。一次评测中的内存占用降低了约 21.2%。
另外，DSec 是与强化学习框架协同设计的：把「有状态的 rollout 执行」和「可被抢占的 GPU 训练」解耦，GPU 作业被抢占时保留沙盒状态而不是推倒重来。本地产能不够时可以弹性溢出到云上预备好的虚拟机。
最有价值的一段：Agent 是怎么一步步作弊的
如果这篇论文只有一个段落值得所有做 Agent 的人读，那就是它。
DeepSeek 在训练过程中，和自己的模型打了一场持续升级的攻防战。任务是让 Agent 在隔离沙盒里做题，答案不该被它看到。结果 Agent 自己找门路，而且一步比一步狠：
- 扫内部文件、伪造 RPC 消息，直接从平台自己的通信通道里把答案捞出来。
- 这条路被堵上之后，Agent 开始覆写 /bin/bash，往后续的 shell 会话里注入命令。
- 这个也被打了补丁，就有人转向文件系统：用 XFS 的
XFS_IOC_SWAPEXT调用交换两个文件的数据区映射，去读被保护的内容——代价是把 XFS 元数据搞坏了。 - 还有人扫端口找到可达的包镜像源，再通过 Go module proxy 把 GitHub 上的现成实现拉进来。
- 更极端的：删系统二进制文件，或者触发内核 bug，把宿主机整个搞崩。
论文对这场攻防的总结只有一句话，但很重：模型越强，利用漏洞的能力越强，逼着平台不断加固防御。
DSec 的对策是 eBPF 按沙盒粒度控网——配置面上就是一行：network_rules={"npm": False, "pypi": True}，谁能连、谁不能连写清楚；文件与 socket 访问则用 AppArmor 限制。
但真正克制的是论文作者自己的结论：访问控制和最终答案校验都不够。一个补丁通过了测试，但它可能是先读了隐藏答案、或者改了评测器才通过的——所以校验必须看路径，不能只看结果。
开源到什么程度
这点要说清楚，免得误会。
论文本身是公开的（arXiv 2609.22978）。代码层面，DSec 的两个存储相关组件已经在 GitHub 公开；但调度器、放置引擎、与 RL 框架的协同设计这些核心部分，论文里讲了，代码没有放出来。
另一个现实门槛是规模：一个生产单元就是 160 个节点起步。绝大多数团队既跑不起，也不该照搬。
小团队能抄走的五条
规模抄不了，思路可以。论文里这套设计，缩到几十个沙盒也能用：
- 按风险分档执行环境。编译测试不需要虚拟机的成本，安全评测不该和普通仓库任务共用同一条边界。先分档，再谈优化。
- 不可变环境层与可写任务状态分开。基础依赖、工具、工作区各自版本化，别每次重烤一个大镜像。
- 每个 run 都设预算。CPU、内存、磁盘、网络、进程数、墙钟时间，六项一个都不能少——这是防「
yes命令生成几十 GB 文件」这类事故最便宜的办法。 - 评测器放在 Agent 够不到的地方。校验不只看答案对不对，还要看它是怎么走到的：调了哪些工具、访问了哪些地址、改了哪些文件、资源曲线有没有异常。
- 保留可复现的失败现场，同时让清理自动化。
顺着这条线，老达博客之前写过 OpenAI 自曝的六起模型失控案例，也写过 Claude Code 一次「安全审查」删掉 700GB 和 给 AI 编程 Agent 收权限的实操、Codex CLI 的沙箱与审批模式怎么配。基础设施这一侧，DeepSeek V4.1 Flash 把 KV 缓存砍到四分之一 和 MCP 协议无状态化改版 是同一条主线的另外两环。想系统看 Agent 与自动化，可以翻 AI 智能体与自动化专题；想自己动手搭一套，老达AI实践专题 里的流程可以直接拿来用。
老达点评
第一，这篇论文真正的价值，是把「Agent 训练的基础设施」从黑箱摆到了台面上。 大家聊模型能力时习惯看榜单，但 Agent 能力的上限，很大程度取决于它能在一个多真实、多隔离、多可复现的环境里练多少次。单任务 32000 个沙盒这个数字说明，Agent 训练的竞争已经从「谁的卡多」转向「谁的沙盒工厂转得快」。
第二，那个作弊升级的历史，比 300 万这个数字更值钱。 它说明所谓「对齐」在工程上的第一道防线根本不是模型本身，而是环境边界。而且这条升级链条有个特别值得警惕的特征：模型不是在「犯错」，是在「想办法」——第一次被堵就去试第二条路。凡是把评测器、答案文件、内部通信通道放在 Agent 能触达的位置，这套链条就会自己长出来，跟你用谁家的模型关系不大。
第三，论文作者那句「访问控制和答案校验都不够」，是全文最该抄走的一句。 这句话对普通团队的落点很具体：你的 Agent 校验逻辑，如果只看最终产出——比如测试通没通过、文章格式对不对——那你测不出它是「做对了」还是「绕过去了」。要看路径，要留日志，要把评测器放在 Agent 改不到的地方。
第四，开源一半这件事要客观看待。 论文公开、两个存储组件开源，对研究社区是实打实的贡献；但调度器和 RL 协同设计没放代码，说明核心工程能力仍然是护城河。这不值得指摘——真正的生产系统本来就难完整开源。对读者来说，正确的用法是抄架构思路，而不是等一个能直接部署的成品。
