💻 computer science

An Empirical Investigation of Multi-Trial Consistency, Trajectory Pathologies, and Reliability Rankings in Software Engineering Agents

本文提出了一种全面的多轮试验评估框架，用于评估自主软件工程智能体的连贯性、可靠性和轨迹病理特征，并通过一项试点研究证明了其操作可行性，该研究揭示了显著的基础设施审查率，并为超越单次试验成功指标奠定了基础。

原作者： Muhammad Tayyab

发布于 2026-09-22

📖 1 分钟阅读☕ 轻松阅读

原作者： Muhammad Tayyab

原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

在现代软件开发领域，庞大的代码库由工程师团队维护，他们依赖自动化工具来发现并修复漏洞。最近，新一代人工智能应运而生，能够作为自主助手，阅读这些代码库、理解问题，并尝试自行编写必要的修复程序。这些系统通常由大语言模型驱动，已在受控测试中展示出解决复杂编程任务的能力。然而，一个关键问题仍悬而未决：这些数字员工能否被信任，在每次执行任务时都保持可靠？在现实世界中，软件更新是自动部署的，如果一个助手在一次尝试中成功，但在下一次被要求执行完全相同的工作时却失败了，这会造成混乱。它引入了不可预测性，迫使人类开发者必须不断检查其工作成果，这反而抵消了自动化的初衷。核心挑战不仅在于 AI 是否能解决一个问题，而在于它能否在不产生困惑、不犯随机错误或不以破坏系统的逻辑方式改变方法的情况下，始终如一地解决问题。

一位来自巴基斯坦拉合尔工程技术大学的研究人员提出了一种衡量这种可靠性的新方法，超越了目前仅计算 AI 单次尝试成功次数的现有标准。现有的方法被称为“单次试验通过率”，它将 AI 视为参加一次性考试的学生：如果答案正确，学生就算通过，而不管该学生是否能再次解出此题。这项新研究认为，对于软件工程而言，这种方法是不充分的。相反，研究人员设计了一套严密的协议，对这些智能体进行多次重复测试，以观察其一致性。其目标是观察 AI 是否能够每次被要求时，都能以完全相同的方式导航代码库、发现漏洞并修复它，还是会在重复的审视下表现崩溃。

为了测试这一点，研究人员建立了一个大规模实验，涉及从流行开源项目中提取的一组特定真实世界编程任务。该研究计划在不同的 AI 模型和不同的软件框架网格上运行这些任务，并将每个任务重复执行五次，以获取完整的性能图景。在开展全面实验之前，研究人员进行了规模较小的“可行性试点测试”，以确保测试机制正常运行。该试点涉及在两个特定的 AI 模型和两个不同的软件脚手架系统上，对 360 次尝试进行规划。然而，其中只有 312 次尝试成功完成并被分析，另有 48 次因外部因素中断。研究人员仔细追踪了 AI 采取的每一步骤，不仅记录了成功或失败，还记录了它改变主意的次数、在使用计算机工具时犯错的频率，以及测试基础设施本身崩溃的频率。

试点研究表明，测试环境本身是脆弱的。在计划的 360 次尝试中，有 48 次被外部因素中断，例如云服务提供商超时或计算机容器意外重置。这导致了 13.3% 的取消率，这一发现凸显了运行此类复杂测试的难度。更重要的是，试点研究显示，当前的测试预算（时间限制）过短，无法产生成功的修复。由于 AI 在每次尝试中被限制在仅五轮对话或行动内，这 312 个完成的序列中没有一个实现了成功的修复。智能体将全部有限的时间都花在了尝试导航代码和理解问题上，从未达到能够应用解决方案的阶段。

尽管在这次简短的试点中缺乏成功的修复案例，但该研究成功证明了收集关于这些智能体行为详细数据的可能性。研究人员识别了 AI 在尝试与计算机系统交互时发生的特定错误类型，例如生成计算机无法理解的命令，或尝试访问不存在的文件。他们还开发了衡量“代码变更”（code churn）的新方法，用于追踪 AI 在得出最终答案前修改自身工作的程度。高水平的变更意味着智能体犹豫不决或不稳定，在没有明确计划的情况下不断重写自己的代码。此外，研究还引入了“工具失败”指标，以区分由 AI 推理能力差引起的错误与由计算机系统崩溃引起的错误。

论文结论指出，虽然这些 AI 智能体展现出了潜力，但目前的评估方法是不完整的。通过仅关注单次尝试，业界忽略了导致这些工具在现实使用中变得不可靠的“波动性”（flakiness）。研究人员认为，一个真正可靠的智能体必须能够在多次试验中一致地解决问题，而不仅仅是侥幸成功一次。试点研究证明，衡量这种一致性的必要工具已经存在，且基础设施可以处理数据收集，即便目前的 AI 模型尚未准备好通过完整测试。研究结果表明，未来的评估必须超越简单的通过或失败评分，转而包含对 AI 行程的详细日志，测量它跌跌撞撞的次数、犹豫不决的程度，以及因外部中断而无法完成任务的频率。

这项工作的终极目标是为自动化软件工程建立一种新的信任标准。正如一名人类员工会因为表现反复无常和不可靠而被解雇一样，AI 助手也必须证明它能够以同样的稳定性履行职责。这项研究并不声称目前的 AI 模型已经解决了自动化修复的问题；事实上，试点数据表明，在严格条件下成功修复次数为零。相反，它提供了一个如何正确测试这些系统的蓝图。通过定义一致性的新指标并追踪导致失败的具体病理特征，研究人员为对人工智能进行更诚实、更严谨的评估奠定了基础。未来的路径包括运行具有更长时限和更强大模型的全规模实验，以观察一致性是否会提高，或者智能体是否只是在错误方面变得更加复杂。在此之前，业界必须认识到，在复杂的软件维护世界中，单次成功的修复不足以保证安全性或可靠性。

技术摘要：超越 Pass@1 —— 一种面向 SWE Agent 的前瞻性评估协议

问题陈述

由大语言模型（LLM）驱动的自主软件工程（SWE）智能体在如 SWE-bench 等仓库级基准测试中展现了显著的能力。然而，主流的评估方法几乎完全依赖于单次尝试解决率（pass@1）。在现实世界的软件维护和持续集成/持续部署（CI/CD）流水线中，单次成功的调用不足以作为软件可靠性的代理指标。如果一个智能体在一次运行中成功，但在后续相同的运行中出现失败、引入回归或进入无效语法循环，则会产生非确定性的“易变性（flakiness）”并导致高昂的人工验证成本。

现有文献缺乏一种标准化的、仓库层级的评估协议，能够共同评估以下维度：

严格的多轮一致性（即所有重复执行均成功的概率，这不同于至少有一次成功的概率）。
中间过程层面的病理特征（例如：代码变更量、工具失败率）。
基础设施损耗（区分智能体自身的失败与外部 API 或环境故障）。

方法论与实验协议

本文提出了一种前瞻性评估协议（Prospective Evaluation Protocol），旨在用于大规模因子实验，并报告了一个用于验证基础设施的可行性试点（Feasibility Pilot）。

1. 实验设计

完整协议（前瞻性）： 一个包含 7,200 个回合（episodes）的因子网格，涉及：
- 任务： 来自 SWE-bench Verified 的 120 个分层任务（8 个仓库，3 种复杂度等级：短、中、长）。
- 模型： 6 种当代 LLM（包括 Gemini 3.6/3.7 Flash、Claude 3.5 Sonnet、GPT-4o、Grok-2、Qwen 2.5 Coder）。
- 脚手架（Scaffolds）： 两种智能体框架：SWE-agent (ACI) 和 OpenHands (CodeAct)。
- 试验（Trials）： 每个配置进行 5 次独立的重复试验（ $k=5$ ）。
可行性试点（已完成）： 在 4 种配置（Gemini 3.6/3.7 Flash 分别运行于 ACI 和 CodeAct）下，使用 30 个任务进行的子集研究，每次 $k=3$ $k = 3$ 次试验。
- 约束条件： 由于在插桩过程中受到 API Token 预算的限制，试点研究被限制为每个回合 5 轮预算（对比原计划的 30 轮）。
- 范围： 计划 360 个回合；完成 312 个有效回合；48 个回合（13.3%）因基础设施问题被截断（censored）。

2. 正式指标公式化

论文引入了特定的数学定义，旨在超越二元化的通过/失败评分：

经验单次尝试通过率 ( $\hat{p}_{attempt}$ )：所有单次尝试的平均成功率。
**严格多轮一致性 ($AllPass@k $)**：针对特定任务，$ $) * * ：针对特定任务，$ k$ 次试验全部成功的概率。定义了两种变体：
- 条件型（Conditional）： 排除任何一次试验被截断的组。
- 保守型（Conservative）： 将截断的组视为失败。
完成率 (CR, $JCR_k$ )：量化基础设施损耗的指标，防止因忽略掉落运行而导致易崩溃的配置看起来更可靠的现象。
补丁变更率 (Patch Churn Ratio, PCR)：一种过程指标，量化“回退或瞬态结构修改行为”。它衡量最终补丁大小与所有回合中累计编辑总量（增加 + 删除行数）的比率。
智能体诱发工具失败率 (Agent-Induced Tool Failure Rate, ATFR)：区分智能体错误（语法崩溃、参数格式错误、超时）与合法的测试断言失败或外部故障。
多目标帕累托评估：系统通过向量 $\langle \hat{p}_{attempt}, AllPass@k, CR, ATFR, PCR \rangle$ 进行评估，而非单一的加权标量。

3. 执行控制

隔离性： 每个回合都在从固定镜像摘要（pinned image digest）实例化的全新 Docker 容器中运行。
随机性： 试验之间的差异仅在于随机 Token 采样（由商业 API 端侧提供）。
成功标准： 遵循官方 SWE-bench 机制（所有 FAIL-TO-PASS 测试必须通过；零 PASS-TO-PASS 回归）。

关键结果（可行性试点）

由于受限于 5 轮预算，试点研究在所有配置下的成功修复率为零（ $\hat{p}_{attempt} = 0.0\%$ ）。因此，该试点并未提供关于模型优越性或可靠性衰减的经验证明。相反，其结果侧重于基础设施的可行性与遥测数据：

基础设施损耗： 研究观察到试点阶段存在 13.3% 的截断率：
- 8.9% 是由于提供商 API 超时。
- 4.4% 是由于容器/环境套接字重置。
- 意义： 这验证了报告完成率（CR）而非默默丢弃未完成试验的必要性。
轨迹病理特征：
- 错误分类学： 78 个错误事件被归类为四类：工具参数格式错误、路径/文件未找到、子壳（subshell）语法崩溃以及命令超时。
- 脚手架差异： OpenHands (CodeAct) 的轨迹表现出更多的路径错误和子壳语法崩溃（可能是由于复杂的 Shell 管道操作）；而 SWE-agent (ACI) 避免了子壳错误，但在进行精确字符串替换时产生了更多的参数键值对格式错误。
过程指标：
- 中位 补丁变更率 (PCR) 在所有配置中均为 0.00。这归因于 5 轮的限制，迫使智能体将预算消耗在仓库导航（如 grep, findfile）上，而非迭代编辑和打补丁。
- ATFR 通常较低（中位数为 0.00），仅有一个配置（Gemini 3.7 Flash + SWE-agent）显示出 0.10 的中位 ATFR。

意义与主张

论文明确阐述了其适度的研究范围与贡献：

协议规范： 它定义了一个完整的、可复现的实验设计，用于 7,200 个回合的因子评估，解决了标准化多轮次 SWE-agent 基准测试的空白。
指标形式化： 它建立了严谨的数学定义，涵盖了一致性（$AllPass@k $）、过程健康度（PCR, ATFR）和基础设施可靠性（CR），超越了$ pass@1 $和$ pass@k$（衡量是否能找到至少一个解）的局限性。
操作验证： 可行性试点证明了轨迹级遥测数据收集的操作可行性，并强调了基础设施截断（13.3%）对评估完整性的关键影响。
概念框架： 论文通过概念性图示（图 1–3）展示了严格的多轮一致性如何可能比单次尝试指标产生一个“可靠性衰减悬崖”，以及过程感知评估如何改变排行榜排名。

局限性与未来工作：
作者强调，由于 5 轮截断导致的 0% 成功率，该试点数据并未展示经验性的排行榜反转或模型优越性。关于多轮一致性和可靠性衰减的实质性经验测量，保留给全规模的 30 轮、7,200 回合基准测试。未来的工作将执行这一完整规模，以量化一致性衰减并评估自动化回溯机制。