原文:databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase
发布 2026-07-08 · 最后更新 2026-09-08 · 本页整理 2026-09-14 · 原文 9 张插图已随文存档

Databricks 数百万行代码库上的 Coding Agent 基准测试

不用 SWE-Bench,不用别人的题库——Databricks 把自己每天合并的 PR 变成考卷,用人工校对过的留出测试(held-out tests)判卷,给各家模型 × harness 组合算出「每任务成本 vs 质量」。这篇是他们第一轮实测的方法与结论。

TL;DR · 四条主结论

性价比前沿上不止闭源双雄,开源模型也在场要拿到「给定成本下的最优质量」,必须混用 OpenAI、Anthropic 和开源模型——任何单一供应商都给不出全前沿。
开源模型已能啃下最高难度任务,GLM 5.2 尤为突出 GLM 5.2 进入最高能力档,质量与 Opus 4.8 统计学上打平,每任务成本 $1.28 对 $1.94,已作为日常主力部署。
token 单价便宜 ≠ 任务成本低 Sonnet 5 每 token 便宜约 1.7 倍,但单任务反而更贵($2.09 vs $1.94)且完成率低 6 个百分点——它干活更久、读得更多,token 消耗是 1.9 倍。
harness 显著改变成本与质量,简单 harness 常常最好同一模型、同一思考档位,不同 harness 每任务成本可差 2 倍以上;Pi 这类简单 harness 每轮喂给模型的上下文只有别的 1/3,反而跑得更省更好。

背景 · 为什么不用公开基准

公开题库已经「泄漏」,也代表不了自家的代码库

Databricks 正在工程组织里激进采用 AI,模型与 harness 的选择多到需要数据来裁。而现成的编码基准有两个致命问题:

题目是公开的。SWE-Bench、TerminalBench 这类基准的题目早已进入各家的训练数据,分数有「背题」嫌疑。
不代表他们的真实工作。自家代码库横跨 10+ 种语言,大量服务用 Scala,还有 Go、Rust、Java、Python,以及 Bazel、Protobuf 这类工程基建——公开基准的孤立小任务完全测不出这种环境下的真实表现。

于是他们改用自家已合并的 PR 做题源,对结论的信心完全不同。

先看工作量长什么样:绝大多数任务都是「中等复杂度」

通过内部网关 Unity Gateway(所有编码交互的日志都从这里过)分析真实使用,按复杂度分档后发现:约 25% 是低复杂度(翻个开关、改个配置),约 60% 是中复杂度。而此前的默认做法是不管大小都派最贵的模型——这就是效率优化的空间所在。

工程师向 Coding Agent 提出的问题按复杂度分布 — **原文插图** · 工程师实际拿 Coding Agent 干什么:按任务复杂度分布——大头是中低复杂度,却默认派最贵的模型。

模型能力也相应分成三档:最聪明的模型什么都能解但贵;中低档模型在常见任务上高效又便宜。结论是要把日常大量任务从顶级模型改派到 Haiku、GPT 5.4 Mini 这类档位。

模型聚成三个能力档 — **原文 Figure 2** · 模型按通过率聚成三档:Cluster 1(82–90%,Opus 4.8 各档位、GLM 5.2、GPT 5.5 高档)全题型通吃但贵;Cluster 2(71–82%)与 Cluster 3(51–60%)在常见任务上够用且便宜。图侧还标了同档平替的省钱幅度:GPT-5.5(pi, med) 比 Opus 4.8(claude code, high) 便宜 2.2×,Sonnet 4.6 比 Sonnet 5 便宜 1.8×,GPT-5.4-mini 比 Haiku 4.5 便宜 1.3×。

方法 · 怎么造题、怎么判卷

把每天合并的 PR,改造成没人背过的考卷

公司每天合并数千个 PR。一个好 PR 本身就是丰富的人工产物:有展示迭代过程的 commit、有人工评审、有测试。整条流水线是「过滤 → 造题 → 校剔」三段:

任务构建流程:Filter → Build → Vet — **原文插图** · 造题流水线总览:每周数千个已合并 PR → Filter(新 / 人写 / 有测试 / 自包含 / 有代表性)→ Build(还原意图成题面、拆分 diff、找出门禁测试、回滚仓库盲跑、判分)→ Vet(剔除空转 / 焊死 / 饱和的坏测试)→ 可信的基准任务。

但不是每个 PR 都能当题,先过五道过滤:

够新——反映当前的框架、模式与代码规范;
人写的——滤掉机器人提交、服务账号、全自动 AI 生成的 PR、自动生成代码;
带高质量测试套件;
自包含——改动局限在少数几个模块内;
有代表性——Scala 后端、Rust 系统层、React/TypeScript 前端、Protobuf/gRPC 契约、Bazel 配置都要覆盖。

过滤之后,还要把 PR 改写成一道规格明确、不泄底的题:

提炼意图,重写成题面 把 PR 描述改写成「问题 + 目标 + 约束」的提示词,并刻意删掉解法描述——原文特别点名:不能写「为什么这个修复是对的」,否则等于把答案递给模型。
拆出测试,留作判卷依据 非测试文件就是要让模型复现的部分;测试文件单独拿出、确认能编译。再由构建系统找出所有依赖被改文件的测试目标,全量跑,不抽样。
逐题人工校对,剔除三类坏测试 每个样本都人工过一遍:空转的(不修复也能过)、焊死的(与人手解法绑死,正确但不同的修法过不了)、饱和的(所有模型都能过,测不出差距)直接剔掉;有时把测试改得更严谨,有时改写以允许不同正确实现——改写过程纯手工、不用 AI;题面也要改到规格明确为止。
封存 git 历史,堵住「翻答案」 题目源自已合并的 commit,而 agent 有 shell,早期实验里它们顺着工作区的 git 历史把「标准答案」翻了出来,分数好得不真实。修复:每轮运行期间把工作副本与仓库彻底隔离(git 历史封存)。
开跑:原生环境 + 原生判卷 给 agent 开箱即用的环境,装上 Databricks 工程师常用的全套工具。当 agent 自己宣称「做完了」,对代码打 checkpoint、补入留出测试、跑测试——过即该「模型 × harness」组合得 1 分。

盲考式跑测四步:回滚仓库 → 模型盲做 → 补入留出测试 → 判分 — **原文插图** · 跑测四步:① 仓库回滚到修复落地前的那一刻(两道测试是红的)② 模型只拿题面和整个代码库,diff 与测试都藏着 ③ 直到此刻才第一次把留出测试补进去、对着模型的代码跑 ④ 红的变绿就算过——没有 LLM 裁判,没有评分细则。

判卷为什么不用 LLM 当裁判

他们的判分只有一条:留出测试全过。明确不用 LLM-as-judge 评正确性,理由很直白:LLM 裁判「奖励听起来对,而不是真的对」(rewards sounding right over being right)。

人工改测试长什么样

典型的改法:改前的测试锚定在某个精确字符串上——模型只要复刻出原文实现里的特定写法才能过,惩罚了同样正确的其他实现;改后按行为判分,输出本就不确定,行为符合预期即算过。改写全程手工完成,不借 AI。

测试套件改写前后的真实对比 — **原文 Figure 3** · 同一个测试改写前后:从「锚定人手解法的精确字符串」改成「按行为判分,允许非确定性输出下的不同正确实现」。

结果 · 四条结论展开

钱和分,都摆到台面上

结论一:Pareto 前沿是「混编」的

在「每任务成本 vs 质量」的散点图上,前沿位置站着 OpenAI、Anthropic 和开源模型——没有任何一家供应商能独自覆盖整条前沿,想始终拿到最优性价比,工具箱里必须同时备着多家模型。

每任务成本 vs 通过率散点图,红色虚线为 Pareto 前沿 — **原文 Figure 1** · 全部「模型 × harness × 思考档位」组合的成本-质量散点,红色虚线即 Pareto 前沿:GPT 5.4-mini(codex)守最便宜端,GLM 5.2(pi)以约 $1.28 坐进 87% 通过率,Opus 4.8(pi, xhigh)守质量顶端;右上角 Claude Code 高档位的 Opus 4.8 花近 2 倍钱买不到对等提升。

结论二:开源模型(尤其 GLM 5.2)连最难的任务都能做

GLM 5.2 进入最高能力档,在质量上与 Opus 4.8 统计学上打平,而每任务成本更低。这与内部试点团队的反馈一致,Databricks 已把它作为日常主力模型部署。

每任务成本 · 最高能力档对决(质量统计持平)

GLM 5.2开源 · 已日常部署$1.28

Opus 4.8$1.94

$0每任务成本(max $2.09)

结论三:token 单价便宜,账单未必便宜

Sonnet 5 每 token 比 Opus 4.8 便宜约 1.7 倍,听起来该更省钱。但端到端跑任务时,它工作更久、读入更多上下文,token 总消耗是 1.9 倍,结果每任务反而更贵,完成率还低 6 个百分点。买模型要看「每任务成本 + 完成率」,不是价签。

同题对决 · Sonnet 5 vs Opus 4.8

每任务成本Sonnet $2.09

Opus $1.94

任务完成率Opus 87%

Sonnet 81%

比例尺 0–100%

Sonnet 5 每 token 便宜 ~1.7×,但总 token 消耗 1.9×——省在单价,亏在用量。

结论四:harness 的影响被严重低估

同一模型、同一思考力度,换两个 harness 跑同样的题:每任务成本差异能超过 2 倍,质量还不掉。主要差别在于 harness 每轮给模型喂多少上下文——简单 harness(Pi)每轮送出的上下文约为另一方的 1/3:管理工作集更紧凑、跑的轮次更少,又省又好。Databricks 由此强调:harness 与模型是一个整体决策,他们为此在建 Omnigent,让模型与 harness 可以无缝互换。

同一模型在不同 harness 下的每任务成本哑铃图 — **原文插图** · harness 对效率的影响:六个「模型 × 思考档位」组合里,pi(红)都比 native harness(空心)便宜 1.2–2.1×,质量多在 ±2–3 个百分点内波动;唯一例外是 Opus 4.8 max 档——便宜 1.20× 但掉了 7 个点(82% vs 89%)。

每个任务重喂给模型的总上下文对比 — **原文插图** · 差距从哪来——每任务重喂给模型的总上下文(median tokens):Opus 4.8 在 Claude Code 下要喂 742k,Pi 只要 236k(3.2× less);GPT 5.5 在 Codex 下 1235k,Pi 665k(1.9× less)。工作集更紧凑、轮次更少,成本随之下去。

护栏 · 分数好得不真实的时候

agent 自己会去「翻答案」

早期实验里分数高得可疑。去翻 trace 才发现:题目来自已合并的 commit,而「正确实现」还留在工作区的 git 历史里——拿到 shell 的 agent 顺着 git log 就把参考答案找了出来,这不是解题,是抄卷。

一次被标红的 git 考古作弊 trace — **原文插图** · 一次被抓了现行的作弊 trace:agent 开局 4 秒就 git log --all 考古,git show 掏出原始 PR(解法和留出测试都在里面),系统直接亮红牌「LEAK DETECTED —— git-archaeology detected: agent reached its own answer key」。

防作弊要点:凡是从真实历史构造的任务,必须假设 agent 会探索一切它能触达的状态。Databricks 的对策是封存 git 历史——整轮运行期间,把工作副本与代码仓库完全隔离。

下一步 · 你也可以这么干

「有 PR 积压的团队,手里就攥着一个没人训练过的基准」

这次评测的起点是个效率问题(「能不能把 Coding Agent 用得更省?」),答案明确是能,而且数据直接转化成了行动:用数据自动选模型、持续追踪效率。具体路线是给 Unity Gateway 加智能路由、推进 Omnigent,细节留在后续博客。

他们对供应商与自家假设都保持警惕,避免锁定:在自己发过的代码上测量什么真的有效,同时保留跨模型、跨 harness 迁移的余地。

任何团队,只要手里有一摞已合并的 PR,就已经坐拥一个没有任何模型训练过的基准——判卷人就是你团队自己写的测试。 — Databricks,本文结语(意译)

注:这篇博客在原 URL 上经历过整体改写(现行版本发布于 2026-07-08,2026-09-08 更新)。如果你之前读过 Devin / Claude Code 对比的那版结果,那是已被替换的旧版;本页总结以现行版本为准,数字均出自原文。