图 1：Agent Lightning v1.0 整体架构。API Gateway 充当训练集群和 Agent 执行集群之间的桥梁。
传统 agentic RL 里，训练引擎拥有完整的环境交互循环——自己构造 prompt、调模型、拿 action、执行、获取 observation，形成标准马尔可夫过程。但现实中的 Agent 运行在 harness 里——harness 管理上下文拼接、工具调用、控制流、子 agent 分发。部署时 harness 是能力的核心，训练时却被绕开了。
Agent Lightning 提出的 Harnessed Agentic RL 让部署时的 harness 直接参与后训练。方法是通过 LLM endpoint proxy，让任意 harness 无需修改就能接入 RL 训练。verl Uni-Agent、AReaL 2.0、slime v0.3.0、Polar 都沿用了这个思路。
这篇论文最大的贡献不在框架本身，而在于首次系统刻画 harnessed agentic RL 带来的工程挑战。这些挑战在现有框架中要么被忽略，要么做了矛盾的设计选择。
Harness 构造每次 LLM 调用时会重新渲染完整消息历史并 tokenize，导致之前采样的 token 序列在新 prompt 中边界完全不同。例如 "having" 第一次被切成 "h" + "aving"，下次可能变成 "hav" + "ing"。三个原因：chat template 非组合性、decode-retokenize 漂移、推理时输出变换。
一个 rollout 可能产生动态数量的训练样本（平均 2.41 个，仅 36% 保持为单样本）。计算 advantage baseline 时，sample 级别还是 rollout 级别？论文认为 retokenization 是偶然现象，不应改变 advantage 计算，rollout 级别更合理。
动态样本数量让 loss 归一化变得微妙。seq-mean-token-mean（GRPO 风格）会给产生更多样本的 rollout 更大权重，而这是 retokenization 等偶然因素驱动的。论文实验验证 rollout-mean 最稳定。
GPU 数量固定，但每个 batch 的样本数量和长度执行前未知。后端需要把动态 workload 映射到固定 worker 上，同时保证同一 rollout 的所有样本在同一个 optimizer update 中，避免 within-rollout policy skew。
全部代码约 3,500 行，三个核心组件：API Gateway（rollout 生命周期管理）、Rollout Controller（K8s 上管理 agent 执行）、Customized Trainer（基于 VERL）。
Collocated Async RL 是一个巧妙的设计：rollout 和 update 共享同一 GPU 池，通过 API Gateway 控制阶段切换。相比同步 RL（等最慢 rollout）和纯异步 RL（双倍 GPU），用更少资源实现约 2x 端到端加速。
| 场景 | 基座模型 | 提升 |
|---|---|---|
| Search Agent (HotpotQA) | Llama-3.2-3B | 25.1% → 41.7% (+16.6%) |
| 通用指令跟随 | Qwen3-4B | 51.9% → 70.2% (+18.3%) |
| Coding Agent (SWE-bench) | Qwen3.5-9B | 41.8% → 56.4% (+14.6%) |
Coding Agent 仅用 6K 训练样本和适中算力，纯 RL 在 SWE-bench Verified 上拿到 14.6 个百分点绝对提升。论文还发现并阻止了四种 reward hacking 行为（git history 泄露、wget 下载上游代码等）。
价值不在 SOTA 数字，在于把被各框架回避的设计问题摆到台面上。当训练范式从「训练引擎控制一切」变成「harness 控制交互、训练引擎只看到 API 对」，很多理所当然的假设都碎了——token 连续性、样本-奖励一一对应、固定 batch 大小。
对正在构建 agent 系统的人，这篇论文提供了清晰的工程指南：retokenization 怎么处理、advantage 怎么算、loss 怎么归一化、后端怎么调度。而且全部代码开源，3,500 行，可以逐行审查。