1. 这篇论文在解决什么问题Agentic训练的环境困境先交代一下背景。DeepSeek在做大模型的后训练post-training时尤其是RLReinforcement Learning强化学习阶段模型需要不断地在真实或模拟环境里执行动作、观察结果、再决定下一步。这个动作-观察循环在Agentic训练里就是模型写代码、跑代码、看输出、改代码或者调用工具、操作文件系统、浏览网页等等。我和不少做训练框架的同行聊过大家遇到的最大痛点其实不在模型本身而在环境管理。你想想训练进程要跑几千个rollout就是让模型自由探索生成轨迹每个rollout都可能涉及一次代码执行。如果直接把代码丢给Python解释器跑在训练进程里那Python环境会被搞脏一个线程崩了可能影响整个训练任务安全性更是无从谈起。如果每个rollout单独起一个Docker容器容器的创建销毁开销又大得吓人几秒钟的延迟乘以几千次训练时间直接失控。DSec这篇论文全称DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale做的就是把这层环境管理独立出来做成一个弹性沙箱基础设施。训练进程不再自己管理执行环境而是通过HTTP接口甩给DSec集群由DSec负责创建容器、执行代码、保存状态、销毁环境。这样训练进程只管生成动作和读取结果环境相关的脏活累活全部解耦出去。我读完之后最大的感受是这不仅仅是一套基础设施它实际上解决了三个之前一直纠缠在一起的问题——安全性隔离任意代码执行、弹性按需创建海量沙箱、状态持久化一个agent的多轮交互需要在同一个环境里连续进行。下面我把整个系统的设计思路和论文里的关键细节拆开讲最后再聊聊这套设计对自建Agentic训练系统的借鉴意义。1.1 为什么RL训练需要能跑代码的环境要理解DSec的价值得先清楚Agentic训练里环境扮演的角色。传统RL比如训练机器人策略里的环境是模拟器状态转移是固定的。但大模型Agentic训练里的环境往往是代码解释器、文件系统、网络接口这类通用计算环境。模型根据当前任务状态生成一段代码代码在环境里执行执行结果stdout、stderr、返回值、文件变化、退出码作为观察空间反馈给模型模型再生成下一步动作。这个循环里有几个天然需求执行必须隔离。模型生成的代码是不可信的可能是格式错误的、死循环的、删库的、尝试访问敏感文件的代码。它必须在受限沙箱里跑绝不能接触训练集群的主机。状态必须连续。一个agent解决一个编码任务往往需要十几到几十轮交互每轮之间文件和变量状态是延续的。你不能每轮都开个全新容器那样上一轮写的文件、装的包全没了。并发必须极大。训练时是几千个worker并行采样每个worker可能同时跑多个轨迹意味着同时需要存活的沙箱数量可能是几千到上万个而且创建沙箱的请求是突发的不是均匀分布的。DSec把这三件事放在一个统一系统里解决论文里用的词叫Elastic Compute本质上就是面向Agentic训练场景的容器编排系统只不过编排的粒度从服务变成了一个完整的agent工作环境。1.2 固定沙箱方案为什么行不通现在很多研究团队做中小规模的agent实验用的方案是每个训练worker内置一个沙箱管理器——worker进程需要执行代码时调用本地Docker API起一个容器执行完销毁。这个方案在几十并发下勉强能用但规模一上来全崩。三个最明显的问题第一资源利用率极差。每个worker自己管一摊容器容器分布是跟随进程的不是跟随负载的。有些worker可能同时需要10个沙箱有些一个都不需要没法全局调配。第二环境生命周期割裂。基于session的agent任务需要长寿命沙箱但训练进程重启、崩溃、抢占调度时本地沙箱管理器跟着进程一起死所有agent的上下文全部丢失只能从头再来。第三执行吞吐受限于worker单机。当所有rollout都在同一台机器上跑代码时CPU、内存、临时磁盘的争抢会非常剧烈。跑代码和跑推理抢占资源训练吞吐被严重拖累。DSec的架构逻辑就是针对这三个痛点逐项做解耦沙箱生命周期不再绑定训练进程资源调度从单机扩展为集群执行负载被路由到独立的计算节点。1.3 这套系统在DeepSeek训练流水线里的位置论文里DSec是作为agentic training infrastructure出现它处在整个训练流水线的中间层。简单画一下它的上下文训练侧是模型推进rollout进程它们负责把模型生成的中间结果喂进来DSec对外暴露一组HTTP API内部是一个沙箱集群在DSec更外围是数据采集、验证器validator等模块。关键点在于DSec只负责执行和环境管理不做语义判断。代码跑完对不对、返回结果符不符合预期那是验证器或者reward模型的事。这个职责划分非常重要它让DSec变成一个相当纯粹的基础设施——任何训练框架、任何验证逻辑只要是需要在隔离环境里执行模型生成的代码并拿到结果的场景都可以直接接进来。这个点在后面讨论设计启示时我还会展开因为它对理解DeepSeek为什么能快速支持各种任务形态数学题、编程题、工具调用、网页浏览非常关键。2. 架构拆解控制平面、数据平面与执行协议DSec的整体架构读起来很像一个云基础设施系统但它针对训练场景做了很多细节上的取舍。论文给出的核心组件包括一个中心化控制服务、若干执行节点类似计算节点以及训练进程与系统之间交互的协议定义。下面按层次拆开讲。2.1 控制服务的职责沙箱的注册、创建、路由与调度控制服务论文里可以理解为Dsec Controller / Manager是DSec的大脑它维护了全局沙箱Registry知道集群里每个执行节点上当前有多少活跃沙箱、剩余多少配额、沙箱的类型是什么、所属session是谁。当训练进程发起创建沙箱请求时Controller负责检查资源配额和租户属性决定是不是允许创建根据调度策略选一个执行节点常见策略是最空闲优先或者按沙箱类型亲和性优先通知执行节点拉取镜像并启动容器在Registry里注册这个沙箱返回一个沙箱ID后续所有针对这个沙箱的执行请求Controller都会路由到所在节点。这里比较关键的调度单位不是CPU/内存而是沙箱实例。论文里的思路是把沙箱看作第一公民资源调度依据是当前节点上已存活的沙箱数 预估创建成本。这个设计的聪明处在于一个沙箱的生命周期往往贯穿一个agent任务的多轮交互所以调度时不仅要考虑哪台机器现在最空还要考虑哪台机器最可能长时间稳定存活以减少跨节点迁移DSec里不迁移活跃沙箱迁移代价太高这跟云主机反着来。2.2 数据面实现训练进程如何与沙箱交互控制面管生老病死数据面管干活。训练进程创建沙箱后不会直接登录进容器而是统一通过HTTP API发指令。DSec定义的交互接口文档里大概包含这么几类操作exec执行命令比如/run传入要执行的程序代码或者shell命令沙箱内执行器负责运行并把stdout、stderr、execution time、exit code返回。文件读写和编辑agent要修改工程文件时可以读取指定路径的内容或者用定位-替换语义做精准编辑避免整个文件重写带来的token浪费。状态快照与恢复一个长任务中间可以存快照后面从快照恢复环境继续跑这对训练集群容错和任务续跑都很有用。交互结果格式设计得干净利落通常是结构化JSON一个actions字段描述这次执行的内容一个observation字段描述环境的反馈代码输出、报错、文件树等。模型看到的观察就是observation训练框架拿到的反馈也是它接口天然贴近Agentic训练的推理循环。这里有个细节值得说为什么不直接让训练进程起一个SSH会话或者用Docker SDK因为DSec的沙箱是可以刷状态的——模型完蛋了环境崩溃了训练进程可以随手让DSec销毁旧的、立即创建一个同类型的新沙箱然后继续。如果训练进程直接持有容器句柄恢复就得自己做迁移复杂度会高很多。中心化路由的存在让环境丢失对训练进程变成一件影响很小的事。2.3 沙箱的类型设计不只是Python解释器论文里DSec支持的沙箱类型是分层的。最核心的是代码沙箱CodeSandbox里面预装Python解释器、常用科学计算库numpy、pandas这类、编译器gcc/clang、Shell工具链。这类沙箱用来承接数学推理、编程竞赛、数据分析类任务。但Agentic训练不全在写代码还有工具调用型任务和搜索/浏览型任务。论文里还提到了可以内嵌WebAgent相关的能力——比如沙箱里跑一个Chromium实例模型可以通过一个浏览器工具接口去操作页面。这非常像DeepSeek在实际发布中提到的WebCanvas或类浏览器控制环境。我把沙箱类型理解成一个可扩展的注册表每种沙箱类型就是一个预配置的镜像模板加上一组操作原语。训练代码要用的环境全部提前打进镜像里而不是运行时再装。这是沙箱要快的基本保障——创建容器只解决镜像运行时的开销不承担包安装的时长。2.4 容错处理分布式训练里的半崩溃哲学RL训练里环境的崩溃是常态不是异常。模型写代码可能让沙箱OOM内存溢出、写坏文件系统、甚至让容器挂掉。DSec对这种情况的处理方式让我觉得它是真正被训练事故毒打过的系统。它没有追求永不故障的沙箱而是假设沙箱会经常坏然后快速替换。论文里应该是明确说了崩溃沙箱里的agent session会被丢弃或基于最近的检查点恢复训练进程收到错误码后可以决定是重试、更换沙箱还是放弃这条轨迹。这背后体现的部署哲学是与其花大力气保证单个沙箱的稳定性不如把替换沙箱设计成极廉价和高频的操作。这个思路跟分布式训练里checkpoint/restart的容错模型是一致的只不过DSec把它应用到了环境层。3. 弹性扩展策略从单个Agent到千级并发DSec名字里的Elastic弹性不是白叫的。对训练来说资源需求是陡变的一个训练step刚开始所有worker同时创建沙箱一个step结束沙箱批量销毁。这个波峰波谷如果不用弹性方案而是提前预留几千台机器加几千个常驻容器成本直接翻几倍。3.1 沙箱创建延迟预创建池与镜像缓存论文里一个关键的优化点是想尽办法降低沙箱创建延迟。容器创建的瓶颈通常不在docker run本身而在镜像拉取和初始化依赖。DeepSeek的做法我推测是几个手段的组合提前把沙箱镜像预置到每个执行节点避免运行时拉取保留一个热沙箱池warm pool后台常备少量已经创建好、等待分配的干净容器训练进程请求创建沙箱时优先从这个池子里捞省掉镜像启动时间镜像层启用共享缓存同类型的沙箱共享基础层只差异化顶层。这个思路跟Serverless里的冷启动优化是一个道理。论文如果给出数据的话目标应该是把创建延迟压到百毫秒级滚动的训练worker几乎不会感受到创建了一个新容器的等待。3.2 资源波动的应对Scale-to-Zero与按需扩容训练并不是24小时满负荷的。可能是白天调代码、跑实验夜里集中大规模训练。DSec的弹性策略允许集群在低负载时把执行节点缩到很少甚至缩到零scale-to-zero训练任务开始前由控制服务根据job的资源预估量发起扩容。这带来的一个好处是基础设施成本能被压住。但注意扩缩容不是即时的节点扩容要拉起新机器、准备镜像、注册到集群一般需要几十秒到几分钟。所以论文里应该有为每个训练job预留扩容提前量的概念或者提供一个训练开始前预热集群的接口。对我来说这个设计的启示在于弹性不只是省钱的技巧它直接决定了你可以多快地撞到规模极限。如果你不弹单机器上限可能300个并发沙箱弹了以后单job并发直接到几千。3.3 多用户与租户隔离训练实验的打架预防做训练研究的人应该都有这种经历同时开两三个实验各自都要几百个环境执行一旦资源没隔离所有实验一起变慢互相干扰到怀疑人生。DSec里提到了租户tenant的概念训练job可以申请自己的资源配额控制服务负责调度多个job之间的资源池。这个功能对于团队协同开发和并行实验很有价值。每个实验相当于有一条独立通道访问DSec集群互不抢劫资源。3.4 对GPU训练进程的影响最小化等待最后再提一个容易被忽视的点。DSec把环境执行从训练进程里彻底拿出去之后最直接的效果是训练进程不再被慢速的本地代码执行阻塞。以前跑RL模型生成一条轨迹要等本地容器执行完所有代码才能继续下一步而这个执行时间可能是几十毫秒到几十秒不等GPU推理进程就干等着。用DSec以后rollout worker发出执行请求后可以做别的——生成另一批动作、处理另一条轨迹。执行和推理异步流水线化训练吞吐自然上来了。这个解耦让两边各自最大化利用率的原则PSD强调了很多次我觉得是所有Agentic训练框架都应该抄的作业。4. 从DSec到Agentic训练方法论几个关键设计启示标题里写着A Sandbox Infrastructure for Effective Agentic Training at Scale我读完整篇最大的收获倒不是DSec本身有多牛而是它背后反映的DeepSeek对Agentic训练的系统性理解。有几点想单独拿出来聊聊。4.1 验证器与沙箱的分工逻辑DSec明确把执行和验证分开沙箱只负责给代码一个可以跑的、可观测的、隔离的环境至于这道题做得对不对由验证器模块Validator判断。这个分离看似微不足道实际上让训练基础设施的复用性大幅提升。你可以想象老版本里很多人为了验证一道数学题的答案可能直接在生成脚本里调用一个subprocess去执行Python表达式把验证和执行耦合在一起。一旦任务变成做工程写测试修bug这种脚本就完全废了得从头写一套。有了统一的沙箱API之后验证器只是一个消费观察结果的纯函数——输入是沙箱反馈的输出、文件状态、退出码输出是reward。新任务来临时重点变成设计验证逻辑而不是再搭一遍环境。这个抽象层级对规模化太重要了。4.2 上下文持久化是Agentic训练规模化的隐形门槛很多人低估了一个agent任务要持续存在多个沙箱里这件事的难度。但在DSec的设计里环境持久化是一等需求。因为Agentic任务跟单轮问答不一样它的本质是一个agent在多轮交互中和环境持续对话。这个持久化如果做不好会出现什么情况模型已经改了5轮代码第6轮环境崩了如果没做状态保存这5轮的全部工作就白费了。在数千并发规模下环境崩溃是必然发生的所以恢复有多快直接影响训练效率。DSec用session粒度管理生命周期用快照/恢复让环境具备穿越崩溃的能力这套机制我认为是它和普通容器集群最本质的区别之一。普通容器编排关注的metric是服务没宕机DSec关注的是agent的完整交互历史没丢。4.3 对开源自建Agentic训练平台的借鉴意义读这篇论文的时候我心里一直在想如果自己的团队要搭一套agent训练环境至少能借鉴出三层东西接口层定义一个执行-观察的规范API不要绑定具体技术栈。这个接口应该天然支持动作代码/命令/工具→ 反馈输出/状态→ 下一步的循环。服务层做一个中心化的沙箱路由服务把环境创建、调度、销毁统一管理按需创建池化复用来扛规模。环境层把每个agent的工作环境做成可预置的镜像把跑环境这件事从训练进程里剥离出来当作一个独立服务来调。这三层看起来都是基础设施该干的事但很多团队实际做的时候第一版总是忍不住把环境管理器塞进训练代码里——一个类里管model、管sampling、管docker、管reward。DSec的经验是越早把环境这层抽出去后面做规模化和多任务扩展就越轻松。5. 阅读笔记之外的实操延伸如果你要自建类似的沙箱训练环境笔记写到这里理论层面聊得差不多了。但我知道看这篇笔记的人很大概率不是DeepSeek的员工而是感兴趣在自己项目里复现这套思路的工程师或者研究者。所以我再加一段偏实战的内容讲讲从DSec的论文出发自己搭一套可用的Agentic沙箱训练基础设施哪些环节最值得投入哪些坑我已经踩过了。5.1 最小可行方案Docker加一个编排层其实你不用一上来就搭Kubernetes。最小可行方案可以是这样用Docker或者Docker的Python SDK作为容器运行时的底座写一个简单的FastAPI服务提供/create_sandbox、/run_code、/read_file、/delete_sandbox这几个接口后端用一个SQLite或者Redis做沙箱注册表记录每个sandbox_id对应的容器信息和session归属训练进程就只通过这个HTTP服务操作环境不再直接碰Docker。这套方案一两天就能搭出来已经能支撑小规模的Agentic训练实验几十个并发。性能瓶颈会出现在单机的容器密度和API服务的并发处理上限但对原型验证来说够用了。5.2 规模化时要补的课镜像管理、故障注入与配额一旦并发规模上到几百甚至上千原型的短板马上暴露。下列说法都来自我实际踩过的坑镜像版本管理要严肃。每个沙箱类型都要有镜像tag比如code_env:1.2.0训练任务和镜像版本绑定不然环境一半更新一半不更新会让你调试到怀疑人生。必须有配额和限额。模型可能会生成无限循环的代码沙箱里必须对运行时间、内存、CPU核数、文件系统大小做硬限制。超限直接kill进程不能只靠软超时。故障要当成基线场景。从第一天就把沙箱挂了怎么办写进训练逻辑不要假设环境永远不坏。训练代码里要能处理HTTP 500、超时、连接被拒这类错误。日志和指标单独出来。沙箱的执行日志、耗时、失败率要统一收集训练任务挂了以后排查环境问题这是唯一的抓手。5.3 和安全相关的几条边界因为是训练代码执行的沙箱安全隔离级别要高于普通测试环境。我自己的建议是容器不加privileged权限不mount宿主机目录网络默认隔离或者只暴露必要出口沙箱镜像里不放训练集群的密钥或者可访问内部服务的凭据沙箱执行阶段限制DNS和网络端口如果任务需要联网则用一个白名单代理转发。这些不用做到云级别的强隔离但对训练场景来说模型代码无法碰到训练数据和宿主节点一定是底线。5.4 什么时候值得上DSec这种完整架构最后聊聊取舍。如果你的项目还不大单机训练几十个并发Docker封装那套完全够用不必过度设计。但如果你已经到了这几个阶段那确实值得参考DSec把环境层做成独立服务rollouts已经分布式部署在多台机器上agent任务开始需要多轮交互、长上下文、文件持久化同时跑多个训练job资源协调已经靠人肉完成不了训练吞吐开始被本地执行阻塞GPU利用率上不去。说到底DSec解决的本质问题是一个规模化之后的架构问题。早期直接练规模大了再分拆是自然演进路径但读一下DSec的论文可以让你在还没到规模之前就知道往哪个方向演进。最后我自己的一点体会基础设置这类系统做得好的时候你会感觉不到它的存在——训练代码只管生成动作、接观察、算reward环境永远在线、永远干净、永远够用。DSec的论文把这种隐形背后的设计讲得相当清楚。而真正把环境当服务做好Agentic训练的各种新玩法工具调用、多智能体协作、浏览器操作、代码agent才可能流水线化地量产出来。这也是我觉得这篇论文值得反复读的原因。