JetBrains 于 2026 年 8 月 30 日发布了一份分析，介绍用于编程代理 Junie 的大型语言模型评估方法，并呼吁不要再依赖“解决率”（resolve rate）这一单一指标。该公司认为，了解代理是否通过了任务测试固然重要，但这本身无法揭示代理是如何达到结果的、耗费了多少成本，以及其代码补丁是否有限且易于维护。
这一理念源于 JetBrains 在其自有基准测试中对 Claude Opus 4.7 和 Gemini 3.5 Flash 进行的比较。两个模型解决了相同数量的任务，但 Opus 平均需要 184 步，运行成本为 2.79 美元；Gemini 则需要 271 步，成本为 1.24 美元。最终结果相同，并未反映出两者在执行路径或工具使用效率上的明显差异。
解决率隐藏了什么？
Junie 在 issue 和软件仓库的上下文中运行，允许模型检查文件、搜索符号、修改代码、运行命令和测试。这些操作构成了可以被监控的“执行路径”，但不能据此声称揭示了模型的内部思维。通过这一路径，可以了解代理是否在修改前定位了问题所在，是否重复进行搜索，是否验证了自己的假设，或者是否在未验证最终补丁的情况下结束任务。
因此，JetBrains 提议采用一个结合四个评估角度的流水线：功能结果、执行效率、补丁质量和过程质量。具体指标包括测试结果、运行时间、令牌数量、模型调用次数和工具调用次数、成本、修改的文件和符号数量、复杂度变化、重复读取文件、在结果未发生变化时重复执行命令，以及工具失败循环。
从结果到达成结果的路径
JetBrains 在比较 Claude Opus 4.7 和 Gemini 3.5 Flash 时，使用包含 523 个任务的四个基准测试验证了该方法。Opus 解决了 267 个任务，解决率为 51.1%；Gemini 解决了 254 个任务，解决率为 48.6%。两者在 430 个任务上的结果相同：两种模型共同成功完成 214 个任务，共同失败 216 个任务。实际差异仅出现在 93 个任务中，因此行为差异比排行榜上的原始差距更为重要。
在一个两种模型都成功完成的任务示例中，二者都在第 15 步打开了相关文件，找到了根本原因，并进行了全面验证。但 Opus 使用了更有针对性的搜索，并在 13 步后开始执行，在 53 步内完成任务，在探索、执行和验证之间进行了 6 次切换。Gemini 则更广泛地检查了整个单元，在第 30 步进行了首次可执行检查，直到第 88 步才首次修改生产代码，随后需要 192 步，并在各阶段之间进行了 34 次切换。
两种模型都通过了测试，并修改了参考补丁所修改的同一个文件和同一组符号。但 Opus 没有触及其他文件，而 Gemini 的补丁扩展到了另外 4 个文件；评估过程认为该补丁范围过大，包含明显重复以及一些幻觉。JetBrains 强调，这一示例仅用于说明，并不是独立的统计结果。
失败并非只有一种情况
对两种模型共同失败的 216 个任务进行分析后发现，根据评估结果，超过 85% 的案例都包含对根本原因的完整或部分识别。在其中一个案例中，两个代理都理解到文本超过符号上限导致了错误，但它们提出截断文本，而不是将文本拆分为正确的部分。在另一个案例中，它们修复了一个路径中的下载参数，却遗漏了配套路径中的同一问题。
从实际角度看，这些情况不同于代理未能找到负责的组件。原因可能是执行不完整、修改了错误的层、未遵守任务的精确契约，或者在验证前停止。因此，执行路径有助于确定需要采取的干预位置：改进仓库内导航、调整任务表述、加强修改完成度，或强制加入最终验证步骤。
用行为档案取代单一排名
JetBrains 得出结论：Claude Opus 4.7 更倾向于确定模糊缺陷背后的根本原因，并解决了 Gemini 未能解决的 53 个任务。但它的 123 次运行没有包含任何可执行验证，其中 68 个任务被视为已解决。该公司认为，这种行为可能留下与回归或边缘情况有关的未发现风险。
相比之下，当预期行为明确且负责的组件相对确定时，Gemini 3.5 Flash 更倾向于运行可执行检查，并利用其结果改进解决方案。不过，它在收敛到解决方案以及立足于仓库方面表现出问题：它会重复执行等效的搜索或命令，在构建结构上花费大量步骤，并且更依赖未记录的接口、依赖项、路径或测试装置。其运行中有 195 次，即 37.3%，被分类为包含中度或严重幻觉；Opus 则为 130 次。此外，Gemini 有 80 次运行，即 15.3%，表现出大量或严重重复；Opus 为 6.5%。
这在实践中意味着什么？
在一项更广泛的比较中，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 以相当于 GPT-5.5 运行成本 3% 的成本解决了 38.9% 的任务。
这些数字表明，模型的选择取决于成本和风险所在的位置。诊断能力更强的模型可能适合不熟悉的仓库或模糊缺陷，而在测试和反馈可用时，更严格执行验证的模型可能更好。当失败尝试的成本有限时，即使解决率较低，低成本模型也可能成为实用选择。但这一解读并不意味着某个模型在所有环境中都具有固定不变的行为。
JetBrains 警告，不应将行为档案推广到模型本身，因为这些结果依赖于 Junie 的特定架构。此外，基于大型语言模型的评估员所作的判断并非“参考真值”，而且会受到单个黄金补丁的很大影响，尽管正确解决方案可能使用不同的文件或架构层。因此，解决率仍然是必要基础，但当它附带有关效率、修改质量和工作路径的证据时，其价值会更高，而不是被简化为一个总排名。