AgentRL: Scaling Agentic Reinforcement Learning with a Multi-Turn, Multi-Task Framework

See also (sibling notes,平行阅读): agents/notes/01_DR-Venus, 02_LiteResearcher, 03_AgentWorld, 04_MemPalace, 05_Rethinking, 06_AgentGymRL;以及 models/notes/08_INTELLECT3(prime-rl, 类似的 async agentic RL 设计)。

1. 动机:multi-turn × multi-task 撞上的三堵墙

从 RLHF (单步、单任务、reward model) 到 RLVR (单步、单任务、verifier),社区已经把「单步 RL」基本打通。但只要把场景换成 agentic—— LLM 要跟 OS / DB / KG / 网页 / 模拟家庭 这种环境做多回合交互, 同一套 RL 训练栈立刻处处漏水。论文 Table 2 里把痛点拆成三堵墙,我把它进一步展开成 1.1–1.3。

1.1 历史脉络:从 single-turn 到 multi-turn,bottleneck 漂移

之前以 GRPO 为代表的 RLVR 训练栈 (VeRL / OpenRLHF / EasyR1 / NeMo-Aligner) 都默认同步 (synchronous) interleaved pipeline:每个 step 内,先用 actor 把整 batch 的 trajectory 全 rollout 完,再统一做一次 forward + backward 更新。在 single-turn (math/code) 里这套是最优的 —— 所有 trajectory 长度方差小、生成时间几乎一样,GPU 几乎不会闲。

到了 agentic 场景,trajectory 由若干 (state, action, reward) 组成,每一步要等环境返回 observation 才能进下一步。WebShop 一条 trace 可能 6 步、ALFWorld 可能 30 步;OS 任务里每步还要等 docker 里 bash 跑完。结果是同 batch 内 trajectory长度方差极大,同步 pipeline 等于全队等最慢的那个,GPU 利用率从 80%+ 掉到很难看。AReaL (2505.24298) 已经指出这点,但它只解决了「reasoning task 多步思考」,环境管理还是单一的。

1.2 别的方案为什么不够 — 谁占了哪个坑、各让了什么

1.3 为什么这事不平凡

三堵墙叠加形成的工程 + 算法复杂度:

• 同步 pipeline 浪费的不是 10–20%,是几倍。 论文 Figure 4 里 14B 同步在 64 GPU 上达到 17K tok/s,async 版本到 56K tok/s —— 也就是说在多 turn agent 场景里,同步实现拿不到 scaling。原因是 trajectory 长度长尾叠加 environment 阻塞,GPU bubble 占比从 single-turn 的 ~10% 涨到 60%+。
• fixed-policy sampling 在 multi-turn 里 coverage 急剧坍塌。 single-turn 里 GRPO 用 group of K 个 sample 估 advantage,只要 K 张样本有差别就行;multi-turn 里同一个 policy 在长 trajectory 上趋向模式坍塌,GLM-4 反复进入「直接给答案不调 tool」、Llama 反复「乱调 tool」,K=8 个 trace 全是同一种错。论文给的 Figure 8a 直接量化了这个:Webshop 上 cross-policy sampling 的 pass@128 比单 model 高 ≈10pt。
• 多任务下 reward scale / sequence length 异质,共用一个 advantage 等于让强势任务把弱势任务踩死。 ALFWorld trajectory 30 步、reward 0/1 但成功率从 8% 起步;DB 任务 trajectory 5 步、success rate 已经 48%。如果把所有 token 的 advantage 一起 standardize, 弱任务的 ±1.5 σ 信号会被强任务的 ±0.3 σ 信号稀释。Figure 7b 显示不做 task-wise norm,ALFWorld 的 train pass rate 直接在 0.4 附近震荡上不去。

2. 背景速查

3. Fully-Asynchronous Generation–Training Pipeline

3.1 它和 「同步」 / 「半同步」 长什么不一样

论文 Figure 3 把 sync vs async 画了一张 Gantt 图。我把三种典型结构合并成一张更密的对照:

3.2 实现要点

• Coroutine scheduling. 每条 trajectory 由一根 coroutine 维护(它负责 LLM 生成 → 调环境 API → 等 obs → 再生成),所有 coroutine 共享一个 SGLang 推理 pool。一根阻塞了不影响别人。
• Dynamic batch. Trainer 不锁定 batch size: 拿到 queue 里 ≥ B_min 条就 fire,不等 B_max。这个设计很关键 —— 避免「最后那条 30 步的 trajectory 卡住整个 step」。
• Bounded staleness. 队列 size 设上限 + 每次 train step 后强制把所有排队的 trajectory drain 给 trainer。这意味着 staleness 最多 ~1 个 step,接近 on-policy。论文 claim 这是 acceptable 的;反过来如果允许更老的数据,off-policy 偏置会变大。
• Param sync. Trainer 每个 step 后,把新 weight broadcast 给一组「fresh」rollout engine;另一组「stale」engine 故意延迟更新(为 cross-policy sampling 服务,见 §4)。

3.3 Worked Example: 一条 30 步的 ALFWorld trace 撞上一条 5 步的 DB trace

假设 batch 里有 64 条 trace。同步模式下:1 条 ALFWorld 30 步、平均每步 1.5 s = 45 s;63 条 DB 平均 5 步 × 1.5 s = 7.5 s。Sync trainer 的 wall clock = max(45, 7.5) = 45 s,即 GPU 在 [7.5, 45] 这 37.5 s 内空转 87.5%。

Async 下:DB trace 7.5 s 完成 → 进 queue → trainer 攒到 B_min=16 立刻 fire 第一次 train,然后第二次,然后… 在那 45 s 内 trainer 已经做了 5–6 次 update; ALFWorld trace 在 step 22 时 trainer 已经更新了好几代,这里就出现 staleness 1–6 step,这就是为什么需要队列上限 + drain 强制策略。

4. Cross-Policy Sampling — 在 multi-turn 里抢回 exploration

4.1 它要解决什么

GRPO 的 group 里 K=8 个 trajectory 是同一个 π_θ 采样的。在 single-turn 里,K 条只要起始 token 不同,整体 distinguishable;multi-turn 下,K 条往往在第 1–2 个 action 就已经因为 KV cache 趋同陷入同一种策略错误(模式坍塌)。结果是 advantage 全部接近 0 (group 内 reward 方差 → 0),GRPO 梯度直接消失。

4.2 方法 — 一棵 cross-policy 树

引入一个 model pool M = {πθ(0), πθ(−1), πθ(−2), …}(实际就是 fresh 模型 + 几个 stale 模型 —— 不更新参数的早期 snapshot)。每一个 environment step,从 M 里均匀随机抽一个 π 来生成这一步的 action:

4.3 直觉 — 为什么这事保留了 validity

论文给了一个 grounding-function 的论证(Appendix C):每个 LLM 的输出空间 L 都覆盖到「合法语言空间」 L_valid,而 L_valid 通过 grounding function Γ 投影到环境 state space S^env。Cross-policy 的 supp(τ^c) ⊋ ∪_m supp(τ^m) 但 supp(τ^c) ⊂ L_valid —— 因为每一步都还是某个 valid LLM 给的,不会跳出 L_valid 进入「乱码区」。这就是为什么换成 random token sampling 不行 —— 那会把你打到 L \ L_valid。

4.4 实现:fresh + stale engines

多 model 的 architecture 异构会让 KV cache 不能共享,所以本文用了一个工程 trick:让 fresh engine (每 step 同步参数) 和 stale engine (每 N step 才同步) 都跑同一个 architecture,只是权重版本不同。这样 stale 就充当「另一个 policy」, 同时兼容 SGLang 的 tensor parallel 和 cache reuse。

4.5 反向论证:不做会怎样

Figure 8a 的 Webshop 实验:K=128 时 cross-policy pass rate ≈ 0.78 vs 单 model ≈ 0.68 (Qwen2.5-14B) / ≈ 0.65 (Llama-3.1-8B)。Mix 模式 K=128 ≈ 0.72。也就是说 cross-policy 的 +10pt 提升一半来自「双 model」,另一半来自「per-step 切换」,这是 mix 拿不到的。从训练 curve (Figure 8b) 看,有 cross-policy 的 model 在 pass@k 大 k 时持续高 ~5pt,说明它保留了 diversity。

5. Task Advantage Normalization

5.1 公式

对 task i 的当前 batch,把所有 (sample, group, step, token) 四元 index 下的 token-level advantage 收到一个集合 A_i^tok,然后:

注意三个细节:

1. 这是第二次 normalize。GRPO 本身已经在 group 内做了 (R−μ_R)/σ_R 一次;这里在整个 task batch 范围再做一次。
2. Normalize 的对象是 token-level advantage,不是 trajectory-level reward。
3. 每个 task 独立做,所以 ALFWorld 的 σ_AF 和 DB 的 σ_DB 不会互相干扰。

5.2 Worked Example

设定:同一 batch 里有两个 task。ALF 的 group reward 是 {0,0,0,0,1} (5 trajectory),DB 是 {1,1,0,1,1}。GRPO 第一次 normalize 后,每条 trace 的 trajectory advantage:

 broadcast 到每个 token 上(同一 trace 内每个 token 共享)。ALF 平均 trace 长度 = 30 token, DB 平均 = 5 token。

不做 task-norm: 全 batch token-level  集合中, ALF 占了 5×30 = 150 个 token, DB 占了 5×5 = 25 个 token。ALF 的 ±0.5 / ±2.0 主导了 σ_global。最终 DB 的 ±2.0 在 σ_global 下变成 ~±1.6,可用;但 DB 那条 −2.0 的 trace 只有 5 个 token,贡献的 raw signal 总量(Σ |Â|) ≈ 25 × 0.8 = 20,而 ALF 的总量 ≈ 150 × 0.7 ≈ 105。梯度被 ALF 长尾任务主导, DB 等于没在学。

做 task-norm: ALF 内部和 DB 内部各自 standardize;两个 task 都拿到 mean=0, std=1 的 token advantage。每个 task 都贡献 ~ 任务规模成正比的稳定梯度,interference 大幅下降。

反向论证:这其实就是 multi-task SGD 里经典的 GradNorm / loss balancing,只是这里在 RL advantage 维度做。如果 advantage scale 已经齐(reward 都是 0/1 + sequence 长度差不多), task-norm 应当无效;论文实验里 KG/OS/ALF 长度方差大,所以 +5.6 pt (Table 6: 65.0 vs 59.4)。

6. 环境框架: Controller / Worker / Container

Multi-task 不仅是算法挑战,本质先是 异构环境管理 挑战 —— 5 个 task 需要 5 种依赖 (Ubuntu docker、MySQL、Freebase KG、ALFWorld textworld、WebShop simulator)。AgentRL 给了一个三层结构:

关键 insight:把所有 task 改造成OpenAI function-call format是「统一接口」的真正承载点。例如 KG 的 7 个 query 操作 (get_relations, get_neighbors, count, …)、DB 的 (execute_sql, commit_final_answer)、OS 的 bash —— 都被统一成 tool definition + JSON 参数。模型只需要学「调对哪个 tool,填对参数」这一种行为模板。这也就是为什么 BFCL-v3 上做 OOD 评测会有显著 +3.0 pt 提升 (Table 5)—— 训练分布天然就是 function-call。

7. 端到端 Worked Example

跟踪一条 KG 任务 trajectory,问题:「Find the founder of the company that owns Freebase」。

step 0  [fresh π@v=237]  → tool_call: get_relations(entity="Freebase")
step 1  [stale π@v=230]  → tool_call: get_neighbors(rel="owned_by")
step 2  [fresh π@v=237]  → tool_call: get_relations(entity="#1")
step 3  [stale π@v=230]  → tool_call: get_neighbors(rel="founder")
step 4  [fresh π@v=237]  → "Final Answer: #3"
                           reward = 1.0  (verifier matches)

Async pipeline 视角:这条 trace 共 5 步,每步 LLM 1.2 s + env 0.3 s ≈ 7.5 s。trace 在 t=7.5 进 queue。同 batch 还有 7 条 ALFWorld 30 步 trace (~45 s) 和 56 条 DB 5 步 trace (~7.5 s)。Trainer 不等 ALFWorld,直接攒到 16 条就 fire 第一次 update —— 第一批 update 时这条 KG trace 已用上 fresh π@v=237 的 grad。

Cross-policy 视角:这条 trace 的 step 0/2/4 来自 fresh,step 1/3 来自 stale。Importance ratio 计算时,GRPO 的 ρ = π_θ(a|s) / π_old(a|s),分子全用 fresh π_θ;分母原本是 πold,现在等于「实际 sampling 时用的那个 π」。论文没显式给 importance correction (按 GRPO 默认就当作 single π_old),实务上靠 stale engine 滞后步数小 + clip 范围控制。

Task-norm 视角:这条 trace reward = 1.0,group 内 5 条 reward 是 {0,0,1,0,0},GRPO  给该 trace = (1−0.2)/0.4 = 2.0,broadcast 到 ~80 个 token。然后取 KG 整 batch (假设 200 trace × ~80 token = 16k token),做 ( − μ_KG) / σ_KG → 最终 token-level à ≈ +1.5 σ。这才是塞进 GRPO loss 里的有效 advantage。

8. 实验关键结果

8.1 主结果:32B 反超 GPT-5 / Claude-Sonnet-4

8.2 Multi-task 不输 best-of-five 单任务专家 (Table 4)

这个对比最锋利:对每个 task 单独训一个 14B model,各自 SR 是 89.7 / 73.9 / 72.2 / 43.1 / 60.3 (avg 67.8);一个 multi-task 14B SR 是 91.5 / 72.2 / 72.8 / 43.6 / 58.5 (avg 67.7)。差距 −0.1 pt 几乎可以忽略。但 multi-task model 多出来一个 BFCL-v3 OOD +3.0 pt 的 generalization 提升 (Table 5),说明它没有过拟合到 5 个 task。

8.3 Ablation

两个 trick 各贡献 4–6 pt,在 KG 和 OS 上效应最大(都是 long-horizon、open-state 的任务,正符合理论预期)。

8.4 Throughput

14B 在 Webshop 上:同步 16/32/64 GPU = 9K / 16K / 29K tok/s;async = 17K / 33K / 56K tok/s。倍率从 16 GPU 的 1.9× 涨到 64 GPU 的 1.93×, 接近 perfect scaling 直线 —— 也就是说 async 不仅降低绝对开销,也让scaling 不饱和。这是同步 implementation 给不出来的。

8.5 Failure mode (Table 7)

"Task Limit Reached" 比例,base → AgentRL:ALF 0.68 → 0.07,WS 0.275 → 0.020。也就是 RL 主要修了「没 budget 在限定回合内交答案」这个 failure mode,不是单纯的「答错了」。这个观察呼应 §8.1: AgentRL 大胜 ALF/WS 的本质是「学会了高效 act」,不只是「学会了 reasoning」。

9. 与同类工作对比

核心差异点:

• vs AReaL: AReaL 的 async 是「long CoT 内 token-level streaming」,trace 内长度方差不大;AgentRL 的 async 处理的是「环境阻塞 + trace 长度差几个数量级」, 颗粒度 per-env coroutine。
• vs prime-rl: prime-rl 的 async 主要解决「跨节点高延迟」(INTELLECT 体系跨 datacenter);AgentRL 的 async 解决「同节点环境长尾」。两者正交,理论上可以叠加。
• vs OpenRLHF / NeMo-RL: 两者都没有 environment 抽象层,做 multi-turn agent 要自己外挂;AgentRL 的 Controller/Worker/Container 是一等公民。
• vs AgentGym-RL:(sibling note 06)AgentGym-RL 也支持多任务,但偏重「环境 SDK 标准化 + benchmark」,RL 算法层更接近原始 GRPO;AgentRL 在算法层多了 cross-policy + task-norm 两个 trick。
• vs RAGEN/GiGPO/ARPO: 后者是「方法论文」,只在一个 env 家族里证明算法有用;AgentRL 是「框架论文」,目标是把这些算法都能复用到任意 env。

10. 局限 / 个人 take / 待验证问题

• Cross-policy 没有正式的 importance correction. 实际 GRPO 把 stale π 当 fresh π_old 处理,clip 范围内当作 on-policy。这在 stale lag 很小(≤几步)时大概率没事,但论文没给 stale lag 的 sensitivity 曲线 —— 如果 lag 拉到 50 步会怎样?个人觉得这是首要的待验证项。
• 5 个 task 都是 verifier-easy. 所有任务的 reward 都是 binary 0/1,−0.2 惩罚超时。要扩到「open-ended」任务(写代码、写文章、网页操作)还需要 reward model 接入,目前框架不直接支持。
• OS 任务上没赢 Claude-4-Thinking. 51.7 vs 51.0 持平 —— 大概率 OS 任务比 ALF/KG 更需要 long-context 推理 + reasoning model 的优势在那里发挥。AgentRL 32B 没 reasoning trace,可能差在这里。
• 「全异步带来的 staleness 偏差」claim 太软. 论文说「staleness acceptable」但没给 lag → reward 的 trade-off 曲线。从 Figure 4 推测 lag 一般在 1–6 step 内(B_min=16 时 trainer 一秒做 5 次 update);需要看 ablation。
• Cross-policy 的 stable training claim 和 Limitation 里自己的「mild instability」相矛盾. 论文 §G.1 承认 cross-policy 会带来 minor distribution shift,可能是 KG 任务上 Figure 7a 里 ours 比 baseline 后期的现象 —— pass rate 涨得慢但 ceiling 高。
• Open question: 这套 cross-policy + per-task norm 能否套到 reasoning task (math/code) 上?直觉上 reasoning 是 single-turn,task-norm 不必要;但 cross-policy 在 long CoT 内可能也有效(用早期 snapshot 当探索源)。

5 个想验证的点

1. 不做 importance correction 时, stale lag 从 1 步加到 50 步, advantage 偏差和最终 SR 怎么变?
2. Cross-policy pool 大小从 2 → 8 个 model, exploration 收益是否单调?
3. Per-task norm 改成 「per-task running avg + 小窗口 std」(streaming 版),会不会更稳?
4. 把 reward 换成 RM-based dense reward,task-norm 是否还成立?(soft reward 可能 σ_i 变化巨大)
5. 用 32B AgentRL 替换 stale engine 里的 model 为更早的 14B snapshot,跨 size 的 cross-policy 是否仍 work?

11. Memory points (冷回忆用)