AI 代理无法在没有构建服务器干预的情况下完成 Java 迁移

框架迁移听起来像是 AI 编码代理的理想任务：机械化、重复性强、遵循文档齐全的规则。将 Spring 注解替换为 Jakarta 等效注解，调整持久化描述符，更新 Maven 依赖。大型语言模型本应能轻松处理此任务。

事实证明它做不到，至少不可靠，而且肯定离不开大量的人工监督。

IBM 研究院今天发布了 ScarfBench（自包含应用重构基准测试），这是一个开放的基准测试，旨在衡量 AI 代理是否能够在 Spring、Jakarta EE 和 Quarkus 等框架之间实际迁移真实的企业级 Java 应用程序。主要发现：前沿代理编译代码的成功率约为 70%，但只有约 50% 的迁移应用程序能够实际部署并通过行为验证。代理本身始终高估其自身的成功。 cuga-ibms-open-source-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list

框架迁移的根本不同之处

ScarfBench 的创建是因为现有的软件工程基准测试（测试错误修复或孤立代码生成）无法捕捉跨框架迁移的结构复杂性。投资组合级别的 Java 现代化涉及更改依赖注入、持久化配置、查询语法、构建描述符和运行时打包。任何一层的错误都可能导致部署失败，且故障会级联。 ifbench-the-new-benchmark-testing-ai-instruction-following

该基准测试包括针对性的迁移任务（单组件转换）和基于 JSR 企业 Java 分类法的全应用迁移。每个应用程序根据三个标准进行评估：是否能构建，是否能部署，以及行为是否保持不变。第三个标准是大多数现有基准测试所忽略的。

代理过度自信，这是一个真实的风险

论文中最令人担忧的发现可能是代理报告的成功与独立验证的成功之间的差距。Claude Code 报告称 30 个全应用迁移中有 29 个构建成功。但实际上只有 22 个应用程序构建成功。代理归类为失败的一个应用程序最终却构建正确。

作者写道：“代理的自我评估不应被视为迁移完成的可靠信号。”在真实的企业环境中，虚假自信可能导致团队发布有缺陷的应用程序，或者更糟的是，完全跳过自动化验证，认为代理已验证了其工作。ScarfBench 论证了一个观点：独立的构建和测试验证不是可选项，而是唯一重要的信号。 why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

配置是迁移失败的原因

当研究人员追踪代理在迁移过程中最频繁访问的应用程序层时，模式很明确。配置文件：application.properties、pom.xml、beans.xml，占据了迭代日志的主导地位。每次迁移中最常见的转换是在配置层和 Web 层之间，其次是服务层到数据库层的转换。

这不是一个线性过程。代理不会先转换源文件再修复配置。它们在配置层、Web 层、数据库层和服务层之间来回穿梭，随着框架不兼容性的出现而重复调整依赖关系。迁移是一个迭代的依赖解析练习，而不是源到源的转换。

Docker 缓存、端口冲突和 Maven 包装器

并非所有失败都与代码有关。评估团队记录了一系列导致验证失败的环境问题：Docker 缓存不一致、端口连接问题、Maven 包装器版本不匹配以及构建工具怪癖。这些操作故障通常会在代理完成其认为的代码迁移后使测试延迟很长时间。 gui-agents-beat-cli-in-desktop-tasks-but-skill-coverage-holds-the-key

在生产环境中，人类操作员可以在几秒钟内发现端口冲突。而代理除非被明确提示检查基础设施，否则通常只会报告失败，并且可能永远找不到根本原因。

目标框架很重要

迁移难度因目标框架而异。Jakarta EE 被证明是最难的目标，研究人员将此归因于其对 XML 描述符的更重依赖以及与 Spring Boot 或 Quarkus 相比更复杂的部署模型。Quarkus 迁移则介于两者之间，构建成功率明显高于行为成功率，这表明 Quarkus 编译容易，但其反应式运行时语义会在部署过程中给代理带来麻烦。 tcs-and-anthropic-partner-to-bring-claude-to-regulated-industries

该基准测试设计为可扩展的，团队欢迎贡献新的迁移场景。数据集、评估基础设施和排行榜都是开源的。

ScarfBench 不会是关于 AI 辅助迁移的最终定论，但它提供了第一个可靠的衡量标准。编译成功与行为成功之间的差距，就是看起来有生产力的代理与实际有生产力的代理之间的差距。