9 月 22 日小米放出 MiMo-V2.6 的同时，还顺手 fork 了一个很多人没太在意的仓库：verl。几天之内这个 fork（XiaomiMiMo/verl）拿到 465 颗 star，而它的上游 verl-project/verl，正以 23,650 颗 star 坐在开源 RL 后训练框架的头把交椅上。这不是一次孤立的 fork：把 TRL、OpenRLHF、AReaL、NeMo-RL 摆上同一张桌子你会发现，Agentic RL（用可验证任务奖励训练 Agent）的后训练基建，已经从论文附录长成了五条明显分化的工程路线。小米官方口径（经 AI工具集转述）称 MiMo-V2.6 做了约 6 天 Live RL、约 75 万条轨迹，这套数字背后的基建选型问题，如今每个要训练自己 Agent 的团队都躲不开。
选型困惑也随之而来：五条路线全部 Apache-2.0、全部 Python、README 里全都写着"高性能""可扩展"，star 数却从 2,033 一路拉开到 23,650。只看 star 会得出"选 verl 就完了"的结论——但 star 差距里有一大半是先发时间差（TRL 建仓于 2020 年 3 月，NeMo-RL 建仓于 2025 年 3 月，相差整整五年）与社区定位差异，不完全是能力差距。
先划口径边界：本文的 star 数、fork 数、许可证、建仓与最近推送日期，全部来自 2026-09-27 的 GitHub API 快照；各框架 README 自报的性能数字本文一律不采信——各家评测 harness 不同，跑分不可横比。本文比的是定位、生态、工程形态与适用场景。另外交代与站内已有文章的分工：开源旗舰模型横评 比的是模型本身，本文比的是训练框架；LLM 微调 SOP 讲的是 SFT/LoRA 通用微调路线，与本文的 Agentic RL 框架选型互为补充。小米侧的模型发布细节见 MiMo-V2.6 发布报道，fork 仓的逐项拆解见 小米 verl fork 资源，两条都不在本文重复展开。
一、五方基本盘
先把规格摆上桌（快照 2026-09-27，许可证为 GitHub API license 字段口径）：
| 框架 | 仓库 | Stars | Forks | 建仓时间 | 许可证 | 官方定位 |
|---|---|---|---|---|---|---|
| verl | verl-project/verl | 23,650 | 未采集 | 未采集 | Apache-2.0 | HybridFlow：灵活高效的 RL 后训练框架 |
| TRL | huggingface/trl | 19,398 | 3,021 | 2020-03-27 | Apache-2.0 | 用强化学习训练 transformer 语言模型 |
| OpenRLHF | OpenRLHF/OpenRLHF | 10,045 | 1,026 | 2023-07-30 | Apache-2.0 | 基于 Ray 的易用、可扩展、高性能 Agentic RL 框架（PPO/DAPO/REINFORCE++） |
| AReaL | areal-project/AReaL | 5,796 | 612 | 2025-02-24 | Apache-2.0 | LLM Agent 应用的 RL 桥梁，主打简单与灵活 |
| NeMo-RL | NVIDIA-NeMo/RL | 2,033 | 574 | 2025-03-16 | Apache-2.0 | NVIDIA 高效模型强化学习可扩展工具包 |
三个第一眼结论：
- 头部两家的 star 差距不大，但资历差了五年。 TRL 是五方中建仓最早的（2020-03-27），比 OpenRLHF（2023-07-30）早三年多，比 AReaL 与 NeMo-RL 早了将近五年。verl 的上游建仓时间本次快照未采集，但 23,650 颗 star 说明它的社区存量与 TRL 同一量级；一个 2020 年起步的"生态老将"和一个后发冲到同一高度的"规模选手"，增长逻辑完全不同，这点在第三节展开。
- 许可证层面五方零差异。 全部 Apache-2.0（以各仓 LICENSE 原文为最终口径），意味着许可不再是选型变量，决策权重全部落到工程形态与生态咬合度上。唯一的例外是小米 fork 的搭档仓 mimoagent 用了 MIT，同样宽松。
- 五方都在活跃维护。 快照期内最近推送：TRL、AReaL、NeMo-RL 均为 2026-09-27，小米 fork 为 2026-09-26，OpenRLHF 为 2026-09-17。没有一家处于停摆状态，"选个还活着的"这道筛题五家全过。
二、定位与架构轴：谁在同步、谁在异步、谁背靠谁
五款框架的真正分野不在"能不能做 RL"，而在三根轴上：同步还是异步、单机还是多机优先、背靠谁的生态。以下逐个过，架构描述保持官方 README 级别的保守表述。
verl：最大社区盘，加上小米的生产级实战背书
verl 的官方定位是 HybridFlow——"灵活高效的 RL 后训练框架"，字节跳动系开源项目，现迁移至 verl-project 组织维护。它拿下这一赛道 star 头名的意义在于：当"用可执行测试、规则检查这类可验证奖励训练 Agent"从论文玩法变成工业需求时，社区用脚投票选出的默认答案就是它。
小米 fork 让这个判断多了一层实战背书。2026-09-21，小米创建 XiaomiMiMo/verl（快照 465 star、49 fork、Apache-2.0、最后推送 2026-09-26），README 自述为"MiMo 的 Agentic RL 训练代码"，基于 verl 0.9.0.dev 增加了五套 RL 环境复现代码：
| 领域 | 任务族 | 验证器 | 启动脚本 |
|---|---|---|---|
| Code | 软件工程 | 可执行测试 | scripts/code/train.sh |
| Cyber | 漏洞复现 | 规则检查 | scripts/arvo/arvo.sh |
| General | 知识工作 | Rubric 评审 | scripts/general/general.sh |
| Visual | 网页开发 | 视觉评分 | scripts/design/webdev.sh |
| Music | 符号音乐作曲 | 规则检查 | scripts/design/music.sh |
同日创建的还有两个搭档仓：uni-agent（14 star，Apache-2.0，长程 Agent 训练框架）和 mimoagent（30 star，MIT，"100 行解决 GitHub issue 的极简 Agent"），加上训练数据集 MiMo-V2.6-RL-oss 在 Hugging Face 开放下载，构成一套完整的训练基建全家桶。结合小米口径里"约 6 天 Live RL、约 75 万条轨迹、训练上下文 1M、单步更新推到 2.7-3.7B token、大 Batch 加全异步架构"的说法，这次 fork 更像生产级训练的真实基建，而非发布日的宣传动作。要留意的是：GitHub compare 显示该 fork 相对上游 ahead_by 为 0、behind_by 为 16，分叉细节无从核实，本文只写 README 可证事实，不做"领先上游多少"的断言；训练配方细节以小米技术报告为准，接入层面可参考 MiMo-V2.6 接入 SOP。
TRL：HF 官方出品，生态最广的默认起点
19,398 颗 star、3,021 个 fork，2020 年 3 月建仓，五方中资历最老。官方定位一句话："用强化学习训练 transformer 语言模型"——这是五方中覆盖面最宽的表述，它不预设你在做 Agent 训练，RLHF、偏好对齐这类"把模型调得更好用"的需求都在射程之内。加上 Hugging Face 官方出品、与 transformers 生态天然咬合，个人与中小团队做 LoRA 级 RLHF 试水时，最先撞到的名字几乎总是 TRL。代价也要说清楚：当目标从"对齐"升级到"大规模可验证奖励的 Agentic RL"时，它的抽象设计是否还贴合你的集群规模，需要按自己的任务实测判断——这一步本文不做无依据的断言，留给你的 PoC。
OpenRLHF：Ray 基座的多机中坚
10,045 颗 star，2023-07-30 建仓。官方描述把关键信息全压进了一句话："基于 Ray 的易用、可扩展、高性能 Agentic RL 框架（PPO & DAPO & REINFORCE++）"。拆开看：Ray 基座意味着分布式编排交给通用基础设施而非自研调度，这对已有 Ray 运维经验的团队是直接加分项；PPO、DAPO、REINFORCE++ 三个算法名直接写进仓库描述，等于把"我支持哪些主流 RL 算法"当成了招牌。对需要在多机上跑大规模 RL 后训练、又不想绑定某一家云厂商技术栈的团队，OpenRLHF 是五方里"中间路线"的代表：比 TRL 更聚焦大规模训练场景，比 verl 少一层 HybridFlow 的概念负担。
AReaL：蚂蚁系，异步 Agent RL 的旗手
5,796 颗 star，2025-02-24 建仓，官方口号"LLM Agent 应用的 RL 桥梁（The RL Bridge for LLM-based Agent Applications），Made Simple & Flexible"，蚂蚁系背景，素材给它的标签是"异步强调"。这个标签值得单独说透：当 Agent 轨迹越拉越长（小米口径的训练上下文是 1M）、环境交互越来越贵时，同步式的"生成一批、训练一批"会让算力大量空转在等待环境返回上；异步设计让生成与训练解耦并行，因此被普遍视为 Agent RL 框架的分水岭。小米在 MiMo-V2.6 训练中强调"全异步架构"，与 AReaL 的路线互相印证了同一个趋势。如果你的训练任务里"环境"是大头——长程任务、真实工具调用、多轮交互——AReaL 的定位正中这一点。
NeMo-RL：NVIDIA 工具包，企业栈的入场券
2,033 颗 star，2025-03-16 建仓，五方中最年轻、star 最少，但背靠 NVIDIA-NeMo 组织，官方描述为"高效模型强化学习的可扩展工具包"。它的价值逻辑与另外四家不同：选它往往不是因为社区排名，而是因为你的集群本来就架在 NVIDIA 全家桶上——同生态内训练、推理与运维工具链的咬合度，是外来框架难以替代的。star 少在这个语境下不代表弱，代表的是用户面窄而深。如果你的基础设施已经押注 NeMo 生态，把它拉进候选名单即可；如果不是，它对你的优先级自然靠后。
三、场景化选型结论
把上面的分析压成四条可以直接执行的答案：
- 个人或小团队，LoRA 级 RLHF 试水：选 TRL。 HF 官方出品、生态最广、与 transformers 工作流无缝衔接，试错成本五方中最低。先用 TRL 把"奖励从哪来、数据怎么流"这件事跑通，再判断要不要上更重的框架。
- 大规模可验证奖励 Agentic RL：verl 或 OpenRLHF 进 PoC。 两者都是为这个场景生长的：verl 有 HybridFlow 抽象、最大社区盘，现在还多了小米 fork 的实战背书与五套环境复现代码可参考；OpenRLHF 有 Ray 基座与 PPO/DAPO/REINFORCE++ 的算法招牌。两个都值得跑一遍，用你自己的任务与集群实测吞吐后再定。
- 长程异步 Agent 训练：AReaL。 异步是它的立身之本，轨迹越长、环境交互越贵，异步的收益越大。小米公开口径采用全异步架构，也在为这个方向站台。
- NVIDIA 全家桶企业栈：NeMo-RL。 基础设施已经在 NeMo 生态里，训练框架留在同一家生态里，运维与版本兼容成本最低。
两个交叉提醒：
- TRL 与 verl/OpenRLHF 不是对立选项。 实际团队里常见的是两段式路径：用 TRL 做日常对齐迭代，把可验证奖励的大规模 Agentic RL 交给 verl 或 OpenRLHF，按项目阶段切换而非二选一。
- 小米那五套环境脚本的价值不在跑分，在于"可抄作业"。 验证器怎么接（可执行测试、规则检查、Rubric 评审、视觉评分）、任务族怎么组织、启动脚本长什么样，都是现成参考。哪怕你最终不用 verl，读一遍这套目录结构也比从零设计省一周。
四、许可证与风险
五方全部 Apache-2.0（GitHub API license 字段口径），商用、修改、再分发在许可证层面没有额外门槛，这在这个赛道算得上整齐划一。但三条红线要划清楚：
- 以各仓 LICENSE 原文为最终口径。 GitHub API 的 license 字段是自动识别结果，可能与仓库中的 LICENSE 文件存在出入；商用落地前务必通读原文，尤其是专利授权与商标条款。小米 fork 搭档仓 mimoagent 的 MIT 同理。
- star 数是快照不是趋势。 2026-09-27 的快照能说明存量人气，不能说明维护质量与响应速度；五方建仓时间相差最长五年，跨时间直接比 star 天然失真，比"谁增长快"需要至少两个时间点的数据。
- 性能声明全部自报。 各框架 README 里的加速比、吞吐数字都在自家 harness 与自选任务下测得，互相之间不可比，也不应作为选型依据。唯一可靠的办法是拿自己的任务、自己的集群各跑一遍基准——这一步没有捷径。
结语
这一轮对比最大的收获不是"谁赢了"，而是五条路线各自长清楚了：TRL 管对齐起步，verl 和 OpenRLHF 管大规模可验证奖励训练，AReaL 管异步长程 Agent，NeMo-RL 管企业栈收口。小米 fork verl 这件事的价值，是给"开源框架能否扛生产级 Agentic RL"这个问题添了一个可核实的实证案例——75 万条轨迹的口径摆在那里，fork 的五套环境代码开放可查。你要做的，是把本文的四个场景结论对号入座，然后用自己的任务实测。star 会变，路线分工短期内不会。
常见问题
Q1： 这五款框架可以直接比跑分吗？
A1： 不能。各家评测 harness 与任务设置不同，性能数字均为各仓 README 自报口径，互相之间不可比。本文刻意不比跑分，只比定位、生态与工程形态；选型请用自己的任务在目标集群实测。
Q2： star 数能当作选型依据吗？
A2： 只能当参考。本文 star 为 2026-09-27 的 GitHub API 快照，五方建仓时间相差最长五年，先发项目天然占优。更稳的做法是看最近推送时间、社区响应节奏，以及与你自身场景的适配度。
Q3： 小米 fork 了 verl，是不是代表 verl 就是唯一答案？
A3： 不是。fork 是小米针对自家模型训练的选择，README 也写明这是"MiMo 的 Agentic RL 训练代码"。它证明 verl 能扛生产级训练，但不否定 OpenRLHF、AReaL 等框架在各自场景的价值。
Q4： 我只想做普通 RLHF 对齐，需要上这些重型框架吗？
A4： 多数情况不需要。LoRA 级别的偏好对齐从 TRL 起步即可；只有当任务涉及大规模轨迹采集、可执行验证器或多机集群时，才需要考虑 verl、OpenRLHF 或 AReaL。通用微调路线可参考本站 LLM 微调 SOP。
Q5： 商用这些框架有什么法律风险要注意？
A5： 五方在 GitHub API 口径下均为 Apache-2.0，商用门槛较低，但以各仓 LICENSE 原文为最终口径；商用前请核对 LICENSE 文件原文，特别是专利授权与商标条款，必要时咨询法务。