Automating Android Build Repair: Bridging the Reasoning-Execution Gap in LLM Agents with Domain-Specific Tools
该论文提出了包含 1019 个真实案例的 Android 构建错误基准 AndroidBuildBench，并设计了结合领域专用工具的 LLM 智能体 GradleFixer，通过“工具桥接”策略将通用 Shell 命令替换为领域感知抽象，成功将 Android 构建错误的修复率提升至 81.4%，有效弥合了大模型高层推理与底层执行之间的差距。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
这篇论文讲述了一个关于如何让人工智能（AI）学会修好 Android 手机应用的故事。
想象一下，你开了一家非常繁忙的手机应用工厂（Android 开发）。每天都有成千上万种应用在这里生产。但是，这个工厂有个大毛病：机器经常卡住，产品造不出来（构建失败）。
以前，如果机器坏了，得靠经验丰富的老工匠（程序员）一个个去检查、去修。现在，我们想请一位超级聪明的 AI 助手（大语言模型，LLM）来帮忙修机器。
这篇论文发现，虽然这位 AI 助手脑子很灵光（懂得很多理论知识），但让它直接上手干活时，它却经常手忙脚乱，把问题搞得更糟。
为了解决这个问题，作者们做了一件很聪明的事：给 AI 换了一套“专用工具”。
1. 核心问题：AI 为什么“眼高手低”？
想象一下，你让 AI 去修一台复杂的机器。
- 通用工具（Shell）：就像给 AI 一把万能工具箱，里面全是螺丝刀、锤子、扳手，但没有说明书。AI 知道“需要拧螺丝”，但它不知道具体该用哪把螺丝刀，也不知道该往哪个方向拧。结果就是，它可能拧错了地方，或者把螺丝拧断了。
- 现状：在修 Android 应用时，AI 往往被允许使用这种“万能命令行”（Shell）。它能读懂错误日志，知道大概哪里出了问题，但在执行具体操作（比如切换 Java 版本、重新编译）时，它经常因为指令太复杂、步骤太多而失败。
论文发现：AI 其实懂怎么修，但它不会用通用的工具把想法变成行动。这就是所谓的“推理与执行之间的鸿沟”。
2. 解决方案：GradleFixer（给 AI 配了“智能遥控器”）
作者们没有让 AI 继续在那堆杂乱的通用工具里翻找，而是给它设计了一套专用的“智能遥控器”（Domain-Specific Tools）。
这就好比：
- 以前：你让 AI 去修车，它得自己找扳手、找千斤顶，还得知道怎么把千斤顶顶在正确的位置。
- 现在：你给 AI 一个一键启动按钮（
run_build），一个一键换油按钮（change_java_version），和一个一键诊断按钮（run_gradle）。
这种“工具桥接”（Tool Bridging）策略有两个神奇的效果：
- 简化操作：AI 不需要再纠结复杂的命令语法，只需要按按钮。就像你不需要知道怎么发电，只需要按开关。
- 防止乱跑：专用工具限制了 AI 能做的事情，让它只能做“修车”相关的事，不会去乱拆别的零件。
结果：用了这套专用工具的 AI（叫 GradleFixer），修好问题的成功率从普通的 60% 多飙升到了 81.4%！甚至，用一个小一点的 AI 模型配上专用工具，比用一个大模型配通用工具还要厉害，而且更省钱。
3. 新工具：AndroidBuildBench（AI 的“练功房”）
为了训练和测试这个 AI，作者们还建了一个专门的**“练功房”**（Benchmark），叫 AndroidBuildBench。
- 以前：大家测试 AI 修代码，通常是看它能不能修好 GitHub 上的某个 Bug。但这就像让 AI 去修“已经坏掉的汽车”，而不是修“正在组装时卡住的流水线”。
- 现在：这个“练功房”收集了 1019 个真实的 Android 构建失败案例。
- 这些案例来自 43 个真实的开源项目。
- 关键点：每个案例都配好了“正确答案”（因为这是从代码提交历史里找到的，后面肯定有人修好了）。
- 这就好比给 AI 出了一套有标准答案的试卷，让它反复练习，直到它能独立把流水线修好。
4. 生动的案例对比
论文里举了几个有趣的例子，展示了“通用 AI"和“专用 AI"的区别：
案例一：缺了一个参数
- 通用 AI：看到报错说“缺参数”，它试图在底层文件里硬塞一个参数，结果越改越乱，最后卡死。
- 专用 AI：它像侦探一样，顺着代码的“链条”一步步往上找，发现是顶层函数没传参，于是它系统性地把所有相关函数都改了一遍，一次性修好。
案例二：被假警报误导
- 通用 AI：看到日志里有个关于"Java 版本”的警告，就以为是大问题，开始疯狂降级版本，结果把系统搞崩了。
- 专用 AI：它知道那个警告只是“红鲱鱼”（假线索），它直接调用专用工具去查真正的错误原因（数据绑定错误），一步步解决，最后成功。
5. 总结与启示
这篇论文告诉我们一个重要的道理：
在让 AI 干活时，光给它一个“聪明的大脑”是不够的，还得给它一套“趁手的工具”。
- 不要指望 AI 能像人类专家一样，在复杂的命令行里自由发挥。
- 要把复杂的任务封装成简单的、像 API 一样的按钮。
这对未来的意义：
这意味着，未来我们不需要非得用那种超级昂贵、超级大的 AI 模型。只要给小一点、便宜一点的 AI 配上专业的工具，它就能在特定领域（比如修 Android 应用）表现得比那些“什么都会但什么都不精”的大模型还要好。
这就好比：你不需要一个会造飞机的天才来帮你拧螺丝，你只需要一个拿着电动螺丝刀的熟练工，效率更高，成本更低。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。