面向智能体训练的沙箱基础设施：DSec弹性计算设计实践

做智能体训练做到后半程基本都会碰到同一个尴尬模型开始学会调用外部工具了但你不敢让它放开手去调。倒不是担心模型本身有什么恶意而是训练过程中大量试错行为真实环境根本兜不住。命令执行错了、文件写乱了、外部接口被反复请求这些不确定操作一旦落到生产环境代价都是实打实的。我参与设计并落地了这套面向大规模智能体训练的沙箱基础设施DSecDeepSeek弹性计算目的就是把“让智能体放开手脚探索”这件事变得可控。DSec这个名字有两层含义既是DeepSeek Elastic Compute的缩写也暗示了这套体系的底座是沙箱安全Sandbox能力。它的核心定位很直接在大规模、高并发的智能体训练场景下给每个训练任务提供一个隔离、弹性、可观测的沙箱环境。适合正在做AI Agent训练、LLM工具调用评测、数据飞轮构建的团队参考也适合想把自己实验室的模型训练环境升级成正规化基础设施的个人开发者。开头先把结论说清楚DSec不是另一个训练框架它解决的是训练任务运行环境层面的问题——资源怎么弹性伸缩、任务怎么互相隔离、危险操作怎么拦截、训练过程怎么审计。下面我把这套基础设施的设计思路、核心模块和落地过程中的经验教训拆开讲。1. 智能体训练为什么需要“沙箱弹性”双载体1.1 传统训练环境在智能体场景下的三个失灵现场传统的模型训练跑批任务环境诉求非常单纯固定的数据、固定的脚本、固定的显存。但智能体训练完全不是这么回事智能体会在训练过程中动态生成操作序列可能调用工具、执行代码、读写文件、请求外部服务。我们最早在普通训练机上跑这类任务很快撞上三个问题。第一个是单点污染。智能体一旦在某个环境里执行了错误命令后续训练数据都会被污染。智能体把配置改乱了、安装了乱七八糟的依赖下一次实验的结果就和上一次不可比了。做过的同学都懂训练数据一脏整个评测结论直接作废浪费的不只是算力还有团队的时间。第二个是安全边界缺失。训练智能体时会有一类特殊行为叫“探索性操作”智能体为了完成任务会尝试各种极端路径。在真实系统里一个错误路径可能触发文件删除、权限变更、批量请求外部API等高风险动作。这些动作在训练阶段放任不管就等于把一个没上完保险的新司机丢到市区道路上。第三个是资源利用率波动太剧烈。智能体任务和传统训练任务不一样它的计算负载是脉冲式的——推理的时候吃GPU思考推理内部状态的时候又几乎不吃调用外部工具时CPU冲高等待响应时又完全闲置。固定分配资源的传统方式要么在闲置期浪费算力要么在峰值期拖慢任务怎么调都不对。这三个问题叠加起来指向同一个解法把每个智能体训练任务的运行环境拆成独立沙箱然后让资源池像水一样在不同任务之间流动。DSec就是冲着这个目标去的。1.2 沙箱定位不是“限制”而是“允许更多”团队里有人一开始对沙箱有误解觉得加了沙箱就是给智能体戴手铐脚镣限制它的探索能力。实际跑下来才理解沙箱真正的价值是给了你“敢放开”的底气。沙箱内部智能体可以执行任何高风险操作——删文件、改配置、装软件、疯狂循环所有动作都被限制在一个可丢弃、可恢复的虚拟边界内。训练策略可以设计得更激进探索的路径可以更长因为每次试错后要么直接复用环境要么一键重置。安全边界越清晰你能给智能体的自由度反而越大。DSec的沙箱设计遵循一个原则默认拒绝、显式放行。沙箱内不是“什么都不能做”而是默认什么都不能做训练任务通过声明式的权限配置文件显式声明自己需要哪些文件读取、哪些网络端点访问、哪个工具集挂载。这个设计一开始会让人觉得繁琐但到了多团队共享资源池的阶段它的价值就出来了——权限边界从口头约定变成了代码审查的对象。1.3 为什么弹性计算是智能体训练的刚需而不是加分项再单独说弹性。智能体训练有个很反直觉的特点任务不是一条直线跑到底而是分成了海量短小的会话片段每个片段结束就得判断是保留环境还是重置。这意味着资源需求会随着任务切换产生剧烈的潮汐效应。我们内部跑过统计单批智能体训练中GPU峰值占用率只占整个训练周期的35%左右其余时间GPU要么在等工具响应要么在做轻量级的上下文推理。如果是固定分配资源等于这65%的时间都在空烧钱。DSec的弹性计算层会把这类不饱和任务聚在一起动态腾挪资源把闲置的算力补给真正需要的地方。从成本角度也算过一笔账在多团队并行训练的高峰期弹性调度帮我们省掉了大约40%的新增机器采购预算。这个数字直接决定了DSec从实验项目转正为基础设施。2. 弹性计算架构资源池、调度策略与伸缩判据2.1 DSec弹性池的整体设计DSec弹性计算层借鉴了云端Serverless容器实例的思路但在细节上针对训练场景做了很多调整。整个体系分为三层底层是统一的异构资源池中间是会话调度器上层是面向训练任务的沙箱运行接口。资源池屏蔽了物理硬件的差异。不管是GPU节点、纯CPU节点还是高内存节点统一抽象成可调度的资源切片。调度器根据任务画像决定把它放到哪类节点上而不是让任务自己去挑选机器。这样做的直接好处是物理机的故障对上层完全透明一台机器宕机后上面的沙箱任务可以快速迁移到其他节点重启训练任务不需要感知底层变化。沙箱运行接口暴露给训练框架的是统一的创建、重置、销毁三个动词。训练框架不关心沙箱跑在哪台机器上、底层是虚拟机还是容器——它只要求每次创建的沙箱环境是一致的、可用的。2.2 扩缩容判据不只是看CPU和内存做弹性计算最容易踩的坑就是只按CPU和内存使用率来扩缩容。智能体训练场景里这些指标会严重误导。一个沙箱可能在CPU跑满的同时实际是在等一个外部工具的HTTP响应此时扩再多的CPU也提不了速。我们为DSec设计了多维度伸缩判据重点看三个信号任务排队深度调度队列里等待创建的沙箱数量超过阈值立即扩容计算节点。沙箱闲置率一批沙箱长时间处于空闲等待状态说明资源被占着但没干活触发缩容回收。外部调用时延如果大量的沙箱在等外部接口响应说明瓶颈不在计算资源此时不应该扩容节点而应该增加外部服务的并发能力或调整超时策略。这三个信号组合使用能比较准确地判断资源到底是真缺还是假缺。刚开始上线时我们只用CPU使用率做判断结果GPU节点疯狂扩容外部接口被打爆后来加入后两个判据才稳定下来。2.3 调度策略从“平均分配”到“碎片整理”弹性调度器最核心的逻辑其实是碎片整理。智能体训练任务天然是长短不一、负载不均的如果按传统公平调度策略平均分配资源很容易出现一部分节点塞满了短任务一部分节点闲置。DSec的调度器实现了一种类似内存碎片整理的策略短任务会优先打包到同一批节点上长任务单独调度到另一批节点上。调度器会周期性审视正在运行的沙箱状态如果一个节点上的短任务陆续结束就把剩余任务迁移到其他节点把整节点释放回资源池。这套策略让整体资源利用率提升了将近20个百分点。另一个值得一提的机制是分级抢占。训练任务有高优先级和低优先级之分高优先级任务到达时可以抢占低优先级任务的资源。但抢占并不是直接杀掉低优先级任务而是先触发低优先级沙箱的检查点保存保存完成后才回收资源。这样低优先级任务不会白跑高优先级任务也不会等太久。3. 沙箱隔离的落地选择运行时、文件系统、网络与审计3.1 为什么不用裸Docker当沙箱初期我们尝试过直接用Docker容器做沙箱跑了一周就放弃了。原因在于Docker的隔离边界对恶意或失控行为来说是远远不够的。容器共享宿主机内核一旦训练过程中的某个操作借助漏洞或错误配置突破容器边界后果就是在宿主机上执行危险命令。DSec最终选择了容器运行时轻量级虚拟化结合的双层方案。优先采用gVisor这种用户态内核方案它的核心思路是把系统调用拦截到用户空间再处理对沙箱内的进程来说它是内核对外部宿主内核来说它只是个普通进程破解难度高很多。同时保留了一部分Kata Containers节点用于处理那些确实需要真实内核特性的训练场景。代价是虚机方案性能会打折扣但对训练任务来说沙箱内的环境一致性带来的收益远大于那点性能损耗。3.2 文件系统只读挂载与可写层分离智能体在沙箱里最常见的危险行为就是把环境搞乱。依赖冲突、配置文件改坏、临时文件占满磁盘。DSec的文件系统方案采用分层设计。基础镜像层始终只读挂载沙箱内看到的是干净的、和镜像一致的文件系统。智能体产生的所有写操作都被引导到独立的上层可写层这个可写层在沙箱重置时直接丢弃不影响基础环境。这样做的额外好处是镜像的加载非常快因为基础层被多个沙箱共享只有可写层是各自独立的。这个设计还带来一个隐藏收益镜像仓库的存储压力和网络带宽压力大幅下降。因为基础镜像可以被成百上千的沙箱共享而不是每个沙箱拷贝一份完整环境。我们清理过一批重复的历史镜像之后镜像仓库总容量缩减了约65%。3.3 网络出站规则与外部工具授权智能体训练中涉及外部API调用是常态——搜索、代码执行、数据库查询等。沙箱不可能完全断网但也不可能放行所有目标地址。DSec的网络策略在实践里经历了三次迭代第一版用传统的IP白名单结果训练任务需要访问的公共服务经常换IP维护成本极高。第二版改成域名白名单加端口限制稳定了很多。第三版加入了七层出站代理所有沙箱的外部流量都经过统一代理节点代理层负责域名解析、TLS终止、请求拦截。训练任务在权限声明里写明允许访问的外部服务域名代理层按域名放行其他的一律拒绝。要特别提一下外部工具的授权边界。智能体调用外部工具比如订阅消息推送、查询某个数据库接口时DSec不会直接转发智能体的请求而是由沙箱内的工具网关接收请求校验操作是否在任务声明的允许范围内再向外部服务发起调用。这个网关层天然形成了一层拦截智能体对工具的每次“误操作”都停在沙箱内部不会影响到真实的外部系统。试过在Windows环境下做工具沙箱化的同学可能遇到过类似SetNamedSecurityInfoW failed这类权限异常。这类问题通常来自沙箱进程目录的ACL权限继承异常解决思路是挂载目录时显式指定安全描述符而不是依赖目录的默认继承。我们在DSec的文件系统初始化阶段增加了权限描述符的显式配置这类问题彻底消失。3.4 审计日志与训练数据回流沙箱基础设施不能只管运行还要管“留下来什么”。每次智能体在沙箱内的操作记录、工具调用参数、执行结果、报错信息都以结构化日志的形式统一收集。这些日志既是训练数据的一部分也是事故追溯的依据。DSec的审计日志分三个等级全量操作日志记录沙箱内每个进程的启动参数和退出码、工具调用日志记录每次外部API调用的请求和响应摘要、决策日志记录智能体在关键节点做了哪些选择。全量日志保留7天工具调用和决策日志保留整个训练周期。这套日志体系在调试智能体行为时帮了大忙。有次智能体在训练中反复请求一个接口从日志看逻辑上完全合理但请求频率明显过高最终定位到是工具网关缺少单任务维度的调用限流。这个案例说明没有日志兜底的沙箱等于闭着眼睛训练。4. 大规模并发训练下的工程化细节任务画像、断点与离线部署4.1 任务画像驱动的资源预置当沙箱数量从十几个涨到上千个调度策略必须从“任务来了分配资源”变成“任务还没来提前备资源”。DSec引入了一个任务画像机制在训练任务启动前先做一次轻量级的资源预估。画像数据来自历史训练任务的运行时统计包括平均会话时长、GPU占用曲线、外部调用频次、可写层增量大小。调度器根据这些数据预测新任务需要的资源量级决定应该把沙箱预置到哪一类节点上。这比实时调度少了几十秒的冷启动延迟对短会话密集型的智能体训练来说延迟降低直接影响到训练吞吐。预置资源也不能做过头了。我们设计了预置资源的“过冲保护”机制预置的沙箱如果在一段时间内没有被使用会被调度器回收避免多任务争抢时出现资源空转。4.2 检查点机制与中断恢复智能体训练任务的时长跨度特别大有的几分钟结束有的连续跑几天。训练中途节点宕机、网络波动、外部服务不可用这些问题不可避免。DSec需要保证的是任务不会因为环境故障而从头再来。DSec的沙箱检查点包含三层状态可写层的增量快照、进程的内存状态通过CRIU实现、沙箱内的工具连接会话状态。检查点默认每5分钟自动生成一次也可以由训练框架手动触发。恢复时调度器会重新创建沙箱挂载最近一次的快照恢复进程状态整个过程对上层训练框架近乎无感。这里有个细节值得说沙箱恢复后的IP地址和网络会话会变化如果任务里依赖了固定IP会被打断。我们统一用域名内部DNS映射来解决沙箱的退出和重建对外只表现为同一域名的解析结果变化智能体感知不到底层环境的迁移。4.3 内网离线环境的适配不少团队有把整套智能体训练环境部署到完全隔离的内网环境的需求。DSec的离线部署不是简单把镜像拷进去而是把整个依赖链做了打包a) 基础镜像分层归档b) 内部PiP/Npm等软件源镜像同步c) 模型权重和推理引擎的离线加载路径d) 沙箱运行时的全套二进制。这套离线包装方案我们在无外网环境下完整跑通过。核心原则是所有外部依赖在使用前就灌入内网仓库沙箱运行期不做任何实时外部拉取。后来我们把这个能力做进了DSec的发布包里离线环境部署从原来的几天压缩到半天。4.4 插件与技能包的版本管理训练智能体时经常要挂载各种“技能插件”——让智能体具备某个特定工具或流程的使用能力。DSec把这类插件做成了可声明、可版本化的沙箱附件。技能插件不是丢进沙箱就完事。每个插件包必须包含元信息版本号、依赖的基础镜像版本、允许访问的API端点列表、权限声明。沙箱启动时会校验插件的版本和宿主沙箱的兼容性避免旧插件挂载到新环境导致诡异行为。我们吃过一个教训有个提示词优化类的插件升级后训练效果骤降排查很久才发现是插件内部依赖了一个被沙箱网络策略禁用的外部服务。所以这里特别建议插件升级时除了跑功能测试还要在完整沙箱环境里做一次端到端验证单独测试插件的单元通过并不代表在沙箱里能正常工作。5. 从零搭建DSec的路线图以及我们趟过的坑5.1 最小可用版本的实施步骤如果你也想自建一套类似DSec的体系我建议按下面这个顺序推进不要一上来就铺太大摊子。第一步先跑通单沙箱的安全边界。在测试机上部署容器运行时写一个最小的沙箱包装器支持创建环境、执行命令、获取输出、销毁环境。这个阶段的目标不是性能而是把“隔离”跑扎实。第二步把沙箱接进训练框架。改造数据采集逻辑让训练任务每个回合都可以按需创建新沙箱或复用已有沙箱。此时不需要考虑弹性伸缩一台机器能跑通流程即可。第三步接入调度和资源池。引入标准容器编排框架把沙箱包装器做成可调度的服务加入任务排队、并发限额、资源配额。第四步完善可观测性。把审计日志、监控指标、沙箱状态上报统一接入团队的监控体系。第五步再做弹性伸缩和自动扩缩容。前四步没有稳定之前不要碰这一步否则扩缩容只会放大噪音让你分不清性能问题是调度导致的还是沙箱本身有bug。5.2 实际踩坑记录调度误判、网络策略与权限问题挑三个让我们印象深刻的坑写一下给后来者省点时间。第一个坑是调度器的并发评估完全不靠谱。刚做弹性伸缩时我们按并发沙箱数量评估节点负载结果节点CPU被打满但并发数还没到阈值。后来改成综合并发数和CPU水位双阈值触发扩容才解决了这个问题。这类问题的共性特点是单看一个指标一定会漏掉另一种资源瓶颈。第二个坑是网络策略配置太细导致服务不可用。有次训练任务突然大面积失败排查发现是某个公共服务迁移了域名新域名没加进白名单。从此我们学乖了网络策略除了精确匹配单独加了一组可配置的“宽松规则”给非核心服务留出口子避免个别域名变动拖垮全部训练任务。第三个坑是沙箱内文件权限的诡异错误。前面提过的权限异常问题在Windows宿主机上特别容易触发主要表现为沙箱进程无法读取挂载目录。我们通过显式配置安全描述符解决。如果你也在Windows环境做类似实验记住一点不要依赖目录继承权限把权限声明放到挂载逻辑里显式处理。5.3 验收标准与持续演化一个沙箱基础设施做到什么程度算合格我个人的验收标准有三条一是训练任务可以任意执行危险操作但不会影响到宿主机和外部系统二是任意节点宕机不影响训练任务的连续性和数据完整性三是资源池利用率能稳定维持在合理水位。三条都过了这套基础设施才算真正站稳。DSec这套体系到现在还在持续演化。最近的重点是把沙箱内的运行数据自动整理成训练语料让智能体每次探索的结果都能沉淀为可复用的训练素材。这个方向已经超出了“基础设施”的范畴更像是在构建一个训练数据飞轮。建沙箱这件事技术上不复杂难的是把边界划清楚。哪些操作放行、哪些拦截、哪些记录这些策略比底层实现更考验功力。我始终觉得好的沙箱基础设施应该让人感觉不到它的存在——它只在危险动作发生时出现平时安静地给智能体提供探索空间。如果你也在思考这个方向可以先把最小闭环跑起来边界和弹性都是一点点磨出来的。