Agent Lightning：线上 harness 直接参与强化学习

发生了什么

微软亚洲研究院发布并开源了 Agent Lightning v1.0，将其定位为「Harnessed Agentic RL」训练范式的一次完整实现。与多数智能体强化学习系统不同，它不要求把部署中的智能体搬进训练框架里重写一遍，而是让同一个 harness 在训练时直接跑起来。

具体内容

整个框架约 3500 行代码，由三个核心组件组成：

• API Gateway：兼容 OpenAI 接口的 LLM 代理，记录 harness 每次模型调用的 prompt、response 和 log probability，并把它们归到对应的 rollout 下。
• Rollout Controller：以本地进程或标准 Kubernetes Job 的形式启动智能体，使智能体执行与训练器分离。
• Customized Trainer：基于 verl 构建，负责创建 rollout、等待完成、收集样本并通过 sample adapter 组装训练数据。

接入方式上，已有 harness 通常只需把原来指向模型 API 的端点改为 Agent Lightning 的代理地址，harness 代码本身不用变动。框架原生支持 Kubernetes，可在自管集群、云上 Kubernetes 或本地基础设施上运行智能体，不依赖 Modal Sandbox、E2B 等付费商业沙箱服务。

训练侧还引入了 Collocated Async RL：rollout 与模型更新共用同一组 GPU。系统收集到足够 rollout 后，API Gateway 暂停接收新请求并等待进行中的请求完成，更新结束后恢复 rollout，整个过程对外部 harness 透明。实验称其端到端速度约为同步 RL 的 2 倍，且占用的 GPU 比常规异步 RL 更少。

与以往相比

传统 agentic RL 假设训练框架掌管与环境的交互循环，ReAct 式轨迹可以映射成一条连续的 token 序列，verl、AReaL、slime 等早期系统都按这个前提设计。但 mini-SWE-agent、OpenHands、OpenCode、Claude Code、Codex 这类真实 harness 各自带有上下文管理、工具协议和执行逻辑，重写成本高，且重写后的智能体未必与线上行为一致。

Agent Lightning 的做法是在智能体与模型之间放一个代理。v1.0 把这一思路正式定义为 Harnessed Agentic RL：部署时用哪个 harness，训练时就由哪个 harness 直接参与强化学习。

代价是训练系统只能看到一串 LLM 请求与响应，一次 rollout 可能被拆成数量不定的样本，由此带来四个工程问题：

1. 重分词与样本合并：harness 以文本保存上下文，重新过 tokenizer 可能改变 token 边界，相邻调用不一定能合并成一个样本。
2. 优势计算：子智能体和上下文摘要会把一次 rollout 拆成多个样本，若按样本级计算基线，样本多的 rollout 会被重复计数。
3. 损失归一化：按样本数平均会让样本多的 rollout 权重更大，而归一化不应被这种 harness 行为扭曲。
4. 训练后端调度：样本数量和长度要等 harness 跑完才知道，GPU 数量与并行配置却通常固定。

对读者意味着什么

1. 如果团队已有成熟的智能体 harness，可以先评估「只改端点」的接入成本，再决定是否自建训练循环。
2. 做智能体强化学习时，应优先在 rollout 级而不是样本级计算优势和归一化，原文实验显示这样验证奖励更高、策略熵更稳定。
3. 需要大规模跑 rollout 的团队，可以把 Kubernetes 现有资源纳入方案，避免沙箱服务费用随规模快速上升。

实验数字

研究者在 SWE-smith、mini-SWE-agent 和 Qwen3.5-9B 上搭建了完整流水线，覆盖数据清洗、环境构建、reward hacking 防护和 RL 训练。训练集约 6000 条样本，不需要大规模算力。仅 RL 训练就把 Qwen3.5-9B 在 SWE-bench Verified 上的 Pass@1 从 41.8% 提升到 56.4%，绝对提升 14.6 个百分点。