✨ 要点🔬 技术摘要
想象一下，你拥有一栋非常古老但建造精良的房子。它已被一个家庭居住了几十年，完美地满足了他们的需求。但社区正在发生变化：旧道路（旧的软件框架）正在被铺设覆盖，而新的、更快速的高速公路（现代框架）正在建设中。这个家庭希望搬动他们的家具，并保持日常作息完全不变，但他们必须搬进一栋建在完全不同地基上的房子，其管道、电路和门把手都截然不同。
这就是SCARFBENCH 试图解决的问题。
问题：搬动整栋房子，而不仅仅是粉刷它
在计算机软件领域，许多大公司运行其系统所依赖的“Java”是一种流行的编程语言。这些系统通常构建于三种特定的“框架”之上（可将它们视为不同的建筑风格或蓝图）：Spring 、Jakarta EE 和Quarkus 。
随着时间的推移，公司希望从一种风格切换到另一种风格，以节省成本或提升运行速度。但你不能仅仅更换油漆；你必须搬动整栋房子。
挑战所在 ：这不仅仅是更改几个词语。你必须重写房屋的布线方式、门的开启方式以及水流方式，同时确保屋内的家庭在日常生活中的体验丝毫不受影响。现状 ：专家称这极其困难。直到如今，仍没有人拥有有效的方法来测试人工智能（AI）能否胜任这项工作。
解决方案：SCARFBENCH（“搬迁测试”）
作者们创建了一个名为SCARFBENCH 的大型测试。你可以将其视为软件的“搬迁模拟器”。
设置 ：他们选取了 34 栋不同“房屋”（软件应用程序），这些房屋最初均以一种风格（例如 Spring）建造。目标 ：他们要求 AI 代理（智能计算机程序）以另一种风格（例如 Quarkus 或 Jakarta）重建这些完全相同的房屋，同时保持家庭的日常作息（软件的行为）完全不变。验证 ：他们并未仅仅询问 AI“你完成了吗？”，而是建立了一套严格的“口试”（测试套件）。新房屋必须：
通过建筑检查员（编译通过）。
点亮灯光并通水（部署成功）。
让家庭像以前一样从前门进入、坐在客厅并打开电视（通过行为测试）。
结果：AI 仍在学会如何搬迁
研究人员测试了当今可用的五种最智能的 AI 编程代理。以下是他们的发现：
得分很低 ：即使是最优秀的 AI，也仅能成功完美搬迁约**12% 到 15%**的房屋。“虚假成功”的陷阱 ：许多 AI 能够建造出在纸面上看起来不错、甚至能点亮灯光（编译和部署成功）的房屋，但当家庭尝试使用时，门打不开或水不通。AI 能够翻译蓝图的“文字”，却无法理解房屋的“逻辑”。某些搬迁更难 ：从一种风格迁移到另一种风格的难度各不相同。迁移到Jakarta 风格最为困难；在超过一半的尝试中，AI 甚至未能完成房屋的建造（编译）。一次成功 ：在 204 项不同的搬迁任务中，仅有一项 由 AI 完美完成，新房屋的功能与旧房屋完全一致。
为何这很重要
这篇论文并非断言 AI 无用。它指出，虽然 AI 在编写代码方面日益精进，但在重构 复杂系统方面仍然表现糟糕。这就像拥有一个能写诗的机器人，但如果你让它将整个厨房搬进新房子并保持冰箱正常运转，它可能会把冰箱放进卧室。
作者们发布了这个“搬迁模拟器”（基准测试），以便其他研究人员能利用它，在未来更好地教导 AI 如何完成这些复杂的搬迁任务。他们实质上是在说：“这是一把标尺；用它来检验你的新 AI 是否真的能搬动整栋房子，而不仅仅是粉刷墙壁。”
简而言之 ：SCARFBENCH 是一次现实检验。它表明，虽然 AI 擅长处理小任务，但将完整的软件系统从一个现代框架迁移到另一个框架而不破坏其功能，仍然是一项需要人类级理解力的工作，而当前的 AI 尚未达到这一水平。
技术摘要：SCARFBENCH
问题陈述
企业级 Java 在软件基础设施中仍占据主导地位，许多应用程序的生命周期已远超其原始架构假设。尽管现代化改造往往由弃用压力以及降低内存开销、提升云弹性等非功能性目标所驱动，但将这些应用程序在不同框架间（特别是 Spring、Jakarta EE 和 Quarkus 之间）迁移是一项复杂且充满风险的工程。
当前的软件工程基准测试主要评估在固定框架栈内的缺陷修复、功能实现或语言版本升级。它们大多未能衡量跨框架应用重构 ，这是一项超越局部 API 替换的任务。成功的迁移需要协调构建配置、依赖注入、持久化、请求处理及部署等方面的变更，以保留应用程序的行为。现有的基准测试通常假设保留底层编程模型已足够，然而当在具有不同运行时模型和惯用法的框架之间迁移时，这一假设并不成立。
方法论：SCARFBENCH
作者提出了SCARFBENCH （自包含应用重构基准），这是一个旨在评估大语言模型（LLM）智能体执行行为保持型跨框架迁移能力的基准测试。
基准构建
范围 ：该基准包含 34 个应用系列，分别在 Spring Boot、Jakarta EE 和 Quarkus 三个框架中实现。结构 ：分为两个层级：
聚焦层级 ：29 个自包含应用，隔离特定的架构层（依赖注入、持久化、表现层、基础设施、业务领域），并基于 Java 规范请求（JSRs）构建。完整应用层级 ：5 个更大、更真实的开源系统，整合了上述各层，用于测试跨层耦合及端到端工作流。
变体 ：这些应用生成了 102 个特定于框架的变体（跨越 1,946 个源文件和测试文件，包含约 151K 行成对的 Java 代码）。任务 ：该基准定义了 204 个定向迁移任务（例如 Spring → \to → → \to → 真实依据 ：专家级 Java 开发人员为每个应用系列手动实现了所有三个框架的变体，确保存在行为等效的实现以供验证。
评估协议
智能体 ：评估了五个最先进的编码智能体：Claude Code (Opus 4.6)、Gemini CLI (Gemini-3.1 Pro)、Codex (GPT-5.4)、Opencode (GLM-5.1) 和 Qwen CLI (Qwen3.5-397B-A17B)。执行框架 ：一个容器化框架分三个连续阶段评估候选方案：
编译 ：候选方案必须成功构建。部署 ：应用程序必须在容器化运行时中启动并发出就绪信号。行为测试 ：候选方案必须通过一套由 1,331 个专家编写的行为测试。
判据 ：正确性由一个框架中立的行為判据决定。判据不使用单元测试（因为它们本身也需要迁移），而是利用 Gherkin 规范具体化为 Playwright/pytest 脚本。这些测试验证外部可观察的等效性（HTTP 路由、响应负载、UI 流程及持久化状态变更）。指标 ：成功以温度参数为 0 时的 pass@1 来衡量，要求候选方案编译成功、部署成功并通过 100% 的行为测试。
主要贡献
SCARFBENCH 数据集 ：一个精心策划的语料库，包含 34 个应用系列，衍生出 102 个变体和 204 个定向迁移任务，并在容器化环境中通过 1,331 个专家编写的行为测试进行了验证。实证评估 ：对五个前沿编码智能体进行了全面评估，揭示了当前能力在系统级转换方面存在显著差距。失败分类法 ：基于对失败轨迹的专家裁决，对涵盖构建、部署和测试阶段的 13 类 recurring 失败模式进行了分类。
实验结果
评估显示，行为保持型框架迁移对当前智能体而言仍是一项重大挑战：
低成功率 ：表现最强的智能体（Claude Code with Opus 4.6）在聚焦层级迁移中的综合测试通过率仅为15.3% ，在完整应用迁移中为12.2% 。在所有 204 个定向任务中，仅有一个 由智能体生成的迁移通过了其完整的测试套件。构建/部署与行为 ：表面成功与行为正确性之间存在显著脱节。智能体经常生成能够编译和部署的代码，但无法通过行为测试。例如，在完整应用迁移中，编译成功率可达 87%，而行为成功率却降至 12%。非对称难度 ：迁移难度高度依赖于目标框架：
Spring ↔ \leftrightarrow ↔ ：最容易处理的一对。Jakarta EE 目标 ：最困难。仅有**2%**的目标为 Jakarta EE 的迁移通过了行为测试，其中 57% 在编译阶段即告失败。
提示工程 ：“基于技能”的提示（模块化指导）提高了编译和部署率，特别是在聚焦任务中，但并未显著缩小完整应用在行为正确性方面的差距。
失败分析
对失败任务的分析表明，错误超出了源代码层面的翻译。常见的失败模式包括：
构建阶段 ：依赖解析问题、过时的模块引用以及项目结构不匹配。部署阶段 ：资源/工件不匹配（例如 WAR 与 JAR 打包）、运行时配置错误（例如端口不匹配）以及依赖连接断裂。测试阶段 ：端点缺失、响应内容错误以及基础设施连接问题。
意义与主张
论文主张，虽然当前智能体能够在源代码层面可靠地翻译框架 API，但它们难以通过目标框架的运行时模型重新表达应用程序行为 。结果表明，在仓库级基准测试（如缺陷修复或版本升级）上的进展并不能干净地转移到需要在目标运行时中执行的系统级转换。
作者将 SCARFBENCH 定位为评估 LLM 在真实企业场景中“智能体”能力的必要步骤，强调真正的现代化改造不仅仅是语法替换；它需要对架构耦合、配置语义和行为保持有深刻的理解。该基准、执行框架及智能体轨迹已发布，以促进自动化软件现代化领域的进一步研究。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。