（本文阅读时间：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 参与强化学习。
为了让 Agent RL 更贴近真实世界中的 Agent 系统，Agent Lightning v1.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,000 条训练样本，就将 SWE-bench Verified 上的Pass@1从 41.8% 提升至 56.4%，绝对提升 14.6 个百分点。同时，数据清洗、Reward Hacking 防护以及训练脚本均已开源，方便社区复现和进一步研究。
当 Agent 越来越复杂，传统 Agentic RL 为何开始失效？
传统 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 的执行方式，很可能已经与真实部署环境中的执行方式不同。
在早期探索中，研究员们提出了一种解耦思路：不要求 Agent 进入 RL 框架，而是在 Agent 与 LLMs 之间插入一个大模型的接口地址（LLMs endpoint Proxy）。Agent 继续按照原来的方式运行，只需将原本调用模型 API 的端点（endpoint）指向 Agent Lightning，训练框架便可以观察并记录模型调用。在 v1.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 而不是训练框架负责。训练系统只能观察一系列 LLMs 的请求与响应对，因此一个 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）配置通常是固定的，因此后端需要动态地将这些可变长度、可变数量的样本映射到固定的训练资源上。
针对这些问题，Agent Lightning v1.0重新设计了样本构建（sample construction）、优势值、损失归一化和训练调度，并将 rollout 层级作为重要的统计和优化单位。
用3,500行代码，搭建完整 Agent RL 控制平面
在系统设计上，Agent Lightning v1.0 将简单性作为第一原则。整个框架约 3,500 行代码，核心由三个组件组成：API 网关（API Gateway）、采样轨迹控制器（Rollout Controller）和自定义训练器（Customized Trainer）。
API Gateway 负责保存 rollout、模型和事件（event），并提供兼容 OpenAI 的大模型代理服务。Agent Harness 的每次模型调用都会自动关联到对应的rollout，并记录训练所需的提示词、回复和对数概率。
Rollout Controller 负责启动和管理 Agent 执行，既支持本地进程，也可以直接将 Agent 作为标准 Kubernetes 任务运行，从而将 Agent 执行与 RL 训练器完全解耦。
Customized Trainer 基于 VERL 实现，负责创建 rollout、等待执行完成、收集样本，并通过样本适配器（sample adapter）构造最终的 RL 训练样本。
因此，对于已有 Agent Harness，通常只需要将大模型的接口地址指向 Agent Lightning 的 Proxy，就可以快速接入 RL 训练。
图2：Agent Lightning v1.0系统架构
Agent 工作负载的另一个特点是 rollout 时间高度不均匀。同步 RL 必须等待一个批次中最慢的 Agent 完成，容易造成大量 GPU 空闲；完全异步 RL 虽然提高利用率，却往往需要分别维护 rollout GPU 池与训练 GPU 池，所需资源更多。
对此，Agent Lightning v1.0 提出了 Collocated Async RL（共位置异步强化学习），让 rollout 与模型更新共享同一组 GPU。系统收集到足够 rollout 后开始更新，此时 API Gateway 暂停接受新的请求，等待正在执行的请求结束；更新完成之后再恢复 rollout。整个状态切换过程对外部 Agent Harness 完全透明。
实验中，该方法相比同步 RL 获得了约2倍的端到端加速，同时又比传统异步 RL 使用了更少的 GPU。
在 RL 训练阶段，为了采集足够的 rollout，通常需要并发运行大量 Agent，因此 Agent执行本身就会消耗大量 CPU、内存和计算资源。
现有一些 Harnessed Agentic RL 框架通常依赖 Modal Sandbox、E2B 等商业沙盒（sandbox）服务来承载这些 Agent。虽然使用方便，但当 rollout 规模不断扩大时，外部沙盒的持续调用成本也会迅速上升。
Agent Lightning v1.0 则可以直接将 Agent 作为标准 Kubernetes 任务运行，复用已有的自建集群、云上 Kubernetes 或本地基础设施，无需依赖外部商业沙盒。
这样既能更高效地利用已有计算资源、降低大规模 rollout 的额外成本，也让从 Agent 执行到 RL 训练的整套流程保持完全开源、可控且易于复现。
图4：Agent Lightning v1.0的Rollout Controller提供了原生的Kubernetes支持，它直接将Agent作为标准Kubernetes任务运行。
为了验证 Harnessed Agentic RL 的实际效果，研究员们基于 SWE-smith + mini-SWE-agent + Qwen3.5-9B 建立了一套完整的数据清洗、环境构建、奖励作弊（reward-hacking）防护和 RL 训练管线。训练集包含约 6,000 个样本，无需依赖大规模计算资源。
实验结果显示，仅通过 RL 训练，Qwen3.5-9B 在 SWE-bench Verified 上从 41.8% 提升到 56.4%，绝对提升14.6个百分点。
与此同时，代码 Agent 实验也进一步验证了前文对“优势值计算”和“损失归一化”两大挑战的分析。相比样本层的处理方式，采用 rollout 层级优势值（Rollout-level Advantage）+ rollout 层级归一化（Rollout-level Normalization）能获得更高的验证奖励，同时训练过程中的策略熵（policy entropy）也更加稳定。
图5：Qwen3.5-9B在SWE-smith验证集上的通过率和策略熵。
Agent Lightning v1.0 聚焦于一个简单却重要的问题：如果未来的 Agent 运行在真实的 Agent Harness 之中，那么为什么训练时不能直接使用同样的 Harness？
围绕这一理念，Agent Lightning v1.0 让真实部署环境中的 Agent Harness 能够直接参与强化学习训练，从而保留工具调用、上下文管理、控制流以及执行环境。同时，这一训练范式也带来了新的研究问题，包括重新分词、动态样本数量、优势值计算、损失归一化和资源调度等挑战。Agent Lightning v1.0 对这些问题进行了系统化梳理，并以约 3,500 行代码实现了一套轻量、透明、可复现的解决方案。
研究员们希望，随着 Agent 系统不断走向真实应用场景，强化学习训练也能够逐渐摆脱理想化环境的限制。Harnessed Agentic RL 的探索，正是在这一方向上的一次尝试，并有望进一步缩小 Agent 研究与现实应用之间的距离。
Agent Lightning v1.0: Towards Harnessed Agentic RL
论文链接：
https://arxiv.org/pdf/2608.17528
项目页面：
https://github.com/microsoft/agent-lightning
你也许还想看：
