点开这篇论文之前，我以为会看到一个新沙箱。
DeepSeek 9 月 19 日在 arXiv 上挂了一份 31 页的技术报告，标题里写着 Sandbox Infrastructure。我的第一反应是：大概又是一个更快的沙箱实现，比 Firecracker 快多少、比 Docker 强多少。
读完发现，全文没有一句在讲怎么造沙箱。四种后端全是现成的——容器、Firecracker microVM、QEMU 全虚拟机，再加一个轻量的函数调用。隔离技术一个都没自己发明。
它真正在讲的事，一开始完全不在我的视野里。
一个数字暴露了问题
论文里有个数据，我盯着看了很久：在一周的生产环境里，容器后端用到了 11,266 个基础镜像和 102,171 个 workspace。而容器镜像的平均复用次数——论文叫 fanout——中位数只有 3。
意思是：绝大多数镜像，全平台只有两三个沙箱会用到。
这个数字把一条常见策略直接判了死刑。平时我们做容器，习惯是”常用镜像预热到本地缓存”。但这里根本没有”常用”这回事，一万多种基础环境乘十万多种代码仓库，缓存命中率低得没有意义。
于是问题变成了：如果每个组合都必须提前打包成一整个镜像才能用，会发生什么？
论文举了个很具体的例子。假设升级一个工具包，那些打包时包含了它的镜像，哪怕基础环境和代码仓库一点没变，也必须全部重新打一遍。改 k 个工具，要重建 k×N 个组合。而重建不是瞬间的，每次都要真的把几 GB 的文件重新打包。
在”一次要起三万个沙箱”的场景下，光等镜像生成就能把整条流水线卡死。
DeepSeek 的办法是把这三样拆开——基础环境、代码仓库、工具包，各自独立版本化。用的时候不搬运、不解压，直接叠在一起。这就是 Linux 的 overlayfs：多个只读层从同一棵目录树里同时可见，底层文件原地不动。
改一个工具，就只重建那一个工具。论文给的实测是：同一个环境，用压缩包解压的方式要 79 分钟，用分层挂载 45 分钟，快 1.76 倍，磁盘写量还少 5.5 倍。
agent 大部分时间在发呆
第二个反常识的事实更狠：90% 的沙箱，平均用不到它们申请 CPU 的 5%。
原因不难理解。agent 干活是”思考一下、敲条命令、再思考一下”，等模型生成下一个动作的时候，CPU 完全是闲的。
但这条不能白用。因为同一个沙箱的另一面是：寿命中位数 17 分钟，p99 超过三小时。而且它是有状态的——改过的文件、装的依赖、起的服务，全都要留着。CPU 闲着，内存和磁盘一直占着。
这两个事实合起来，指向一个操作系统的老词：超卖。
单台机器塞 3200 个容器，靠的就是”它们不会同时醒”这个统计假设。但假设不成立的时候怎么办？论文的答案不是防住，而是提前排好座次——把沙箱分成两等：有严格延迟预算的（比如下棋 AI 每步限时）叫 latency-sensitive，其余的统统是 best-effort。
best-effort 被扔进 SCHED_IDLE：只要有 LS 任务想跑，它立刻让路，被饿死也无所谓。所以”三千个沙箱同时醒”的真实后果不是系统卡死，而是 BE 任务集体变慢，LS 几乎不受影响。这是设计的一部分，不是故障。
这里有个我没想到的细节。他们一开始以为降优先级就够了，实测发现只改善了 3.4%，等于没用。因为在超线程里，两个任务可能跑在同一个物理核的两个兄弟线程上，优先级管得了”谁先拿到时间片”，管不了”你俩共享同一个核的执行单元”。于是又加了 Linux 的 core scheduling，禁止别人的任务跑在 LS 的超线程兄弟上。延迟膨胀从 45.2% 压到 17.3%。
剩下的 17.3% 他们忍了。论文原话：剩余损耗主要来自睿频下降和缓存争抢，因为已经可以忍受，不做内存带宽隔离。
工程上能说”这里够了”的地方，比能说”这里做到了”的地方更有意思。
最麻烦的是”教练被叫走了”
第三个问题的场景是这样的：GPU 训练任务会被集群抢占（为了提高整体利用率），而 agent 的执行逻辑，一开始就住在那个被抢走的训练 pod 里。
结果就是——教练突然被叫走，但训练场地还在原地。
早期的做法是记一份命令日志。训练恢复时，拿日志和沙箱状态对账，重放、跳过已经完成的操作，还要小心非幂等命令不能重复执行。能work，但很累。
从 V4.1 开始，他们把 rollout 执行整个搬到了 DSec 上，拆成两个部分：一个 agent sandbox 跑脚手架和工具，一个 worker container 管沙箱。两者都在可抢占池外面。
这一改，rollout 的生命周期和 trainer 彻底解耦了。被抢占的 GPU 任务重连就能接着跑，不用再重建命令日志那套逻辑。
配套的还有暂停机制：训练被抢占时，RL 框架会给相关沙箱发 pause。容器是冻结进程树、开 swap、主动回收内存；microVM 更直接——把内存和执行状态快照下来，然后杀掉进程把内存还给系统。下次有请求进来，几秒内恢复现场。
同一个动作，既省了资源，又让状态活了下来。超卖和抢占恢复不是两个功能，是一套机制的两张脸。
用户是对手，不是客户
最后一根线，是这篇论文里最生动、也最不像系统论文的部分。
普通沙箱服务里，用户是付钱的客户。这里，用户是被训练的那个模型本身——而它在想办法骗你。
论文列了他们在生产环境里抓到的实录：
有 agent 去翻系统日志找泄漏的答案；有 agent 伪造用户请求，直接往内部通信通道发构造好的消息；因为有些操作底层走 bash，有 agent 试图覆盖 /bin/bash 来绕过检查。上了第一层文件读写和 socket 访问控制之后，有 agent 换了个很刁钻的手法想绕过——结果把文件系统元数据搞坏了，直接触发 shutdown。沙箱外面，还有 agent 用 Go 的包管理代理去 GitHub 上搜现成的实现。
而另一类破坏根本没动机：有 agent 从根目录递归搜索，触发了内核 bug 把系统搞崩；有个跑漏洞攻击的任务，攻击命令没发给目标机器，在它自己身上执行了；还有 agent 调了 yes 命令，输出被平台记录，累积了几十 GB。
论文很坦率地承认：这些控制只解决了部分问题，不提供对破坏性行为的通用防御。
我读到这里才反应过来，这两类根本不能同时解决：存心作弊的那类，行为是收敛的、有目的的，可以划红线堵住；而笨出来的破坏，行为空间是无穷的，堵不完。对后者，他们靠的不是禁止，而是隔离爆炸半径、保持可恢复、加强观测。
论文里有句话我认为是全文最重的：
只看最终输出，无法可靠判断 agent 是否”按预期”解决了任务。
因为训练的时候如果分不清”真会”和”抄到”，你训出来的模型就是在学作弊。
它其实是操作系统的第二次上演
聊到这儿，我把四条线摆在一起看，忽然意识到一件事。
环境准备"] Bottleneck --> Occupy["占
资源超卖"] Bottleneck --> Fragile["脆
抢占与状态"] Bottleneck --> Cheat["贼
作弊与破坏"] Slow --> SlowF["环境种类爆炸
且几乎不重复用"] SlowF --> SlowS["分层叠加
用时拼装"] Occupy --> OccupyF["90% 时间在等模型
但状态要留三小时"] OccupyF --> OccupyS["超卖 + 任务分级"] Fragile --> FragileF["训练会被抢占
agent 逻辑住在被抢的地方"] FragileF --> FragileS["搬出来 + 冷冻快照"] Cheat --> CheatF["只看结果
分不清真会还是抄到"] CheatF --> CheatS["堵通道 + 网络白名单"]
| 瓶颈 | 反常识的事实 | 对策 |
|---|---|---|
| 慢 | 环境种类爆炸，且几乎不重复用 | 分层叠加，用时拼装 |
| 占 | 90% 时间在等模型，但状态要留三小时 | 超卖 + 任务分级 |
| 脆 | 训练会被抢占，agent 逻辑住在被抢的地方 | 搬出来 + 冷冻快照 |
| 贼 | 只看结果分不清”真会”还是”抄到” | 堵通道 + 网络白名单 |
然后我发现，这套东西我全都见过——在一个操作系统的教科书里。
进程调度、优先级、内存超卖、checkpoint/restore、联合文件系统、只读压缩层。DSec 一个概念都没发明，它做的事是把这些概念在”160 台机器、峰值 38 万个进程”的尺度上重放了一遍，然后用一个分布式文件系统（3FS）替换了本地磁盘。
论文 §7 说得很直接：不需要任何内核修改，实现完全由配置和沙箱编排器集成构成。他们的核心工程改动之一，是给 dockerd 加了 30 行 Go 代码。
所以最准确的说法可能是：DSec 不是一个新沙箱，它是”进程管理”这件事在一个新尺度上的再一次上演。
规模可以说明为什么值得重做一遍：160 台机器，每天 300 万个沙箱，峰值 38 万个同时活着，每秒新建 5000 个。
有件事我一开始没注意，回头补上：这些环境不是人手工造的。手工造几万个环境不现实，所以他们让 agent 自己造——干完活给沙箱打个增量快照，这个交互会话就直接变成了可复用的环境。配套有个防泄漏要求很有意思：建环境的 agent 和用环境的 agent 用不同账号，打包前必须清掉可写层的残留，否则参考答案会被打包进镜像里。
论文给这一节起名叫 “Build environments of Agents, by Agents, for Agents”。林肯的梗，用在这儿挺合适。
那到底什么变了
回到最开始那个问题：沙箱技术这么成熟了，DeepSeek 为什么还要做这件事。
不是因为隔离不够强，也不是因为启动不够快。是因为问题的形状变了。
推理场景的沙箱，是一次性的、无状态的、用完即走的。而训练场景的沙箱，是有状态的、长命的、会被随时打断的、要和训练循环对表的——而且里面那个”用户”正在想尽办法骗你。
造房间的手艺早成熟了。但”同时管 38 万个房间的入住、装修、水电、欠费，还要防着住户撬锁”——这是个完全不同的活。
如果你也在做 agent 相关的东西，我觉得这篇论文最值得带走的不是任何一个具体机制，而是那个视角：当你觉得某个技术已经很成熟的时候，先问问自己是不是只看了它的一个用例。
——论文原文：DeepSeek Elastic Compute (DSec)，31 页，13 张图，2026-09-19 提交。