微软亚研院开源Agent Lightning v1.0：3500行代码做Agent强化学习，6000条样本把Qwen3.5-9B提了14.6分

如果你想给自己的Agent做强化学习，通常要付出的代价是：把Agent在训练框架里重新实现一遍。微软亚洲研究院10月7日开源的Agent Lightning v1.0，就是要砍掉这一步。

它的主张可以用一句话概括——部署时用什么Agent Harness，训练时就让这个Harness直接参与强化学习。研究者把这个范式正式命名为 Harnessed Agentic RL。项目已全面重构开源，完整框架约3500行代码，论文见 arXiv:2608.17528。

传统Agentic RL卡在哪

传统的Agentic RL假设训练框架自己拥有完整的环境交互循环。在典型的ReAct式Agent里，模型生成动作，环境返回观察，观察被追加进上下文，模型再生成下一个动作——整个rollout天然对应一条连续的token轨迹。早期的verl、AReaL、slime等系统基本都是这个设计，代价是：想训练一个Agent，开发者通常得把Agent循环在RL框架内部重新写一遍。

但现实里的Agent Harness早就不是那个简单的循环了。mini-SWE-agent、OpenHands、OpenCode、Claude Code、Codex这些代码Agent，各自有独立的上下文管理、工具协议、执行逻辑和软件依赖。为训练重写一套Harness不仅工程代价高，更麻烦的是——训练时Agent的执行方式，很可能已经跟真实部署环境里的执行方式不是一回事了。训出来的策略，压根没见过真正服务用户的那套Harness。

Agent Lightning的解法是在Agent和模型之间插一个LLM Proxy。Agent照原样运行，只需把原本调用模型API的端点指向Agent Lightning，训练框架就能观察并记录下每一次模型调用。对已有Harness来说，改动通常只有endpoint这一处。

3500行代码的三个组件

v1.0把简洁当成第一设计原则，整个框架约3500行，核心由三部分组成：

  • API Gateway：保存rollout、模型和事件，同时提供OpenAI兼容的大模型代理服务。Harness的每次模型调用都会自动关联到对应rollout，并记录训练所需的提示词、回复和对数概率。
  • Rollout Controller：负责启动和管理Agent执行，既支持本地进程，也可以直接把Agent作为标准Kubernetes任务跑起来，让Agent执行与RL训练器完全解耦。
  • Customized Trainer：基于verl实现，负责创建rollout、等待执行完成、收集样本，并通过sample adapter构造最终的RL训练样本。

让真实Harness进来，会冒出四个新问题

Harnessed Agentic RL与传统做法的核心区别是：环境交互循环由Agent Harness负责，而不是训练框架。训练系统只能观察到一系列LLM请求-响应对，因此一个rollout可能被拆成动态数量的训练样本。这带来四个麻烦：

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

优势值计算。一个rollout可能因为重新分词、子智能体或上下文总结被拆成多个样本。如果直接在样本层级算基线和优势值，产生更多样本的rollout就会被重复计入，改变原本rollout层级的统计关系。

损失归一化。类似地，按样本数量平均损失，会让产生更多样本的rollout获得更大的优化权重。而样本数量往往只是Harness内部行为的结果，跟任务表现无关。

训练后端调度。每个rollout最终产出多少样本、每个样本多长，只有Harness跑完才知道；但GPU数量和并行配置通常是固定的。后端必须把可变长度、可变数量的样本动态映射到固定资源上。

v1.0针对这四点重新设计了样本构建、优势值、损失归一化和训练调度，并把rollout层级作为重要的统计和优化单位。

不花钱买沙盒，也不多占GPU

两个工程上的取舍值得一提。

原生Kubernetes支持。采集足够rollout需要并发跑大量Agent，本身就要吃掉大量CPU和内存。其他一些Harnessed Agentic RL框架通常依赖Modal Sandbox、E2B这类商业沙盒服务承载，规模一上去成本涨得很快。v1.0直接把Agent作为标准Kubernetes任务运行，复用自建集群、云上K8s或本地基础设施，不依赖外部商业沙盒，整套流程保持完全开源、可控、可复现。

Collocated Async RL。Agent工作负载的特点是rollout时间高度不均匀。同步RL必须等一个批次里最慢的Agent，GPU大量空转；完全异步RL提高了利用率，却往往需要分别维护rollout GPU池和训练GPU池。v1.0让rollout和模型更新共享同一组GPU：收集到足够rollout后开始更新，此时API Gateway暂停接受新请求、等待在途请求结束，更新完成后恢复rollout，整个切换对外部Harness完全透明。实验中，这比同步RL拿到约2倍的端到端加速，又比传统异步RL用更少的GPU。

6000条样本，涨14.6个百分点

效果层面，研究者基于 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个百分点。数据清洗、reward hacking防护与训练脚本一并开源，方便复现。

代码Agent实验也反过来验证了前面两个挑战的分析：相比样本层级的处理，采用rollout层级优势值（Rollout-level Advantage）+ rollout层级归一化能拿到更高的验证奖励，训练过程中的策略熵也更稳定。

目前v1.0已验证支持的Harness包括 mini-SWE-agent、OpenHands、OpenCode、Claude Code、Codex、LangChain、AutoGen、OpenAI Agents SDK等。

为什么这件事值得关注

v1.0聚焦的是一个朴素但关键的问题：既然未来的Agent都跑在真实的Agent Harness里，那训练时为什么不能直接用同一个Harness？

沿着这个思路，工具调用、上下文管理、控制流和执行环境全部被保留在训练环路内，训出来的策略就是部署时真正会跑的那个。同时它也带出了重新分词、动态样本数、优势值计算、损失归一化和资源调度这一串新的研究问题，并以约3500行代码给出了一套轻量、透明、可复现的解法。

在大型RL框架动辄数万行的当下，这个"小而精"的选择，给Agent训练社区提供了一个容易读懂、改得动、扩得出去的新参照。

项目地址：github.com/microsoft/agent-lightning 论文：arXiv:2608.17528 《Agent Lightning v1.0: Towards Harnessed Agentic RL》 来源：微软亚洲研究院官方博客（2026年10月7日）