这几天圈子里很多人都在转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也完全可以借鉴它的预热池、生命周期管理、隔离分级这些设计。把论文里的架构思想消化掉再结合自己的场景去裁剪这就是读一篇好论文最大的收获了。