04 - 训练框架怎么接环境

前置：03 - 环境接口标准。本篇讨论的是接口确定之后，工程上谁来管环境的生命周期。

本篇回答：训练框架、沙箱平台、集群编排三者之间，环境这件事该由谁负责？不同框架的选择差在哪，代价各是什么？

本篇会用到的词：

词	意思
rollout 阶段	一轮训练里「让模型去环境里试」的那一段。这段时间 GPU 主要在做推理，训练器空着
更新阶段	拿采到的轨迹算梯度、更新参数的那一段。这段时间环境空着
colocate（同置）	训练和推理共用同一批 GPU，交替使用。省卡，但两个阶段没法重叠
disaggregate（分离）	训练和推理各占一批 GPU。可以流水线重叠，代价是卡更多
Ray	分布式执行框架，常被 RL 框架用来管理异构角色（训练器、推理引擎、环境）之间的资源分配
长程（long-horizon）	一条轨迹要走很多步、持续很久的任务。编码 Agent 是典型，一条可能几十步、几分钟
GPU 利用率	这里特指 GPU 真在算的时间占比。环境慢会直接体现为这个数字掉下去

一、为什么这是个基础设施问题而不是接口问题

03 篇讲的是「用什么协议对话」。就算协议定死了，还有一个没解决的问题：这几万个环境，是谁去创建、谁去销毁、谁去回收失败的？

先看清楚代价从哪来。一轮 RL 训练的时间轴大致长这样：

真实系统会用异步与流水线把这两条时间轴部分重叠，但重叠的前提是环境侧能稳定按需供给。环境起停不可预测时，调度器无从流水线化。

选哪一种，本质上是在回答「环境到底是不是一台机器」。是的话只有 ② 和 ③ 可选，而 ② 与 ③ 之间的分界是你能不能接受秒级起停。

以下数据均为本文实测当天通过 gh api 获取：

框架	★	协议	建仓	环境接入方式
`verl-project/verl`	23,040	Apache-2.0	2024-10-31	多轮工具调用与 agent loop 内建；另有独立的 uni-agent 项目做统一 agent 框架
`microsoft/agent-lightning`	17,525	MIT	2025-06-18	不定义环境接口，在模型 API 层代理；Rollout Controller 以 K8s Job 拉起 agent
`OpenPipe/ART`	10,603	Apache-2.0	2025-03-10	面向「给已有 agent 做在岗训练」，走 GRPO
`alibaba/ROLL`	3,365	Apache-2.0	2025-05-28	用 Ray 做多角色分布式，异构任务调度；集成 Megatron-Core、SGLang、vLLM
`NovaSky-AI/SkyRL`	2,176	Apache-2.0	2025-04-22	分三层：skyrl-train 训练、skyrl-gym 环境库（Gymnasium 接口）、skyrl-agent 长程 agent 层
`PrimeIntellect-ai/prime-rl`	1,952	Apache-2.0	2025-02-18	与 verifiers 深度绑定，环境即 taskset，来自 Environments Hub

它把三件事拆成了三个包，这个切分本身就是对本篇问题的一个明确回答：

包	管什么
`skyrl-train`	训练框架，只管梯度和参数
`skyrl-gym`	工具使用类任务的环境库，用 Gymnasium 接口实现数学、代码、检索、SQL 等环境
`skyrl-agent`	长程、真实环境任务的 agent 层，专门处理多轮工具使用

为什么要有第三层：skyrl-gym 那种 Gymnasium 接口对「一步就是一次工具调用」的任务够用，但编码 Agent 那类任务一条轨迹几十步、跑几分钟，需要单独的调度与容错逻辑 —— 这正是 03 篇里 step 抽象撑不住的地方，SkyRL 的做法是再加一层而不是改接口。

这两个框架的重点都不在环境接口上，而在异构角色的资源编排。ROLL 的说法最直白：用 Ray 做多角色分布式架构，实现灵活的资源分配和异构任务调度。

原因回到第一节那张时序图 —— 训练器、推理引擎、环境三者对硬件的需求完全不同（GPU 训练、GPU 推理、CPU 与 IO），而且忙闲交替。把它们塞进同一套静态资源划分里，必然有一方在空转。

接环境时最常见的翻车不在性能，在训练数据和真实运行不一致。

具体表现是：训练时用的是一个为了好接入而简化过的 harness，上线时用的是真实的那个。两者的提示词模板、工具描述、错误处理都有细微差别，于是训练出来的行为在生产上不复现。

03 篇里 verifiers 和 agent-lightning 都在回应这件事，只是方向不同：

判断一个方案有没有认真处理这个问题，看一个问题就够了：训练时跑的 harness，和你上线要用的那个，是不是同一份代码。

如果你现在要从零搭一套，建议按这个顺序，而不是一上来就选最强的：

① 先用最笨的方式跑通一条 rollout。 本地 Docker、串行执行、几十条样本。目标是确认任务能训得动、奖励函数没写反 —— 这一步失败率比想象中高得多。

② 把并发提到几百条，看瓶颈在哪。 大概率会撞在环境起停上。这时候再决定要不要引入 ② 或 ③ 那种方案。

③ 只有当环境成为确定的瓶颈时，才上专门的环境平台。 02 篇那套东西解决的是几万到几十万并发的问题，几百并发时它带来的运维成本大于收益。

④ 从第一天起就把 harness 对齐。 这一条和规模无关，越晚做代价越大 —— 训练数据是按旧 harness 采的，换了 harness 就得重采。

下一篇 → 05 - 任务环境与选型：环境跑起来之后，用什么任务去训？SWE-bench 系、OS 与浏览器系、工具使用系各自的定位与陷阱。