本文译自 Databricks 官方博客《Benchmarking Coding Agents on Databricks' Multi-Million Line Codebase》（2026-07-08），作者 Vinay Gaba、Ankit Mathur、Rishabh Singh、Patrick Wendell、Matei Zaharia。译文仅供学习参考，文内配图均引自原文。
译者注：在动手翻译这篇文章前，想先交代一句我的立场——我是 Pi 的拥护者，也是 Pi 社区的长期使用者。日常工程里用 Pi 跑真实任务时，我和 Databricks 团队有着几乎一致的切身经历：它靠更紧凑的工作集、每轮只喂必要的上下文，确实能在不掉质量的前提下，把 token 消耗和单任务成本压下来一大截。
正因为这段真实体验，下文关于「harness 比模型更能左右成本」的结论，于我而言不是冷冰冰的基准数字，而是每天都在发生的事。译文尽量保留了 Databricks 团队的第一人称视角，供同样在大型代码库上用编程智能体的朋友参考。
核心结论（导读）
我们在自身百万行级、横跨十余种编程语言的代码库上，用工程师真实完成过的编码任务搭建了一套内部基准。跑下来最有价值、也最反直觉的结论有四条：
背景：我们为什么做这件事
在 Databricks，随着我们大举把 AI 引进工程实践，软件开发的方式正在快速改变。过去一年，能写代码的模型与 harness（智能体运行框架）数量激增，开发者的选择比以往任何时候都多。选择越多，越要厘清两件事：面对真实编码任务，哪些编程智能体表现最好；任务表现又如何随价格变化。
这篇文章分享我们在内部搭建的编码基准，涵盖结果与方法。这套基准用 Databricks 代码库里的真实编码任务来考查工具——任务取自百万行级、覆盖多种主流语言的代码库（Python、Go、TypeScript、Scala 等），题目与答案均经仔细复核以确保准确。它并非面面俱到，但由此得出的洞察，已经切实提升了我们工程团队使用编程智能体的效率。下图是各模型与 harness 在整体基准上的得分：
我们分析得出的主要结论如下：
- 编码任务的帕累托前沿（即给定成本下的最优质量）同时涵盖 OpenAI、Anthropic 与开源模型。也就是说，今天只有把多种工具组合起来，才能达到前沿水平。
- 开源模型，尤其是 GLM 5.2，如今已经能胜任难度最高的任务。
- 模型的 token 单价，很难反映端到端任务的真实成本；更大的模型往往 token 利用效率更高，总成本反而更低。
- 模型所依托的 harness，对成本与质量的影响举足轻重。很多情况下，像 Pi 这样简洁的 harness，在我们的工作负载上效果最佳。
下面逐条展开。
模型聚成粗略的「能力梯队」
具体得分差几分，在真实任务里常常被拉平。我们更看重那些能帮我们判断「不同任务该用哪种模型」的规律性结论。事实上，结果清晰地显示，模型与 harness 聚成了三档能力梯队。
能力最强的模型在各类问题上都游刃有余，价格也最贵；中等与较弱的模型对常见任务依然十分有效，而且多数情况下明显更便宜。
日常工作中，工程师要做的事复杂度差异很大：切换开关、改配置这类常见运维任务，用不着最强的模型；但深入的设计探索就离不开它。然而过去，我们的默认模型总是最贵的那一档。基于这次分析，我们决定把更多工作交给 Haiku、GPT 5.4 Mini 这一档的模型。
开源模型已经能写代码了
围绕 GLM 5.2 的讨论热度很高，而我们的结果给出了证据：GLM 已经可以作为很多开发者的日常主力模型。它跻身最高梯队，质量与 Opus 4.8 在统计上持平，单任务成本却只有 $1.28，而 Opus 是 $1.94。
GLM 的质量分数，与我们内部已经试用 GLM 做日常开发的工程师所给的定性反馈一致。鉴于它在日常编码上的出色表现，我们一直在优化 GLM 的服务性能，而证据表明，现在该把它作为日常主力模型用起来了。
单任务成本 vs 单 token 成本
开发者常常靠扫一眼 token 成本，来估算模型完成编码任务会有多贵。但我们发现，由于各模型推理效率差异很大，token 成本往往并不能说明真实任务的成本。这也正是「任务级基准」的必要性所在——因为任务的形态与复杂度，在不同语境下可能截然不同。
以 Sonnet 5 为例：它每 token 的单价比 Opus 4.8 低约四成；但在我们的任务上，Sonnet 单任务成本是 $2.09，而 Opus 只有 $1.94，任务完成度还低了 6 个百分点（81% 对 87%）。主要原因在于，Sonnet 5 为了达成目标运行得更久、读得更多，消耗的 token 约为 Opus 的 1.9 倍。
Harness 对效率影响巨大
当我们用同一个模型、相同的思考强度，跑两个不同的 harness（Claude Code/Codex 对比 Pi）时，单任务成本出现了显著差异（某些情况下超过 2 倍），而质量保持不变。差异主要源于每个 harness 每轮喂给模型的上下文量。
Pi 每轮发送的上下文大约只有前者的三分之一。它更善于管理上下文，维持一个更紧凑的工作集，用更少的轮次完成任务。
这里的经验并非「某个 harness 永远更便宜」，也不是「原生 harness 就一定更差」。恰恰相反，模型选择只是其中一环。正是为了建立这种灵活性，我们才投资了 Omnigent，让切换模型与 harness 不再有摩擦。
为什么要自建基准
SWE-Bench、TerminalBench 这类公开基准有用，却回答不了我们真正关心的问题。原因有二：
- 任务是公开的，答案会随时间渗入训练数据。
- 我们发现，结果与我们代码库的实际情况并不相符——我们的代码库横跨十余种语言，还有大量用 Scala、Go、Rust、Java、Python、Bazel、Protobuf 等写成的服务。
在自家 PR 上构建基准，我们做这些决策时才更有底气，也不必担心新优化会拖慢开发者节奏。
我们怎么搭这套基准
我们用 Unity AI Gateway 采集了所有编码交互的日志，据此分析工程师用编程智能体处理的任务复杂度。复杂度差异很大：约四分之一被标为低复杂度，约 60% 为中复杂度。
然而，昂贵的模型是工程师的默认选择，因此这里显然有巨大的提效空间。
任务构建
我们的工程师每天合并数千次代码改动，本就握有一份现成的高质量数据集。一份好的 PR 是丰富的素材：提交记录刻画了开发者的反复修改，有同事做代码评审，还有测试用例帮我们验证改动是否符合初衷。但要据此构建高质量的基准，还需要几道质量筛查与过滤：
- 时效性：只取近期历史，让任务贴合我们当下的工程实践，包括正在使用的框架、模式与约定。
- 人工提交：剔除机器人提交、服务账号，以及完全由 AI 生成或自动生成的改动。
- 配套高质量测试：只保留附带高质量测试、能验证代码改动的 PR。
- 自包含：改动被限制在少数几个模块内。
- 覆盖典型任务：从全栈分布中挑选 PR——Scala 后端服务、Rust 系统代码、React 与 TypeScript 前端、protobuf 与 gRPC 契约，以及 Bazel 配置。
拿到候选 PR 后，我们着力把任务改写成规格明确的形态：
- 提炼意图，归纳成提示词。我们阅读 PR，搞清楚它到底要解决什么，再描述期望达成的效果。这通常意味着重写 PR 描述——写清问题或目标、列明约束，并隐去关于具体解法的描述。比如，一定要删掉「为什么这个 bug 这样修才是对的」这类说明，否则任务会变得太简单。
- 剥离相关测试。非测试文件的改动，需要模型自行实现，因此我们把测试文件单独放一边，并确保它能编译。我们的构建系统本就能判定哪些测试依赖原始 PR 改动过的文件，于是我们把这些测试目标完整跑了一遍。
如此便得到基准里的一条任务。下面是一个简化示例：
尽管候选任务是用脚本和 AI 生成的，我们仍逐条人工复核每个样本。有些情况下，原 PR 里的测试需要重写，以容纳其他实现方式或变得更严谨——这部分是我们手工完成的（不用 AI）。同样，我们也遇到过需要完善任务描述、让规格更明确的情形。
我们用各 harness 与模型的标准、开箱即用配置来实例化编程智能体，并配备 Databricks 工程师日常可用的全部常用工具。
当智能体明确宣告任务完成时，我们对那份代码拍下快照，补回此前剥离的测试，再跑测试来判断这个「模型 + harness」组合是否通过该任务。我们没有用大模型充当裁判来评判正确性——因为那样会鼓励「看似正确」而非「真正正确」。
额外护栏
在早期实验里，有几个模型的分数好得不真实，于是我们人工查看了这些轨迹（trace）来弄清原委。我们看到的是：由于最初的设置，正确的实现仍然可以从工作树的 git 历史里恢复出来！每个任务都源自一个已合并的提交，所以没有任何东西阻止一个拿着 shell 的智能体沿 git 历史往前翻、找到答案。为了修复这个问题，我们把 git 历史彻底隔离：在每次运行的整个期间，让工作副本与代码仓库完全断开。
下一步
我们从一个简单的问题开始：能不能更高效地使用编程智能体？答案明确是「能」，而且既然我们可以做到数据驱动，就能着手建立自动选模型、追踪效率的能力。
任何公司都能做同样的事。任何一支 backlog 里堆着已合并 PR 的团队，手上都已经握着一套没有任何模型训练过的现成基准，而且是由你们团队自己写的测试来打分。我们正积极补充更多任务（尤其是更难的），并计划把每一个新智能体/框架都跑一遍，从而对我们的选择更有信心。
在 Databricks，我们一直警惕「被锁定」——不只是对供应商，也包括那些会让团队随时间变得不灵活的假设。正是这种直觉，塑造了我们早期在开放格式与标准上的布局，也塑造了我们当下对待 AI 的方式：度量「在我们真正发布的代码上」什么才真的有效，让工程师在统一护栏下于不同模型与框架间自由切换，并持续优化，把 AI 用得更高效。
在后续博客里，我们会更多聊我们如何在 Unity AI Gateway 与 Omnigent 中运用智能路由，帮助开发者在保持高效的同时调用能力最强的智能体。