讲一个很现实的问题：大模型做智能体训练的时候，数据从哪来？纯靠人工标注工具调用轨迹，成本高到离谱；拿生产环境直接让模型去试错，风险和成本也扛不住。DeepSeek团队这篇论文给出的答案是DSec——一套专门为大规模Agentic Training设计的沙箱基础设施。我前前后后读了三遍，一边读一边对照自己做Agent训练基础设施时的经验，今天把这篇笔记整理出来，尽量讲透。
这篇论文的核心价值，不只是"我们做了一个沙箱平台"这么简单，它其实把智能体训练的数据生产流水线整个理了一遍：从沙箱的快速创建、弹性扩缩容，到多租户隔离、恶意输入防护，再到CLI/Web双界面的工具调用范式，每一个环节都有明确的设计取舍。如果你是做模型训练的工程师、搞AI基础设施的，或者正在搭建Agent相关数据流水线，这篇论文值得精读。下面我按自己的理解拆开讲。
1. DSec到底解决了什么问题：智能体训练的数据瓶颈
1.1 智能体训练和传统训练有什么不一样
传统的大模型训练，数据是静态的：语料放在那，模型反复读过就行。但Agentic Training完全不同——模型需要学会在真实（或模拟）环境里调用工具、执行代码、观察结果、根据反馈修正行动。这意味着训练数据不是预先存在的，而是由Agent与环境的实时交互动态生成的。
这个过程一旦规模化，问题就来了。比如DeepSeek的Agent模型DSA（DeepSeek Agent）在做推理时，需要靠代码执行和工具调用来生成高质量的推理轨迹。你让模型写一段代码，它写完了，还得真的把代码跑起来，看看输出是否合理，才能形成完整的"观察-行动-反思"闭环。这种情况下，模型能不能成功执行一段代码、执行后得到什么结果，直接影响训练数据的质量和分布。
最初大家常用的做法是给每个任务手动分配一台机器或容器，或者直接调外部API去执行代码。但一旦训练样本量到百万级、千万级，这种"人肉调度"和"裸容器直跑"的方式就撑不住了：生命周期管理混乱、资源利用率低、隔离性堪忧，更别说处理恶意代码和prompt injection这类安全问题了。这正是DSec出现的背景——它把"沙箱调度"变成了一项基础设施能力，而不是每次训练任务都要临时搭一套的临时方案。
1.2 DSec是什么：一个为Agentic训练而生的沙箱工厂
DSec的定位很清晰：它是一个多租户的弹性计算沙箱基础设施，核心目标是给大规模智能体训练提供安全、高效、可伸缩的代码执行环境。论文里描述的场景是服务于DSA的训练流水线，但它的设计思路完全可以泛化到任何需要"大规模安全执行不可信代码"的场景。
它支持的训练模式有两种，理解这两种模式有助于把握整套系统的设计逻辑。
第一种是传统的监督微调（SFT）。这时候沙箱的作用是数据生产：给模型一个指令，让它调用工具、执行代码，然后把模型与环境交互的轨迹采集下来，经过清洗和筛选后变成SFT的标注数据。模式核心是"高吞吐、可过滤"——你不在乎模型每一步都对，你需要的是大量真实的交互样本，哪怕样本里错误很多也没关系，后面会做质量筛选。
第二种是强化学习（RL）。这时候沙箱变成了环境本身：策略模型在沙箱里执行动作，系统根据执行结果计算奖励信号，反馈给强化学习循环。这里的核心要求是"稳定、低延迟、可重复"——因为RL的每一次反馈都直接影响策略更新，如果沙箱执行不稳定或者环境状态不干净，整个训练过程都会跑偏。
两种模式对沙箱基础设施的要求侧重点不同，但DSec用一套系统同时支撑了两者。这种"一套平台、双模支持"的设计，落到工程上其实相当有挑战——既要保证SFT阶段的高强度扩缩容，又要满足RL阶段低延迟反馈的需求，两者对调度器、对实例生命周期、对资源回收策略的期望是完全不同的。论文里用统一的弹性策略去覆盖这两种负载，后面我会专门展开讲它的扩缩容逻辑。
2. 架构设计拆解：为什么偏偏选微虚拟机
2.1 Firecracker的定位：安全与轻量的平衡点
DSec的核心虚拟化技术选型是Firecracker微虚拟机。这个选择我自己在做同类系统时深有感触：Docker容器虽然启动快、资源占用低，但在多租户场景下隔离性始终差一口气——内核共享意味着逃逸攻击一旦发生，影响范围可能扩散到整个宿主机。反过来，传统QEMU/KVM虚拟机安全边界倒是清晰，但启动时间动辄几十秒，镜像动辄几个GB，规模化跑训练任务时成本太高。
Firecracker是AWS开源的KVM-based微虚拟机方案，它的设计目标就是"像容器一样轻量，像VM一样隔离"。每个微虚拟机实例的内存开销可以压到几十MB级别，启动时间在百毫秒到数百毫秒量级，同时它通过硬件虚拟化提供了完整的独立内核、独立设备模型。DSec选择它作为沙箱载体，本质上是在安全边界和资源效率之间找到了一个工程可接受的平衡点。
打个比方：Docker容器像是合租公寓里的隔断间，室友之间用木板隔开，方便是方便，但隔音和安全性有限；传统虚拟机像是每户独立的一居室，墙是实打实的钢筋混凝土，但房租和维护成本高；Firecracker更像那种麻雀虽小五脏俱全的小户型——每一户都是独立的水电燃气，但面积压缩到了极致。对于沙箱这种"住两天就退租"的场景，微虚拟机几乎是量身定做的产物。
2.2 多租户隔离与批量生命周期管理
多租户隔离是DSec一个无法回避的设计重点，因为Agentic Training场景下的沙箱要执行的是模型生成的代码——这本身就是不可信代码，可能被恶意prompt注入引导去执行危险操作。"黄雀攻击"（即攻击者从一个租户的沙箱横向移动到同一物理机上的其他VM）是论文明确提到的威胁模型之一。DSec的做法很直接：每个沙箱绑定一个单独的微虚拟机，租户之间不存在共享内核、共享运行时的问题，物理机上的VM逃逸被限制在单个租户内。
这让我想起之前做过的一次安全评审：当时我们用容器跑Agent训练数据采集，蓝队模拟了一次容器逃逸，结果横向渗透了三层网络才被拦住。后面换成微虚拟机后，攻击面收敛得非常明显。这不是说微虚拟机万无一失，而是说你在训练数据这种高风险的输入源头，应该把防线的纵深拉得足够厚。
生命周期管理方面，DSec的工程实现也很直接：它把沙箱创建到销毁的全流程拆成多个阶段，每一阶段都有明确的启动超时和重试机制。因为底层依赖的组件（比如存储服务、网络组件）可能在上百个沙箱并发创建时出现偶发超时，如果没有幂等的状态转换和自动重试，整个流水线会被小概率故障拖垮。论文特别强调所有组件接口都做了幂等设计——这是大规模基础设施里最容易被低估、但实际生产中最重要的工程细节之一。
批量操作也值得一提。DSec的设计里，你可以对一批沙箱ID执行统一操作（启动、停止、销毁），而不是一个一个去调API。这个细节在你处理几千个消失的沙箱时才能体会到价值——单实例管理在大规模场景下会成为严重的瓶颈，批量操作配合幂等重试，才能让失控的事故在分钟内被控制住。
2.3 服务编排：幂等状态机与长时间轮询
DSec在编排层面值得学习的一点，是把"状态转换"当成了显式的服务协议。每个沙箱实例有明确的生命周期状态机（比如从"创建中"到"运行中"再到"销毁中"），客户端通过长时间轮询（long polling）方式来endpoint等待状态变更通知。为什么不直接用推送式的Webhook？因为在大规模分布式系统里，推送需要额外的消息队列、重试机制和持久化，复杂度会暴涨；轮询模型天然对故障更鲁棒——客户端挂了，状态照样在服务端推进，恢复后一查就知道当前状态。
长时间轮询相比普通轮询的好处是降低了无效请求量。普通轮询一秒打一次API，在实例数量上千的时候，会给服务器造成大量无意义的压力。长轮询让客户端挂起等待，直到状态变化才返回，既保证了实时性，又控制了请求频率。这种设计思路在做任务调度系统时可以直接照搬，它不依赖任何复杂的中间件，但工程上非常稳定。
我在实际做类似系统时也有同感：编排不能过度依赖单一组件的事件推送。读论文的时候看到他们把长轮询作为兜底同步机制，和我的经验完全吻合——事件推送是优化手段，轮询是正确性保障，二者配合才能在高负载下保持稳定。
3. 弹性伸缩的控制逻辑：队列、利用率和租户信用
3.1 扩缩容指标的选择：为什么不能只看CPU
做基础设施的人对扩缩容都不陌生，但DSec的扩缩容策略比常见的"按CPU利用率扩缩"要精细得多。论文里提到，系统会根据每个流水线的实例队列长度（queue depth）、CPU利用率、以及租户的信用余额来动态决定扩缩容。
为什么需要队列长度这个指标？因为Agentic训练的负载是高度突发的——一批训练任务发下来，几百个沙箱在几分钟内被同时申请，CPU利用率还没来得及反映压力，任务已经积压了。队列长度是超前的指标，它能捕捉到这种脉冲式的需求；而CPU利用率是滞后的指标，它反映的是已经稳定下来的持续负载。两个指标配合，才能既响应突发又避免过度扩建。
这就像开餐厅：光看店内上座率去决定要不要加桌子是不够的，门口等位的队伍才是更早的信号。但如果只盯着门口队伍，又容易在高峰期过后留下大量空桌。队列长度和CPU利用率同时看，才能既接得住高峰，又不至于平时养闲人。
3.2 租户信用机制与抢占式回收
多租户环境下最难的问题之一是：怎么防止个别租户抢占公共资源。如果按优先级硬分，低优先级租户可能永远等不到资源；如果不加限制，资源被少数大任务独占，整个集群的公平性就没了。DSec的解法是引入"租户信用余额"（tenant credit balance）机制：每个租户有一定额度的"信用"，当它持续占用资源时信用会消耗，信用耗尽后系统可以优先回收它的空闲沙箱。
这里的关键细节是"先发制人式"（preemptive）回收：系统不是等租户自己释放，而是主动对空闲沙箱做回收操作，但对每个租户可回收的沙箱数量设了上限。这个上限非常关键——它保证即使某个租户信用已经很低，也不会被一次性回收全部资源导致训练任务大规模中断。设置合理的上限，既能抑制资源滥用，又能保护租户的业务连续性。
这种机制给我的启发是：弹性伸缩不能是"简单加机器/减机器"的二元操作，它需要业务语义的约束。DSec把"租户信用"这种看起来偏业务的概念引入基础设施调度，本质上是在资源分配中增加了一层博弈论的约束，让系统在极端拥堵下也能保持基本的公平性。
3.3 资源约束与QoS：cgroup的weight模式
资源限制方面，DSec采用的是cgroup v2来管理沙箱的CPU和内存。论文提到一个细节我特别认同：CPU管理用的是weight模式而不是hard limit模式。如果给每个沙箱设置固定的CPU硬上限，当一个沙箱处于空闲而另一个沙箱需要更多CPU时，空闲沙箱的上限无法让渡给繁忙者，系统资源会被白白浪费。
Weight模式则不一样：它定义的是CPU时间的相对权重而非绝对上限，CPU有空闲时，繁忙任务可以借用其他沙箱不用的计算能力。这样既保证了每个租户的基础服务质量，又不会导致资源碎片化。这其实和微虚拟机配合得很好——微虚拟机本身占内存较小，CPU用weight调度后整体资源利用率可以做到非常高。
在实际训练任务中，这种设计的效果很直接：一批沙箱同时跑数据采集，有的任务写代码偶尔等待I/O，有的任务全程高性能计算，weight模式让等待的计算资源自然流向高需求的任务。和K8s里常用的requests/limits那种"预留+硬墙"策略对比，DSec的调度方式更适合"单个任务CPU需求波动大"的智能体训练场景。
4. 沙箱交互与Agent训练的数据闭环
4.1 沙箱里跑什么：代码执行、CLI与Web界面
DSec的沙箱不只是"能执行Python代码"这么简单。论文提到，沙箱内的Agent交互界面分为几类：直接的代码执行环境、命令行界面（CLI）、以及基于浏览器的图形界面（Web GUI）。这个设计背后的逻辑，我认为值得每个做Agent数据的人都仔细想想。
很多Agent项目把工具调用等同于API调用——让模型学会请求一个JSON接口就算完事。但真实世界的工具使用场景远不止API：日常工作大量发生在Terminal里敲命令、在网页后台点按钮、在IDE里写代码。如果你的训练数据只覆盖API调用，模型学会的只是"调用接口的工具"；DSec让Agent同时学会在命令行和Web界面上交互，训练出来的Agent能力泛化性会好很多。
对应到实现上，DSec的沙箱要为这些交互形态提供完整的环境基础，比如预装常用命令行工具、提供无头浏览器环境、捕获GUI操作产生的屏幕信息等。这几类交互界面在同一个沙箱内共存，对镜像设计和依赖管理提出了更高的要求。你既要把Python包、Node.js运行时装好，又要在内存有限的情况下跑起浏览器内核，这种"麻雀虽小五脏俱全"的镜像设计，本身就是工程活。
4.2 从任务生成到轨迹回收：一条完整的数据生产流水线
DSec在整个Agent训练闭环里的位置，用一句话概括就是：它是我前面提到的那条数据生产流水线的"执行层"。完整的链路大概长这样：任务生成器选择或生成指令样本→调度器分配一个沙箱→沙箱内加载模型并进行推理→模型调用工具/执行代码→环境返回执行结果→模型根据结果调整下一步→直到任务结束→系统回收轨迹数据并写入数据集。
这条链路的每个环节都有对应模块：DSec负责任务与沙箱的匹配调度、执行环境的生命周期管理、以及执行过程中产生的日志和输出的采集。真正读论文时让我眼前一亮的是，DSec把沙箱内执行的粒度拆到了job级别——同一个沙箱可以顺序跑多个job，而不是一个沙箱只能执行一次任务。这个设计在工程上带来的好处是：减少沙箱创建销毁的频率，降低冷启动开销，同时让调度器在"分配沙箱"和"分配job"两个维度上都有弹性。
这也解释了为什么前面强调幂等性和队列长度——在job粒度的调度下，系统的响应速度不再取决于"启动一台虚拟机"的时间，而取决于"沙箱内当前job是否结束"。频繁且快速的job切换，对底层基础设施的稳定性和调度算法的要求会高一个数量级。
4.3 可观测性与数据质量
智能体训练还有一个让人头疼的点：Agent在沙箱里的行为是全过程的、多模态的。模型可能先敲了一串命令，又打开一个网页，再看一眼代码输出，最后得出结论——这整个过程都是训练数据。DSec必须完整记录这些行为轨迹，同时保证采集过程本身不影响沙箱的执行效率和隔离性。
这是个典型的"观察者效应"问题：如果你在沙箱里塞太多日志采集Agent，执行性能会下降；如果采集不全，训练数据质量又会打折。论文里反复提到"可观测性与效率的权衡"，在实操层面就是：日志怎么存、存多久、采样频率多高、如何与训练框架格式兼容。
我自己的看法是，数据质量是Agentic Training里最容易翻车的地方。沙箱把代码跑通了，不等于Agent就应该学到这种行为——你得区分"这次运行成功是因为模型确实理解了问题"还是"纯属瞎猫撞上死耗子"。所以高效的数据生产基础设施，一定要在执行层就提供数据过滤和注释的钩子，让训练团队能够按质量快速筛选轨迹。DSec在架构层预留的这种能力，是整个数据闭环中不怎么被提起但极其重要的一环。
5. 安全与对抗：沙箱基础设施的另一面
5.1 训练场景下的威胁模型
读这篇论文时，我把安全攻击面单独梳理了一遍。Agentic Training的沙箱基础设施面临的威胁与传统云计算平台不同，它有几个非常特殊的点：
训练数据天然不可信。模型在训练阶段可能被prompt injection诱导产生恶意指令，也可能模型自身"学到"了危险代码模式。也就是说，沙箱执行的代码从源头来看就是敌对的。
数据价值极高。Agent的训练轨迹是核心资产，一旦泄露，等于训练配方被偷走。沙箱平台的网络隔离、数据加密、日志脱敏都要额外小心。
攻击可能来自任意租户。多租户共享物理机环境下，一个租户的恶意沙箱可以尝试攻击同一物理机上的其他沙箱，也就是论文提到的"黄雀攻击"场景。微虚拟机在这个场景下为租户间提供了坚实的隔离边界。
这三点叠加，注定了Agent训推基础设施的安全设计不能用"外网安全+内网信任"这种传统思路，而必须假设每一个沙箱都是被攻陷的，来设计防御纵深。
5.2 多层防护与攻防演练经验
DSec的防护策略是层层设防的：第一层是微虚拟机隔离，保证VM逃逸无法影响宿主机和其他VM；第二层是资源限制（CPU、内存、网络带宽），防止被攻陷的沙箱发起资源耗尽型攻击；第三层是操作系统的安全加固（最小化运行组件、关闭非必要设备）；第四层是运行时监控和输出过滤，及时发现可疑行为。
论文还提到一个很有意思的细节：除了内部工程团队的走查，DSec还邀请了外部安全研究人员进行漏洞赏金测试。做AI基础设施的安全工作，光靠内部视角远远不够——因为Agent生成的内容可能解锁你从未预料到的攻击方式，外部安全研究者的思路更容易打破思维定势。
我自己的实操经验也支持这个结论：去年我们做了一轮Agent沙箱的蓝队演练，内部团队模拟了二十多种注入和逃逸手法，最后发现真正有效的拦截点还是在网络层面和系统调用层面，而保护层最终采用的是微虚拟机方案。把不可信代码放进微虚拟机，再加一层系统调用过滤（seccomp），这个组合在攻防压力测试中表现出色，强烈推荐给同类场景。
6. 从论文到落地：构建自己的Agent沙箱时的经验与坑
6.1 选型决策：从Firecracker到各类方案的一步步取舍
读完论文之后，最直接的问题就是：我也想做一套类似的系统，该怎么选型？我的清单大概是这样的。
裸容器方案（Docker/K8s）适合你的Agent只在受信代码和工具上跑、不涉及不可信模型输出的场景。优点是生态成熟、上手快，缺点是隔离性与微虚拟机有明确差距。要知道，Docker容器逃逸在现实的云上环境里并不罕见，一旦发生了你所面临的就是整个宿主机上的所有任务一起遭殃。
纯Firecracker方案适合训练数据采集这类高风险场景，DSec论文的原型也基于此。缺点是网络模型相对底层，需要自己处理网络配置、镜像管理和存储，K8s集成也需要额外工作。
QEMU/KVM方案适合需要GPU透传或特殊硬件支持的场景，Firecracker目前对PCI设备透传支持有限，这是一个硬约束条件。
如果你想快速落地，也可以用Kata Containers——它封装了微虚拟机的安全性和容器生态的易用性，但对底层资源的控制力不如自己直接管Firecracker强。我的建议是：如果你团队有能力直接对接KVM和Firecracker API选Firecracker，如果希望工程迭代速度更快选Kata，想清楚这两条路再动手。
6.2 冷启动、依赖管理与成本控制
冷启动优化是沙箱平台和老牌VM平台共享的核心命题。DSec的思路依赖快照和预置镜像来回避启动过程中的重复成本，实打实将这部分的耗时压缩到了秒级。我自己的做法是在镜像设计上做分层——基础层直接包含Python运行时、常用科学计算包、Node.js和Chrome，业务层才按任务类型克隆构建成快照。这样沙箱创建时基本不需要再下载安装任何东西，速度和成本都得到了明显的优化。
依赖管理是个隐形杀手：有的训练任务要求装一个特定版本的库，装的时候可能要下载上百MB文件，如果每一个沙箱都在启动时现场装，资源肯定会迅速耗尽。经验做法是设计一个专用的依赖预加载池：沙箱启动后不是立即执行任务，而是先从预加载池里快速拷贝已经解压的依赖目录，比现场通过包管理器安装要便宜得多。这和DSec论文里谈到的"在沙箱里预先配置依赖库，或根据job需求动态安装"，本质上是一个思路。
成本估算方面，沙箱平台的一大优势是按需启停。对于SFT数据生成这类非实时任务，可以把沙箱的空闲回收缩短到分钟级别，很多沙箱一天内可以多次复用，把单条轨迹的生产成本压下来。做这类优化时不要只盯着单个沙箱的成本，而是要看整条流水线的单位数据产出成本——这也是论文的表分析视角里最有价值的启发之一。
6.3 我在实操中踩过的三个坑
关于沙箱，我几次犯错留下的记忆都还比较深，具体是三个方向。
没有做网络层的默认拒绝。最初我以为沙箱里跑了不可信代码，只要隔离了内核就算安全，结果没限制网络出站方向。直到沙箱内一个Agent执行了一段探活脚本，试图去扫描同VPC内的云资源，我才意识到网络层必须按默认拒绝策略实施，只放行预定义的目标地址（如内网数据回传通道）。
忽视了输出数据中的敏感信息。训练轨迹采集往往直接抓取Agent在沙箱内的全部输出，但Agent可能读取到了不该读取的环境变量、文件路径甚至密钥信息，这些未经脱敏就进入了训练数据集，后续清理极其痛苦。这是我在数据质量问题里吃过的最大的亏，务必要在采集层就做敏感信息过滤。
把状态全放在内存里。早期为了追求性能，我把沙箱调度状态放在进程内存里，一台服务重启就丢了全部状态，沙箱变成了孤儿。换成持久化存储之后，再配合DSec那种幂等状态机+长轮询的模式，整个系统的稳定性和可排查性都上升了不止一个台阶。
这几个坑，其实论文里都有对应的解决思路，但如果只读不实践，很难理解为什么要那么设计。我的体会是：读基础设施类论文，最有效的方式是带着自己的工程问题去读，边读边对照自己踩过的坑，收获会成倍放大。
最后再分享一个小技巧：如果你正在计划搭建Agent训练的数据流水线，不要从一开始就追求和DSec一样的完整度。建议先落地最小的闭环——由代码执行环境加上基础的任务调度器实现，再把安全加固和弹性伸缩迭代进去。论文里的整套架构逻辑是完全自洽的，但按阶段演进、逐步补齐每一层的能力，整体的确定性更强一些。
