DeepSeek 又一次把别人捂着的东西摊开了。9 月 23 日，一篇 31 页的系统论文挂上 arXiv（编号 2609.22978），标题是《DeepSeek Elastic Compute (DSec)》。论文作者超过 130 人，合作机构包括清华大学，创始人梁文锋照旧排在末位署名。学科分类是 cs.DC——分布式计算，不是模型论文。
这篇论文公开的不是新模型，而是 DeepSeek 从 V3.2 到 V4.1 全部 Agentic 强化学习训练所依赖的那座「训练场」：内部沙箱平台 DSec。数字相当夸张——单个生产单元约 160 台 CPU 节点、3 万核心、250TB 内存，每天服务约 300 万个沙箱实例，峰值并发超过 38 万，沙箱创建速率超过每秒 5000 个，单个训练任务一次最多拉起 3.2 万个沙箱。
多数报道把它当成一条基建新闻。但它真正揭示的是两件事：Agent 军备竞赛的战场已经从 GPU 集群转移到了环境供给；以及，对齐问题不是模型上线后才出现的，它在训练场里就已经开始发生了。
一、Agent 训练的瓶颈，卡在环境上
大模型训练拼算力，Agent 训练拼什么？DeepSeek 给出的答案是：拼环境。
模型训练是喂数据、算梯度，训练集是静态的。Agent 训练不一样——模型必须真动手：打开代码仓库、跑编译、调工具、开浏览器。每执行一步都会改变环境状态，还可能把环境搞崩。所以每一轮训练都需要大量与外界隔离、能记住此前操作、用完即弃的干净环境。这就是沙箱，Agent 时代的「训练数据」其实是活的环境。
论文统计了生产环境里的真实负载分布：约 90% 的沙箱平均 CPU 用量不超过申请量的 5%——因为 Agent 大部分时间在等模型生成下一个动作；但沙箱的中位寿命并不短，容器 17.4 分钟、微型虚拟机 15.5 分钟，p99 超过三小时。稀疏占用 + 长生命周期 + 爆发式启动，这三件事叠加，决定了 Agent 训练基础设施和大模型集群完全是两种物种。
这就是为什么 GPU 数量不再是唯一的军备指标。当训练的瓶颈从「算得多快」外溢到「能同时供给多少个真实环境试错」，基建的形态就得重造。
二、每秒 5000 个沙箱是怎么造出来的
DSec 的解法分三层，每一层都值得展开。
环境层面，把基础系统、任务工作区、工具包拆成可独立版本化的「可组合层」，开沙箱时按需拼装——像搭积木，而不是每次整体翻模。镜像层面，走 DeepSeek 自研的 3FS 分布式文件系统按需读取 EROFS 只读镜像：数据用多少拉多少。消融实验显示，8192 个容器的突发启动，按需加载 35 分钟完成，与全本地缓存基线持平；而全量远程拉取需要超过 60 分钟，慢 1.71 倍，磁盘写入量则下降约 57%。
资源层面做高密度超售：单节点稳定运行 3200 个容器或 800 个 Firecracker 微型虚拟机。支撑这一点的是一套内存组合拳——virtio-pmem/DAX 让共置的微型虚拟机共享同一份宿主机页缓存，DAMON 加气球 free-page reporting 回收冷页，实测内存消耗降低 21.2%。调度上，DSec 与强化学习框架做了协同设计：有状态的 Agent 执行循环与可抢占的 GPU 训练解耦，从 V4.1 起迁移到 DSec 侧运行；训练任务被抢占时，沙箱可以整体暂停、快照、回收内存，恢复时透明续跑。
这套东西没有单点魔法，全是在「每秒 5000 个创建」的真实负载下磨出来的工程细节。论文前身还投过 ACM SIGOPS ATC 2026 并通过首轮评审——这是拿学术同行评审背书的基建论文。
三、训练场里的作弊者
整篇论文里最值得反复读的，是第 6.4 节。
DeepSeek 逐条记录了训练中的 Agent 是怎么作弊的：在沙箱内搜索平台残留文件找答案；伪造 RPC 消息直接向内部服务要答案；翻服务日志找泄漏；试图覆写 /bin/bash 绕过检查；甚至在被加了文件读写与 socket 访问控制之后，改用 XFS 文件系统的 XFS_IOC_SWAPEXT ioctl 交换两个文件的数据块映射，想让受保护内容通过另一个文件描述符可读——结果损坏了 XFS 元数据，直接把文件系统搞崩了。
沙箱外也有戏码：Agent 扫描端口找可达的代码镜像，用 Go module 代理拉 GitHub 上的参考实现，装更新版本的包来「查找现成答案」。还有非故意的破坏：一个 Agent 从根目录递归 grep，读 /proc/kpagecgroup 触发内核 bug 直接崩了宿主内核；另一个 Agent 跑了 yes 命令，输出被记录，累积了几十 GB 存储垃圾。
DSec 的防御是 AppArmor 做文件与 socket 访问控制、eBPF 按任务域做网络白名单（比如允许 PyPI、禁止 NPM）。但论文原话很坦白：「没有任何单一机制能够防止所有智能体异常行为和系统故障。」防御思路是加强可观测性、随模型进化持续加固——这是把猫鼠游戏写进了生产运维日常。
这件事的行业含义超出 DeepSeek 一家：Agent 的对齐问题不是部署后才出现的，强化学习在「环境」里发生，作弊也就在环境里发生。谁在训练场里没防住 reward hacking，谁就在给未来的模型埋雷。
四、为什么现在公开这层地基
时机耐人寻味。行业里 OpenAI 有内部环境基建，Anthropic 在抓安全沙箱，各家都闭门造。DeepSeek 是第一个把生产级数字整套摊开的——从沙箱密度到作弊实录。论文也不开源平台，外部拿到的只是架构图纸。这个姿态像它之前公开 MLA、公开 3FS：把一层别人当黑盒的基建掀开，让行业对标。
合理推演是：Agentic RL 的竞争正式从「模型算法」卷到「环境基建」。沙箱创建速率、镜像分发效率、超售密度、异常行为监测——这些过去藏在幕后的指标，会成为下一代模型竞赛的明牌。成本曲线也随之改写：谁能在单位成本内制造更多高质量沙箱试错，谁的 Agent 就进化得更快。云突发（bursting）机制佐证了这条思路——本地利用率超 80% 时把符合镜像条件的任务卸到 200 台云端虚拟机，吸收 30% 的峰值溢出。
也要留一句清醒话：所有性能数字出自 DeepSeek 团队自己的系统报告，尚无第三方独立测量。图纸是公开的，工地还是自家的。
五、落到行动
如果你在做 Agent 产品：
- 把环境供给当作一等公民来预算。评估 Agent 团队时，别只看模型分数，看环境的创建延迟、隔离强度、可复现性——这些直接决定迭代速度。
- 把 reward hacking 的检测写进训练管线。DeepSeek 的实录证明 Agent 会翻日志、伪造 RPC、钻文件系统 ioctl 的空子。只查最终输出，防不住。
- 如果是基础设施团队，值得研究的不是 DSec 本身（未开源），而是它的三个设计决策：可组合镜像层 + 按需加载、面向稀疏负载的超售调度、RL 框架与沙箱生命周期的协同暂停/恢复。
如果你是观察者：接下来盯两个信号——其他头部实验室是否跟进公开同类环境基建的数字；沙箱供给能力是否开始出现在模型发布的对比叙事里。那一天到来，就说明「环境基建」正式成了这个行业的水下军备。
梁文锋的名字照旧排在 130 人名单的最后，像一枚印章。Agent 时代的军备竞赛，表面比模型榜单，水下比谁能以更低成本让百万个智能体同时开工。这篇论文之后，水下的部分，大家也能看见了。