大模型训练中的沙箱：从 Agent 强化学习到 Kubernetes 环境工程¶

模型写出一段代码后，怎样知道它能不能运行？代码 Agent 修改仓库后，怎样知道问题是否解决？训练系统越来越多地让模型进入可执行环境，运行命令、观察结果，再根据反馈调整行为。沙箱为这些操作提供受控空间；任务环境和验证器则决定模型能做什么、怎样判定任务完成。

训练沙箱是环境基础设施，不是替代 GPU 训练器的模型训练算法。它尤其适用于代码生成验证、工具调用、软件工程 Agent 和浏览器操作训练。普通文本预训练通常不需要为每条样本启动沙箱；只有训练流程需要执行代码、工具或交互环境时才引入它。

本文是截至 2026-11-09 的公开资料综述；架构图与数值均为说明性示例，不包含本地训练、性能压测或安全认证结果。相关背景参见 Agent RL：veRL 与 Miles 和 Agent Sandbox 选型。

1. 从一道修复任务理解训练沙箱¶

假设任务是修复一个 Python 项目的计费函数。环境先准备仓库、依赖和测试；模型阅读代码、编辑文件、运行测试，并根据失败信息继续修复。最后由验证器判断行为是否满足任务要求。

flowchart LR
  T[任务与环境模板] --> P[沙箱控制面]
  P --> E[隔离执行环境]
  L[模型 / Agent Loop] -->|代码和工具调用| E
  E -->|输出与状态| L
  L -->|轨迹| V[独立验证器 / 奖励]
  E -->|最终结果| V
  V -->|奖励和轨迹| TR[训练器更新参数]
  TR -->|更新模型| L

这是概念流程，不限定同步执行或组件部署位置。一次完整交互叫做 rollout（采样轨迹）：它可以包括多轮模型输出、工具调用和环境反馈。训练器使用轨迹及奖励更新参数；也可以先只做数据生成或评估，不更新权重。代码执行既可能是多轮交互工具，也可能只用于最终答案的验证，具体依训练配置而定。verl 的 Sandbox Fusion 集成

环境不一定都由一个独立虚拟机构成；模拟器和受控 API 同样可以提供状态与反馈。反过来，一个能运行命令的容器也不自动具备任务、验证器和奖励。

2. 三种常见用法¶

2.1 验证生成的代码¶

模型输出函数后，验证器在隔离环境运行测试，收集退出码、标准输出、超时或异常，按规则评分。这类任务可以是单轮：沙箱负责执行和验证，不一定有持续多轮状态。verl 提供 Sandbox Fusion 对接示例，但具体接口、版本和部署方式应以目标版本文档为准。verl 示例

2.2 训练软件工程 Agent¶

给 Agent 一个仓库和 Issue，它可以多轮检索、修改和测试。环境要保存同一轨迹中的文件变化，最终由独立测试或其他规则评分。SWE-Gym 提供面向软件工程 Agent 的任务与环境；它与底层沙箱运行时处于不同层次。

验证器必须防作弊：如果待训练 Agent 能修改最终测试、读取参考答案或直接改评分结果，“测试通过”就可能是奖励作弊。应保护隐藏测试及评分凭据，并在需要时把最终验证放到 Agent 无法写入的独立执行边界；同时检查补丁质量、资源消耗和超时，不能只看一个成功标志。

2.3 浏览器和 Computer Use¶

环境可以提供浏览器、网页、鼠标键盘或桌面，让 Agent 操作模拟系统；验证器检查业务状态，例如是否正确完成模拟表单。要特别区分只读页面、可回滚的测试数据和真实外部系统，避免训练任务发送真实消息或产生真实交易。状态重置要包括账号、Cookie、缓存与服务端数据，光重启浏览器不足以保证干净。

3. 数据如何进入训练¶

在 Agent 强化学习（Agent RL）中，模型按当前策略生成动作，环境执行并返回观察；采样器记录工具输入输出及 token 等轨迹；奖励可能来自测试、规则、模型或它们的组合；训练器再根据所选算法计算优势和损失并更新权重。并非所有方法都使用相同算法，也不是每次工具调用都必须立刻产生奖励。verl Agent Loop 和奖励扩展

训练过程要同时保留：任务与环境版本、模型和采样配置、工具调用、最终产物、验证器版本、奖励及失败原因。训练和评估应划分数据集，隐藏测试不进入模型可访问目录，避免把测试泄漏当成泛化能力。评估时分别统计成功、答案错误、超时、环境故障和未执行；环境故障重试要保留原始尝试，不能只报告最终成功的样本。

3.1 大厂公开实践：哪些阶段真的用到了？¶

公开材料的细节差异很大：有的明确披露了沙箱实现，有的只说明“可执行环境”或“编译运行测试”。下面将证据分开，不把所有代码验证都推断成某一种沙箱实现，也不将后训练案例称为基础预训练案例。

Kimi K2：一套环境同时服务数据合成和强化学习¶

Moonshot AI 的 Kimi K2 技术报告在后训练部分描述：监督微调数据生成既使用可模拟状态的工具环境，也在代码和软件工程等需要真实反馈的场景引入执行沙箱，通过测试通过率等结果筛选轨迹。强化学习部分则从 Issue、Pull Request 和可执行测试构造软件工程环境；报告称其 Kubernetes 沙箱基础设施可支持超过 10,000 个实例并发。

这说明沙箱可以同时服务“生成或筛选训练数据”和“强化学习交互及验证”，但两者的训练信号不同。公开数字是团队报告的实例并发能力，不等同于每秒任务吞吐、GPU 利用率或其他集群可达到的容量。报告并未据此证明基础预训练每条样本都运行在沙箱里。

Qwen3-Coder-Next：从可执行任务到中期训练和后训练¶

Qwen3-Coder-Next 技术报告披露，团队以可运行仓库和测试为基础构造软件工程任务，通过受控注入缺陷等方式生成约 80 万条可验证任务实例。其内部 MegaFlow 将一次编码任务组织为 Agent rollout、验证和后处理三个阶段：rollout 通常在同一个 Pod 中并置 Agent 容器和执行环境容器，验证阶段使用专用容器。

在模型训练阶段，报告将从已有基础模型出发的代码与 Agent 能力训练称为中期训练，包含从可执行任务生成并筛选的多轮轨迹；之后还有监督微调和强化学习。它是执行环境帮助产生中期训练数据、并支持后训练的例子，并不意味着每个预训练 token 都触发沙箱。报告也观察到不同 Agent 框架间的迁移并不总是充分，说明环境和工具格式的多样性值得评估。80 万是论文所述任务实例数量，不是并发沙箱数。

OpenAI：将沙箱视为训练安全边界的一层¶

OpenAI 于 2026 年 10 月发布的前沿模型训练环境安全实践介绍，代码执行和 Computer Use 场景下，Linux 环境采用 MicroVM 中运行受限容器，并结合网络、云身份、监控等多层控制；需要加速器的任务使用支持 GPU 的容器与用户态沙箱等方案。文章还讨论了训练及评估环境中跨边界访问的风险，并称强化防护后恢复了前沿模型强化学习训练。

这个案例的重点是纵深防御：即使模型突破某一层，外围网络和身份边界仍需限制访问。它并未公开每项训练任务的完整资源配置，也不能证明所有预训练和后训练都使用相同沙箱。

DeepSeek 与 Open R1：不要把复现方案当内部架构¶

DeepSeek-R1 技术报告在强化学习奖励设计中，以编译器和预设测试用例说明如何为编程题提供正确性反馈；该说明没有明确给出执行隔离的具体产品或架构。另一个独立项目 Hugging Face Open R1 的开源复现明确支持调用沙箱提供商执行模型生成代码并计算奖励。

两者可以一起理解“可验证奖励如何落地”，但不能根据 Open R1 的选择反推 DeepSeek 的内部沙箱方案。

对平台建设的启发¶

1. 先确定阶段和信号：合成轨迹、中期训练、监督微调与在线 RL 的环境调用位置不同，不能只说“训练用了沙箱”。
2. 把环境、验证器与训练器分别建设：镜像、测试、权限和奖励都要可版本化；终验环境的写权限应与 Agent 执行环境分开。
3. 同时衡量安全和吞吐：实例并发数、任务完成率、P95 创建延迟与有效轨迹产出是不同指标；多层隔离和网络控制也需要真实验证。

4. 开源组件如何组合¶

这些组件可以组合，也存在能力重叠；它们的接口与兼容性随版本变化，不应假设能无适配直接互换。Agent Sandbox 支持选择不同底层运行时；其 Quickstart 也明确将 gVisor、Kata 作为可选的更强隔离配置，而非安装控制器就自动获得虚拟机边界。官方 Quickstart

5. Kubernetes 上的架构与选型¶

可以将训练器和模型推理放在 GPU 资源池，环境控制面与大量沙箱主要放在 CPU 节点池。沙箱执行 GPU 或 CUDA 任务时再单独申请 GPU；是否可用取决于底层运行时、设备透传与驱动兼容性，不能假设所有 MicroVM 或容器隔离方案都支持。

这些是隔离方式的典型特征，不构成强弱的绝对排名或安全保证。具体方案要测试逃逸风险、版本配置、补丁、设备访问及多租户边界。

预热池解决的是冷启动等待，不是免费容量。 预创建容器或虚拟机可以减少镜像拉取和环境初始化，但会占 CPU、内存和磁盘。复用前要重置文件、进程、凭据、网络连接和业务数据；若不能可靠证明清理完成，就销毁重建。Agent Sandbox 提供模板、Claim 和 WarmPool 等资源模型，不能把官方示例中的启动时间当作自己集群的性能结论。Agent Sandbox 文档

在高并发训练中，控制面也会成为瓶颈：频繁创建 Pod、挂载存储、分配 IP、拉镜像与更新状态，会给 API Server、调度器、etcd、镜像仓库和节点磁盘带来压力。要按节点和租户限制并发、平滑补池、设置超时和垃圾回收，并用配额与限流保护共享集群；不要只看 GPU 卡数就估算训练吞吐。

6. 运行指标与容量估算¶

先定义端到端指标：有效完成任务数、验证通过数、每条有效轨迹成本，以及排队、创建、执行、验证各阶段的延迟与失败率。再观察预热命中率、环境创建 P50/P95/P99、镜像拉取、CPU/内存/磁盘、沙箱泄漏、验证器等待和推理 GPU 空闲时间。延迟应按同类任务与环境版本分组，区分冷启动和预热命中。

一个粗略容量示例：若目标每分钟完成 120 个任务，平均每个任务占用沙箱 30 秒，在稳定到达、平均值可代表负载且没有其他瓶颈的理想条件下，平均在用沙箱约为 120 × 30 / 60 = 60 个。实际容量还要覆盖到达突发、尾延迟、失败重试、预热余量和节点故障；这不是压测结果。若一个任务多次调用工具，应按环境实际占用的总时长计算，不能直接把工具调用次数当作任务数。

训练排障应追踪整条链路：若 GPU 推理空闲且大量任务等环境，先看预热与调度；若环境就绪但任务等模型，检查推理吞吐与并发；若测试耗时长，检查验证器、磁盘和依赖。相关性需要用同时间窗口的指标验证，不能只凭单个 GPU 利用率归因。

7. 建设顺序¶

1. 先用少量非敏感代码任务跑通“创建环境 → 模型操作 → 独立验证 → 清理”，记录原始轨迹。
2. 设计隔离、密钥、出站网络、验证器权限和数据保留策略；开展负面测试，确认越权行为被阻断。
3. 再测冷启动、预热、并发、失败恢复和污染清理；逐步提高任务规模，并观察 Kubernetes 控制面与存储。
4. 训练接入后同时报告模型成功率与基础设施失败分母；将结果与固定版本的评估集比较，防止优化吞吐时牺牲有效样本质量。

本文讨论的是设计与选型，不能由组件功能推断生产就绪或训练收益。后续如果在测试集群验证，应单独记录版本、实际隔离、任务集、失败及资源占用；已有 OpenSandbox 实战 和 沙箱故障与网络策略实战 可作为运行时基础，但不能替代训练闭环测试。