在拥有11,000名员工的情况下，我们的AI成本正在上升。应该使用哪种模型和工具框架来降低成本，同时保持良好的质量？

我们不想盲目相信公开基准测试。因此，我们针对自己的任务、代码库和基础设施进行了全面的评估。该评估由超过3,000名软件工程师参与，涵盖三个超大规模云、多种语言和任务。

结果令人惊讶。我们发现，对于同一种模型，工具框架的选择可以显著节省成本（约2倍）。我们还发现GLM 5.2表现极为出色。我们将Omnigent部署在这些模型和框架之前，可以轻松地为不同任务组合使用不同的工具框架和模型。

详情如下：

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

来源：https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase 在Databricks，随着我们积极采用AI进行工程开发，软件构建的方式正在迅速变化。过去一年，用于代码编写的模型和工具框架生态迅速扩张，为开发者提供了前所未有的选择。面对更多选项，了解哪些编码智能体在实际编码任务上表现最佳，以及任务性能如何随价格变化，变得愈发重要。

本文分享了我们在Databricks构建的内部编码基准测试的结果和方法论。该基准测试评估了工程师在Databricks代码库上实际编码任务中使用的工具。任务涉及对拥有数百万行代码的代码库进行修改，涵盖多种流行语言（Python、Go、TypeScript、Scala等），并且任务和解决方案都经过仔细审查以确保准确性。这并非旨在全面，但此次实践揭示的洞察已经让我们的工程团队在使用编码智能体方面变得更加高效。以下展示了模型和工具框架在整体基准测试中的得分情况：

我们的基准测试中成本与性能的对比

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

我们分析的主要结论如下：

1. 编码任务的帕累托前沿（即给定成本下的最佳质量）包括来自OpenAI、Anthropic以及开源模型的工具。这意味着目前只有混合使用多种工具才能达到前沿性能。
2. 开放模型，特别是GLM 5.2，现在能够处理最高难度的任务。
3. 模型的Token价格并不能很好地反映端到端任务的实际成本。大型模型在Token效率上可能高得多，总体成本反而更低。
4. 调用模型的工具框架对成本和质量的巨大影响。在许多情况下，像Pi这样的简单工具框架在我们的工作负载上表现最佳。

让我们深入探讨每一点。

模型大致分为几个“能力层级”

具体结果上几分的差异在实际任务中往往可以忽略。我们更关注那些有助于判断哪些模型适合哪些任务的模式性规律。事实上，结果表明模型和工具框架清晰地分为三个能力层级。

模型能力层级

图2：整体结果中出现了三个不同的能力层级，每个组中哪些模型有效存在细微差别

在性能的高端，我们看到最智能的模型能非常有效地解决各种问题，但它们非常昂贵。中低等智能的模型在常见任务上仍然非常有效，并且在许多情况下，它们也便宜得多。

在日常工作中，工程师要做很多不同的事情，其复杂性差异很大：像翻转标志或更新配置这样的常见操作任务不需要极其智能的模型，而更深层次的设计探索则需要。然而，过去我们的默认模型总是最昂贵的。基于此分析，我们决定应将更多工作推向Haiku和GPT 5.4 Mini这类模型。

开放模型已可用于编码

人们对GLM 5.2充满了期待，我们的结果显示GLM可以成为许多开发者的日常驱动模型。它位于顶级能力层级，在质量上与Opus 4.8统计上持平，但每个任务成本为1.28，而Opus为1.94。

GLM的质量分数与内部开发者的定性反馈一致，他们一直在试用GLM进行日常开发。鉴于其在日常编码任务中的出色表现，我们一直专注于以最佳性能提供GLM服务（https://x.com/Yuchenj_UW/status/2070166719839326396），证据表明是时候将其作为编码的日常驱动程序进行部署了。

每任务价格 vs 每Token价格

开发者经常通过Token成本来估算模型完成编码任务的费用。然而，我们发现，由于模型在推理效率上存在差异，Token成本通常不能很好地反映任务总成本。这强调了进行任务级基准测试的必要性，因为不同环境中任务形态和复杂性可能不同。

例如，Sonnet 5每Token价格比Opus 4.8便宜约1.7倍，但在我们的任务中，我们发现Sonnet每个任务成本为2.09，而Opus为1.94，同时任务完成分数低6个百分点（81%对87%）。这主要是因为Sonnet 5工作更久，读取了更多内容，消耗了1.9倍的Token。

工具框架对效率有重大影响

当我们通过两个不同的工具框架（Claude Code/Codex 和 Pi）运行相同的模型，并使用相同的思考努力时，我们观察到每个任务的成本差异显著（某些情况下超过2倍），而质量保持不变。主要区别在于每个回合每个工具框架向模型输入了多少上下文。

工具框架对效率的影响

Pi每个回合发送的上下文大约少3倍。它更好地管理了上下文，保持了更紧凑的工作集，并在更少的运行次数内完成了任务。每个任务重新提供给模型的总上下文量

这里的教训不是某个工具框架总是更便宜，也不是原生工具框架更差。相反，模型选择只是拼图的一部分。建立这种灵活性正是我们投资Omnigent（https://omnigent.ai/）的原因，以实现模型和工具框架的无缝切换。

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

像SWE-Bench和TerminalBench这样的公共基准测试很有用，但它们无法回答我们的问题。原因如下：

• 任务是公开的，因此解决方案会随时间泄露到训练数据中。
• 我们发现结果对我们的代码库不具有代表性，我们的代码库涵盖10多种语言以及许多用Scala、Go、Rust、Java和Python、Bazel、Protobuf等编写的服务。

通过基于我们自己的PR构建基准测试，我们可以更有信心地做出决策，确保我们的优化不会妨碍开发人员。

我们如何构建基准测试

我们使用了Unity AI Gateway（https://www.databricks.com/product/artificial-intelligence/unity-ai-gateway）来捕获所有编码交互的日志，这使我们能够分析工程师使用编码智能体处理的任务的复杂性。任务复杂性存在显著差异，约四分之一被标记为低复杂性工作，约60%为中等复杂性。

工程师实际向编码智能体提出的请求

然而，昂贵的模型是工程师使用的默认模型，因此在提高效率方面显然存在巨大机会。

任务构建

我们的工程师每天合并数千个代码变更，因此我们已经拥有一个很好的数据集。一个好的Pull Request是一个丰富的产物，包含展示开发者迭代的提交、人工审查以及有助于验证代码变更符合意图的测试。然而，我们需要进行多项质量检查和过滤，才能从中构建出高质量的基准测试：

• **时效性：**我们从近期历史中提取任务，以便任务反映我们当前的构建方式，包括当前使用的框架、模式和约定。
• **人工编写：**机器人提交、服务账户、完全由AI生成的变更以及自动生成的变更被过滤掉。
• **关联高质量测试套件：**我们筛选出包含高质量测试以验证代码变更的PR。
• **自包含：**变更限于少数模块。
• **代表典型任务：**我们选择了涵盖整个技术栈的任务分布：Scala后端服务、Rust系统代码、React和TypeScript前端、protobuf和gRPC契约以及Bazel配置。

任务构建步骤计划

一旦有了候选PR，我们通过以下步骤专注于构建明确描述的任务：

1. **提取意图并总结为提示。**我们阅读PR，了解其实际目的，然后描述我们期望的结果。通常，这意味着重写PR描述，陈述问题或目标，命名任何约束，并删除解决方案的描述。例如，删除关于为什么某个bug修复是正确的解释很重要，因为这会使任务过于简单。
2. **拆分出相关测试。**非测试文件是模型必须自行复现的变更，因此我们将测试文件放在一边，并确保我们可以编译这些非测试文件。我们的构建系统已经能够确定哪些测试依赖于原始PR中修改的文件，因此我们全部运行了那些测试目标。

通过这个练习，我们得到了基准测试中的单个任务。下面是一个简化的例子：

虽然我们使用脚本和AI来生成候选任务，但我们对每个样本进行了人工评估。在某些情况下，我们发现原始PR中的测试需要重写，以允许替代实现或使其更严格，我们手动进行了这些重写（未使用AI）。同样，我们也发现需要改进任务描述以使其明确描述的情况。

测试套件中的前后对比

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

我们使用标准、开箱即用的配置来实例化编码智能体工具框架和模型，并配备Databricks工程师可用的所有常用工具。

设置和审查过程

当智能体明确表示完成任务时，我们检查点该代码，打上被保留的测试补丁，并评估测试以确定该任务是否为该“模型+工具框架”组合的“通过”。我们没有使用LLM作为评判者来评估正确性，因为我们发现这样会奖励听起来正确而非实际正确。

额外的防护措施

额外的防护措施

在早期实验中，一些模型得分看似好得难以置信，因此我们手动检查了跟踪记录，以了解这些智能体轨迹中发生了什么。我们发现，由于我们的原始设置，“正确”的实现仍然可以从工作树的Git历史中恢复！每个任务都源自一个已合并的提交，因此没有什么可以阻止拥有shell的智能体通过Git历史向前查找它。为了解决这个问题，我们封闭了Git历史：在每次运行的整个过程中，我们将工作副本与仓库完全切断。

接下来是什么？

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

任何公司都可以做到这一点。任何拥有已合并PR backlog的团队都已经拥有了一个基准测试，这些测试没有模型训练过，并且由团队编写的测试进行评分。我们正在积极添加更多任务（尤其是更困难的任务），并计划让每个新的智能体/工具框架都通过此基准测试，以便对我们的选择更有信心。

在Databricks，我们一直警惕锁定，不仅是对供应商，还有那些使团队随着时间推移变得不那么灵活的假设。这种直觉同样塑造了我们对开放格式和标准的早期押注（https://www.databricks.com/blog/what-open-lakehouse-open-data-standards-explained），也塑造了我们现在处理AI的方式：衡量那些对我们交付的代码真正有效的东西，让工程师在一致防护措施下自由切换模型（https://www.databricks.com/blog/ai-gateway-governance-layer-agentic-ai）和工具框架（https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents），并进行优化以有效利用AI。

在后续博客中，我们将进一步讨论如何利用Unity AI Gateway（https://www.databricks.com/product/artificial-intelligence/unity-ai-gateway）和Omnigent（https://omnigent.ai/）中的智能路由功能，帮助我们的开发者在保持效率的同时使用最智能的智能体。