SWEeper-Bench：让代码智能体自己发现交互式软件中的漏洞

导语

代码智能体正在从“根据需求写代码”走向“交付可以被用户使用的软件”。但对于交互式应用而言，代码看起来合理，并不意味着功能真的正常：某些缺陷只有在用户完成一连串操作后才会出现，例如进入特定页面、修改状态，再返回或执行下一步操作。传统软件工程评测通常已经告诉智能体哪里出了问题，因而没有充分检验它能否主动发现问题。

SWEeper-Bench 正是针对这一缺口设计的基准。它把“寻找未知缺陷”与“修复缺陷”放在同一个任务中，评估代码智能体是否能够独立完成从探索到验证的闭环。

核心要点

• 200 个真实任务：任务来自 200 个广泛使用的开源 Web 应用，并基于真实 bug 修复记录构建。
• 不给出明确故障描述：智能体获得代码库，以及类似“找出并修复 Focalboard 的看板分享和成员管理问题”的开放式请求，而不是现成的错误报告。
• 必须进行交互式测试：仅阅读代码往往不足以发现问题，智能体需要启动应用、设计用户操作路径，并观察浏览器中的实际行为。搜索建议界面等功能也可能只有在特定步骤组合下才暴露异常。
• 按用户体验验收：一个具备代理能力的验证器会在浏览器中检查修复结果，依据用户实际能看到和操作到的效果进行判断。
• 结果仍不理想：在 15 个前沿智能体中，表现最佳者通过率为 59.0%。轨迹分析表明，最主要的障碍是识别故障行为，而不只是编写补丁。

为什么难

发现交互型 bug 需要智能体同时具备几种能力：理解功能意图，定位相关代码，构造有信息量的操作序列，并判断界面结果是否违背预期。许多智能体能够找到相关页面或组件，却在测试停留于“页面能打开、按钮能点击”的浅层检查，未能继续执行触发缺陷所需的步骤；即使看到了异常，也可能无法把它归因到真正的问题。

这说明，自动化编码的难点正在从局部代码生成扩展到环境探索和行为推理。一个补丁是否正确，不能只看测试是否通过，还要看用户完成真实任务时是否仍会遇到故障。

意义与影响

SWEeper-Bench 为代码智能体提出了更接近生产环境的要求：智能体不仅要响应已知需求，还要主动承担质量保障责任。对研究者而言，该基准可以帮助区分“会修复明确 bug”和“能发现未知 bug”的系统；对工具开发者而言，结果也提示需要加强浏览器操作规划、异常识别、状态追踪和回归验证。

更长远地看，只有当智能体能够持续运行、探索并验证软件，开发循环才可能从“用户先发现问题、开发者再修复”转向更主动的自动化排查。SWEeper-Bench 的 59.0% 通过率也表明，这一目标尚未解决，而交互式测试能力将是下一阶段代码智能体竞争的关键。

来源：Hugging Face Daily Papers