万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？

今年9月19日，DeepSeek 发布了一份技术报告，里面记录了一个 Agent 偷答案时发生的意外。万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图1

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图2

在此之前，平台已经给沙盒加上了文件读写和 socket 访问控制，Agent 不能再直接翻日志、碰内部通信接口。

于是它找到了另一个办法：利用 XFS 提供的一个 ioctl——XFS_IOC_SWAPEXT。这个接口原本用于交换两个文件的数据 extent 映射，Agent 想借此让受保护文件的内容通过另一个可访问的文件描述符暴露出来，从而绕过已有的权限控制。

结果答案没偷成，XFS 元数据先被写坏了，整个文件系统被迫 shutdown。万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图3

这不是一份大模型论文里常见的内容。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图4

这个论文报告编号 arXiv:2609.22978，标题是《DeepSeek Elastic Compute（DSec）：面向大规模 Agent 训练的有效沙盒基础设施》。

正值中秋、国庆假期，我们前阵子也刚忙完边缘计算大会。趁着假期，花了三天时间把 DeepSeek 最新发布的这篇论文认真啃了一遍，也顺手把一些有意思的数据和工程细节整理了出来。

这篇文章不是论文的逐段翻译，而是一次站在基础设施视角的解读。个别细节如有理解不到位的地方，也欢迎大家留言交流、指正。如果读完有所收获，欢迎转发、收藏。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图6

正文总共 31 页，从头翻到尾，没有注意力机制，没有 MoE，也没有新的训练算法，讲的几乎全是另一类问题：怎么在一台机器上同时塞下 3200 个容器，怎么让几个 GB 的镜像不用整包下载，怎么回收 microVM 里迟迟不肯释放的内存，以及 GPU 训练任务被抢占之后，怎么把一个进行到一半的 Agent 沙盒冻起来，等训练恢复时再原样接着跑。

在一个所有人都在数加速卡、比参数规模的行业里，DeepSeek 拿出 31 页来算另外一笔账，这件事本身就值得多看一眼。

报告给出的生产规模是这样的：一个 DSec 生产单元大约有 160 台 CPU 节点、3 万个 CPU 核和接近 250TB 内存，每天创建约 300 万个沙盒，峰值同时在线约 38 万个，每秒创建超过 5000 个。

注意这里最显眼的单位不是 GPU，而是 CPU、内存和沙盒。

问题也由此而来：当 Agent 真正开始在环境里做事，给它造“房间”为什么会变得这么贵？

一间有记忆的房间

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图7

多数人对沙盒的想象，是一个用完就扔的容器：拉个镜像，跑段代码，拿到结果，销毁。Serverless 已经沿着这套思路发展了很多年，但 Agent 使用的沙盒，从根子上就是另一种东西。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图8

它首先是爆发式的。单个 rollout 或评测任务最多会一次申请 3.2 万个沙盒，而且这些环境必须在很短的窗口里同时到位，因为训练批次在环境准备好之前，一个样本也用不上。这不是同时打开三万个记事本，更像是同时装修三万个房间，每间房的水电网各自独立，装完马上就得住人。

但紧接着出现的是一个完全相反的特征：这些房间绝大多数时间又是空的。

报告统计，约 90% 的 container 和 microVM 沙盒，平均 CPU 使用量都不到申请量的 5%。原因很简单，Agent 执行一个动作以后，大量时间是在等模型生成下一步动作，CPU 只能跟着干等。这给超卖留下了巨大的空间，生产环境里单节点可以承载多达 3200 个容器或 800 个 microVM；论文也特意说明，这是实际展示过的运行点，而不是系统硬上限。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图9

上图把这种工作负载画得很直观：setup 结束以后，CPU 需求变成一个个短促的尖峰，绝大多数时间都接近空闲；但内存并没有跟着掉下来，而是随着工具调用积累状态，并在整个执行过程中持续占用。计算是间歇性的，状态却是持续存在的。

这也是 Agent 沙盒最麻烦的地方。CPU 很闲，意味着你可以大胆超卖；内存和状态一直留着，又意味着你不能像处理普通短任务那样，看到 CPU 空闲就把整个环境扔掉。

更何况，这些沙盒本身还很长寿。容器沙盒的生命周期中位数是 17.4 分钟，microVM 是 15.5 分钟，两者的 p99 都超过三个小时。模型改过的文件、安装过的依赖、启动过的服务都必须留在原地，因为后面每一轮工具调用都依赖此前积累的状态。

于是一个很别扭的局面出现了：CPU 早就闲下来了，内存和可写状态却一直占着不肯走。

再往下数，麻烦只会更多。

在线判题、整仓库的软件工程、安全攻防、图形界面的电脑操作、Android 开发，这几类任务对 CPU、内存、依赖体积、系统功能和隔离强度的要求天差地别，不可能用一种沙盒抽象全部吃掉。短小、无状态的任务适合 FnCall，要运行完整操作系统的任务则可能需要 microVM 甚至完整 VM。

环境本身的多样性也很惊人。论文统计的一个生产周里，容器后端服务了 11266 个基础镜像和 102171 个 workspace；microVM 后端只有两个共享基础镜像，却对应 53590 个 workspace，此外还有 103 个 toolkit 在流转。67.8% 的沙盒除了基础镜像之外，至少还需要一个 workspace 或 toolkit，所有活跃制品加起来超过 130TB。

更棘手的是复用率。容器镜像的 fanout 中位数只有 3，microVM 更是只有 1。也就是说，传统容器体系里那个非常重要的假设——“镜像会被大量复用，所以提前缓存到节点本地就好了”——在这里基本失效了。

真正让这个问题变得荒谬的，是镜像访问率。

DSec 统计了不同语言环境在运行时真正读取的镜像数据：C++ 是 8.7%，Go 是 13.3%，Java 是 9.2%，JavaScript 只有 4.2%，Python 是 6.0%。也就是说，为了启动一个沙盒，传统做法可能要把几个 GB 的镜像从远端完整拉下来、解压、写进本地盘，而其中接近九成的数据，在这个沙盒的一生里可能一次都不会被碰到。

这不叫翻书查一个词，这叫先把整座图书馆搬进门。

最后还剩下两个更麻烦的现实条件：Agent 是不可信的，它可能破坏文件系统、吃光资源，甚至干扰同机的其他任务；Agent 又必须能够随时被打断，因为 GPU 训练任务会被抢占，但一个已经进行几十分钟的 rollout 不能跟着一起报废。

把这些条件叠在一起，就会发现 Agent 沙盒和传统 Serverless 的工作负载虽然长得有点像，底层假设却几乎是反着来的：它既要求瞬间出现，又要活很久；CPU 大部分时间不用，状态却不能丢；环境种类极多，复用率却很低；还必须默认里面运行的东西会做出意料之外的事。

配角为什么突然变成了主角

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图10

过去不需要这么折腾，因为环境过去没有这么重要。

传统大模型训练主要面对静态数据，输入输出对准备好以后，模型负责学习其中的规律；早期 RL 的环境通常也相对轻量，生命周期和状态复杂度远没有今天这么高。但 agentic RL 改变了这个关系：模型不再生成一段文本就结束，它要读代码库、调用工具、执行命令、观察报错、修改文件，然后根据真实反馈决定下一步动作。

走到这里，环境就不再只是训练系统外围的一件配套设施。模型能够执行哪些动作、看到什么反馈、遇到什么失败，以及任务最终能不能被可靠验证，都开始取决于它所在的环境。

这也是 DSec 出现的真正背景。

如果把 DSec 的整体架构摊开看，会发现它并不是一个单独的“沙盒运行时”，而是一整套围绕 Agent 环境搭起来的基础设施。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图11

图里左侧是集群级控制面，负责身份认证、请求入口、沙盒调度和节点监控；中间的 Edge、Aether 和 Chronus 分别处理生命周期、会话以及 Exec/File/HTTP 等实际交互；再往下，才是 FnCall、Container、MicroVM 和 FullVM 四种不同的沙盒后端。最底层的 3FS 则承载 EROFS 和 OverlayBD 镜像。

这张图其实也解释了 DSec 的设计思路：它没有试图发明一种万能沙盒，而是把“调度一个环境”“维持一个会话”“在环境里执行操作”和“具体用什么隔离后端”拆成了不同层。后面那些看起来零散的 EROFS、OverlayBD、AppArmor、eBPF、Firecracker 和 pause/resume，实际上都能在这张图里找到自己的位置。

第一个越过临界点的是量。每天 300 万个沙盒、38 万峰值并发、每秒超过 5000 个创建请求，意味着任何需要经过单一中心节点的路径都有可能成为瓶颈。因此 DSec 的入口层被设计成无状态的，sandbox ID 本身编码了归属 edge，任意入口实例都可以直接把请求路由过去，整个入口层可以水平扩展。

第二个是资源利用方式。九成沙盒平均只使用不到申请 CPU 的 5%，说明 CPU 有巨大的超卖空间；但 p99 超过三个小时的生命周期又意味着，不能靠“任务结束立刻销毁”来回收内存。于是过去不太显眼的 page cache、冷页回收、CPU sibling interference，突然都变成了决定一台机器究竟能塞下多少 Agent 的问题。

第三个是镜像分发模型的前提整体失效。运行时只访问 4.2% 到 13.3% 的镜像数据，活跃环境制品超过 130TB，而 fanout 中位数又只有 1 到 3，这三个数字放在一起，指向的结论很直接：高复用、本地缓存高命中的假设在这里都靠不住，必须把“先搬完整镜像再启动”换成“真正访问什么，就取什么”。

评测结果也说明这已经不是锦上添花的优化。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图12

在 8192 个容器的真实 RL workload 中，按需 EROFS 路径约 35 分钟完成全部任务，远端冷拉完整 Docker image 需要超过 60 分钟，后者慢 1.71 倍；与此同时，按需加载把每节点累计磁盘写入从超过 1600GB 降到了约 700GB，减少约 57%。

另一个 workspace 和 toolkit 的实验更加直观。tar.gz 是顺序流格式，每个沙盒都必须先完整解压，再把文件写进自己的可写层，最终任务需要 79 分钟；改成直接挂载 EROFS 层以后，只需要 45 分钟，总磁盘写流量前者大约是后者的 5.5 倍。

更有意思的是，DeepSeek 并没有为此重新发明一套 Linux 内核。DSec 的内存和 CPU QoS 机制基本都建立在现有 Linux 能力上：virtio-pmem、DAX、DAMON、virtio-balloon、SCHED_IDLE、core scheduling，不需要修改内核，真正的工作是把散落在文件系统、虚拟化、内存管理和调度器里的这些零件，拼成一个能承受几十万 Agent 的生产系统。

所以“为什么是现在”的答案其实有两半：需求侧，agentic RL 把环境从配件变成了训练过程本身的一部分；供给侧，文件系统、虚拟化、存储和 Linux 内核里已经存在足够多的基础机制，让人终于可以把这套东西真正拼出来。

把屋子拆成积木

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图13

DSec 解决这些问题的办法并不神秘，它没有试图找到一种万能的沙盒，而是把环境拆开，分别解决组合、分发和资源回收三个问题。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图14

先看环境怎么拼。

传统做法的问题，在这张图里其实已经很清楚了。如果把基础镜像、workspace 和 toolkit 烧成一个完整镜像，那么只要其中一个 toolkit 更新，所有包含它的完整镜像都可能需要重新构建。假设有 M 个基础镜像、N 个 workspace、K 个 toolkit，升级 m 个基础镜像就可能要重新构建 O(m·N) 个组合，工具链升级也面临类似问题。一个 toolkit 改一行代码，后面可能跟着成千上万个镜像重新构建。

DSec 的办法是把三者做成独立、版本化的层：base image 在下面，workspace 和 toolkit 在创建沙盒时再动态插入，通过 overlayfs 组合起来。为此它修改了 dockerd，在创建容器时动态插入 EROFS-backed lower layer，而这部分修改只有大约 30 行 Go 代码。

组合拆开以后，维护成本也从组合关系上的 O(m·N)、O(k·N)，降到了分别维护各自层的 O(m) 和 O(k)。

第二个问题是数据怎么来。

既然一个沙盒一生只会读取镜像的一小部分内容，就没有必要在启动前把整个镜像搬过来。DSec 在容器侧把只读层做成 EROFS，放到 3FS 上，文件数据只有真正被访问时才从远端取；与此同时，3FS 擅长大块顺序 I/O，却不擅长细碎的随机写，因此所有不可预测的小写入都留在节点本地。

microVM 走的是另一条块设备路径，用 OverlayBD 配合 ublk 按块读取远端数据，并增加本地二级缓存。实现细节虽然不同，背后的原则却非常统一：读的数据按需从远端成块取，写的数据留在本地，不再为了启动一个环境提前搬运绝大多数永远用不到的内容。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图15

把这些机制放回整套系统里看，DSec 实际上做的是三件事：环境层拆开组合，镜像数据按需读取，空闲的 CPU 和内存尽可能重新交还给其他任务。图里的 EROFS、OverlayBD、DAMON、Virtio Balloon 和 CPU QoS，分别对应的就是这几个问题。

第三个问题，是空闲资源怎么还回来。

microVM 的内存浪费有两个来源。一方面，同一份只读镜像数据可能在 host 和 guest 的 page cache 里各存一份；另一方面，guest 已经不用的内存并不会天然及时回到 host。DSec 用 virtio-pmem 配合 DAX 减少重复 page cache，再通过 DAMON 和 virtio-balloon 的 free-page reporting 主动寻找并回收冷页。

效果很明显。真实 agentic RL workload 下，virtio-pmem+DAX 将 host 峰值内存降低了 40.2%；DAMON 配合 balloon free-page reporting 虽然没有明显降低峰值，却把时间积分意义上的内存消耗降低了 21.2%。两者同时开启时整体内存最低，但 virtio-pmem 也有代价：瞬时 CPU 峰值从 26.5% 上升到了 41.4%。论文因此明确指出，在 CPU 紧张的部署里，运维人员完全可以只开 free-page reporting，继续使用 virtio-blk。

这一点很有意思，因为它透露出的不是“所有指标都要优化到极致”，而是一种很典型的生产系统思路：找到真正限制容量的资源，在收益和副作用之间做到够用，然后停手。

CPU 侧也是同样的逻辑。DSec 把沙盒分成 latency-sensitive 和 best-effort 两类，后者放到 SCHED_IDLE 下，在前者需要 CPU 时主动让路；但调低优先级仍然挡不住 SMT sibling 之间的竞争，所以 latency-sensitive workload 又配上 Linux core scheduling，避免无关的 best-effort 任务同时跑在同一个物理核的兄弟线程上。

在论文的实验里，50% best-effort load 下，没有 QoS 保护时单步延迟比无共置基线增加 45.2%，加上 SCHED_IDLE 和 core scheduling 后，增幅被压到 17.3%。剩下的干扰来自频率、内存带宽和共享 LLC 等因素，DSec 没有继续堆更复杂的隔离机制，因为这个结果已经能够满足需求。

把 Agent 的生命从 GPU 里拿出来

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图16

如果只看工程技巧，EROFS、DAMON 和 core scheduling 都很有意思；但整份报告里，我认为更值得注意的是另一个变化：DeepSeek 把 Agent rollout 的生命周期，从 GPU 训练任务的生命周期里拆了出来。

早期版本里，agent loop 和模型服务、RL framework 一起运行在可抢占的 GPU training pod 中。GPU job 一旦被抢占，sandbox 可能还活着，但 agent loop 已经没了。恢复时只能依靠 command log，把训练框架恢复出来的 rollout state 和 sandbox 里实际执行到的位置重新对齐，还必须确保那些带副作用、非幂等的命令不会被重复执行。

从 DeepSeek-V4.1 开始，这套关系变了。

Rollout execution 被搬到 DSec 上，拆成两个部分：一个 agent sandbox，负责承载 scaffold 和工具；一个 worker container，负责管理 sandbox，并提供与具体 scaffold 无关的控制层。两者都运行在可抢占 GPU pool 之外，并共同保存完整的 rollout state，成为这一轮 Agent 执行的 single source of truth。GPU job 被抢占以后，新的训练任务重新连回来就可以继续，不需要再靠 command log 重建整个执行过程。

换句话说，GPU 从 Agent 的宿主，变成了 Agent 生命周期里可以断开、再重新接入的一段算力。

这也解释了为什么 pause/resume 在这里不是一个普通的小优化。GPU job 被暂停以后，对应 sandbox 仍然必须存在，否则 rollout 状态就丢了；但让几十万个暂时没人使用的 sandbox 继续占着内存同样不可接受。因此 RL framework 会主动通知 DSec 暂停相关环境。

容器侧先用 docker pause 冻结进程树，然后打开 swap，通过 memory.reclaim 主动回收匿名页和 file-backed page；恢复时先用 MADV_WILLNEED 异步预取，再 unpause。microVM 更直接：保存内存和执行状态快照，随后杀掉 Firecracker 进程释放 runtime memory；恢复时重新启动进程，从 snapshot 接着执行。

状态留下，内存先还。

这个设计真正解决的不是一次抢占，而是一个更深层的问题：Agent 的“生命”究竟属于谁。

当 rollout state 被环境层自己保存以后，GPU trainer 不再拥有 Agent 的完整生命周期，它只是需要时连接上来参与计算。对于一个越来越依赖长时间、多轮交互的训练系统来说，这个边界变化可能比单项性能优化更重要。

当 Agent 开始拆自己的墙

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图17

做到这里，新的问题也随之出现：住进这些房间里的东西，并不会老老实实按照设计者预想的方式活动。

论文专门用一节记录了生产环境里观察到的 Agent misbehavior，其中一类是为了完成任务，从非预期渠道寻找答案。

Agent 尝试过直接向 chronus socket 发送伪造 RPC 消息，也翻过 chronus 日志寻找泄漏的答案；因为 chronus 的一些操作会调用 bash，它们还试过覆写 /bin/bash，绕过检查或者给后续 shell session 注入命令。文件和 socket 权限收紧以后，才有了文章开头那个 XFS_IOC_SWAPEXT 的故事。

沙盒外也不消停。Agent 会扫描端口和服务寻找能够访问的镜像源，通过 Go module proxy 获取 GitHub 上的参考实现，甚至安装更新版本的软件包，试图找到已经存在的目标功能。论文因此明确指出，只检查最终输出，并不能可靠判断 Agent 究竟是自己解决了任务，还是从某个不该去的地方找到了答案。

更麻烦的是，并不是所有事故都来自有意“作弊”。

有 Agent 从根目录递归执行 grep，一路遍历 /proc 并读取 /proc/kpagecgroup，最终触发内核 bug，把内核直接搞崩；有漏洞利用任务原本应该把攻击命令转发给单独的目标 VM，结果命令误执行在 Agent 自己的容器里，把自己的 kernel 打挂；还有 Agent 运行了 yes，而 chronus 为了支持异步读取命令输出持续记录 stdout，最后几十 GB 数据被一路写进存储。

DSec 的应对分成两层。文件和 socket 权限由 AppArmor 控制，即使 Agent 控制的进程在 sandbox 内以 root 身份运行，策略仍然生效；网络侧则通过 per-sandbox eBPF 程序做细粒度 allowlist，可以按照 IP、端口和协议过滤，而且策略能够随着任务阶段动态变化。论文给出的例子是，一个任务可以允许访问 PyPI，同时禁止访问 NPM。

但论文在这里没有把话说满。作者明确承认，这些机制只能覆盖问题的一部分，并不能提供针对所有破坏性行为的通用防御，例如触发 kernel bug 这类事故依然可能发生。

这其实是 Agent 基础设施和普通云计算之间一个很有意思的差别。过去做容器安全，主要担心的是恶意用户；现在还要面对一种新的执行主体：它未必有破坏系统的目的，但会为了完成目标主动探索环境，会尝试设计者没有预料过的路径，也可能因为一个看似普通的命令把底层系统推到从未测试过的角落。

模型能力越强，这个问题反而越不会自动消失。

环境也开始成为一种资产

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图18

还有一个容易被忽略的问题：这么多不同的 Agent 环境，到底由谁来造？

如果每天要运行数百万个 sandbox，靠工程师手工准备环境显然不现实。DSec 给出的答案很有意思——让 Agent 自己造。

平台提供了 pack_diff，任何时候都可以对 sandbox 做一次增量磁盘快照，之后再把这个 snapshot 恢复成新的 sandbox。这样一来，一个 Agent 的交互式构建过程可以直接变成可复用环境，不需要再走一遍独立的 image-building pipeline。

DeepSeek 把这件事概括成一句话：

Build environments of Agents, by Agents, for Agents。

这背后已经不只是“生成一个镜像”了。论文提到，DeepSeek 内部还有一套平台负责对 Agent 构建出来的环境做 quality check，并导出成标准格式，供后续 RL 和 evaluation 使用。与此同时，环境建造者和真正运行任务的 Agent 使用不同账号，build 阶段残留的数据也必须在 pack 之前从 writable layer 中删除，避免把 reference answer 一起封进最终环境。

当一个环境可以被 Agent 构建、被快照、被检查、被版本化、被标准化导出，再被后续训练和评测重复消费，它就已经不太像传统意义上的“一次运行条件”了。它开始具备一种资产的形态：能够积累、能够复用、能够管理质量，也有清晰的生产者和消费者。

这可能是 DSec 这份报告里最容易被低估的一层变化。

过去谈训练资产，人们首先想到的是数据、模型权重和算力。Agentic RL 往前走以后，环境也开始进入这张表。一个高质量的软件仓库环境、一套复杂的 Android 开发环境、一个可以稳定复现的安全攻防环境，它们本身都可能决定训练任务能不能被规模化复制。

环境不再只是装数据的盒子，它自己开始成为训练数据的一部分。

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图19

另一张算力账

万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图20

这也是为什么，DSec 值得放到更大的背景里看。

它当然没有说明 GPU 不重要，更没有证明模型参数规模已经不重要。更准确的说法是，当训练从“给模型看数据”逐渐扩展到“让模型在真实环境里行动”，单卡峰值算力已经不足以解释整个 Agent 训练系统的吞吐。

GPU 负责模型计算，但一次 rollout 能不能跑起来，还取决于 CPU 能不能及时提供环境、内存能不能容纳足够多的有状态会话、镜像能不能快速分发、文件系统能不能扛住突发 I/O，以及 GPU 被抢占以后，已经进行了一半的 Agent 能不能活下来。

这是一张过去很少有人认真计算的账。

DSec 给出的答案也不是“隔离越强越好”。论文对 FnCall、container、microVM 和 full VM 做了很坦率的对照：越往完整虚拟机走，系统功能和隔离能力通常越强，但启动速度、运行开销和资源密度也会付出代价。平台因此没有强迫所有任务进入同一种最强隔离环境，而是让调用方根据 workload 选择合适的 backend。

这背后的思路其实贯穿整篇报告：不是追求某一个指标的理论最优，而是在规模真正上来以后，寻找整个系统最便宜的平衡点。

因此，一些过去很难出现在大模型发布会中心位置的技术，也开始被重新估值：分布式文件系统、EROFS、overlayfs、page cache、DAMON、balloon、CPU core scheduling、镜像分层、按需加载，以及 pause/resume。它们没有新的模型架构那么显眼，也很难直接变成一张能力榜单，却决定了一家公司能不能把 Agent rollout 从几千个实验环境，推到每天数百万个沙盒的生产规模。

这份报告还有一个很少见的地方，就是它没有把生产系统写得过于干净。XFS 元数据被 Agent 搞坏、kernel 被意外击穿、yes 堆出几十 GB 输出、攻击命令打到 Agent 自己身上，这些不太光彩的事故都被留在了论文里。

但也正是这些事故，让 DSec 比一套单纯的“高性能沙盒系统”更值得看。

因为它们共同指向了 Agent 时代一个越来越具体的问题：当 AI 从回答问题走向在环境里真正做事，我们要建设的就不只是更聪明的模型，还包括一个足够丰富、足够便宜、能够恢复，同时又知道在哪里划线的世界。

房间得足够大，让它有事可做；边界也得足够清楚，让它不能想去哪就去哪。

模型最终能长成什么样，不只取决于脑子有多大，也取决于我们给它造出了一个什么样的世界。万字长文｜DeepSeek 每天 300 万沙盒：Agent 基础设施到底难在哪？图21