谷歌团队发布T2J-Bench：63个整仓任务检验PyTorch到JAX迁移

权重转换、模型计算、训练循环、推理服务，这四块都归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，到底能干到什么程度？

T2J-Bench由Google Cloud AI Research、伊利诺伊大学厄巴纳香槟分校、南加州大学、圣母大学和Google DeepMind的团队提出，配套设计的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%

研究覆盖了 5 种 agent harness 以及它们各自支持的模型，一共 20 组开箱即用的配置。每个实验设置都要在全部 63 个任务上跑 3 个随机种子，结果报均值和种子间标准差；候选仓库由同一套独立评测流程打分。

这些现成配置里表现最好的是 OpenCode + opus-5，总体得分 0.676。分项看，Spec 已经拿到 0.927，Numeric 和 Behavioral 却只有 0.670 和 0.741——结构规范查得再细，行为保真这一关还是没跟上。

图 5 | 这是论文主结果表的截图。表中 R 表示总体迁移得分，其下标对应三个随机种子下样本标准差的数值；其余各列则给出分项结果以及训练和推理结果。附录中的 OpenHands 与 Terminus-2 配置也属于完整的 20 组基线。该表在原论文中为表 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 相近的图示 API 成本下，追加两轮普通续跑的 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 之间。

这些结果说明，在已测试的不同 harness 和 backbone 上，TwinHarness 都站得住。对已有 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。