Asuka-Bench: Benchmarking Code Agents on Underspecified User Intent and Multi-Round Refinement
该论文介绍了 Asuka-Bench，这是一个旨在通过模拟真实世界的多轮迭代优化周期来评估代码智能体在 Web 开发任务上表现的新型基准测试，其中智能体基于自动化 UI 测试和自然语言反馈，对定义不明确的项目进行迭代改进，从而揭示了当前模型之间显著的性能差距。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正在雇佣一位才华横溢但有点过于刻板、甚至有些“死脑筋”的建筑师来盖房子。
旧方式（现有基准测试）
过去，测试这些建筑师就像是给他们一份完美的、长达50页的蓝图，上面列出了每一颗钉子、每一根电线和每一种油漆颜色。你要求说：“照着这个盖。”然后他们交给你一座完工的房子。如果房子与蓝图完全一致，他们就得A；如果不一致，就得F。
问题在于，现实生活并不这样运作。真正的客户很少拥有一份完美的50页蓝图。他们通常只会说：“我想要一间带厨房和睡觉地方的房子，”然后，一旦看到第一稿，他们就会意识到：“噢，其实我是想要更大的厨房，”或者“等等，门开的方向不对。”
新方式（Asuka-Bench）
这篇论文介绍了 Asuka-Bench，一种测试“代码智能体”（Code Agents，即编写软件的AI程序）的新方法。与其给AI一份完美的蓝图，研究人员会给它一个模糊且混乱的需求，比如：“做一个带有产品列表和购物车的购物网站。”
然后，他们不仅仅是对第一个结果进行评分。他们建立了一个三人团队来模拟真实的开发周期：
- 建造者（代码智能体/Code Agent）： 这是试图根据模糊需求构建网站的AI。
- 检查员（UI智能体/UI Agent）： 这是一个实际在浏览器中访问网站的机器人。它不阅读代码，而是像人类用户一样行动。它点击按钮、尝试购买商品，并检查页面是否加载。这就像是一个质量控制员走进房子，去检查门是否能正常开启。
- 客户（用户大语言模型/User LLM）： 这是另一个观察检查员行为的AI。如果检查员发现了一个问题（例如，“‘购买’按钮不起作用”），客户会将其转化为一条礼貌的便条给建造者：“嘿，按钮坏了，请修复它。”
随后，建造者会修复网站，这个循环往复进行，最多进行三轮。
“DAG”类比
研究人员还发明了一种聪明的方法来提供反馈，叫做 DAG（有向无环图）。你可以把它想象成一个食谱。
- 如果你正试图烤一个蛋糕，你不能在烤好之前就涂抹糖霜。
- 在旧的测试方法中，如果蛋糕烤糊了，检查员可能还会抱怨缺少糖霜，尽管你无法为一个烤糊了的蛋糕涂抹糖霜。
- 在 Asuka-Bench 中，系统知道先后顺序。如果“烘焙”步骤失败了，它会阻止检查员去检查“涂抹糖霜”这一步。它只会告诉建造者：“你没把蛋糕烤好。”这防止了建造者被那些尚未发生的环节所产生的投诉搞糊涂。
他们的发现
研究人员使用这种方法测试了8种不同的AI模型。以下是他们的发现：
- 有些AI更擅长修复，而有些则不然： 仅仅因为一个AI擅长构建初稿，并不意味着它擅长修复错误。有些模型构建了一个很棒的第一版，但却无法理解“客户”的笔记来修复错误。另一些模型起步很乱，但随着每一轮反馈的进行，它们变得越来越好。
- 差距巨大： 最好的模型在经过三轮修复后，大约能完美完成52%的项目。最差的模型仅能完成约8%。这是一个巨大的差异。
- 依然困难： 即便是最聪明的AI也无法完美完成每一个项目。这表明，虽然AI正在进步，但它在处理人类需求的这种琐碎、反复的互动时，仍然感到吃力。
总结
Asuka-Bench 是为AI编程员设计的一种新的“路考”。与其要求他们在一条完美笔直、空旷的赛道上驾驶（完美的蓝图），不如让他们在城市交通中驾驶，在转错弯时听从乘客的指引，并纠正航向。事实证明，能够倾听并修复错误，是一项与单纯“会直线行驶”完全不同的技能。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。