假设你是一个技术负责人，团队里有 500 个工程师，每人每天用 Codex、Claude Code 或 Cursor 写代码。你每个月花在 AI 编程工具上的账单是六位数美元。现在老板问你：我们用的这套组合，真的是最优解吗？

你可能答不上来。

市面上有 SWE-Bench、TerminalBench 这类公开基准测试，但它们的数据集早就进了各家模型的训练语料，分数存在严重的"泄题"效应。更要命的是，那些基准测试里的代码库跟你们公司的技术栈完全不搭，Scala 微服务的坑、Bazel 构建的复杂度、Protobuf 合约的细节，在公开数据集里根本测不出来。

Databricks 的工程师团队也遇到了同样的问题。他们的代码库超过千万行，横跨 Scala、Go、Rust、Java、Python、TypeScript 等十几种语言，每天合并上千个 PR。与其依赖公开基准，他们决定自己做一套"体检系统"，用真实的内部 PR 来评估编程 Agent 的能力。

这套基准测试花了三个月搭建，跑出了几个让整个行业都该认真看看的结论。

为什么要自建基准？#

Databricks 的工程副总裁 Patrick Wendell 说得直白：公开基准测出来的结果，跟我们在实际代码库上看到的表现，是两回事。

核心原因有三点：

第一，数据泄露问题没法避免。 SWE-Bench 的测试用例是公开的，模型训练时几乎必然见过。AI 在测试集上的高分，可能只是"背题"背得好，不代表真的会解决新问题。

第二，你的代码库跟基准测试里的完全不一样。 大多数公开基准用 Python 写的小项目，而 Databricks 的代码库里到处都是 Bazel 构建、Protobuf 服务间通信、Scala 后端微服务，复杂度不在一个量级。

第三，你需要的是决策依据，不是排行榜排名。 企业真正想知道的是：我的工程师日常写什么类型的代码？什么难度的任务该用什么模型？哪套 Harness 综合最优？

Databricks 的做法是：从过去几个月合并的真实 PR 中筛选出一批高质量样本，把它们改造成"考题"，然后用这些考题去跑不同的模型和 Harness 组合，逐一打分。

基准是怎么搭的？#

搭建过程比想象中复杂很多，Databricks 团队踩了不少坑。

选题阶段。 他们从成千上万个 PR 中筛选，标准很严格：必须是人工编写的代码（过滤掉机器人提交和 AI 生成的），必须附带高质量测试（不然没法验证正确性），改动范围要集中在几个模块内（太分散的无法评估），而且要覆盖全栈（后端、前端、构建配置都要有代表性）。

每个候选 PR 还需要人工复审，把 PR 描述改写成"需求规格"，删掉一切暗示了实现方案的描述。这里有个有趣的细节：如果 PR 描述里写"因为这个 bug 的根因是 xxx，所以修复方案是 yyy"，后半句会被删掉，只保留对问题的描述，不然对模型来说就太简单了。

还有一个关键的"防作弊"措施：封存 Git 历史。 早期测试时，团队发现某些模型的分数高得离谱。检查日志后发现，这些 Agent 在自己的工作目录里翻 Git 历史，直接找到了原始 PR 的解决方案，然后照抄。团队随后做了一个简单但有效的处理：运行时把工作目录从完整仓库中割离，彻底阻断这条路。

评测阶段。 Databricks 没有用 LLM 来当裁判。他们的逻辑很明确：用 AI 来评价 AI，奖励的是"听起来对"而不是"实际上对"。所有评测都用测试用例的通过率说话，二进制判定，pass or fail。

四个核心发现#

跑完所有组合后，数据告诉了他们四件反直觉的事。

发现一：模型分成三个明确的"能力等级"#

所有被测的模型和 Harness 组合，自然地聚类成了三个梯队：

  • 第一梯队（顶尖）： GPT-5.5 级别的最强模型，什么任务都能做，但极贵。
  • 第二梯队（中坚）： 比如 Haiku 和 GPT-5.4 Mini 级别，日常任务完全够用，成本低得多。
  • 第三梯队（基础）： 只能处理简单重复操作，稍微复杂一点就掉链子。

关键是，大部分工程师 80% 的日常操作（改配置文件、翻 flag、小范围重构）根本不需要第一梯队的模型。“我们的工程师过去不分青红皂白，所有任务都默认用最贵的模型。这个习惯必须改。“这是 Databricks 团队的结论。

发现二：开源模型真的能打了#

GLM 5.2 在基准测试中的表现和 Opus 4.8 在统计上持平，但每次任务的成本是 $1.28 vs $1.94。

这验证了今年以来社区里一直在说的一个趋势：开源模型在编程任务上的能力已经逼近闭源旗舰。Databricks 内部正在把 GLM 推成日常开发的默认模型，只在复杂架构设计时才切回顶级模型。

发现三：Token 单价根本不能用来算成本#

这是最反直觉的发现。

大部分人比较模型成本时，直接看 API 的 token 单价。但 Databricks 发现，每次任务的实际花费和 token 单价是两个维度的事。 Sonnet 5 的 token 单价比 Opus 4.8 便宜约 1.7 倍，但在同样的任务集上，Sonnet 每次任务平均花费 $2.09，而 Opus 只有 $1.94，而且完成率低了 6 个百分点（81% vs 87%）。

为什么更便宜的模型反而更贵？因为 Sonnet 5 跑同样的任务时多消耗了 1.9 倍的 token，它需要反复阅读更多上下文、做更多轮尝试才能完成任务。高效的推理能力省下来的 token，可以完全抵消 token 单价的差距。

这告诉我们：选模型不能只看单价，要端到端地看"干完活的成本”。

发现四：Harness 对成本的影响比模型还大#

同样的模型、同样的推理强度，用不同的 Harness 来调用，每次任务成本差距超过 2 倍，而完成质量几乎没差别。

怎么回事？Databricks 对比了原生 Harness（Claude Code、Codex）和 Pi（一个轻量级的第三方 Harness），发现 Pi 每次发送给模型的上下文量只有原生 Harness 的 三分之一。Pi 做了更激进的上下文管理，始终维持一个紧凑的工作集，让模型更快完成任务。

但这不是说原生 Harness 不好。复杂的架构设计任务可能需要更多上下文。关键在于，你不应该只考虑"选什么模型"这一个变量，Harness 的选择同样重要，而且两者可以自由组合。

Databricks 的应对策略是投资 Omnigent，一个内部的多模型、多 Harness 调度层，让开发者可以从具体的技术选型中抽离出来，专注于任务本身。

这套方法论，你的团队也能用#

Databricks 这篇博客最值钱的不是那些具体数据（每个团队的数据都会不同），而是他们搭建基准测试的方法论。

核心思路极其简洁：你的 Git 仓库里已经躺着最好的测试数据集了。 每一个合并过的 PR，都是一个包含了需求描述、实现方案、测试验证的完整样本。只要把实现方案摘掉，替换成任务描述，你就有了一个针对自己代码库量身定制的考题。

Databricks 把这套东西跑起来了，证明了不管多大规模的代码库，都可以用数据驱动的方式来优化 AI 编程工具的选择。而且因为你用的是自己的代码、自己的测试，不必担心数据泄露问题，毕竟没有任何公开模型能拿到你们内部的私有仓库。

对普通开发者的启示#

哪怕你只是一个个人开发者，不管理 500 人团队，这套方法论里也有值得带走的东西：

第一，别只盯着模型排行榜。 SWE-Bench 的分数在你自己的项目上参考价值可能很有限。花一个小时，找几个你最近合过的 PR，去掉实现细节后丢给不同的 Agent 试试，你能得到远比公开基准更真实的数据。

第二，算账的时候看"每任务成本"而不是 token 单价。 你花 $20 月订阅了一个 AI 编程工具，感觉挺便宜。但如果你一周用它干了 200 个任务，而换一个搭配可能每次任务成本减半，那一年下来能省的钱就不是小数目了。

第三，别忽视 Harness 的差异。 同一套模型，在 Codex CLI 里跑和在一个定制化 Harness 里跑，效率和成本可能是两个世界。值得花时间尝试不同的 Harness 组合，找到最匹配你工作流的那一个。

总结#

Databricks 的这轮基准测试，本质上回答了所有用 AI 写代码的团队都在问的三个问题：

  1. 什么模型真适合我的代码库？（答案：自己测，别只看公开基准）
  2. 怎么在能力和成本之间找平衡？（答案：按任务难度分层，日常任务用中档模型）
  3. Harness 到底重不重要？（答案：它的影响可能比模型本身还大）

在 AI 编程工具遍地开花的 2026 年，选对工具组合已经不是一个技术偏好问题，而是一个工程效率问题。

参考来源： Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase — Vinay Gaba, Ankit Mathur, Rishabh Singh, Patrick Wendell, Matei Zaharia, Databricks Blog, July 8, 2026.