Google 團隊發佈 T2J-Bench，評估編碼智能體的 PyTorch 至 JAX 整倉遷移

从权重转换、模型计算到训练循环和推理服务，T2J-Bench 用 63 个整仓任务检验 PyTorch 到 JAX 的迁移质量。20 组现成 agent–model 配置中，最强基线得分为 0.676；保持 Claude-Code 与 opus-5 不变，TwinHarness 将得分从 0.649 提升至 0.723，相对提升 11.4%。

图 1 | 论文首页的题名、作者与机构信息截图。

论文题目：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 接近的图示 API 成本下，追加两轮普通续跑的 Claude-Code 和 OpenCode 分别达到约 0.66 和 0.60，而 TwinHarness 为 0.723。这说明，在这些配置和预算下，结构化验证反馈能支持更高质量的迁移。

与此同时，初始 OpenCode 以更低成本取得 0.676。它和 TwinHarness 都位于观察到的帕累托前沿：初始 OpenCode 提供较低成本的选择，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。