RL 算法与 Infra Co-Design

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

2024                     2025                         2026
RLHF                  Reasoning RL                Agentic / Omni RL
 │                         │                           │
single-turn               long CoT                  agent loop
prompt→response           32k/64k reasoning         tool/env interaction
 │                         │                           │
fixed-ish length          heavy tail length          unbounded duration
 │                         │                           │
sync PPO                  GRPO / async RL            service-oriented RL
 │                         │                           │
LLM is center             rollout becomes bottleneck agent runtime is center
 │                         │                           │
trainer owns loop         rollout/trainer decouple   harness owns loop
 │                         │                           │
text only                 text/VLM                   omni / diffusion /
                                                      tool / browser / code

LLM Centric -> Agent Loop Centric

Agent Runtime 独立抽象出来

参考 https://qingkeai.online/blog/Agentic-RL

Deployment Runtime 和 training runtime 开始统一

直接使用真实 Agent Harness 进行训练。

传统 Agentic RL 通常假设训练框架自己拥有完整的环境交互循环。例如，在典型的 ReAct Agent 中，模型生成动作（action），环境返回观察结果（observation），观察结果被追加到已有上下文中，随后模型继续生成下一步动作。整个 rollout 因此天然对应一条连续的 token 轨迹。早期的 verl、AReaL、slime 等强化学习系统基本沿用了这一设计。如果想训练一个 Agent，开发者通常需要把 Agent 循环重新实现到 RL 框架内部。

但现实中的 Agent Harness 已经越来越复杂。无论是 mini-SWE-agent、OpenHands、OpenCode、ClaudeCode、Codex 等代码 Agent ，还是各种通用 Agent 系统，都拥有独立的上下文管理、工具协议、执行逻辑和软件依赖。为了 RL 训练而重新实现一套 Harness，不仅工程代价高昂，更重要的是，训练时 Agent 的执行方式，很可能已经与真实部署环境中的执行方式不同。

1
2
3
4
5
6
7
8
9

LangGraph
OpenAI Agents SDK
internal harness
browser runtime
code sandbox
memory
context compaction
multi-agent
...

如果训练的时候不用真实 harness：

Train/deploy distribution mismatch 会非常严重。

在早期探索中，研究员们提出了一种解耦思路：不要求 Agent 进入 RL 框架，而是在 Agent 与 LLMs 之间插入一个大模型的接口地址（LLMs endpoint Proxy）。Agent 继续按照原来的方式运行，只需将原本调用模型 API 的端点（endpoint）指向 LLM Inference Engine，训练框架便可以观察并记录模型调用。研究员们进一步将这一范式明确定义为 Harnessed Agentic RL，即部署时使用什么 Agent Harness，训练时就直接让这个 Harness 参与强化学习。¹

也就是：

deploy-time harness directly participates in post-training。

类似的设计可以参考 Roll 里面的 CLI-Native Mode²

Trainer 看到的不再是 trajectory，而是 Trace

Sample:
    input_ids
    response
    reward

现在

Trace
 ├── LLM Call 1
 │     ├── prompt
 │     ├── response
 │     └── logprob
 │
 ├── Tool Call
 │
 ├── Observation
 │
 ├── LLM Call 2
 │
 ├── Sub-agent
 │
 ├── Tool Call
 │
 └── Final Reward

Retokenization & Sample Merging 的问题

Retokenize Drift

Harness 通常以文本形式维护上下文，但 RL 训练依赖 rollout 时真实采样的 token IDs。即使两次调用在文本层面可以连续拼接，重新经过对话模板和分词器（tokenizer）后，token 边界也可能发生变化，因此相邻调用并不总能安全合并成同一个训练样本。

Advantage Calculation

一个 rollout 可能由于重新分词（retokenization）、子智能体（subagent）或上下文总结（context compaction) 被拆成多个样本。

如果直接在 sample level 计算基线和优势值，就会让产生更多样本的 rollout 被重复计入，从而改变原本 rollout 层级的统计关系。

Infini RL

Observability 必须从 GPU metric 变成 Agent trace

以前看：

GPU Util
MFU
NCCL bandwidth
step time

Agent RL 还必须看：

trajectory latency
tool latency
turn count
failure reason
reward
model version
environment version
staleness
token distribution

所以现在 verl 已经开始推出把 RL state trace、training metric 和 distributed rollout service dashboard 连起来的 RL observability。

白盒 RL 与黑盒 RL

异步 Async RL

1. Producer-Consumer 方式保持 Rollout Manager 侧保持始终最大 concurrency 并发，也就是说同一时刻始终有 M 个 worker 在做 rollout
2. 当发现完成 N sample 的时候，停止 Rollout，开始训练
   1. 这里是怎么停的？有几个角色
   2. 首先是 Agent Worker 不需要感知，如果它正好出在 create_chat_completion 的时候，就阻塞在 HTTP 调用就好，也就是这个 Agent Worker 的 Rollout 还没结束
   3. 然后是 Rollout OpenAI Server 和 Rollout Engine 通过一个 request pool 来

假设一条 trajectory 很长，一个 agent 可能跑 20 分钟。
Worker 在 trajectory 执行到一半时，trainer 发布了新 policy。

你会不会允许同一条 trajectory 前半段由 policy v 100 生成，后半段由 v 101 生成？