Agent Lightning 与 LEGO-RL：训练后的 Agent，必须在你的 Harness 里重新证明自己

两项新研究从不同方向揭示了同一个变化：包在 AI 模型外面的运行时，现在也直接参与模型训练。微软研究团队发布的 Agent Lightning v1.0，用部署时的 Agent Harness 做强化学习；独立发布的 LEGO-RL 则让同一个编程模型分别在三种原生 Coding Agent Harness 里训练，并在同一 benchmark 上得到三组不同的提升。

数字很亮眼。Agent Lightning 报告称，Qwen3.5-9B 在 SWE-bench Verified 上从 41.8% 提升到 56.4%。LEGO-RL 报告称，Qwen3.5-35B-A3B 在 OpenHands SDK 中从 64.0% 提升到 70.4%，在 Claude Code 中从 62.4% 提升到 68.2%，在 OpenCode 中从 57.2% 提升到 66.6%。这些是研究结果，不是对你的应用可靠性的承诺。

对非技术创始人、AI App Builder 用户和小型产品团队来说，今天最重要的结论是：一个训练后的 checkpoint，不会自动把论文里的成绩带进另一个 Harness。Prompt、工具 Schema、上下文压缩、重试规则、Sandbox、终止逻辑和 Verifier 都在塑造强化学习所奖励的行为。外围系统一旦改变，学到的优势可能缩小、消失，甚至优化到错误的产品目标上。

本文提供一条模型与 Harness 的证据链、一份完整的 rollout receipt、一个订阅支持案例、一套三路重放试验、常见失败模式，以及上线、限流或暂停的决策方法。你不必亲自做强化学习，但必须要求每个训练后的模型，在用户真正会经历的流程里重新挣到它的分数。

Agent Lightning 与 LEGO-RL 到底改变了什么

传统模型训练常被描述成一个由 Trainer 完全控制的闭环：发送 Prompt、接收答案、评估答案，再更新模型。长时间运行的 Agent 并非如此。模型外还有一套运行时，可能负责规划、调用工具、重写消息、总结早期步骤、生成子 Agent、重试失败动作，并决定任务何时结束。

Agent Lightning v1.0 论文把这种方式称为 harnessed agentic reinforcement learning。部署时的 Harness 掌握环境交互循环，Trainer 则通过 Endpoint Proxy 观察一连串模型请求与响应。它用大约 3,500 行代码实现，并公布了编程 Agent 的数据流程和训练脚本。作者报告称，使用约 6,000 条训练样本，在 SWE-bench Verified 上取得 14.6 个百分点的绝对提升。 LEGO-RL处理的是相邻问题：它加入进程内模型代理、Trainer 端概率重算、Sandbox 编排、Reward Integrity 防护和轨迹监控。作者让同一个基础模型分别在 OpenHands SDK、Claude Code 和 OpenCode 里训练；评估时将 temperature 固定为 0.7，最多运行 200 轮，Context Budget 为 200,000 token，并为三种 Harness 报告不同的起点和提升。

不能把两项研究拼成一张排行榜。它们使用的模型、训练样本、优化方法、Harness 和实验设置都不相同。真正一致的信号在架构层：被改进的单位已经不再只是“模型”，而是模型在一套特定交互系统中产生的行为。

先把容易混淆的术语拆开

下面这些概念常被一句“Agent 更强了”混在一起，产品决策前必须分开。

模型 checkpoint 是某一时刻保存下来的精确参数版本。“Qwen3.5”只是家族名，具体基础版、微调版或 RL 版 revision 才能指向行为。
Agent Harness 是模型周围的运行时，包括 Prompt 组装、规划循环、工具、记忆、上下文压缩、审批、重试、遥测与终止规则。微软当前对 Harness 的说明展示了多少关键行为实际上位于模型之外。
Rollout 是一次完整的任务尝试，包括模型调用、工具调用、环境观察、状态改变和最终结果，可用于评估或训练。
Verifier 判断这次 Rollout 是否应该获得 Reward。它可以运行测试、检查成品、应用 Rubric，或组合多项检查。
Reward 是从 Verifier 得出的训练信号。二元“通过”可以很好地验证一个窄任务，却可能过于粗糙，无法代表业务结果。
Replay（重放） 是在固定条件下重新运行任务，用来比较行为，而不只比较最后一个分数。
生产接受检查 判断用户的真实工作是否在产品约束内完成。它不等同于训练 Reward。

这些区别解释了为什么一个模型可以在编程 benchmark 上变强，却让你的客服、研究、文档或运营产品变差。Benchmark Verifier 也许只奖励测试通过；你的产品还可能要求权限正确、客户范围无误、解释清楚、延迟可控、成本有上限，并能在失败后恢复。

为什么论文里的提升不能单独迁移

Checkpoint 保存了模型参数，却没有保存产生 Reward 的完整系统。

Harness 会在模型调用之间改变模型看到的经历。Agent Lightning 记录了一个很细却重要的例子：同一段文本在后续消息历史中重新 Tokenize 时，可能被切成不同的 Token。上下文总结或子 Agent 也可能打破一个假设，即后一个 Prompt 只是前一个 Prompt 在 Token 层面的简单延伸。如果 Trainer 重建的序列与真正产生动作的序列不同，参数更新就可能指向错误行为。

LEGO-RL 指出了相邻风险。Harness 侧的压缩与重新序列化会改变历史；Sandbox 崩溃、依赖失败、超时、Verifier 配错和 Reward Hacking，都可能让昂贵的轨迹丢失或污染 Reward。项目报告 Rollout 与训练概率的相关性高于 0.99，但这只是对其公开流程的证据，不能保证下载 checkpoint 后在你的运行时中仍有同样收益。

LEGO-RL 自己的数据也体现了 Harness 依赖：分别训练后，OpenCode 提升 9.4 个百分点，OpenHands SDK 提升 6.4，Claude Code 提升 5.8。这不能证明哪一种 Harness 更好，因为三者起点不同、模型分别训练，而且作者没有对主要训练配置进行多次重复实验。它能证明的是，“这个 RL 模型提高了 X 分”并不是一个完整的产品主张。

AI Harness Engineering 论文给出了更宽的系统视角：软件 Agent 的能力来自模型、Harness 与环境的组合。对采购者或应用构建者而言，Model Card 是评估输入，不是接受结果。

建立一条八段证据链

采用经过 RL 训练的 Agent 模型前，把公开主张与生产决策通过以下八段连接起来。

环节	必须固定什么	为什么会改变结果
1. 任务	指令、Fixture、允许范围、成功定义	换一个工作，所需行为就可能不同
2. 环境	仓库或数据快照、依赖、网络、资源	工具和测试可能产生不同表现
3. Harness	版本、系统指令、工具 Schema、压缩、重试	模型看到和能做的事情改变了
4. Rollout	精确请求、响应、工具事件、终止原因	最终输出会隐藏路径与中间失败
5. Verifier	代码或版本、断言、阈值、评分政策	Reward 可能代表了错误的成功
6. 训练变换	Tokenize、样本合并、Advantage、归一化	参数更新可能对不上原始 Rollout
7. Checkpoint	精确 revision、Tokenizer、生成设置	家族名无法唯一标识行为
8. 产品接受	用户结果、安全、延迟、成本、恢复	Benchmark 通过未必创造产品价值

大多数小团队无法看到全部训练内部细节，这本身不是问题，前提是决策承认缺口。给每一段标记 已验证、厂商报告、我方重放观察 或未知。绝不能把“未知”自动解释成“应该一样”。

未知项还必须产生运营后果。NIST 生成式 AI Profile把风险管理视为覆盖完整生命周期的工作，包括测试、评估、验证、确认和部署后监控。放到这次决策中，影响较低且未知的训练变换，可以进入受限重放；如果未知的是 Verifier、Checkpoint、权限边界或数据来源，则涉及高后果动作的路线必须阻断，直到明确负责人解决。只有当一个标签能改变暴露范围、所需证据或监控强度，它才有意义。

开放基础设施让其中一些环节可以被检查。Agent Lightning 仓库公开了代码和编程 Agent 示例，LEGO-RL 仓库也随论文开放框架。Harbor 的评估文档展示了一种有用的 Job 记录：配置、轨迹、Verifier Reward、测试输出、时间与产物放在一起。开源不等于结果已被证明，但它让评估者至少有具体对象可以固定和检查。

从产品工作出发，而不是从 SWE-bench 出发

SWE-bench Verified 很适合评估 Agent 能否在可执行验证环境中解决一组选定的真实仓库 Issue，但它不是所有 AI 产品的代理指标。SWE-bench 官方网站明确区分 Benchmark 版本与评估基础设施，这正说明任何百分比都应该与 Dataset、Harness、模型和设置一起出现。

先用一句话写清你购买这个模型到底要完成什么工作：

在已认证客户、当前账户状态和允许动作集合已知的情况下，解决一项订阅支持请求；无法安全完成时，转给人工，而且不得修改其他账户。

然后让接受标准独立于模型自己说“已完成”：

识别了正确的账户与请求；
答案有现行政策依据；
只调用允许的工具与参数；
系统记录确认状态确实改变；
客户得到清晰结果或安全转人工；
延迟与总成本处于试验预算内；
失败后账户仍可恢复。

如果新模型不能改进这个接受对象，它的 Benchmark 成绩仍然有研究价值，却不足以成为产品迁移理由。

案例：升级订阅支持 Agent

假设一个四人 SaaS 团队用 Agent 处理套餐变更和取消订阅。当前模型运行在一套简单 Harness 中，包括检索、账户查询工具、套餐变更工具、取消草稿工具，以及任何最终取消动作前的人工审批。团队现在得到一个经过 RL 训练的新模型，厂商称它更擅长长链路工具使用。

创始人先挑选 60 个脱敏案例：20 个普通套餐变更、10 个取消请求、10 个账户指代不清案例、10 个旧政策案例，以及 10 个工具或依赖失败案例。所有案例都不能触碰真实账户，每个案例都有确定的 Fixture 和由负责人确认的预期结果。

第一次对比只更换 Checkpoint。生产 Harness、Prompt、工具、压缩阈值、重试上限与接受 Verifier 全部固定。新模型完成了更多普通套餐变更，却重复调用账户查询工具，并在歧义案例中更容易触发上下文压缩。压缩后，两次运行丢掉了尚未完成的审批状态，却错误宣称订阅已经取消。业务接受率并没有提高。

第二次对比只改 Harness 政策，保留旧模型：账户身份成为不可被对话改写的 Session State，取消审批放到对话历史之外，查询重试最多两次。两个模型都变好。新模型此时有小幅接受率优势，但工具调用中位数和成本仍然更高。

最终决定是限制路由，而不是全面替换。新 Checkpoint 只处理复杂的套餐迁移案例，先运行一周；取消订阅仍走旧路径，等待更多证据。排行榜无法告诉团队的关键事实在这里出现了：模型提升、Harness 修复和产品路由各自贡献了不同价值。

这个案例完全是假设场景，数字仅用于说明方法，不是 Agent Lightning、LEGO-RL 或真实客户的实验结果。

使用 Model–Harness Rollout Receipt

每次评估保留一份 Receipt。下面是 YBuild 模板，不是任何研究团队的官方 Schema。

yaml

evaluation_id: support-agent-2026-08-20-b
product_job: resolve_or_escalate_subscription_request

model:
  provider: example-provider
  checkpoint: exact-revision-or-hash
  tokenizer: exact-version
  decoding: { temperature: 0.2, max_output_tokens: 4000 }
  training_claim: vendor_reported_harnessed_rl

harness:
  name: internal-support-agent
  version: git-sha
  system_instructions: sha256
  tools_schema: sha256
  compaction_policy: v3
  retry_policy: lookup-max-2
  approval_state: external-store-v2
  termination_rule: confirmed_outcome_or_escalation

environment:
  fixture_set: support-safe-60@sha256
  policy_snapshot: 2026-08-18
  network: disabled
  real_side_effects: false

verifier:
  version: support-acceptance-v5
  deterministic_checks: [identity, policy, action_scope, recorded_state]
  human_review: sampled_20_percent
  reward_used_for_training: unknown

results:
  attempts: 60
  valid_acceptance_rate: pending
  unsafe_action_attempts: pending
  correct_escalation_rate: pending
  median_tool_calls: pending
  p95_latency_seconds: pending
  cost_per_accepted_case: pending

decision:
  outcome: hold
  allowed_route: none
  owner: product-lead
  next_evidence: rerun_after_approval_state_fix
  expires: 2026-09-03

这份 Receipt 可以防止“我们测过新模型”变成无法追溯的口头主张。Harness 版本、压缩政策、工具 Schema、Verifier 或 Checkpoint 只要变化，就创建新 Receipt，不要把旧结果直接改写成新结果。

迁移前运行三路重放

多数产品决策不需要完整复现一篇科研论文。只要进行受控的三路重放，就能拆开最大的影响因素。

A. 旧模型 + 当前生产 Harness

这是基线。在关闭真实副作用、或把动作导向合成系统的前提下，运行一组固定且具有代表性的案例。记录有效接受率、危险动作尝试、正确转人工、延迟、工具调用、Token、成本和失败恢复。

B. 新模型 + 当前生产 Harness

只更换 Checkpoint，以及必需的 Tokenizer 或 API Adapter。不要同时重写 Prompt、更换工具、增加轮数上限和替换 Grader。这个对比回答的是：模型在你拥有的系统里到底提供了多少边际提升。

C. 新模型 + 拟上线 Harness

现在再加入让新模型发挥所必需的 Harness 修改。B 与 C 的差异显示外围系统贡献了什么。如果 C 变好而 B 没变好，就应把它称为系统迁移，而不是模型升级；预算和审查范围也要按系统迁移处理。

非确定性行为必须重复运行。一次通过或失败可能只是随机性。候选结果出现前就固定案例集，为最终决策保留隐藏 Holdout；基础设施错误与有效 Agent 失败可以分开统计，但不能悄悄删除任何一类。

即使不用 Harbor，也可以借鉴它的结果结构：把配置、轨迹、Verifier 输出、时间和产物保存在一起。小团队测 60 个案例，用一张 Spreadsheet 加导出的 Trace 就够了，前提是每一行都有稳定 ID 和明确结论。

不要让训练 Verifier 兼任产品裁判

强化学习会优化能够获得 Reward 的行为。因此，即使训练由其他团队完成，Verifier 质量仍然是你的产品问题。

编程 Verifier 可以在测试通过时给一个二元 Reward。LEGO-RL 明确指出，可执行验证可靠却粗糙，无法给错误恢复等中间行为分配 Credit；其防护也不能保证抵御所有 Reward Exploitation。论文同时说明，每种 Harness 的主要配置只完成了一次训练，因此提升的重复运行方差仍未知。

产品接受检查必须覆盖训练 Verifier 看不到的后果。对客服 Agent 来说，数据库最终状态正确仍然不够：它可能泄露了另一个用户的数据、使用了未授权优惠、错误宣称操作已完成，或消耗了十倍成本。研究 Agent 的答案可能正确，却没有来源支持；文档 Agent 可以生成格式正确的文件，却留下危险的隐藏内容。

把三种判断分开：

判断	要回答的问题	负责人
训练 Reward	这次 Rollout 是否产生了用于更新模型的信号？	训练团队
Benchmark Verifier	运行是否满足固定 Benchmark 任务？	评估负责人
产品接受	用户工作是否安全且经济地完成？	产品负责人

同一项测试可以服务多个判断，但任何一行都不能悄悄代替其他两行。

留意八种失败模式

只按 Checkpoint 采购。 团队记下模型名，却没记录产生主张的 Harness、设置、工具和评估版本。
同时迁移所有层。 模型、Prompt、工具、记忆、重试和 Grader 一起变化，结果无法归因，也无法安全回滚。
Reward 与结果错位。 Verifier 奖励任务完成，却不检查产品真正要求的权限、解释、成本或恢复。
压缩导致状态丢失。 长任务把审批、用户纠正、范围限制或失败记录总结掉，而产品仍需要这些状态。
Rollout 统计被清洗。 崩溃和超时被当作“基础设施噪声”删除，但用户会遇到同一个依赖边界。
Reward Hacking。 Agent 绕过真实集成或修改测试，满足了 Verifier，却没有完成本来要做的工作。
一次运行就下结论。 在生成和环境都有随机性的情况下，一次训练或一次评估被当成稳定效果。
从 Benchmark 直接外推业务。 SWE-bench 提升被当作客服、分析或文档可靠性的证据，却没有产品重放。

这些失败模式并不表示 Harnessed RL 是错误方向。它们指出了采用证据必须放在哪里。

什么时候应该使用这套方法

当你购买或测试一个号称针对工具使用、编程、搜索、Computer Use 或其他长链路 Agent 工作流训练的模型时，这套框架最有价值。供应商在产品名不变时替换底层模型、团队更换 Harness，或 Benchmark 成为采购主张核心依据时，也应该使用。

对于没有工具、没有外部状态、输出契约容易确定的无状态文本转换，可以使用更轻量的检查。即便如此，也要固定模型 revision，并用自己的输入分布测试。

不要把本文当作运行 RL 训练的教程。训练需要优化、分布式系统、Sandbox 安全、数据许可、Verifier Integrity 和模型风险方面的专业能力。Agent Lightning 与 LEGO-RL 是公开代码的研究框架，不是“小团队本周就该训练生产模型”的证据。

现有证据也有明确边界。Agent Lightning 的编程结果来自作者报告的一种模型与流程；LEGO-RL 只使用一种模型架构，每种 Harness 分开训练，每个主要配置仅运行一次，混合 Harness 的泛化尚未解决。两项研究都依赖带可执行 Reward 的编程任务，不能证明开放式协作、受监管决策或你的真实流量会获得同样收益。

用矩阵决定上线、限制还是暂停

证据状态	决定	产品动作
新 Checkpoint 在当前 Harness 中提高产品接受率，Guardrail 未退化，多次运行稳定	渐进上线	从低后果流量开始，按 Receipt ID 监控，保留回滚
只有修改 Harness 后才提高，贡献来源清楚，恢复测试通过	按系统迁移处理	模型与 Harness 一起审查，对组合版本做 Canary
某一路线改善，另一路线成本或失败上升	限制并路由	只发匹配任务，保留 Fallback 与到期日
Benchmark 提升存在，但产品接受率持平或不确定	暂停	保留当前路径，补充证据或改进测试
出现未授权动作、状态丢失、Verifier 绕过或不可恢复副作用	阻断	先修复模型外控制，再进行下一次真实试验
Checkpoint、Harness、Verifier 或数据来源缺失	带明确未知项暂停	记录缺口、负责人和期限

严重控制失败不能被平均进良好的通过率。一个模型即使解决更多案例，只要跨越了未授权动作边界，就不能称为“总体更好”。Hard Blocker 必须与分数提升分开。

48 小时创始人重放计划

第 0–6 小时：定义工作。 选择一条窄产品流程，写清接受检查、Hard Blocker、成本上限和安全转人工。固定一组不会产生真实副作用的代表性案例。 第 6–12 小时：固定系统。 记录当前 Checkpoint、Harness Commit、指令、工具 Schema、压缩与重试政策、环境和 Verifier。候选运行开始前，先创建基线 Receipt。 第 12–24 小时：运行 A 与 B。 在当前 Harness 中比较旧、新 Checkpoint。重复非确定性案例，保留崩溃、超时、轨迹、Verifier 输出和成本。 第 24–34 小时：检查第一次分歧。 找出行为最早在哪一层不同：任务理解、工具选择、参数、重试、压缩、终止还是 Verifier 结果。不要只看最终答案。 第 34–42 小时：必要时运行 C。 加入最小且有依据的 Harness 修改，用同一案例与隐藏 Holdout 重放。任何提升都应记录成组合系统结果。 第 42–48 小时：做决定。 渐进上线、限制路由、暂停或阻断，并写清负责人、流量边界、停止信号、回滚目标和 Receipt 到期日。证据不足时，“未知”是完全有效的结论。

创始人该做的决定

Agent Lightning v1.0 与 LEGO-RL 让 Agent 训练更可检查，也更接近真实的工具运行时。它们最重要的产品启示并不是排行榜上的数字，而是 Harness 已经进入训练边界。

这会改变 AI 产品采购、测试和升级模型的方式。先问提升来自哪套 Harness，再把任务、环境、Rollout、Verifier、训练主张、Checkpoint 与产品接受串在一起。能一次只改一层时，就不要同时改动所有层。候选模型必须在你的真实流程中重放，并分别记录模型与 Harness 的贡献。

模型可以在别人的系统里拿到漂亮成绩。只有当完整的模型–Harness 组合通过你的用户工作、控制边界和恢复测试，它才真正挣到进入你产品的资格。

参考资料