最近看到 DeepSeek 公开分享的一个数据让我这个常年搞 Agent 基建的人愣了好一会儿训练阶段系统一天要创建 300 万个沙箱。这个数字不是展示肌肉而是把 Agent 训练的一个隐性前提摆到了台面上——每个 Agent 的每一步试错背后都要有一个隔离、干净、可随时丢弃的执行环境。说白了沙箱才是 Agent 训练真正意义上的“练功房”而且这个练功房不是搭一个就完事是一秒几十个地往外吐。这篇就聊聊Agent 训练为什么对沙箱需求这么凶300 万这个量级的背后需要什么样的架构设计以及我在实际项目中踩过哪些坑、怎么排查优化。适合正在做 Agent 训练基础设施、搞强化学习环境、或者准备搭建代码沙箱服务的朋友参考内容偏工程实操理论点到即止。1. Agent 训练为什么需要“一天 300 万个沙箱”1.1 智能体训练到底在练什么很多人对“训练 Agent”有个误解以为它跟训练普通大模型一样喂一批静态文本就行。但 Agent 的核心能力是与环境交互模型要输出工具调用、要写代码、要执行命令、要看执行结果然后根据结果决定下一步动作。这个“行动—观察—再行动”的循环没法靠静态语料模拟出来。拿“让模型学会用 Python 写脚本处理数据”来说正确的训练数据不是一个写好的答案而是一整个执行轨迹模型生成代码沙箱执行代码返回 stdout、stderr、退出码模型看到反馈后修正代码再执行……这些轨迹只有在真实可运行的环境里才产得出来。所以 Agent 训练的实际形态是一边跑模型推理一边在沙箱里执行动作再把执行反馈拼进训练样本。训练规模一大沙箱就变成了吞吐瓶颈。我自己的经验是一个 2000 卡规模的训练集群跑 Agent 任务沙箱创建 QPS 稍微跟不上整个 rollout 流程就会像堵车一样往后瘫。1.2 300 万这个数字是怎么算出来的300 万听起来夸张但你拆开算就合理了。一天有 86400 秒300 万除以 86400约等于每秒要新建 35 个沙箱高峰时段这个数字只高不低。注意这里的“创建”是累计次数不是同时在线数量。Agent 训练中的一个原则是“用完即弃”每次执行动作都希望环境是全新的避免上一个任务留下的状态污染下个样本。而且不只是 rollout 阶段需要沙箱。Agent 训练里常见的做法是先用模型生成大量候选轨迹再用执行结果做筛选拒绝采样一个模型推理进程对应好几个候选动作每个动作都要丢进沙箱跑一遍。假设一个样本要经过 3 次工具调用 2 次代码修正那一个最终样本背后就有 5 次沙箱创建。这么一算百万级日创建量其实是个很克制的数量级。这类基础设施问题有个特点它不是某一台机器的问题而是整体调度和资源供给的问题。下面这几章我把架构设计和实践要点拆开讲。2. 大规模沙箱的架构设计与调度思路2.1 沙箱单元选型不是越重越安全既要隔离性好又要创建快这两个目标天然冲突。我用下来容器方案还是最平衡的选择重量级方案反而容易把训练管线拖垮。常见的沙箱单元有几种方案隔离强度启动耗时适用场景普通 Docker 容器弱内核共享百毫秒级常规代码执行、工具调用gVisor 容器中用户态内核拦截秒级需要更强隔离但仍要容器的场景微型虚拟机Firecracker强独立内核数百毫秒级高安全要求成本较高重型虚拟机最强秒到分钟级不适用于高频率创建我给 Agent 训练做沙箱时的选型结论是默认用 Docker 容器 CGroup Namespace高危任务再套 gVisor。原因是训练场景的隔离重点不是防住国家级攻击而是防止 Agent 把宿主搞乱、防止任务之间串数据。容器里加只读根文件系统、限制网络、限制 PID 数量已经能挡住绝大多数事故。想进一步提速可以跳过标准 Docker 守护进程直接用 runc 或 containerd 的底层接口创建容器省掉一层 API 开销。我实测下来同样的镜像通过 containerd 去创建比docker run快 30% 以上因为少了守护进程的调度和日志钩子。2.2 生命周期管理创建、复用、销毁沙箱数量一大生命周期管理就是主战场。核心思路是“池化预热 按需创建 空闲回收”三个环节缺一不可。池化预热是指维护一个常驻沙箱池训练任务来的时候直接拿池子里的容器用而不是现场创建。池子大小需要按峰值并发估算假设高峰期同时有 100 个 trajectory 在执行每个执行要阻塞等待沙箱就绪那池子至少要 100 个再留 20% 缓冲就是 120 个。池子太小会排队太大则浪费内存我们通常按峰值并发的 1.2 倍设置并用水位线自动扩容。按需创建解决的是“池子不够”的突发情况这里必须做创建限流。不然调度器一抖几千个创建请求同时打到镜像仓库仓库直接被打挂。我们用的办法是两层限流全局令牌桶限制每秒创建总量任务维度的信号量限制单个训练任务最多同时占用的沙箱数。空闲回收是老生常谈但容易忽略。训练任务从执行队列里拉走沙箱后如果忘记归还泄漏的容器会越积越多。我建议在沙箱上打两个时间戳拿到时间、最后活跃时间。连续空闲超过 5 分钟的容器直接销毁活跃但超过任务最大时长的也强制回收。这两条规则能挡住绝大多数资源泄漏事故。2.3 镜像与依赖分发隐藏的吞吐瓶颈日创建 300 万个沙箱真正最先挂掉的往往不是计算资源而是镜像仓库。每个容器启动前都要拉镜像如果不做优化仓库带宽和存储 I/O 会变成最硬的瓶颈。我在生产环境里用这三板斧解决分发问题第一镜像尽量做到分层复用。同一个训练框架的大版本镜像只需要构建一次业务代码再打一个小层。这样拉镜像时大部分层都命中缓存真正传输的只有增量层。实际操作时业务依赖一变动就重新 Build 整个镜像是拉取流量暴涨的首要原因。第二用 P2P 分发工具比如 Dragonfly给镜像做分发加速。集群里有几百台机器同时拉同一个层P2P 工具会让机器间互相共享数据仓库压力瞬间小了一个数量级。我们接入 P2P 之后镜像拉取失败率从千分之五降到了万分之一以下。第三把常用的依赖目录做成宿主机只读缓存再挂载进沙箱。比如 Python 的 site-packages、Node 的 node_modules如果依赖没变根本不需要重复下载直接 bind mount 进去启动时间能压到 200 毫秒左右。3. Agent 训练流程如何与沙箱联动3.1 从模型输出到执行反馈的一条链路一个 Agent 训练样本的生产链路大概是这样的模型根据 prompt 生成一段动作文本可能是一段 Python 代码也可能是一个工具调用参数。这段文本被解析成执行任务交给沙箱调度器。调度器分配一个容器把代码注入进去执行收集 stdout、stderr、退出码、超时标志然后再把这些信息拼成一个 feedback 消息返回给模型。模型读完反馈决定是修正重试还是继续下一步。这条链路里沙箱不是孤立的执行环境而是训练回环中的“裁判”。它会决定这个动作是成功还是失败也会通过超时、资源限制等手段给模型传递隐含信号。比如一个死循环代码如果沙箱不设 CPU 限制会一直跑到把节点吃满设了超时后模型就能通过 TimeoutError 学到“这步操作不行”。所以沙箱的资源限制参数本质上也是在给模型构造训练信号这比单纯跑代码的意义大得多。这个回环对沙箱调度提出了一个硬性要求反馈必须快。模型在等沙箱结果的时候GPU 上是空转的。沙箱启动每慢 100 毫秒整个训练吞吐就跟着掉一截。这也是为什么前面反复强调冷启动优化的原因。3.2 harness、Agent 框架与沙箱的分工这里要区分两个容易混淆的概念harness 和 Agent 框架。我理解的 harness 是“把模型、沙箱、工具调用串起来的那层执行脚手架”它负责定义一次 rollout 长什么样任务怎么拆解、模型输出怎么解析、沙箱结果怎么回填、失败怎么重试。它不关心模型权重怎么更新也不关心业务逻辑怎么设计。Agent 框架则更偏策略层负责决定 Agent 该调哪个工具、该怎么规划步骤。简单说Agent 是“大脑”harness 是“骨架和反射弧”。沙箱在最底层提供“手脚”和“感官”。这个分层在工程上很重要。我见过不少团队把 Agent 逻辑和沙箱调度写成一坨结果想替换执行环境或者换模型时改动面巨大。正确的做法是定义好三层接口Agent 层只发动作harness 层只做编排和重试沙箱层只做执行。接口用 JSON 或 protobuf 定义每层都能独立压测。3.3 用沙箱反馈扩充训练数据拒绝采样与自对弈当前 Agent 训练里沙箱不仅是执行工具更是数据工厂。模型生成大量候选动作沙箱执行后产生成功与失败的反馈这些反馈经过筛选变成训练样本。这个过程实际上就是把模型自身的探索行为转成监督数据。拒绝采样是最直接的形式让模型生成 10 条候选路径沙箱跑完只保留最终成功或部分成功的那几条作为正样本失败的路径要么丢弃要么转成负样本。这个过程对沙箱的依赖极大因为每条候选路径都要真实执行一遍数据有效率低就需要更多试错来凑样本。自对弈更像把 Agent 放在一个沙箱回环里自己跟自己练。两个实例互相出题、互相判分沙箱提供执行环境和结果验证。DeepSeek 公开的智能体训练新方法里强调的也是“让模型通过执行得到 reward 信号”这条路。我自己复现过类似思路心得的难点不在模型而在沙箱的反馈质量如果沙箱返回的错误信息不够结构化模型很难从失败中学会正确操作。所以我们的沙箱会对常见异常做分类比如语法错误、运行时错误、资源超限、环境缺失每类都有固定而清晰的返回格式训练效果明显好过一坨原始 stderr。3.4 微调策略LoRA 与全参数训练的沙箱需求差异聊到 Agent 训练避不开 LoRA 和全参数微调的取舍。不只是训练成本的问题两者的沙箱需求也完全不同。LoRA 微调因为只训练少量低秩参数迭代速度快适合频繁试不同的 prompt 策略、工具调用格式或奖励函数。每次改动只需重新生成一批轨迹样本沙箱量的增量相对可控。我们做 LoRA 时常用 rank 64、学习率 1e-4 这类参数一个任务几小时就能出结果沙箱峰值并发大概在几十到几百之间普通容器池就能扛住。全参数训练或强化学习则完全不同。它要跑大量 rollout又要同时更新所有参数沙箱的数量级直接跳到上千甚至上万。此时沙箱调度的稳定性会比模型训练本身还难搞。我建议做全参数 Agent 训练前先做一次沙箱容量压测目标峰值并发 1000 个容器持续跑 30 分钟看镜像拉取耗时、容器创建耗时、节点资源水位三个指标。如果创建耗时抖动超过 3 倍说明调度层还要细化。4. 关键优化手段与参数经验4.1 冷启动优化预启动池与镜像缓存沙箱创建时间基本等于“调度时间 容器运行时创建时间 镜像准备时间 应用初始化时间”。想快就得把这四段时间分别压。调度时间要优化的是任务排队逻辑。别用一把全局锁做沙箱分配改成每个节点一个本地队列调度器只负责把任务分发到节点。容器运行时创建时间可以通过预创建容器来规避也就是沙箱池。应用初始化时间则靠预置镜像里的 init 流程把不需要每次执行的安装步骤全部挪到构建阶段。镜像准备是最容易忽略的。Docker 的存储驱动是 overlayfs容器启动时如果镜像层里的文件很多会触发大量元数据操作。我们的经验是把镜像里的文件数从 10 万级压到 1 万级启动时间能快一倍。方法很土但有效——基础镜像选用精简版别随手拿一个带全套开发工具的大镜像Python 依赖能编译成 wheel 就编译成 wheel减少运行时的动态链接开销。4.2 并发与资源配额先算账再扩容做沙箱调度先算清楚每类任务要多少资源别凭感觉给配额。我给一个典型配置供参考代码解释类沙箱 CPU 1 核、内存 512MB、磁盘 2GB、PIDs 限制 128超时 30 秒复杂工具调用类 CPU 2 核、内存 1GB、超时 120 秒。并发量的估算公式我习惯这么写并发沙箱数 单任务平均沙箱占用时间秒 × 每秒任务发起数。比如每秒要跑 200 个执行请求每个平均执行 3 秒那同时占用的沙箱就是 600 个。再加 20% 缓冲池子设 720 个。如果池子里每个沙箱平均占 512MB 内存单机 64GB 扣掉系统开销后大概能跑 110 个那就需要 7 台机器同时在线。这里要特别提醒资源配额别只看内存还要看 inode 和临时文件。Agent 执行代码经常会写临时文件如果沙箱磁盘限制太小任务可能莫名其妙失败。我们踩过最典型的坑磁盘配额 500MB跑一个数据处理任务在写中间结果时直接爆盘日志里只显示No space left on device很难联想到是配额问题。4.3 隔离加固防止 Agent 把沙箱玩坏Agent 代码在沙箱里是“不可信”的它可能尝试访问宿主机文件、开端口、下载外网资源、甚至把自己装成一个挖矿程序。加固隔离不能省略但也不能重到影响性能。我会按这个顺序做加固只读根文件系统。除了/tmp和指定的工作目录其余全部只读。这能让 Agent 代码写不进系统目录也杜绝了容器内提权改配置的可能。seccomp 限制系统调用。默认 Docker 的 seccomp profile 已经能挡掉大部分危险调用但训练场景建议再单独禁用mount、ptrace、reboot三个调用。网络白名单。默认不让沙箱访问外网只允许访问任务指定的 API 和内部服务。这一步能同时达到安全和节省带宽两个目的。CPU 和内存限制。这是防死循环和内存泄漏的最后防线。这里有个反直觉的经验太严格的隔离反而会拖慢任务。比如 gVisor 对文件 I/O 的拦截开销明显如果只是普通代码执行用 Docker seccomp 就够了。我们只在需要对抗恶意样例或跑不可信第三方代码时才上 gVisor。5. 常见问题与排查技巧实录5.1 问题速查表下面这串问题是我在 Agent 训练沙箱运维中真实遇到过的按频率排序整理成一张表现象根因解法沙箱创建超时镜像拉取占满带宽开 P2P 分发分层缓存常用镜像创建成功但任务还是慢容器池水位不够任务排队提高池子上限按峰值并发 1.2 倍配置执行结果不一致沙箱有残留状态执行前清理工作目录或强制每次新建节点磁盘满僵尸容器和日志堆积定时清理退出容器限制日志文件大小GPU 利用率上不去rollout 等沙箱反馈GPU 空转预取下一批任务流水线并行偶发网络不通沙箱网络白名单误拦检查 CIDR 配置区分内外部访问路径这里说一个通用排查顺序先看调度队列有没有堆积再看容器创建耗时最后看镜像仓库和网络。多数沙箱问题都出在这三个环节很少是容器运行时本身的问题。5.2 两个印象深刻的排查案例第一个案例是“沙箱创建量一高整个集群都不稳了”。现象是并发超过 500 个容器后节点负载没怎么涨但任务整体延迟翻了三四倍。我们逐层排查最后发现是 Docker 守护进程的事件监听和日志驱动在大量创建时成了瓶颈。解决办法是切到 containerd 的底层接口并且把日志驱动从 json-file 改成无日志或按量限流。这个改动之后同样并发下的创建 P95 从 1.2 秒降到 0.4 秒。第二个案例是执行结果偶现“脏数据”。现象是同一个代码片段在不同沙箱里跑输出时对时不对。追查后是沙箱复用时/tmp目录没清干净上一次任务留下的临时文件影响了这次执行。修复方式很简单沙箱归还前执行一次git clean风格的清理脚本或者直接放弃复用用完即毁。这个教训让我彻底认识到Agent 训练数据对干净环境的敏感度远超普通 CI 任务。5.3 想从小规模开始先抄这几条作业如果你们团队还没到这个规模也不必一上来就上大基建。我建议从最小闭环开始先把这些基础能力做了用 Docker 加内存和 CPU 限制搭一个 20 个容器的小池验证 Agent rollout 流程。把沙箱创建接口封装成 Web 服务加上每秒创建量令牌桶先学做限流。给每个沙箱打标签记录创建时间、执行次数、最后活跃时间这是做资源回收的前提。镜像分层控制在两层以内常用环境构建一次业务代码挂载进容器。这套小规模闭环跑通之后再逐步加 P2P 分发、池化预热和动态扩容。方向对了量级上来只是时间问题。我个人实际操作中的体会是Agent 训练里的沙箱调度表面是个基础设施问题本质是延迟、成本和隔离三者之间的三角博弈。想抓住主要矛盾就得先把“快”做到极致再用不同的隔离级别去满足不同任务的成本要求。就像 DeepSeek 那个 300 万沙箱的数字重点不在于它有多惊人而在于它意味着 Agent 训练已经从“能不能跑通”进入到了“能不能大规模高效跑”的阶段。希望这篇梳理能帮你少走点弯路。