一句话结论
XStack 要解决的不是“模型会不会写 JAX”，而是“智能体能不能把一个完整的 PyTorch 仓库迁成在 TPU 上跑通、且结果对得上原论文的 JAX 仓库”。按论文摘要给出的结果，这件事目前仍不可靠：最强的 Claude Opus 5 通过率 75%。
方法要点
核心思路是把研究者日常最烦的活直接变成评测任务，而不是另造一套合成题。论文指出现状：机器学习代码主要活在两套组合里——PyTorch 配 NVIDIA GPU，JAX 配 Google TPU。在两者之间搬仓库，意味着要跨框架、跨硬件地重建并测试。
任务形式可以压成三句话：
- 输入一个 PyTorch 仓库；
- 输入一台干净的 TPU 机器；
- 输出一个 JAX 仓库，按作者设定的评分标准判定是否通过。
关键设计有三点：
- 判定锚在“源仓库已发表的结果”上，并由作者做认证与校准。也就是说，不是看代码像不像 JAX，而是看迁移后能不能复现原来的数字。这一点决定了基准不容易被“翻译式改写”糊弄。
- 覆盖整个仓库，而不是单个函数或单个模型文件。跨框架、跨硬件，天然是长程任务：依赖、训练循环、数据管线、随机性、并行策略都得处理，论文也把它描述为长程且有挑战。
- 环境是干净 TPU 机器，排除“本机碰巧能跑”的干扰。
按论文任务定义整理的评测流程（非原文代码）：
# XStack 单次评测流程（依据论文任务定义整理）
repo = load_pytorch_repo(task) # 输入：PyTorch 仓库
env = clean_tpu_machine() # 输入：一台干净 TPU 机器
out = agent.run(repo, env) # 智能体交付 JAX 仓库
score = grade(out, reference=task.published_result) # 对照源仓库已发表结果
passed = score.meets(criteria)
这套设计的好处是任务本身就是真实需求：迁移成功就能把代码解放到另一套硬件上，评测结果和工程价值是同一条线，不存在“刷分很行、上手没用”的落差。
关键数字
原文只给通过率，没给相对提升幅度，因此下表不补算差值。
| 数据集 | 指标 | 系统 | 结果 |
|---|---|---|---|
| XStack | 仓库迁移通过率 | Claude Opus 5 | 75% |
| XStack | 仓库迁移通过率 | GPT-5.6-sol | 45% |
| XStack | 仓库迁移通过率 | 其余所有智能体 | 至多 40% |
三点读法：
- 75% 不是“基本可用”。剩下四分之一是整仓库级别的失败，通常意味着训练跑不完，或者跑完了但结果对不上。
- 45% 说明第二梯队与第一名之间有清晰断层，差距不是靠多试几次就能抹平。
- 其余所有智能体至多 40%，说明这不是“随便接个强模型就行”的任务；工具链、上下文管理、报错回环都会影响最终能否交付。
局限与前提
- 框架边界明确：只覆盖 PyTorch/NVIDIA 与 JAX/TPU 这两套组合。其它框架组合是否同样难，摘要没有给结论。
- 准入前提：评分锚在源仓库“已发表的结果”上，且需作者认证与校准。没有可复现发表结果的仓库，进不了这个基准。
- 硬件前提：需要干净的 TPU 机器。个人开发者没有 TPU 访问权，就只能读分数，不能自己刷榜。
- 作者自己的结论很克制：智能体迁移“仍不可靠”，XStack 是让跨框架、跨硬件迁移变得可测量的一步。摘要层面没有给失败模式的分类统计，也没有成本或延迟数据。
- 通过率是判定式结果，不衡量代码可维护性、风格与后续改动成本。迁移能过，不等于迁得干净。
能不能用
论文声明发布 XStack（原文为“We release XStack”），但摘要未给出代码仓库地址，也未涉及模型权重——这类基准通常只发布任务与评测代码。要动手，先看两个入口：arXiv 摘要页 与 ar5iv 全文。
本地复现的最低条件：
- 能访问 TPU 机器，且环境可清空重建；
- 准备待迁移的 PyTorch 仓库，并确认它有可对照的已发表结果；
- 按论文评分标准实现或接入判定脚本，包含结果认证与校准环节；
- 给智能体配长程执行能力：跑训练、读日志、改代码、重跑。
适用人群很具体：做框架迁移工具链的团队，以及要给编程智能体做回归测试的团队。不适合想找“一键转框架”脚本的读者——75% 的上限说明现在还做不到无人值守。如果你只想判断“该不该把这件事交给智能体”，这份基准给出的答案是可测的：先挑一个有已发表结果的中等仓库，跑一次端到端迁移，用能不能复现数字来定，而不是看代码写得多像 JAX。