Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering
该论文指出，当前的编程基准测试与智能体软件工程（agentic software engineering）不匹配，因为它们将模型性能与系统测试框架组件混为一谈，通过依赖单一的标准答案来惩罚有效的替代方案，并且缺乏用于迭代系统改进的细粒度反馈。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
以下是关于论文《编码基准测试与智能体软件工程不匹配》（Coding Benchmarks Are Misaligned with Agentic Software Engineering）的解释，使用了简单的语言和日常类比。
核心观点：我们评判的对象错了
想象一下，你正试图判断一位厨师烹饪复杂菜肴的水平如何。
目前，我们测试编程“智能体”（即编写软件的 AI 系统）的方式就像是这样：你给厨师一份预先写好的食谱（“参考解决方案”）。厨师尝试烹饪这道菜。如果最后的成品看起来与食谱书中的图片完全一致，厨师就会获得满分。如果厨师做出一道美味、健康且富有创意的版本，虽然味道更好但外观略有不同，他们却会得到低分。
本文的作者认为这是一个有缺陷的系统。他们指出，我们不仅是在测试厨师（AI 模型），我们还在测试整个厨房设置（“系统框架”），其中包括炉灶、工具、食材以及指令。
核心问题：“厨房” vs. “厨师”
论文提出了一个至关重要的区别：
- 模型（厨师）： 这是生成代码的 AI 大脑。
- 系统框架（厨房）： 这是 AI 生活其中的复杂环境。它包括它使用的工具、它阅读的上下文、它遵循的规则，以及告诉它是否出错的反馈循环。
类比：
把编程智能体想象成一辆 F1 赛车。
- 模型是引擎。
- 系统框架是底盘、轮胎、空气动力学设计、维修团队以及车手的策略。
目前的基准测试就像是一场比赛，你只看最终的成绩，然后说：“这个引擎很快！”但论文指出，即使使用完全相同的引擎，如果你更换了轮胎或车手策略（即改变了框架），赛车的速度也可能快 20% 或慢 20%。
作者展示了在现实世界的测试中，改变“厨房设置”（框架）对结果的影响，与将“厨师”（AI 模型）升级到更新版本所带来的变化一样大。然而，我们目前的测试却将其视为仅仅是关于“厨师”本身的问题。
破碎系统的三个症状
论文识别了当前测试方法与现实不符的三个具体方式：
1. 模糊界限（混淆）
类比： 想象一名学生参加数学考试。他得了 80 分。我们假设这个学生很聪明。但如果这个学生用了一个计算器、一张小抄，还有一个在旁边耳语答案的导师呢？如果我们不报告他们是如何得到这 80 分的，我们就无法判断这个学生是真的聪明，还是工具起到了作用。
论文的观点： 当前的基准测试只报告一个单一的分数（例如，“模型 X 的准确率为 65%”）。它们没有告诉你使用了哪些工具或环境。这使得我们无法得知 AI 是真的变得更聪明了，还是仅仅因为“厨房”变得更好了。
2. “唯一正确答案”陷阱（单一参考）
类比： 想象你要求一名木匠做一张桌子。你有一张你想要的特定桌子的照片。
- 场景 A： 木匠做了一张坚固、美观且实用的桌子，但使用的木材纹理与你的照片略有不同。
- 场景 B： 木匠做了一张看起来和你的照片完全一样的桌子，但它摇摇欲坠，随时会散架。
目前的基准测试会给场景 B 打满分，而给场景 A 打不及格，因为它与照片不完全一致。
论文的观点： 真正的软件工程并不是关于复制某一个特定的解决方案。它是关于以最好的方式解决问题。通过强迫 AI 去模仿一个特定的补丁，我们惩罚了那些具有创造性、有效且通常更好的解决方案。我们测试的是 AI 能否“模仿”特定的补丁，而不是它能否“解决”问题。
3. 黑盒（缺乏组件信号）
类比： 想象你的汽车坏了。你把它送到修理厂，技师说：“车坏了。”这就是一个“端到端”的评分。它告诉你出了一些问题，但它没告诉你哪里出了问题。是电池？轮胎？还是引擎？
论文的观点： 当编程智能体未能通过测试时，目前的基准测试只会说“失败”。它们不会告诉你为什么。是 AI 误解了指令？是工具失效了？还是环境崩溃了？如果不了解“厨房”的哪个部分出了问题，开发者就无法修复系统。他们只能靠猜。
我们应该如何改进？
作者提出了三个改进方案：
- 报告完整的食谱： 在发布测试结果时，我们必须列出使用的每一个工具、环境和设置。我们需要知道分数是来自一个天才 AI，还是来自一个功能强大的厨房。
- 根据行为而非外观进行评分： 与其检查代码是否看起来像“黄金标准”，我们应该检查代码是否有效运行并遵循了规则（如安全检查或设计模式）。解决一个问题应该有多种方法，测试应当接受任何有效的解决方案。
- 测试局部，而非仅测试整体： 我们需要拆解系统。分别测试 AI 理解指令的能力与使用工具的能力。这有助于我们修复具体的损坏部分，而不是盲目猜测。
总结
该论文认为，我们正在尝试用为过去（简单的、单次的代码生成）设计的工具，来衡量软件工程的未来（复杂的、自主的 AI 系统）。
为了向前迈进，我们需要停止将 AI 模型视为唯一重要的因素。我们需要开始测量整个系统——工具、规则和反馈循环——因为在现实世界中，正是这些要素在完成工作。除非我们这样做，否则我们的排名和分数将会产生误导。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。