这几天圈子里很多人都在转DeepSeek的新论文，题目是《DeepSeek Elastic Compute(DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale》。我对这个方向一直很关注，论文放出来当天就仔细读了一遍。今天这篇就算是一篇论文阅读笔记，把我读到的核心设计、我觉得有价值的地方，以及结合工程实践的一些思考，一次性梳理清楚。
先给还没读论文的朋友交代一下背景。Agentic训练和普通的大模型训练不太一样，它需要让模型在模拟环境里反复执行任务、观察反馈、修正策略。这些任务五花八门，可能是写代码、操作软件、浏览网页、调用工具，而且每一个都要运行在隔离环境里，也就是论文里说的sandbox。随着训练规模扩大，sandbox的数量会从几十个涨到几万个，怎么高效地创建、调度、回收这些环境，就成了一个非常现实的基础设施问题。DSec就是DeepSeek给出的答案，一个面向大规模Agentic训练的弹性计算沙盒基础设施。
论文里的几个关键词——Elastic Compute、Sandbox、Agentic Training——其实分别对应了三件事：资源怎么弹性伸缩、任务怎么隔离执行、训练怎么高效跑起来。我的理解是，DSec本质上是一套把"计算资源池"和"训练任务调度"深度耦合的系统。不是简单地在Kubernetes上跑几个容器，而是从资源管理层到执行层都做了针对性的优化。接下来我把论文里的核心内容拆开讲，同时会穿插一些我对这套架构在真实场景下落地时的一些看法。毕竟论文里写的是一回事，实际部署起来又是另一回事。
1. 论文要解决的核心问题：Agentic训练为什么需要专用沙盒基础设施
1.1 传统训练和Agentic训练的本质差异
先说一个最根本的问题：为什么不能用普通的GPU训练集群来解决Agentic训练？看过论文里对Agentic Training工作负载的分析，我最大的感受是，两者的资源消耗模式完全不一样。传统大模型训练是典型的长时间高负载任务，几十块GPU一次性申请，一跑就是几天甚至几周，资源利用率高，调度也相对简单。但Agentic训练完全是另一副样子。
Agentic训练的任务具有几个特征：数量极大、单任务时间短、资源波动剧烈。模型在训练过程中需要反复和环境交互，比如一个Agent要在一个模拟浏览器里完成某个操作，它可能几秒钟就完成一次交互，然后环境就要被回收，下一个交互又需要一个新的环境。如果还是按照传统方式去预分配资源，结果就是大批GPU和CPU在绝大多数时间里处于闲置状态，资源浪费会非常严重。DSec论文里特意强调了这一点，Agentic训练中每个sandbox的存活时间可能只有秒级到分钟级，而且创建和销毁的频率极高，这种工作负载形态对调度器提出了完全不同的要求。
我自己的理解是，Agentic训练本质上是一种高并发、低延迟、短任务密集的在线型工作负载。它更像一个高并发的API服务，而不是一个批处理任务。如果你用批处理的思维去管理这些sandbox，系统的瓶颈很快就会从GPU算力转移到调度器本身。举一个生活化的例子，传统训练像是你雇了一个装修队，一次性进场，干好几个月，你要管的是材料能不能持续供应。Agentic训练更像是餐厅的翻台率管理，桌子要不断地安排客人、收拾桌面、重新接待，核心能力是快速周转，而不是一次性包场。DSec这套系统的出发点，就是针对这种快速周转的场景来设计资源管理体系。
1.2 沙盒技术的痛点在哪里
有了这个认知，你就会明白为什么论文要花大量篇幅去讲sandbox的设计。沙盒本身不是一个新概念，Docker容器、虚拟机、gVisor这些都算。但Agentic训练场景下的沙盒有很多特殊性，通用方案其实撑不起来。
首先是安全边界的问题。Agent在环境里执行代码时，这个代码是不可信的。训练过程中模型会探索各种极端行为，可能会试图逃逸环境、访问宿主机资源、发起网络攻击，甚至干扰训练任务本身。如果沙盒的隔离不够强，一个恶意的Agent行为就有可能导致整个训练集群被污染。所以DSec的沙盒必须同时具备强隔离和轻量化的特性，这两个特性在传统方案里往往是矛盾的。
其次是启动速度的问题。我在实际部署类似环境时有个很深的体验：Docker容器启动一个轻量环境大概是几百毫秒到秒级，但如果要做更强的隔离，比如用微虚拟机，启动时间就会上升到数秒甚至更久。在Agentic训练中，如果每个交互都要等环境启动，训练效率就会大打折扣。论文里提到DSec在沙盒创建路径上做了不少优化工作，核心目标就是把环境启动的延迟压到尽可能低。
还有个容易忽略的问题是环境的一致性和可复现性。Agentic训练中，环境往往需要从同一个初始状态启动，如果你手动维护镜像，很容易遇到环境漂移的情况——有的沙盒里软件版本新一点，有的旧一点，训练结果就没法复现。DSec的设计中考虑了统一镜像管理、缓存复用这些机制，这在实际训练中真的非常关键。说句实话，很多团队训练效果不稳定，最后排查下来是沙盒环境不一致导致的。论文在这一点上的设计思路值得借鉴。
1.3 DSec的目标：把弹性变成基础设施能力
看完整篇论文的框架，我总结DSec要解决的问题可以归纳成三点：第一，让sandbox的创建、运行、回收像调用一个函数一样简单和快速；第二，让整个资源池的利用率和弹性达到一个比较理想的最优解；第三，让多份训练任务之间可以安全地并行运行，互不干扰。这三条每一条都对应着架构上的具体设计，不是一句口号。
弹性这个词在DSec里有特别具体的含义。传统云计算的弹性和Agentic训练所需的弹性完全是两个量级的挑战。云计算的弹性通常是指分钟级扩缩容，而DSec面对的Agentic训练，扩缩容的粒度是单个sandbox，频率是每秒都有可能发生。弹性已经不是"能不能扩"，而是"扩的时候能不能快、能不能准、能不能跟训练任务的需求精准匹配"。DSec论文里用了Elastic Compute这个词来命名这套系统，我觉得是准确的，它指向的就是这种极高粒度的资源弹性能力。后面我把论文里的架构设计拆开讲。
2. DSec核心架构拆解：从控制面到数据面
2.1 整体架构的分层设计
论文里给出的系统架构图，我最先注意到的是它做了清晰的控制面和数据面分离。控制面负责决策：怎么调度、怎么分配资源、什么时候扩缩容。数据面负责执行：真正去创建sandbox、运行Agent代码、返回执行结果。这两者分开之后，各自的职责就变得非常明确，也方便独立扩展。这个设计原则业界其实已经非常成熟，但DSec在细节上有自己的取舍。
我理解DSec的控制面是一个中心化的调度集群，它需要维护一个全局的资源视图，知道自己当前管理了多少个节点、每个节点上有多少个sandbox在运行、运行的是哪个训练任务的哪个step、预计什么时候结束。所有新建sandbox的请求都汇聚到控制面，由控制面来决定放在哪台物理机上。这种中心化设计的好处是调度决策可以做到全局最优，不会出现某些节点忙死、某些节点闲死的情况。代价就是控制面的调度吞吐量必须足够高，否则它自己就会成为系统的瓶颈。
数据面则设计得相对简单，每个计算节点上运行着一个轻量的执行代理，负责响应控制面的指令，在本机创建和销毁sandbox，同时把运行状态上报回去。这种设计让数据面节点的逻辑非常简单，可以快速横向扩容。我看到论文里花了比较多的篇幅在描述这种调度架构下如何做到低延迟和高吞吐，其实这个领域已经有非常多的工程积累，DSec的价值在于把它和Agentic训练的特定需求深度结合在了一起。
2.2 沙盒的生命周期管理：从创建到回收
沙盒生命周期管理这部分是DSec里最核心的机制之一，也是我读得最仔细的部分。一个Agent的训练过程会不停地在多个sandbox之间切换，沙盒的生命周期可以被划分成几个阶段：创建、预热、运行、挂起、复用、销毁。论文里最值得关注的设计，是对"复用"和"挂起"这两个状态的处理。
普通的容器环境，用完就销毁是最简单的方案。但Agentic训练中sandbox的创建是有成本的，即使你已经做了很多优化，频繁创建依然会浪费资源。DSec引入了一种缓存池的机制，预先创建一批处于"待命"状态的sandbox，训练任务需要时直接从池子里取，用完再归还回池子。这就像你开餐厅，如果每来一桌客人都从买菜开始准备，那效率肯定是起不来的；先备好一些半成品，客人点菜后快速加工，出餐速度才能提升。DSec的预热池设计就是这个思路，论文里专门讨论了池的大小、预热时机、过期回收策略这些参数是怎么联动的。
另外还有一个"挂起"机制也很有意思。有些sandbox里运行的长任务可能只是暂时在等待外部输入，比如在等另一个环境返回结果。这时候如果直接把sandbox销毁，所有上下文就都丢了，重新创建的成本很高。DSec可以让这种sandbox进入一种挂起状态，资源被暂时回收但状态被保留，等输入到达时再恢复。这种机制在我们实际做编排时是非常有价值的，它相当于把状态和资源解耦了。但要处理好挂起时的资源快照和恢复时的数据同步，这里面的技术细节还是很复杂的。
2.3 沙盒间通信与训练数据流
Agentic训练中还存在一个常见的场景，那就是多个Agent需要在同一个任务里协作。比如一个Agent负责写代码，另一个Agent负责运行测试，它们之间需要共享文件或者通过消息传递结果。这就涉及到sandbox之间的通信问题。
DSec的沙盒网络设计让我觉得做得比较务实。它没有让所有sandbox都暴露在同一个大网络中，而是默认采用隔离网络，每个sandbox只有通过明确的授权才能访问另一个sandbox。在设计上，它同时支持同节点上的高速通道通信和跨节点的转发。这种机制的好处是安全边界清晰，训练任务之间不会互相干扰，同时也为多Agent协作提供了通路。我看过太多团队在搭这种环境时忽略网络隔离的问题，最后不同训练任务的数据混在一起，无论如何排查都找不到原因。网络隔离这件事在一开始就规划好，后面真的能省很多事。
训练数据流这块，DSec的一个核心设计是让数据尽量在本地流转。Agent执行任务时会产生大量的日志、交互记录、操作轨迹，这些数据是训练模型的重要语料。如果每一步操作都往中心化存储里写，整个系统都会被IO拖垮。DSec会让节点上的临时数据在本地先聚合，周期性异步上传，既保证了数据的完整采集，又避免了对训练主链路的干扰。这套设计理念跟现代可观测性架构的思路很像，先缓冲再聚合，而不是每一条数据都实时打通。
3. 弹性计算与调度策略：DSec怎么实现大规模资源池动态伸缩
3.1 从静态分配走向动态水位控制
在读论文之前，我一直觉得弹性伸缩就是监控CPU使用率，超了就加节点，低了就减节点。但DSec的调度策略让我看到了更精细的玩法，它不是简单的监控告警触发伸缩，而是建立了一套基于负载预测的"水位控制"机制。
所谓水位控制，通俗地说就是系统会一直维持一个动态的"备用sandbox池"。当训练任务的并发量上升时，池子里的sandbox可以被立即取走使用，同时系统会立刻补充新的sandbox进入池子。这样，即使调度器反应慢一点，任务也不会等到资源创建完成才能运行。DSec论文里把这一层抽象成了一个基于预测的资源准备模型，它会根据近期任务到达的历史曲线，预测未来一段时间内可能需要多少sandbox，然后提前把资源水位调整到合适位置。
这种策略对于一个在线型负载特别有用。我在构建类似的系统时有直观的感受：Agent训练任务的并发往往是突发性的，模型在某个阶段可能突然产生大量的并行探索需求，如果系统从零开始创建环境，延迟完全不可控。而DSec的做法是让系统始终保持在一个"稍微超前于实际需求"的状态，用少量冗余资源换取稳定的训练体验。这跟水位控制的水库调度是一个逻辑，旱季存水、雨季放水，目标是让下游始终有稳定的流量。
3.2 动态迁移与碎片整理
大规模调度还有一个非常棘手的问题，就是资源碎片化。比如你在一台物理机上创建了十几个sandbox，每个只用了很小的资源份额，当一个大任务到来时，单机剩余资源不够，你又不能让已经运行的sandbox让路，最后大任务只能被安排到另一台机器。长此以往，每台机器上都有一些空闲的零碎资源，但这些资源又不足以跑一个完整任务，整体资源利用率就会下滑。
DSec在调度策略里处理了这个问题，它会定期对集群做"碎片整理"。具体的做法是把一些正在运行的sandbox迁移到其他节点，腾出连续的可用资源给更大的任务。这个过程在论文里没有给出特别多的工程细节，但据我对这类系统的了解，沙盒迁移的核心挑战是状态转移。如果sandbox是无状态的还好，直接销毁重建就行；但有状态的sandbox需要先冻结、然后同步磁盘和内存状态、再在目标节点恢复，每一步都有失败的风险。DSec在这里采用的策略应该是优先迁移无状态或轻状态的sandbox，对于重状态沙盒则通过内部调度策略避免形成碎片。
这个思路对实际工程很有参考价值。我们做资源池管理时，最容易犯的错就是一味的贪心填充，盲目把任务塞到当前最优节点上，结果导致后续大任务无处安放。长期运行的系统，一定需要周期性的全局视角来调整资源分布，哪怕调度过程本身消耗一些资源，总比机器利用率越来越低要好。
3.3 分级调度：短任务优先与优先级队列
Agentic训练任务不能都平等对待。论文里提到调度器引入了分级调度的机制，我觉得这是对实际训练场景中不同任务形态的一种适配。
简单来说，DSec的调度器会区分长任务和短任务。短任务通常是Agent的单步操作，执行时间很短，比如调用一个工具、访问一个网页、执行一段代码。长任务则可能是完整的任务链路，需要持续占用资源几分钟甚至更久。如果调度器不做区分，短任务可能在长任务后面排队，导致训练主链路的延迟被拉长。DSec的策略是让短任务优先插队，保证训练交互的实时性；长任务则会被调度到资源更充裕的节点，避免影响短任务的周转。这个设计有点像操作系统里的短作业优先调度算法，放到大规模分布式系统里来看，思路是完全相通的。
此外，论文里还提到了优先级队列和多租户策略。当多个训练项目共用同一个资源池时，不可能大家永远占同样多的资源，必须要有权重分配。DSec可以根据训练任务的重要程度配置不同的优先级，高优先级的任务可以抢占低优先级任务的空闲资源，但不会打断低优先级任务正在运行的sandbox。这种软抢占策略在训练场景下非常实用，因为训练任务整体是中长周期的，你可以调整任务整体的进度速度，但没有必要去强行中断一个正在执行的动作。
4. 安全隔离机制：如何保证不可信Agent代码在沙盒里安全运行
4.1 多层隔离与最小权限原则
Agentic训练的安全问题，比一般的代码运行环境更棘手。因为训练的目标就是让Agent产生各种行为，包括探索攻击、逃逸、尝试非法操作，这些行为在传统安全体系里会被直接拦截，但在这里恰恰是"正常的训练数据"。如何在允许Agent做各种危险操作的同时，保证宿主集群不受影响，这是DSec安全设计要解决的根本问题。
DSec的做法是采用多层隔离架构。最外层是整机级别的资源隔离，每个训练任务只能在自己被分配的节点组里活动，不能触达集群的管理面。中间层是容器级的隔离，Agent的代码运行在独立的命名空间里，文件系统、网络栈、进程视图都是隔离的。最内层是针对单个进程的权限控制，Agent代码的执行用户是受限用户，不能访问未被授权的内核接口。你会发现这套设计和现代云原生安全模型非常相似，核心思想就是一个词：最小权限。每个环节都只给Agent它该有的能力，额外的能力一律不开放。
论文里还提到了一个有意思的设计，就是针对"逃逸行为的观察"。传统系统检测到逃逸行为会立刻封堵，但在Agentic训练中，逃逸行为本身是一种需要被采集的训练信号。DSec的沙盒会记录Agent尝试逃逸的行为轨迹，同时保证这些尝试不会真的造成破坏。这种"允许尝试但不允许成功"的机制，把安全防护和训练数据采集统一了起来。我觉得这是Agentic训练基础设施一个非常特殊的点，如果你用纯安全思维去做，可能会误伤训练数据；但用纯训练思维去做，又可能真的让集群被搞乱。DSec在这里找到了一个平衡点。
4.2 内联过滤与资源配额的一体化
除了隔离，沙盒还需要有资源配额的控制能力。Agent在训练中可能写出一个死循环、申请超量内存、打开太多文件句柄，这些行为如果不加限制，会把一台节点拖垮，影响其他训练任务。
DSec在资源配额上的设计，强调的是"硬限制"而不是"软限制"。内存超过阈值直接OOM杀进程，CPU超过配额直接调低调度权重，磁盘写入超过配额直接报错。这种机制本身不新颖，但它把这个能力做进了沙盒创建控制链路的每个环节。也就是说，你不是创建一个裸的进程再给它加限制，而是从创建之初，限制就已经带有强制属性。我在实际工作中踩过类似的坑：配额没有跟沙盒的结构绑定，结果进程起来之后发现默认配额缺失，等发现时已经造成影响了。DSec从架构上规避了这个问题，配额不是附加项，而是沙盒的基础属性。
这里还有一个值得注意的细节，就是资源的"按秒计费"式调度。Agentic训练的sandbox生命周期过短，如果还按照传统的分钟级来分配资源，就会出现很多浪费。DSec在调度层面精细化到了秒级的配额管理，sandbox运行多少秒就分配多少资源。资源配额与沙盒生命周期绑定，进一步提升了整体资源池的利用率。
4.3 沙盒镜像管理与信任链
最后一个让我印象深刻的点是镜像管理和信任链。DSec的沙盒并不是在每次创建时从一个公开镜像拉取，而是使用了一层带有内部验证机制的镜像缓存体系。每个镜像在发布时都会生成一个内容寻址的校验值，沙盒创建时使用的镜像必须是经过验证的。这种做法的好处是双重的：一方面防止了不安全的镜像混入训练环境，另一方面内容寻址可以让重复的镜像层被多个sandbox共享，大大减少了存储消耗和启动时间。用过Docker的人应该秒懂，镜像分层复用是最基本的优化手段，但要做到大规模、高并发的场景下依然稳定，对底层存储的压力是非常大的。
我读这篇论文的一个总体感受是，DSec在安全设计上没有发明特别"玄幻"的技术，它做的最出色的一件事情，是把安全机制内建到了基础设施的每一个层级中。安全在这里不是一个附加模块，而是资源生命周期管理的一部分。这其实也代表了业界的普遍共识：如果你想在AGI训练中安全有效地运行不可信代码，那安全就必须是基础设施的原生属性，贯穿始终。
5. 从论文到工程实践：我能直接落地的几点启发
5.1 弹性沙盒池的最低成本实现
读论文的时候我一直带着一个问题：我自己能做一套简化版吗？虽然DSec这样的系统需要强大的团队和基础设施才能完整实现，但它的很多设计理念，是可以低成本复刻的。我把它拆解成具体的实践步骤，这里分享给大家参考。
基础版的弹性沙盒池，有三个核心组件：资源采集器、决策引擎和管理API。资源采集器负责收集当前所有节点的CPU、内存、磁盘、sandbox数量、平均生命周期这些数据。决策引擎根据历史数据预测未来负载，计算出当前应该有多少个sandbox处于预热状态。管理API负责执行创建和回收动作。这三个组件用开源技术完全可以搭建，调度核心可以在Kubernetes的HPA基础上做定制开发。如果你想快速验证这套思路，可以先不考虑多租户和跨节点迁移这些高级特性，专注于把"预热池"和"按需回收"这两条主链路跑通。我个人觉得，一个几百个sandbox规模的场景，用这种简化方案就有机会取得和论文里比较接近的实际效果。
5.2 几个关键的工程参数
在部署这类系统时，有几个参数需要仔细调，论文里也提到了类似的经验。我结合自己的实践，总结成一个速查表：
| 参数 | 作用 | 建议初始值 | 调节方向 |
|---|---|---|---|
| 预热池大小 | 决定任务到达时无需等待即可使用的sandbox数量 | 高峰并发的30%-50% | 任务延迟高则加大，资源空闲多则减小 |
| 池内最小空闲量 | 低于此水位立即补充sandbox | 峰值需求的10% | 任务到达波峰陡峭时提高 |
| 池内最大空闲量 | 高于此水位停止创建，回收多余sandbox | 峰值需求的80% | 资源利用率优先时可以降低 |
| sandbox闲置超时 | 超过该时间未使用的sandbox被销毁 | 60-120秒 | 任务间歇性长可适度加大 |
| 调度器扫描周期 | 控制面检测资源水位变化的频率 | 2-5秒 | 追求低延迟可缩短，追求性能可延长 |
参数之间是关联的。我之前遇到过一个典型的情况，预热池设置太小，导致高峰期大量请求同时等待创建sandbox，虽然单个创建只要几百毫秒，但排队导致整体训练速度下降得非常明显。后来把预热池水位调高，延迟直接下来了，代价只是多占了一些空闲资源。在训练场景里，用一点资源冗余换训练速度，其实是很划算的。
5.3 实际操作中常见的踩坑与排查思路
最后这部分，我梳理一下自己实际搭建类似环境时遇到的比较典型的坑，以及排查的思路：
第一个坑是"冷启动延迟"。表面上看创建sandbox很快，但真正训练开始时发现第一步操作就非常慢。排查了一圈发现是镜像拉取的问题，因为节点的本地缓存是空的，每次都要从仓库拉镜像。解决办法就是提前在节点上预置镜像，或者做一个镜像预热任务，在节点空闲时提前把镜像拉下来。这个问题在论文里的预热池设计里其实已经隐含了，但很多自研方案容易忽略这一点。
第二个坑是"僵尸sandbox"。某些Agent任务可能意外退出，但sandbox却没有被正常回收，长时间占据着资源。如果你没有合适的清理机制，时间一长整个资源池就被这些僵尸环境占满。应对方案是建立一套租约机制，每个sandbox运行时绑定期限，期限一到强制回收。这比依赖任务自己报状态要可靠得多。
第三个坑是网络策略误伤协同任务。前面我说的多Agent协作场景，如果网络隔离策略配置得过于严格，Agent之间的合法通信也会被拦截。排查这类问题的一定要区分session流量和训练数据流量，两者要通过不同的网络策略来管理。我在这上面吃过亏，把session通信和日志上传都走同一个网络规则，结果其中一个Agent执行耗时操作时，超时导致另一个Agent以为它挂了，整个协作链路崩溃。后来把两条链路分开配置，问题就解决了。
第四个坑是数据采集丢失。Agent执行过程中产生的训练数据非常宝贵，如果沙盒销毁时数据还没落盘，就会直接丢失。一定要设计好沙盒销毁前的数据回收流程，正常情况下用优雅销毁，先同步数据再释放资源；只有出现异常时才走强制销毁。优雅销毁的触发率应该是绝大多数，如果发现强制销毁比例过高，肯定是资源限制设置有问题的，需要排查是内存配额还是超时阈值设置得不合理。
6. 论文之外：DSec对Agentic训练基础设施的影响与展望
6.1 大型AI公司为何都在自研类似基础设施
以我对这个行业的观察，最近半年凡是认真做大模型Agent方向和强化学习的团队，几乎都在搭建类似的沙盒基础设施，只是叫法各有不同。DeepSeek直接把DSec写成论文公开出来，对整个行业是很有价值的。它相当于把一条可行的技术路线公开摆到了桌面上，让后来者有了参考方向，不需要再完全从零摸索。
为什么大家都在跟进，深层次的原因是：Agentic训练的基础设施已经不是可有可无的辅助系统，它直接决定了训练的上限。当模型需要和环境高频交互来完成学习时，环境的吞吐量、延迟、隔离强度就直接等同于训练效率。如果你的沙盒环境每秒只能创建几十个，训练规模就上不去；如果环境隔离不够强，很多Agent探索行为就无法安全地展开来。基础设施彻底变成了训练能力的组成部分，而不再只是一个支撑系统。这也是为什么我在文章开头说，这篇论文值得所有做Agent相关技术的人仔细阅读，不管你是做算法还是做工程，都应该理解底层基础设施的设计逻辑。
6.2 Agentic训练进入规模化时代后，基础设施的几个术方向
顺着DSec论文的思路往下想，我觉得接下来Agentic训练基础设施还会在几个方向上继续演进。一个是多集群联邦管理，单一集群很难无限横向扩展，不同机房甚至不同云厂商的资源如何统一调度，会是再往下规模化的必经之路。另一个是GPU资源的混部调度，Agentic训练里有一部分Agent动作不需要GPU，纯CPU即可满足，如果能把这些任务调度到GPU集群的空闲CPU上，资源利用率还能再提高一大截。
还有一个我自己比较看好的方向，是沙盒环境与模型训练更深度的融合。比如根据模型当前的学习进度，动态调整环境的复杂度或任务的随机性，这就不只是基础设施的活了，而是需要训练框架和沙盒编排深度协同。DSec在这篇论文里定义了沙盒与训练框架的接口标准，这为后续的深度协同留出了空间。
6.3 给技术团队的实际建议
如果你所在的团队现在也在规划Agentic训练的基础设施，我的建议是：不要一上来就追求DSec那样的完整形态。先梳理清楚自己的训练场景有几个核心需求：需要多少并发agent、单次任务的平均时长是多少、有没有跨Agent协作的需求、对隔离强度的要求有多高。把这些数字定下来之后，再决定需要建设到什么程度。
最关键的判断是：你需要的可能是70分的弹性沙盒池，而不是100分的安全隔离系统。安全等级每提高一档，系统复杂度和维护成本都会翻倍。如果你的Agent任务都是内部可控的，不涉及恶意代码探索，那简单的容器级隔离可能就够用了。真正需要强隔离的场景，一定要确保Agent在训练中会实际执行不可信代码。不要在需求还不明确的情况下，就为想象出来的极端场景过度设计，等你真的需要的时候再升级，时间上是来得及的。
DeepSeek这篇论文最大的价值，不一定是它的技术细节有多超前，而是它非常清晰地展示了：当Agentic训练走到一定规模之后，基础设施层面会遇到什么问题，以及用什么思路来解决这些问题。这套思路本身是可以在各种规模的团队中落地的，哪怕你只做几百个sandbox，也完全可以借鉴它的预热池、生命周期管理、隔离分级这些设计。把论文里的架构思想消化掉，再结合自己的场景去裁剪，这就是读一篇好论文最大的收获了。
