ScarfBench 给 AI 编码代理划线：企业 Java 迁移不能只看能否编译

IBM Research 6 月 30 日发布 ScarfBench，测的是一件很具体、也很难讨巧的事：AI 编码代理能不能把企业 Java 应用在 Spring、Jakarta EE、Quarkus 之间完成跨框架迁移。

最扎眼的数字是：即便是当前表现最强的代理，行为成功率也低于 10%。

这和很多人对 AI 编码工具的直觉不太一样。现在的代理已经能改不少代码，也经常能把项目跑到 build pass。但企业迁移的验收标准不是“看起来改完了”，而是构建、部署、行为都要过关。

这才是 ScarfBench 有意思的地方。它不是再做一个泛软件工程榜单，而是把 AI 拉到企业 Java 现代化的老问题里：旧系统能不能换框架，同时守住原来的行为。

ScarfBench 补的是迁移评测缺口

过去两年，很多 AI 编码评测更偏向修 bug、补函数、改测试。SWE-bench 这类基准推动了代理能力竞争，但企业框架迁移不是同一类题。

迁移 Spring、Jakarta EE、Quarkus 时，代码只是表层。依赖注入、持久化配置、查询语句、Web 层描述、构建脚本、容器启动方式，都会被牵动。哪怕 Java 文件改对了，配置错一处，应用也可能启动不了。

ScarfBench 的口径更接近企业验收。它不主要拿生成代码和参考代码做静态比对，而是看迁移后的应用能不能构建、部署，并通过专家测试验证行为。

这个设计对企业 Java 架构师更有用。因为真实迁移交付时，老板和业务方不关心 AI 改了多少文件。他们关心旧接口是否还按原样响应，数据库访问是否一致，应用在容器里能不能稳定启动。

换句话说，ScarfBench 把问题从“AI 会不会写代码”，推进到“AI 改完后能不能交付”。

评测结果暴露了三个短板

ScarfBench 给出的结果很直接：构建成功率高于部署成功率，部署成功率又高于行为成功率。

这意味着，只看 build pass 会高估迁移质量。项目能编译，不代表能部署；能部署，也不代表业务行为没变。这一点在企业系统里尤其要命，因为很多错误只有跑到集成环境或行为测试里才会露出来。

更麻烦的是，代理对自己是否完成任务的判断并不可靠。原文提到 Claude Code 的一个例子：它在 30 个整应用迁移中报告 29 个构建成功，但独立验证只有 22 个真正构建成功；它判定失败的那个应用，最终反而能构建。

这类误判不是小瑕疵。企业流程一旦相信代理的自我报告，人工复核就会被推迟，问题也会被推到更贵的阶段。

ScarfBench 还暴露了另一个现实：失败不只来自 Java 源码转换。代理会在配置文件、Web 层、数据库访问、服务层之间反复修改。配置文件尤其耗精力。

环境和工具链也会拖后腿。Docker 缓存不一致、端口连通、Maven wrapper、构建工具链，都可能让验证卡住。这些问题不新鲜，但它们正是企业 Java 的日常。

这也是我不太买账“一键迁移”叙事的原因。企业 Java 现代化从来不是把 A 框架的注解替换成 B 框架的注解。它更像修一张旧网，牵一发而动全身。

企业团队该把 AI 放在验证链里

对企业现代化团队来说，ScarfBench 的信号不是“别用 AI”。更准确的判断是：AI 可以进入迁移流程，但不能站到验收流程的终点。

比较现实的做法，是把 AI 编码代理放在前半段。让它生成迁移草稿、定位依赖冲突、批量改配置、补测试入口。后半段必须交给自动化测试、构建验证、部署验证和架构师复核。

最该调整动作的是两类人。

企业 Java 架构师和现代化团队，不宜只拿“代码生成能力”做采购依据。试点时应该要求供应商给出可审计的验证链：改了什么，为什么改，在哪一步失败，是否真的部署成功，哪些行为测试通过。

AI 编码代理开发者也要改重心。单纯提升生成代码的漂亮程度不够。更重要的是让代理学会处理依赖、配置、环境和工具链问题，并且减少错误自报。

这里还有一个限制要说清。ScarfBench 覆盖了三大 Java 生态，也有 204 个迁移任务，但它仍然不等于每家企业的遗留现场。

很多公司的 Java 应用更不干净。旧版 Maven 插件、内部镜像仓库、历史数据库脚本、手写 XML、框架混用、没人敢删的配置，都可能让迁移难度继续上升。

所以接下来最该看的，不是谁在榜单上小幅领先。更关键的是两个变量：代理能否把自我报告变成可验证证据；企业能否把 AI 迁移纳入现有 CI、容器和测试体系。

回到开头那个低于 10% 的行为成功率，它不是说 AI 编码代理没用。它说明边界还在。能编译只是第一道门，守住旧行为才算真正交卷。