未必。
Agent Lightning v1.0 的论文挂出来，多数人会盯住那个数字：六千条训练样本，SWE-bench Verified 从 41.8% 到 56.4%。十四个多点，确实好看。但真正值得想的不是这个。
是"harnessed agentic RL"这个提法本身。
它的意思是：部署时用的 harness，直接参与训练。训练器不再拥有环境交互循环，harness 拥有。训练器看到的只有 LLM 的请求和响应。
换句话说，训练循环和部署循环，合并了。
这件事值得停下来想想。传统 agentic RL 有个默认假设：训练时你得自己搭一个环境，把 agent 的行为抽象成训练器能理解的东西。这个抽象一直是权宜之计。部署时 agent 跑在 Claude Code 或者别的什么 harness 里，训练时跑在你自己搭的循环里，两边永远对不齐。你优化的那个 agent，和最后上线的那一个，不是同一个东西。
Agent Lightning 原来的做法是用一个 LLM endpoint proxy 把任意 agent 接进 RL，这条路线后来被 verl、slime、AReaL 2.0 各自采纳了一部分。v1.0 把话说得更直白：既然对不齐，那就别对齐，让 harness 本身进训练。
这和 vibe coding 那边的一个趋势是同构的。工具在吃掉方法论。以前“怎么训练一个 agent”是一套独立的工程，有专门的训练框架、专门的环境抽象。现在这个工程被压缩成一个很薄的东西——论文里的实现大概三千五百行代码。三千五百行，撑起 SWE-bench 上十四个点。
薄不是缺点。薄是这个路线成立的表现。
你可能会反对说，让 harness 参与训练，结果就不可比了。各家 harness 不一样，训出来的模型没法横向评价。这个反对有道理，但它假设“可比性”还是这个领域的核心需求。我怀疑不是。模型最后都部署在某个具体 harness 里。一个在干净环境里训出来、在真实 harness 里掉点的模型，它的“可比性”本身就有水分。宁可训练时就把 harness 算进去。
换句话说，问题不是“这样训练还纯不纯”，是“纯”这个标准本来就要换了。¹
论文里列的那些挑战——retokenization、样本合并、advantage 怎么算——都是合并带来的摩擦。训练器只看得到请求响应对，那 advantage 的边界在哪、多个请求算一个 episode 还是分开算，这些在传统 RL 里有现成答案的问题，现在都得重新谈。我不觉得这些是工程细节。它们是“训练单位是什么”的重新定义。传统 RL 里，episode 是自然单位。harness 进来之后，一个 episode 被打散成一串请求，粒度变成一个设计决定，而不是给定的。
这里我可能错了，但暂时这么认为：这类摩擦会越来越多地出现在论文里，而它们会反过来塑造我们对“一次 agent 任务”的理解。以前是环境定义任务，以后是 harness 定义任务。
有意思的是作者把代码和训练脚本全放出来了，还给了 coding-agent RL 的完整可复现管线。这个做法本身就在说话：他们觉得这套东西的价值不在框架——三千五百行没什么可藏的——在于让别人拿任意 harness 来接。框架越薄、越容易被替换，这个范式扩散得越快。
如果我对，接下来一年会看到的是：训练框架这个词慢慢失去意义，讨论从“用什么框架训”变成“把哪个 harness 拖进训练”。harness 的作者会发现自己手里多了一样东西——不只是部署界面，还是训练环境。这个身份变化，比任何一张 benchmark 表都值得提前想。²
开头那个“未必”，说的是对分数的兴奋。分数是真的，但分数是旧范式的记分方式。范式换掉的时候，记分方式也会换。
¹ 短期内 benchmark 排行榜不会消失，大家还是要靠它说话。但一个只在干净环境里成立的分数，含金量会先被使用者看穿，再被榜单承认。
² 开头的说法太绝对了，收紧一点说：不是所有训练都会走这条路，但在“部署在 harness 里”这个前提下训的模型，多半会。