从排行榜到模型画像：面向智能体编码的大语言模型深度评估
内容提要
JetBrains研究团队提出一种超越“解决率”的编码智能体评估方法，从结果、效率、补丁质量和过程四个维度分析模型轨迹。对比Claude Opus 4.7和Gemini 3.5 Flash发现，两者解决率相近但行为差异显著：Opus诊断强但验证不足，Gemini验证好但易冗余和幻觉。该框架旨在构建模型画像，优化模型选择与智能体设计。
延伸解读
解决率之外的隐藏差异
文章指出，两个模型在解决率上相同，但行为差异显著：Claude Opus 4.7平均184步、成本2.79美元，而Gemini 3.5 Flash平均271步、成本仅1.24美元。这说明解决率无法反映效率、成本和过程质量。对于实际应用，选择模型不能只看最终通过率，还需考虑运行成本和轨迹特征，否则可能忽略重要的性能差异。
失败模式的细分价值
传统评估将失败视为单一结果，但轨迹分析显示失败可能发生在定位、诊断、实现或验证等不同阶段。例如，两个模型在216个共同失败任务中，超过85%至少部分识别了根因，但未能完整修复。这种细分有助于针对性地改进：若问题在定位，可优化导航；若在实现，则需加强完成度。这比单纯提高解决率更具指导意义。
模型画像与选择权衡
通过多维度评估，文章构建了模型画像：Opus诊断强但验证不足，Gemini验证好但易冗余和幻觉。在更广模型对比中，GPT-5.5解决率最高且始终验证，但补丁质量不如Opus；Qwen 3.6 27B FP8成本极低但解决率低。这提示用户应根据任务类型和成本预算选择模型，而非仅依赖排行榜。
评估方法的局限
文章强调，模型画像基于特定Junie脚手架，不能泛化为模型固有属性。LLM评判依赖单一黄金补丁，可能对合法但不同的解决方案产生偏见。因此，这些评估结果应视为诊断信号而非绝对真理。用户在使用时需结合具体场景，谨慎解读，避免过度依赖单一评估框架。
Q&A
为什么说仅用解决率评估编码智能体不够全面？
解决率只显示任务是否通过，但无法揭示模型如何达成结果，比如效率、补丁质量和过程。两个模型可能解决率相同，但行为差异巨大，如步骤数、成本和补丁质量。
JetBrains提出的编码智能体评估框架包含哪些维度？
该框架从四个维度评估：功能结果（是否解决）、执行效率（成本、时间）、补丁质量（是否聚焦、简洁）和过程质量（探索、实现、验证过程）。
Claude Opus 4.7和Gemini 3.5 Flash在解决率相同的情况下，行为有何不同？
两者解决率相近（51.1% vs 48.6%），但Opus平均184步、成本2.79美元，Gemini平均271步、成本1.24美元。Opus诊断强但验证不足，Gemini验证好但易冗余和幻觉。
在评估中，为什么说失败也可能发生在不同阶段？
失败可能发生在定位代码、识别根因、实现修复或验证结果等不同阶段。例如，模型可能找到了根因但实现不完整，或验证不足。分析轨迹可以区分这些失败模式。
Claude Opus 4.7的主要优势和弱点是什么？
优势是诊断能力强，能识别模糊缺陷的根因；弱点是完成度不足，有时跳过验证，或未遵循现有代码模式，导致补丁不完整。
Gemini 3.5 Flash的主要优势和风险是什么？
优势是验证能力强，更常运行可执行检查并利用反馈；风险是收敛性差，容易冗余搜索，且幻觉率较高（37.3%的运行有中度或严重幻觉），补丁可能超出范围。
在更广泛的模型对比中，GPT-5.5、Opus、Gemini和Qwen各自的特点是什么？
GPT-5.5解决率最高（51.5%）且总是执行验证；Opus补丁质量最好；Gemini成本低但幻觉和冗余较高；Qwen 3.6 27B FP8解决率低（38.9%）但成本极低，仅为GPT-5.5的3%。
该评估框架的局限性有哪些？
局限性包括：基于特定Junie脚手架，不能泛化到模型本身；LLM评判是诊断信号而非绝对真理；依赖单一黄金补丁，可能对有效但不同的解决方案评分偏低。
