Agent Lightning v1.0：开源面向真实Agent Harness的轻量级强化学习框架

（本文阅读时间：12 分钟） 随着 AI Agent 从单纯的模型逐渐演化为由模型、工具和执行环境共同组成的复杂系统，Agent 的能力越来越依赖于模型之外的 Agent Harness （Agent运行框架 ）。 然而，当我们希望通过强化学习（RL）进一步提升 Agent 能力时，一个现实问题 出现了：许多现有 Agent RL 系统要求开发者将 Agent 重新实现到训练框架内部。这不仅增加了工程成本，也让训练环境与真实部署环境逐渐脱节。 为 了解决这一问题， 微软 亚洲研究院的 研究员们 提出 了 Harnessed Agentic RL 训练范式 ，并 开源 了 全面重构的 Agent Lightning v1.0 。 相比原版本 的 Agent Lightning ， v1.0 更强调 轻量、真实 的 Harness 集成以及完整可复现的 Agent RL 训练流程 。 也就是 说，在 Agent Lightning v1.0 中， 部署时使用什么 Agent Harness，训练时就直接让这个 Harness 参与强化学习。 为了让 A gent RL 更贴近真实世界中的 Agent 系统，Agent Lightning v 1.0 围绕 Harnessed Agentic RL 进行了全面 重构，在系统设计、工程实践和训练效果等 方面 都 带来了多项关键改进。 极致轻量 ： 完整框架 仅 约 3,500 行代码 。 Agent Lightning v1.0 将 简单性 作为第一设计原则，以尽可能小 且 清晰的代码库实现完整的 Harnessed Agentic RL 系统，让框架更容易理解、修改和扩展。 直接使用真实 Agent Harness 进行 训 练 。 Agent 可以通过 Agent Lightning v1.0 提供的 LLM Proxy 与模型交互，无需修改原有 Agent Harness 代码 。 原生支持 Kubernetes。 Agent 可以直接以 Kubernetes 任务 的形式运行，无需依赖外部商业沙盒服务 。 无论是自建集群还是本地基础设施，都能够支持大规模 Agent rollout。 提供完整的 Coding Agent 训练示例。 研究员 们 基于 Qwen3 .5-9B 构建了一套端 到端训练流程，仅使用约 6 , 00 0 条训练样本，就 将 SWE-bench Verified 上 的 Pass@1 从 41.8% 提升至 56.4%，绝对 提升 14.6 个百分点。同时 ， 数据清洗、Reward Hacking 防护以及训练脚本 均 已 开源 ，方便社区复现和进一步研究。 论文信息已整理至文末，欢迎点击相关链接，了解更多技术详情。 当 Agent 越来越复杂，传统 Agentic RL 为何开始失效？ 传统 Agentic RL 通常假设训练框架自己拥有完整的环境交互循环。例如 ， 在典型的 ReAct Agent 中，模型生成 动作（a ction ） ，环境返回 观察结果 （ o bservation ） ， 观察结果 被追加到已有上下文中，随后模型继续生成下一步 动作 。整个 rollout 因此 天然对应一条连续的 token 轨迹 。早期的 verl 、 AReaL 、slime 等强化学习系统基本沿用了这一设计 。 如果想训练一个 Agent，开发者 通常 需要把 Agent 循环 重新实现到 RL 框架内部。 但 现实中的 Agent Harness 已经越来越复杂。 无论是 mini-SWE-agent、 OpenHands 、 OpenCode 、Claude Code、Codex 等 代码 Agent ， 还是 各种通用 Agent 系统 ，都拥有独立的上下文管理、工具协议、执行逻辑和软件依赖。为了 RL 训练而重新实现一套 Harness，不仅 工程 代价 高昂 ，更重要的是 ， 训练时 Agent 的执行方式 ，很可能已经与真实部署环境中的执行方式不同 。 在早期探索中，研究 员们 提出了一种解耦思路：不要求 Agent 进入 RL 框架，而是在 Agent 与 LLM s 之间插入一个 大模型的接口地址 （ LLM s e ndpoint Proxy ） 。 Agent 继续按照原来的方式运行，只需 将 原本调用模型 API 的 端点（ endpoint ） 指向 Agent Lightning，训练框架便可以观察并记录模型调用。在 v 1.0 中 ， 研究员 们进一步将这 一 范式明确 定义 为 Harnessed Agentic RL ， 即 部署时使用什么 Agent Harness，训练时就直接让这个 Harness 参与强化学习 。 图 1： 传统Agentic RL 和 Harnessed Agentic RL 的对比。 传统Agentic RL 由训练框架直接管理环境和Agent循环，而 Harnessed Agentic RL 由Harness管理环境和循环。 让真实 Agent 参与训练，并没有想象中简单 Harnessed Agentic RL 与传统 Agentic RL 的一个核心区别是：环境交互循环由 Agent Harness 而不是训练框架负责。训练系统只能观察一系列 LLM s 的 请求 与响应对 ，因此一个 rollout 可能被拆成动态数量的 训练样本 。这 也 带来了四个关键挑战 。 上下文重 新 分词与样本合并 （ Retokenization & Sample Merging ） ： Harness 通常以文本形式维护上下文，但 RL 训练依赖 rollout 时真实采样的 token IDs。即使两次调用在文本层面可以连续拼接 ， 重新经过 对话模板 和 分词器（ tokenizer ） 后 ， token 边界也可能发生变化，因此相邻调用并不总能安全合并成同一个 训练样本 。 优势值计算（ Advantage Calculation ） ： 一个 rollout 可能由于 重新分词（retokenization）、子智能体（subagent）或上下文总结（context summarization） 被拆成多个 样本 。 如果直接在 样本层级 计算 基线 和 优势值 ， 就会让产生更多 样本 的 rollout 被重复计入，从而改变原本 rollout 层级的 统计关系。 损失归一化（ Loss Normalization ） ： 类似地， 如果直接按照 样本 数量平均 损失 ， 产生更多 样本 的 rollout 会获得更大的优化权重。 由于 样本 数量往往只是 Harness 内部行为带来的结果， 因此 损失归一化 也需要避免被 样本数量 扭曲。 训练 资源 调度（ Training Backend Scheduling ） ： 每个 rollout 最终会产生 多少 样本 、每个 样本 有多长，只有 Harness 执行完成后才能确定。但 GPU 数量以及 数据/张量并行 （ data / tensor parallel ） 配置通常是固定的，因此后