Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase

在 Databricks 数百万行代码库上对编码代理进行基准测试 | Databricks 博客

跳至主要内容

公告

2026 年 7 月 8 日

在 Databricks 数百万行代码库上对编码代理进行基准测试

作者：Vinay Gaba、Ankit Mathur、Rishabh Singh、Patrick Wendell 和 Matei Zaharia

在 Databricks，随着我们积极采用 AI 进行工程开发，我们的软件构建方式正在迅速变化。过去一年中，代码编写模型和工具链的格局迅速扩展，为开发者提供了前所未有的选择。随着选项增多，理解哪些编码代理在真实世界编码任务中表现最佳，以及任务性能如何随价格变化变得越来越重要。

本文分享了我们在 Databricks 构建的内部编码基准测试结果和方法论，该基准测试通过实际编码任务评估工具表现。这些任务涉及对涵盖多种流行语言（Python、Go、TypeScript、Scala 等）的数百万行代码库进行修改，任务和解决方案均经过仔细审核以确保准确性。这并非旨在全面覆盖所有情况，但该测试已揭示出关键洞察，使我们的工程团队在使用编码代理时效率显著提升。以下是我们基准测试中模型和工具链的整体评分：

图 1：我们基准测试中的成本与性能关系

我们分析的主要结论包括：

• 编码任务的帕累托前沿（即给定成本下的最佳质量）包含来自 OpenAI、Anthropic 和开源模型的解决方案。这意味着目前，只有混合使用不同工具才能实现前沿性能。

• 开源模型，特别是 GLM 5.2，现在能够处理最高难度的任务。

• 模型的每令牌价格并不能准确反映端到端任务的实际成本。更大的模型可能在令牌效率上表现更优，总体成本更低。

• 模型调用的工具链对成本和质量有显著影响。在许多情况下，像 Pi 这样简单的工具链在我们的工作负载中表现最佳。

让我们对每个结论进行更深入的探讨。

模型大致聚类为三个“能力层级”

具体结果的微小差异在实际任务中往往相互抵消。我们更关注有助于判断不同任务应使用哪些模型的主题性规律。事实上，结果显示出模型和工具链在三个能力层级上存在明显聚类。

图 2：我们的整体结果中出现了三个明显的能力层级，每个层级中有效的模型存在细微差别

在性能的高端，我们发现最智能的模型在解决各类问题时都非常高效，但成本极高。中等和低智能模型在常见任务中仍然表现出色，且在许多情况下成本显著更低。

日常工作中，工程师需要处理大量复杂程度差异显著的任务：像切换标志位或更新配置这类常见运维任务不需要极高智能的模型，但更深入的设计探索则需要。然而，过去我们默认使用最昂贵的模型。基于此分析，我们决定将更多工作负载分配给 Haiku 和 GPT 5.4 Mini 类模型。

开源模型已准备好用于编码

GLM 5.2 一经发布就引发了广泛关注，我们的测试结果表明 GLM 已经成为许多开发者的主力模型。它在能力层级中位列顶级，质量指标与 Opus 4.8 统计上并列，但每任务成本仅为 1.28 美元，显著低于 Opus 的 1.94 美元。

GLM 的质量评分与我们内部开发者在日常开发中试用 GLM 后的反馈高度一致。由于其在日常编码任务中的出色表现，我们一直致力于为 GLM 提供最佳性能。现有证据表明，现在是时候将 GLM 部署为开发者的主力模型了。

每任务成本 vs 每 token 成本

开发者通常通过观察 token 成本来估算模型完成编码任务的费用。然而我们发现，由于模型之间推理效率存在差异，token 成本往往无法准确反映整体任务成本。这凸显了任务级基准测试的必要性，因为不同场景下的任务形态和复杂度可能存在显著差异。

以 Sonnet 5 为例，其每 token 成本约为 Opus 4.8 的 1.7 倍，但我们的测试显示，Sonnet 的每任务成本（2.09 美元）反而高于 Opus（1.94 美元），且任务完成评分低 6 分（81% vs 87%）。这主要是因为 Sonnet 5 需要更长时间的推理和更多的上下文阅读，消耗了 1.9 倍的 token。

框架对效率有重大影响

当我们使用相同模型和相同推理努力，通过两种不同框架（Claude Code/Codex vs Pi）进行测试时，发现任务成本存在显著差异（某些情况下差异超过 2 倍），但质量保持一致。主要差异在于每个回合框架向模型提供的上下文量。

Pi 每回合提供的上下文量约为 Claude 的 1/3。它更高效地管理上下文，保持更紧凑的工作集，从而在更少的运行次数内完成任务。

这里的关键教训不是某个框架始终更便宜或原生框架更差，而是模型选择只是拼图的一部分。正是为了实现这种灵活性，我们投入开发了 Omnigent，使模型和框架的切换变得无缝。

为什么要构建自己的基准？

SWE-Bench 和 TerminalBench 等公开基准很有用，但无法回答我们的问题。原因有以下几点：

• 任务是公开的，解决方案会随时间进入训练数据。

• 我们发现这些基准无法代表我们的代码库，我们的代码库涵盖 10+ 种语言，包含大量用 Scala、Go、Rust、Java 和 Python 编写的代码，以及 Bazel、Protobuf 等工具。

通过基于我们自己的 PR 构建基准，我们可以更有信心地做出决策，确保优化方案不会影响开发者的效率。

我们如何构建基准

我们使用 Unity AI Gateway 捕获了所有编码交互的日志，这使我们能够分析工程师通过编码代理处理任务的复杂性。任务复杂性存在显著多样性，约四分之一的任务被标记为低复杂度，约 60% 为中等复杂度。

然而，昂贵的模型是工程师默认使用的模型，这显然存在巨大的效率提升空间。

任务构建

我们的工程师每天合并数千次代码更改，因此我们已经有了一个很好的数据集可供使用。一个好的拉取请求（pull request）是一个丰富的产物，其中包含展示开发者迭代过程的提交记录、人工评审以及帮助验证代码更改是否符合其初衷的测试。然而，我们需要进行多项质量检查和过滤，才能从中构建出高质量的基准：

• 近期性：我们从近期的历史中提取数据，以确保任务能反映我们当前的开发方式，包括目前使用的框架、模式和惯例。
• 人工编写：过滤掉了机器人提交、服务账户提交、完全由AI生成的更改以及自动生成的更改。
• 关联高质量测试套件：我们筛选出包含高质量测试的拉取请求，用于验证代码更改。
• 自包含性：更改仅限于少数几个模块内。
• 代表典型任务：我们从全栈任务分布中选取拉取请求，包括Scala后端服务、Rust系统代码、React和TypeScript前端、protobuf和gRPC合约以及Bazel配置。

在获得候选拉取请求后，我们专注于构建明确的任务：

• 提取意图并总结为提示：我们阅读拉取请求以理解其实际目的，然后描述期望的成果。通常这意味着通过说明问题或目标、命名任何约束条件，并删除解决方案的描述来重写拉取请求的描述。例如，删除解释为什么某个错误修复是正确的内容很重要，因为这会使任务过于简单。
• 分离相关测试：非测试文件是模型需要独立重现的更改，因此我们将测试文件单独存放并确保能够编译这些文件。我们的构建系统已经能够确定哪些测试依赖于原始拉取请求中被修改的文件，因此我们完整运行了所有这些测试目标。

通过这一过程，我们得到了基准中的单个任务。以下是一个简化的示例：

$
/$

尽管我们使用脚本和AI生成候选任务，但我们手动评估了每个样本。在某些情况下，我们发现原始拉取请求中的测试需要重写，以允许替代实现或提高严谨性，我们手动完成了这些修改（未使用AI）。同样，我们也发现了一些需要改进任务描述以使其更明确的案例。

图3：我们测试套件中的前后对比：之前的测试依赖于验证精确的字符串匹配，当模型尝试解决任务时，这导致了一些失败。这不是测试非确定性输出的好方法，因此我们将其重写为评估行为。

我们使用标准的开箱即用配置实例化了编码代理框架和模型，并提供了Databricks工程师通常可用的所有常用工具。

当代理明确表示任务已完成时，我们会保存该代码、修补保留的测试，并运行测试以确定该任务是否对该模型和框架组合而言是“通过”。我们没有使用大型语言模型（LLM）判断来评估正确性，因为我们发现这会奖励“听起来正确”而非“真正正确”的结果。

额外防护措施

在我们早期的实验中，一些模型得分看起来好得不真实，因此我们手动检查了追踪记录，以了解这些代理轨迹中发生了什么。我们发现由于最初的设置，“正确”的实现仍然可以在工作树的Git历史中被恢复！每个任务都源于一个已合并的提交，因此只要代理具备shell能力，就没有什么能阻止它通过Git历史向前追溯找到正确实现。为了解决这个问题，我们对Git历史进行了封存：在每次运行期间，我们完全切断工作副本与仓库的连接。

下一步计划？

我们从一个简单的问题开始：我们能否更高效地使用编码代理？答案是明确的肯定，而且由于我们可以采用数据驱动的方式，我们可以开始构建自动选择合适模型并跟踪效率的能力。

任何公司都可以这样做。任何拥有已合并PR积压任务的团队，实际上都拥有一个尚未被任何模型训练过的基准测试集，而这个测试集由你们团队编写的测试进行评分。我们正在积极添加更多任务（尤其是更具挑战性的任务），并计划让每个新代理/测试框架都通过这套任务进行验证，从而对我们的选择更加有信心。

在Databricks，我们一直对锁定效应保持警惕，这不仅针对供应商，还包括那些随着时间推移让团队变得不够灵活的假设。这种本能影响了我们早期对开放格式和标准的押注，也塑造了我们当前对AI的处理方式：衡量实际在我们部署的代码上有效的方法，为工程师在不同模型和测试框架之间提供一致的防护措施，同时进行优化以更有效地使用AI。

在后续的博客中，我们将进一步探讨我们如何利用Unity AI Gateway和Omnigent的智能路由功能，帮助开发人员在保持效率的同时使用最智能的代理。

订阅最新文章

订阅我们的博客，将最新文章直接发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"