发布背景：训练与部署「两套智能体」的老问题
Agent 的强化学习长期面临一个结构性错位：主流 RL 训练框架（verl、AReaL、slime 等）都建立在同一个假设之上——训练框架拥有智能体的交互循环。模型行动、环境返回观察、观察拼回上下文，整条 rollout 是一条连续的 token 轨迹，训练器可以对它做完整的优势估计与损失计算。
但生产环境的智能体不是这样运作的。OpenHands、mini-SWE-agent、OpenCode，以及各类商业编码智能体，都自带上下文管理、工具协议与执行逻辑——这套包围模型的外围软件就是 Harness。如果为了训练而在 RL 框架内重建一个 Harness，会带来两个成本：重建本身昂贵，而且重建出来的副本可能和部署版本行为不一致——你训练的对象不是你交付的对象。
2026 年 10 月 7 日，微软亚洲研究院开源的 Agent Lightning v1.0 试图正面回应这个问题。官方技术报告（8 月 18 日提交的预印本与 10 月的 v1.0 发布说明）把这套思路命名为 Harnessed Agentic RL：训练时使用的就是部署时的那个 Harness，一个字都不改。
Agent Lightning 不是又一个智能体框架，而是训练侧的基础设施：它不管理工具、不编排上下文、不执行任务——它只做一件事，让任意一个已经在生产中运行的 Harness 恰好成为 RL 训练的数据采集口。
Harnessed Agentic RL：代理拦截而非重建循环
整个范式的落点是一个 OpenAI 兼容的语言模型代理。它被插在 Harness 与模型之间：
- 对 Harness 透明：Harness 照常发出模型请求，代理把这些请求转发给真实模型，同时记录每一对请求-响应，以及训练所需的模型概率（logprobs）。开发者通常只需把 Harness 的模型端点指向代理，不必改动工具调用与执行代码。
- 对训练器诚实：训练器看到的不是自己生成的轨迹，而是真实 Harness 在真实执行逻辑下产生的轨迹——上下文压缩、子智能体分叉、工具重试这些行为都原样保留。
第三方报道确认，这套代理已经与 mini-SWE-agent、OpenHands、OpenCode 等开源 Harness 验证过兼容性，微软的说明中也将 Claude Code、Codex 等常见编码智能体列为可接入对象——后者属于厂商口径，尚未见独立复现。
这个设计的深层含义是：RL 训练的对象从「模型」扩展为「模型 + Harness」这个组合。训练增益不再是抽象的模型能力提升，而是这个具体部署形态在具体任务分布上的提升——这既是优点，也是需要小心的解读边界（见第五节）。
控制平面三组件与 Collocated Async RL
Agent Lightning v1.0 的控制平面由三个组件构成，合计约 3500 行代码——这个体量在动辄数万行的训练框架里属于刻意为之的轻量，官方明确说它是为「可审查、可修改、可扩展」设计的：
| 组件 | 职责 | 关键细节 |
|---|---|---|
| API Gateway | 记录模型调用与训练数据 | OpenAI 兼容端点；记录提示、响应与 logprobs |
| Rollout Controller | 启动与管理智能体运行 | Agent 以本地进程或标准 Kubernetes 作业运行，支持自管集群、云 K8s 与本地基础设施 |
| Customized Trainer | 收集样本并更新模型 | 基于 verl 定制；经样本适配器把完成的 rollout 转为训练数据 |
值得单独说明的是运行形态的选择：rollout 作为标准 Kubernetes 作业运行，意味着团队可以复用自己已经付费的集群容量，而不是把训练样本生产外包给按次计费的沙箱服务（如 Modal Sandbox、E2B）。对一个打算持续迭代内部智能体的团队来说，这笔账并不小。
Collocated Async RL：让推理与训练共享 GPU
第二个工程亮点是 GPU 调度。智能体 RL 的天然难点是 rollout 时长不可预测——一次运行可能几秒，也可能几分钟，而 GPU 必须在推理（产生 rollout）与训练（更新权重）之间分配。Agent Lightning 的 Collocated Async RL 做法是让两者共享同一批 GPU：
- 当积累的 rollout 足够时，网关暂停接受新的模型请求；
- 等待进行中的请求排空；
- 执行模型更新；
- 恢复智能体运行。
微软报告的实测结果是：端到端速度约为同步 RL 的 2 倍，同时 GPU 占用少于常规异步训练方案。这两个数字都是厂商自报，尚无独立复现，但调度思路本身是清晰且可检验的。
编码实验：41.8% 到 56.4% 的读法
官方给出的基准结果由一条完整的编码管线产生，三个要素缺一不可：
| 管线要素 | 配置 | 说明 |
|---|---|---|
| 数据集 | SWE-smith | 已开源；经数据清洗，约 6000 个训练样本 |
| Harness | mini-SWE-agent | 极简编码智能体，部署形态与训练形态一致 |
| 模型 | Qwen3.5-9B | 小型开源模型；未动用大规模算力 |
结果是 SWE-bench Verified 的 Pass@1 从 41.8% 提升到 56.4%，绝对提升 14.6 个百分点。管线还覆盖了数据清洗、环境构建与 reward hacking 防护——最后一项在编码 RL 里尤其重要，因为模型很容易学会「改测试」而不是「改代码」。
换一个角度看：41.8% 意味着约 58.2% 的任务未解决，56.4% 意味着未解决率降到 43.6%——训练消除了约四分之一的失败。但必须强调三点：这是单一模型 + 单一 Harness + 单一基准上的结果；分数是微软自报；它不能直接推广为「任何 Harness 接入都能获得类似提升」。
实验还验证了技术报告的核心论点：rollout 级优势计算 + rollout 级归一化优于样本级处理，带来更高的验证奖励和更稳定的策略熵。这一点的价值在第五节展开——它直接回应了「不拥有循环」带来的样本碎片化问题。
四大技术挑战：不拥有循环的代价
把循环留给 Harness，代价是训练器必须在不完整的视野下工作。官方发布说明列出了四个真实 Harness 带来的技术挑战，每一个都值得单独理解：
挑战一：重分词导致样本无法合并
Harness 输出的文本在经过代理转发时可能被重新分词，token 边界发生移位，导致相邻的模型调用无法干净地合并成一条连续训练样本。训练器看到的是碎片，而不是整段轨迹。
挑战二：一个 rollout 拆成多个样本
上下文摘要与子智能体会把一次智能体运行切成多段。如果不加处理，训练器会把这些碎片当作独立样本——但它们其实共享同一次任务结果。
挑战三：样本级优势计算重复计数
如果简单地对样本做平均，产生更多碎片的 rollout 会获得更高权重——不是因为它任务完成得好，而是因为 Harness 的行为把它拆得更碎。这是样本级优势偏差：优势估计被 Harness 的工程特性扭曲，而非任务表现驱动。
挑战四：不可预测的负载排期
每次运行的样本数量与长度在 Harness 结束前都是未知数，必须动态排期到固定的 GPU 与并行配置上——这正是 Collocated Async RL 要解决的问题。
四个挑战共享同一个根源：训练器与执行循环分离。微软的应对（rollout 级优势与归一化）把碎片重新聚合到「一次运行」的粒度上做估计，从机制上消解了挑战二与挑战三的大部分影响；挑战一则仍需在样本适配器层做对齐处理。
短板与开放问题
- 算力成本不透明：官方未披露编码实验的 GPU 小时数与硬件配置。对想评估「内部微调是否划算」的团队来说，这是最关键的缺失数字——结论是否成立，取决于这笔账能不能算出来。
- 缺少关键消融：没有「同一模型、同一数据、在重建循环上训练」的对照实验。「真实 Harness 是增益来源」目前是设计论证，不是实验证明。增益究竟有多少来自训练范式、多少仅仅来自数据与任务本身，无法区分。
- 单点结果：全部基准证据来自一条管线（SWE-smith + mini-SWE-agent + Qwen3.5-9B）与一个基准（SWE-bench Verified）。尚无第二个模型或第二个 Harness 上的复现。
- Reward 依赖：RL 只从奖励中学习。Agent Lightning 解决的是「如何从真实 Harness 采数据」，但「如何为你的业务任务定义可计算的奖励」仍是使用者自己的功课——而后者往往比前者更难。
- 早期阶段：v1.0 是早期框架，API 稳定性与长期维护承诺有待观察；商业沙箱豁免意味着环境构建（可执行测试环境、依赖管理）全部要自建。
与既有方案的对照及观察点
| 维度 | Agent Lightning | 传统 Agentic RL（verl 等） | 提示工程 / RAG 路线 |
|---|---|---|---|
| 训练对象 | 部署中的真实 Harness + 模型 | 框架内重建的循环副本 | 不更新模型 |
| 接入成本 | 改模型端点即可 | 重建 Harness 于训练框架内 | 低，但天花板明确 |
| 训练-部署一致性 | 高（同一套代码） | 取决于重建质量 | 不涉及 |
| 样本完整性 | 碎片化，需 rollout 级聚合 | 连续轨迹，天然完整 | |
| 沙箱依赖 | 自管 Kubernetes，无付费沙箱 | 视框架而定 | 不涉及 |
| 代码量级 | 约 3500 行（可读可改） | 通常数万行 | 不涉及 |
把 Agent Lightning 放回本站此前的分析脉络：R-TECH-17 提出的「Harness 工程范式」论证了运行层五原语（沙箱、权限、压缩、观测、状态）决定智能体的真实上限；Agent Lightning 则从训练侧给出了同一命题的镜像——Harness 不只是运行时的护城河，现在也是训练时的数据入口。哪个 Harness 生态能被更好地训练，哪个生态就在迭代速度上多一个杠杆。
三个值得跟踪的观察点：其一，独立复现 41.8% 到 56.4% 的结果，或在第二个模型、第二个 Harness 上重复同一管线；其二，官方披露 GPU 小时与硬件配置，让内部微调的成本账可算；其三，reward-hacking 防护在更开放的任务域（非编码）中是否同样有效——编码任务有测试套件做天然奖励，而多数业务任务没有。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。