[LOADING...]

Felix Plantenberg

Felix Plantenberg 是 JetBrains 的机器学习工程师实习生，负责改进 Junie 的评估流水线。除此之外，他的工作还涉及卫星图像处理、数据分析和流程自动化。他构建并评估数据驱动的软件，背景涵盖计算机科学、管理和机器学习。 LinkedIn
[LOADING...]

Marco Damonte

Marco Damonte 是 JetBrains 的机器学习科学家。他喜欢寻找难题的答案，并指导初级科学家。LinkedIn

超越解决率

想象一下，将来自不同前沿实验室的两个大语言模型接入同一个编程智能体，结果发现它们解决的基准任务数量完全相同。如果评估到此为止，你可能会认为这两个模型可以互换，然后直接选择更便宜的那个。

在我们的一项私有基准测试中，就发生了这种情况：Claude Opus 4.7 和 Gemini 3.5 Flash 解决了相同数量的任务。但这一平局掩盖了两种截然不同的执行特征。Opus 平均使用 184 步，每次运行成本为 2.79 美元；而 Gemini 平均需要 271 步，但每次运行成本仅为 1.24 美元。最终结果相同，但两个模型达成结果的方式却不同。

这种差异在比较编码智能体时最常用的指标——解决率——中是看不到的。它衡量评估测试通过多少任务，以百分比表示。解决率回答了一个重要的问题，即智能体是否解决了任务，但关于解决方案是如何达成的，它却很少提及。

像 Junie 这样的编码智能体，不仅仅取决于其背后的大语言模型。给定一个 issue 和一个代码仓库，Junie 让模型可以检查文件、搜索符号、编辑代码、运行命令和执行测试。这些可观察的动作构成了智能体的轨迹。轨迹不会揭示模型的内部推理，但确实能展示模型如何与仓库交互。我们可以看出它是否在编辑前定位了问题、重复了相同的搜索、验证了其假设，以及最终补丁是否保持聚焦。

我们构建了一条评估流水线，既分析结果，也分析产生结果的过程。它结合了四个视角：功能结果、执行效率、补丁质量和过程质量。功能正确性仍然是起点，而额外的指标则解释最终得分背后隐藏的因素。

当前评估遗漏了什么

JetBrains Research 最近的一篇帖子描述了在最近一篇研究论文中提出的 基准意义鸿沟：基准测试衡量的是特定设置下的表现，但其分数往往被视为更广泛编码能力的证据。性能提升可能无法迁移到其他任务，即使在同一个代码库内也是如此，而且模型排名可能会随任务类型而改变。

我们的工作关注的是单次智能体运行内部的一个相关鸿沟。通过测试并不能完全描述补丁质量。两个补丁可能都实现了所需行为，但在范围、复杂性以及与现有架构的契合度方面可能存在巨大差异。例如，一个可能只改动一个相关函数；另一个可能增加辅助函数、状态、分支或不相关文件——但仍然能通过同样的测试。

失败的结果同样具有歧义。智能体可能从未找到相关代码，可能误解了原因，修改了错误的层次，只实现了部分修复，或者在没有充分验证的情况下停止。这些失败都要求采取不同的措施。例如，重复搜索可能意味着需要更好的仓库导航或更聚焦的提示。另一个例子是正确诊断了问题，却生成了不完整的补丁，这可能表明实现或任务完成环节存在问题。

成本和延迟增加了另一个维度。如上所述，两次成功的运行可能在 token 数、运行时间、模型调用和工具使用方面存在显著差异。如果任务需要广泛调查，长轨迹并不一定是坏事。重要的区别在于额外的工作是促成了解决方案，还是源自重复且无效的动作。

对于模型选择，更有用的问题是：哪种模型适合特定类型的任务、它把精力花在哪里、以及它通常如何失败。通过我们的流水线对轨迹和补丁进行细粒度分析，可以回答这些问题。

评估结果与过程

对于每个基准任务，流水线会结合 issue、仓库上下文、生成的补丁、测试结果和执行轨迹。然后，它从四个视角对运行进行评估，提出以下问题：

• 结果：补丁是否解决了任务？哪些测试通过或失败？
• 效率：运行需要多少 token、模型调用、工具调用和秒数？成本是多少？
• 补丁质量：改动是否涉及相关文件和符号，是否保持克制，并避免不必要的复杂性？
• 过程质量：智能体如何推进探索、实现和验证？它是否复现了问题、重复了工作，或者在没有测试最终改动的情况下就停止？

我们提出了一种将确定性指标与语义评估相结合的流水线。确定性层从日志和仓库数据中得出可复现的度量。这些度量包括测试结果、运行时间、token 使用量、工具调用、修改的文件和符号、代码复杂度变化、重复文件读取、未更改命令的重试以及工具失败循环。

仅靠规则无法解释每一个动作。打开一个文件两次可能是浪费，也可能是在相关编辑之后有必要的。一个大的补丁可能不够聚焦，也可能适合跨多个组件的改动。针对这些问题，LLM 评判器会从 issue、补丁、轨迹和受限的仓库上下文中接收结构化证据。它们会评估各个里程碑，例如找到相关代码、复现缺陷、识别根本原因、在补丁中解决该原因、引入不必要的复杂性以及验证结果。这种组合让我们对进展有了更清晰的认识。它不仅显示运行是否失败，还显示了失败发生在定位、实现还是验证阶段。下图展示了上述组件，这些组件内置于我们的评估流水线中。

[LOADING...]

智能体轨迹揭示了什么

我们使用该流水线，在 Junie 中比较了 Claude Opus 4.7 和 Gemini 3.5 Flash，涉及包含 523 个任务的四个基准数据集。结果如下所示：

[LOADING...]

如上图所示，Claude Opus 解决了 267 个任务（51.1%），而 Gemini Flash 解决了 254 个任务（48.6%）。两个模型在 430 个任务上产生了相同的结果：都解决了 214 个，都失败了 216 个。只有 93 个任务将它们区分开来。总体分数接近，但轨迹和补丁显示了不同的行为特征。

相同的结果，不同的轨迹

对同一任务的比较让不同的行为特征变得具体。一次 Opus 运行和一次 Gemini 运行都解决了同一个任务。两者都在第 15 步首先打开了一个相关文件，被评判为已识别出根本原因，并进行了彻底的验证。然而，到那时为止，它们的进展增量不同。Opus 在文件内进行了有针对性的搜索，并在 13 步后开始实现。Gemini 最初更广泛地检查了那个大型模块。它在第 30 步执行了第一次可执行的检查，但直到第 88 步才进行第一次生产代码编辑。Opus 用了 53 步完成，在探索、实现和验证之间切换了六次；Gemini 则需要 192 步，并进行了三十四次这样的切换。下图描绘了不同的路径。

[LOADING...]

Gemini 的额外调查部分是有用的，但它也扩大了范围，并导致了一次未被请求的改动。两次运行都通过了评估测试，并且都修改了参考解决方案所修改的相同文件和符号。Opus 没有改动其他任何东西。Gemini 的补丁还涉及另外四个文件，并在其中进行了编辑。该补丁被评估为散乱，存在显著的冗余和中度的幻觉。

这个单一的例子更多是说明性的，而非统计性的。它展示了同样的基准测试成功，既可以来自一条直接、克制的运行路径，也可以来自一条带有不必要扩张的更长路径。

失败可能发生在多个阶段

一次成功的运行通常要经历四个阶段：定位相关代码、识别根本原因、实现完整修复、验证结果。解决率将整个过程压缩为一个单一的二元结果，而轨迹分析则能显示智能体在哪里成功、在哪里不足。

由于轨迹分析能够区分这些阶段，我们可以更好地分析两个模型都失败的 216 个任务。我们可以在下图中看到分析结果。

[LOADING...]

对于两个模型，超过 85% 的运行被评估为至少部分识别了根本原因。例如，在一个任务中，两个智能体都认识到超出 token 限制的文本导致了错误，但它们选择截断文本，而不是将其拆分为有效的块。在另一个任务中，两者都修正了一个代码路径中的错误下载参数，却忽略了相邻路径中的相同问题。二元的失败判定将这些运行视为智能体从未找到相关组件的情况，尽管它们距离正确解决方案已经非常接近。

模型并非完全迷失。它们已经触及相关机制，但实现修复不完整、改动了错误的层次，或者遗漏了任务的精确契约。

这不仅仅是匹配参考补丁的问题。参考解决方案是有用的，但它并不是唯一有效的实现。一个候选方案可能改动不同的文件或架构层次，但仍然解决相同的机制。因此，结构比较需要与对诊断、完整性和验证的语义评估相结合。

从排行榜到模型画像

利用这些结果，我们可以构建特定于模型的画像，从而提供更多关于其优缺点的信息。下面我们为 Claude Opus 4.7 和 Gemini 3.5 Flash 列出了一些示例画像。

Claude Opus 4.7：诊断能力强，完成能力较弱

Opus 更有可能识别模糊缺陷的根本原因。它经常能够触及正确的机制或架构层次，并解决了 Gemini 未解决的 53 个任务。这些结果使 Opus 在主要挑战是理解不熟悉的仓库或将可见症状与其根源区分开来时，成为一个有用的起点。

主要弱点出现在定位之后。一些运行找到了正确的机制，但止步于复现测试，遗漏了相邻的分支或调用点，或者实现了一个看似合理的自定义方案，而不是遵循仓库中已有的模式。在 123 次运行中，Opus 没有执行可执行的验证，其中 68 次运行仍然解决了任务。跳过可执行验证意味着补丁的正确性从未真正得到确认，因此即使是一个已解决的任务，也带有未被发现的回归或边界情况失败风险，而这些风险只有运行代码才能暴露出来。

总体而言，Opus 的画像表明它是一个强大的诊断模型，如果能明确过渡到实现、完成和测试阶段，它会受益良多。

Gemini 3.5 Flash：验证更强，仓库根基与收敛性较弱

Gemini 更有可能运行可执行检查，并利用其输出来改进解决方案。当预期行为明确、责任组件相对清晰且反馈易于获得时，这些特性很有用。

我们发现 Gemini 的主要风险在于收敛性和仓库根基。Gemini 经常在到达相关代码后仍然继续搜索，重复等效的命令，或者花费大量步骤在构建基础设施上。它也更容易依赖未经核实的 API、依赖项、路径或测试夹具：其 195 次运行（37.3%）被评估为包含中度或严重幻觉，而 Opus 为 130 次。一些补丁超出了 issue 的范围，或包含无关的产物，80 次运行（15.3%）表现出显著或严重的冗余，是 Opus 6.5% 比率的两倍多。

总体而言，Gemini 受益于精确的任务契约、符号验证、清晰的停止规则以及对 diff 的最终审查。

更广泛的模型

我们还在更广泛的模型集上运行了该流水线。我们在相同的四个基准数据集上评估了 GPT-5.5、Claude Opus 4.7、Gemini 3.5 Flash 和 Qwen 3.6 27B FP8。下表比较了它们共同拥有的 522 个任务。同样的四个视角也区分了它们：GPT-5.5 达到了最高的解决率（51.5%），并且是唯一一个始终运行可执行检查的模型；Opus 在每一项补丁质量指标上都领先；Qwen 3.6 27B FP8 解决了 38.9% 的任务，而每次运行成本仅为 GPT-5.5 的 3%。

[LOADING...]

GPT-5.5 和 Opus 在解决率上只相差 0.4 个百分点，每次运行的成本也相差不到 1 美分，因此排行榜会把它们视为可互换。但它们的补丁并非如此：Opus 有 24.7% 的运行被评估为存在中度或严重幻觉，而 GPT-5.5 为 33.7%；Opus 有 6.3% 的运行出现显著或严重的补丁冗余，而 GPT-5.5 为 13.2%，同时 Opus 产生的轨迹是四个模型中最短的。GPT-5.5 作为回报提供的是过程纪律，因为它从不在没有可执行检查的情况下结束运行，而 Opus 在 23.6% 的运行中跳过了验证。

Qwen 3.6 27B FP8 则是第三种权衡：在解决率上落后 12.6 个百分点，并且是四个模型中识别根本原因能力最弱的，但成本足够低，一次失败的运行也花费甚少。因此，哪种模型更可取，取决于工作中成本高昂的部分是诊断、补丁审查，还是运行本身。

局限性与结论

在本文中，我们推断出了 Claude Opus 4.7 和 Gemini 3.5 Flash 的画像。这些推断基于本次评估中使用的特定 Junie 脚手架，不应被用来泛化描述模型本身。此外，LLM 评判器的评估是诊断信号而非真实基准，并且在很大程度上基于单一的参考补丁；而在编码领域，参考补丁在大多数情况下并不是唯一可行的解决方案。因此，如果有效解决方案与参考方案不同，评判器可能会倾向于给出负面评分。

解决率仍然是编码智能体评估的基础，但当它与效率、补丁质量和过程方面的证据结合时，会变得更加有用。我们的总体目标不是用另一个聚合分数来取代排行榜。我们想了解每个结果产生的原因，并利用这些模式来改进模型选择、提示设计和智能体设计。从行业角度来看，我们可以通过超越总体成功率、转向细粒度评分和行为画像，来更好地完善智能体设计。另一方面，从用户角度来看，我们现在可以帮助 Junie 用户为具体任务选择合适的模型。