T2J-Bench：0.649→0.723，Coding Agent迁移后训练推理还对齐吗？

权重转换、模型计算、训练循环、推理服务，这些环节都被 T2J-Bench 纳入考察范围，整仓任务共 63 个，用来衡量 PyTorch 迁到 JAX 的质量。20 组现成的 agent–model 配置里，最强基线拿到 0.676 分；Claude-Code 与 opus-5 保持不变的前提下，TwinHarness 把分数由 0.649 拉到 0.723，相对提升 11.4%。

• 论文题目：T2J-Bench: Benchmarking Coding Agents on Execution-Grounded PyTorch-to-JAX Repository Migration

• 论文标题：T2J-Bench：在基于执行的 PyTorch 到 JAX 迁移库上对编码代理进行性能评估

• 论文：https://arxiv.org/abs/2605.29054

• 项目主页：https://ft2023.github.io/T2j-web/

• 开源代码：https://github.com/google-research/t2j-bench/

一个 PyTorch 模型仓库要搬到 JAX，模型定义、权重加载、训练循环、推理缓存都得配合着重写。改动看着不起眼，梯度方向或者后面的训练轨迹却可能因此变掉。这活儿交给 Coding Agent，到底能干到什么程度？

参与这项工作的团队来自 Google Cloud AI Research、伊利诺伊大学厄巴纳香槟分校、南加州大学、圣母大学和 Google DeepMind。他们提出 T2J-Bench，并设计 TwinHarness：agent 借助可运行的原始仓库，一轮一轮找出行为差异，修复并验证。研究盯住的问题只有一个——源代码本身已经给出的执行证据，怎么变成有用的迁移反馈。

整仓迁移到底要保住哪些行为？先看两个框架的差别。

PyTorch 组织计算靠的是即时执行、有状态模块和面向对象那一套；JAX 走的是另一条路，参数显式写出、以函数式表达、执行可编译。Agent 迁移时得把程序的执行方式重新搭一遍，让模型、训练状态和运行入口在新框架里配合起来。

论文里有个直白的例子：误差先平方再平均，和先平均再平方，只差一处计算顺序，损失和梯度就不一样了。代码照样能跑，训练却已经偏离原实现。优化器更新、注意力掩码、推理阶段的 KV cache 里，都可能藏着同类问题。

图 2 画的是同一源仓库的三种迁移结果：行为保住了、出现偏差、或者仍旧依赖 PyTorch。图中代码和损失曲线只是用来说明问题，并非实测数据。原论文图 1。

还有一种更隐蔽：候选仓库表面给出了 JAX 接口，实际计算还在调 PyTorch。输出可能和源实现很接近，框架迁移却没真正完成。所以 T2J-Bench 两头都查——候选实现有没有甩开源框架依赖，相同输入下有没有保住被评估的执行行为。

训练轨迹和服务状态被纳入评测，原因也在这里。单次前向输出只反映系统行为的一部分，真到工程交付，还得过反向传播、连续更新、多请求推理这几关。

63 个任务覆盖训练与推理服务

T2J-Bench 收了 63 个自包含的仓库级迁移任务，横跨 18 个模型家族。每个任务都给出来自真实代码库的 PyTorch 源树和公开权重，源树一般含 15 至 20 个模块。Agent 要交的是原生 JAX/Flax 仓库，保留规定的文件结构与公共接口，还要做出不依赖 PyTorch 的 checkpoint 转换。

训练这块，15 个模型家族分别配上 SFT、DPO、PPO 三类目标，组合出 45 个 LoRA 微调任务；服务这块，6 个模型家族配上单序列、变长批处理、分块预填充三种 paged-attention 模式，共 18 个任务。训练和服务的模型家族有重叠。

图 3 展示的是 T2J-Bench 的任务构建、迁移交付与独立评测流程。原论文图 2。

评测拆成三块来看。Spec 管的是结构、接口和框架独立性；Numeric 拿模块输出、损失、梯度这些数值做比对；Behavioral 则盯训练动态以及推理过程里的行为和状态。候选代码跑在隔离、离线、没有 PyTorch 的环境里，再与事先从原始 PyTorch 实现录下的参考结果对照。

最后的 reward 落在 0 到 1 之间，是个连续分：规范检查充当乘性门控，数值和行为两项按默认等权合成。所以 0.723 只是评测得分，不能当成 72.3% 的任务成功率来读。参考的 JAX 实现同样要过这套评测，它拿到的 0.980 用来证明任务可解；真正的评测真值还是出自 PyTorch 原始实现。

TwinHarness 把源代码变成可执行规格说明

跨框架迁移其实有个现成的反馈来源——原始仓库自己跑得起来。TwinHarness 就围着这份“可执行的规格说明”做文章：改动之前先让 agent 找出差异，改完之后再核对修复是否站得住。所谓 harness，指的是组织 agent 调用工具、拿到反馈、把任务往前推的那套运行流程。

诊断阶段读当前代码和已有的运行证据，找出迁移缺口，定下要修什么；迁移阶段动的是 JAX/Flax 实现、权重转换，以及训练或服务路径；验证阶段把更新后的仓库跑一遍，记下检查结果，再把证据交给下一轮诊断。代码状态和诊断证据分开存放，免得只靠对话记忆去重建之前的结论。

图 4 | TwinHarness 的诊断、迁移、验证循环，以及基于源实现的差分检查和候选侧检查。原论文图 3。

验证信号有两类。一类把 PyTorch 和 JAX 放在匹配的输入下，比对输出结构、字段和可观察行为；另一类直接查候选实现本身，比如模块能不能导入、参数树是否合理、梯度是否有效、JAX tracing 过不过得了，以及训练入口能不能跑起来。

每条结论都会打上“已证实”“已违反”或“尚未证实”的标记。检查工具没给结论，和候选代码被确认有错，是两回事。TwinHarness 只用任务里对 agent 可见的资源，隐藏测试、冻结评测参考、评测器代码和 benchmark reward 都不碰，开发反馈与最终评分因此保持分离。

相同模型和 agent 下迁移得分提升 11.4%

研究覆盖了五种 agent harness 和它们支持的模型，合计 20 组现成配置。每套设置都在完整的 63 个任务上跑三个随机种子，报的是均值和种子间标准差；候选仓库由同一套独立评测流程打分。

现成配置里最强的是 OpenCode + opus-5，总体得分 0.676。它的 Spec 分数已经有 0.927，可 Numeric 和 Behavioral 分别只有 0.670 和 0.741——结构规范检查和行为保真之间，差距还摆在明面上。

图 5 是论文主结果表的截图。R 表示总体迁移得分，其下标对应三个随机种子的样本标准差；表中其余各列给出分项结果以及训练、推理表现。除这 20 组基线外，附录里还列有 OpenHands 和 Terminus-2 两种配置。原论文表 3，第 9 页。

把 Claude-Code + opus-5 固定为基础后，TwinHarness 的总体得分由 0.649 升到 0.723，绝对增益 0.074，相对增幅 11.4%；对比最强的现成配置 0.676，高出约 7.0%。据论文介绍，这一均值在它所评估的配置里是最高的。

分项看，数值分数从 0.618 升到 0.730，行为分数从 0.728 升到 0.792。不过提升并非覆盖每个细分任务：OpenCode + sonnet-5 的推理总分依然高于 TwinHarness，而后者距离 0.980 的参考实现也还有不小差距。实验证明了源实现反馈有用，同时也留出了继续改进的余地。

迁移质量更高，对应的是怎样的成本取舍

新流程实不实用，得把质量放进成本坐标里看。论文以跑完一轮 63 个任务的 API 花费为口径做比较，并给 Claude-Code 与 OpenCode 各加了普通续跑轮次，看追加修改究竟能换来多少收益。

图 6 展示迁移质量与 API 成本的权衡关系。横轴取对数刻度，纵轴采用断轴；×1 指初始运行，×2 和 ×3 分别代表追加一轮、两轮普通续跑。红星标注的是 TwinHarness。原论文图 4a。

在图上与 TwinHarness 成本相近的位置，Claude-Code 和 OpenCode 追加两轮普通续跑后分别约为 0.66 和 0.60，TwinHarness 则为 0.723。可见在这些配置和预算条件下，结构化的验证反馈能撑起质量更高的迁移。

另一边，初始 OpenCode 用更低的成本拿到了 0.676。它和 TwinHarness 都落在观察到的帕累托前沿上：前者是低成本选项，后者是保真度更高的选项。这个结果说的是质量与成本之间的取舍，不能理解成 TwinHarness 在任何预算下都最便宜。

成本曲线还暴露出一个现象：OpenCode 追加一轮后从 0.676 掉到 0.628，追加两轮后约为 0.60。改动多了，可能把本来正确的行为弄坏，所以反馈质量会直接影响继续迭代还值不值得。

四组 harness 与 backbone 搭配都有提升

TwinHarness 的收益是不是只出现在某一种搭配上？研究又比对了四组匹配的 harness–backbone 配置，每组的底层 agent 与模型都固定不变，只比较加入该流程前后的表现。

图 7 给出四组匹配配置的总体 reward 对比：粉色代表基础 agent，蓝色代表 TwinHarness，每组所用的底层 harness 与模型完全一致。原论文图 5。

具体数字上，Claude-Code 一侧，opus-5 由 0.649 升到 0.723，sonnet-5 由 0.408 升到 0.467；Gemini-CLI 一侧，gemini-3.7-flash 从 0.102 升到 0.222，gemini-3.8-flash 从 0.087 升到 0.217。四组配置的绝对增益在 0.059 至 0.130 之间。

这些数据说明，TwinHarness 在已测试的几种 harness 与 backbone 上都能用。对已有 agent 系统来说，研究给出了一条可以试的改法：模型和底层执行工具都不动，把源实现运行、差分检查以及诊断证据更系统地接进迁移流程里。

不过实验范围仅限于 T2J-Bench 上的匹配配置比较，对未知任务分布能否泛化，目前还得不出结论。不同框架、不同仓库类型、不同部署条件下这套流程是否成立，仍要后续检验。

结构化反馈又是怎么影响后面修复的？

研究还看了第一轮到第二轮的变化。固定 opus-5 时，普通 OpenCode 续跑从 0.676 掉到 0.628；TwinHarness 在 OpenCode 上则从自己首轮的 0.632 升到 0.706。它在第一轮并不占优，优势是在后续的诊断和修复环节才显现出来。

从任务层面看是另一种图景：普通续跑在第二轮得分退步的任务有 22 个，TwinHarness 只有 2 个。论文的判定标准是变化超过 0.01 算提升或退步，绝对变化不超过 0.01 算持平，两种方法都拿自己的首轮候选作比较。

图 8 展示 OpenCode + opus-5 在 63 个任务上的第二轮变化：普通续跑为 7 个提升、34 个持平、22 个退步，TwinHarness 则为 11、50、2。原论文图 6。

上述现象与「结构化验证有助于保住已有正确行为」的解释相符，但研究并未单独拆出某个组件的因果贡献，也不代表轮次继续加下去就一定会一直涨。

T2J-Bench 把仓库迁移拆成可执行、可对比的行为检查，TwinHarness 则说明怎样让这些任务里本就可用的源代码进入开发反馈。benchmark 代码开放之后，研究者能在统一的任务和评测流程下比较各自的 agent，进一步弄清哪些执行证据最有助于系统在跨框架时保住原有行为。

作者信息

论文署名方面，Tao Feng、Jiefeng Chen、Linxin Song、Yufan Zhuang、Yue Huang、Bhavana Dalvi Mishra、Chi Wang、Xiangru Tang、Jieyu Zhao、Ge Liu、Tomas Pfister 与 Jinsung Yoon 共同完成。其中 Tao Feng 和 Jiefeng Chen 列为共同第一作者，通讯作者则由 Tao Feng、Jiefeng Chen、Jinsung Yoon 三人担任。

这项研究是 Tao Feng 和 Linxin Song 在做 Google Cloud AI Research 学生研究员的时候做出来的，参与合作的机构有 Google Cloud AI Research、UIUC、USC、圣母大学以及 Google DeepMind。