文章总结： Databricks基于内部数百万行代码库的真实PR构建CodingAgent评测基准，覆盖多语言技术栈，以保留测试而非LLMjudge判定任务完成。核心结论包括：不存在单一模型垄断成本-质量前沿，开源模型已进入最高能力层；单token价格无法预测单任务总成本，需以任务成本为评估单位；harness显著影响成本与质量，评测单位应为模型乘harness乘配置。文章还揭示了Git历史泄漏漏洞并给出防泄漏审计建议，强调团队应使用自身任务分布评测并优化路由策略。
综合评分： 85
文章分类： 解决方案,AI安全,安全工具
Databricks 如何在数百万行代码库上评测 Coding Agent
原创
zouyee
zouyee
DCOS
2026年9月16日 07:27
江苏
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
来源：Databricks 官方博客（https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase），Vinay Gaba、Ankit Mathur、Rishabh Singh、Patrick Wendell、Matei Zaharia，2026 年 7 月 8 日。
本文基于原文重新编译与翻译，重点梳理真实代码库评测的方法、成本结论、harness 影响，以及团队如何用自己的历史 PR 建立内部 benchmark。
摘要
当 Coding Agent 从“偶尔试用”变成日常生产工具，团队真正需要回答的问题已经不再是“哪个模型在公开榜单上最高”，而是：
- 哪个模型能解决我们的真实任务？
- 同一个任务最终要花多少钱，而不只是每个 token 多少钱？
- 模型和 harness 应该如何组合？
- 哪些简单任务可以交给更便宜的模型？
- 如何避免公开 benchmark 的数据泄漏和任务分布偏差？
Databricks 用内部近期合并的 PR 构造了一套 Coding Agent benchmark。任务来自数百万行代码库，覆盖 Python、Go、TypeScript、Scala、Rust、Java、Protobuf、gRPC 和 Bazel 等技术栈；每个任务都经过人工检查，并以隔离保留的测试而非 LLM judge 判定是否完成。
他们得到四个主要结论：
- 不存在单一模型垄断成本—质量前沿。 OpenAI、Anthropic 和开源模型都位于 Pareto frontier 上。
- 开源模型已经能处理最高难度的一部分编码任务。 GLM 5.2 在这套内部评测中进入最高能力层。
- 单 token 价格很难预测单任务总成本。 更强、单价更高的模型可能因为推理路径更短，反而具有更低的任务成本。
- harness 会显著影响成本和质量。 上下文如何选取、重复回灌多少、需要运行多少轮，可能带来两倍以上的成本差异。
1. 为什么公开榜单不够用
SWE-bench、Terminal-Bench 等公开 benchmark 很有价值，但它们无法直接回答一个企业工程团队最关心的问题。
首先，公开任务和解法会随时间进入训练数据，评测结果可能受到污染。其次，不同公司的代码分布差异很大。Databricks 的代码库跨越十多种语言，既有 Scala 后端服务、Go 和 Rust 系统代码，也有 React/TypeScript 前端、Protobuf 与 gRPC 契约，以及 Bazel 构建配置。一个在公开 Python 仓库上表现优异的 Agent，不一定能适应这种多语言、大型 monorepo 环境。
更关键的是，公开榜单通常只给出“能力分数”，却很难回答内部落地问题：
- 日常任务中，低、中、高复杂度分别占多少？
- 工程师是否一直在用最昂贵的模型处理简单修改？
- 模型贵，究竟是 token 单价高，还是完成任务实际消耗更多 token？
- 换一个 harness 后，同一个模型的成本会发生什么变化？
因此，Databricks 没有把公开 benchmark 当作最终采购依据，而是从自己的工程活动中构造评测集。
2. 先看结果：成本与能力不是一条直线
图 1：不同模型与 harness 组合的单任务成本和任务完成率。来源：Databricks。
这张图最重要的信息不是某个点领先几分，而是 Pareto frontier 同时包含闭源和开源模型。换句话说，在不同预算区间里，最优选择来自不同供应商和不同模型家族。
Databricks 因此没有把结论简化成“全员切换到某个最强模型”。更合理的策略是保留多模型、多 harness 的可替换性，再根据任务难度进行路由。
2.1 三个粗粒度能力层
图 2：整体结果形成三个较明显的能力层，但每层内部仍存在模型与 harness 的差异。来源：Databricks。
评测结果大致聚成三个能力层：
- 最高能力层：能处理各种复杂度的任务，但通常成本最高。
- 中等能力层：可以完成大量常见工程任务，价格明显更低。
- 基础能力层：适合改配置、切换开关、局部单文件修改等边界清晰的工作。
工程师每天处理的工作并不都需要最高推理能力。修改一个 flag、更新配置和探索大型系统设计的难度完全不同。Databricks 过去默认使用最昂贵的模型，内部任务分布却显示大量工作可以下沉到 Haiku、GPT 5.4 Mini 这一档。
这里的实践含义是：路由策略不应只在模型失败后降级，而应在任务开始前做能力匹配。
3. 开源模型已经进入日常编码主力区间
在这套内部 benchmark 中，GLM 5.2 进入最高能力层，质量上与 Opus 4.8 在统计意义上接近，但平均任务成本分别约为：
| 模型 | 平均成本 |
| — | — |
| GLM 5.2 | 1.28 美元/任务 |
| Opus 4.8 | 1.94 美元/任务 |
Databricks 的内部试用反馈也与评测结果一致：GLM 已经可以成为许多开发者的日常主力模型。
这一结果不意味着开源模型在所有维度都优于闭源模型，也不能直接推广到每个公司的代码库。它真正说明的是：“开源模型只能处理简单编码任务”已经不是可靠假设。 如果企业拥有自己的 serving 能力、隐私要求或供应商多样性诉求，开源模型值得进入正式评测，而不只是作为低成本 fallback。
4. 为什么 token 单价会误导成本判断
开发团队常用输入、输出 token 单价快速估算模型成本。但端到端 Coding Agent 的总成本还取决于：
- 模型为了完成任务要读多少代码；
- 推理过程中反复回看多少上下文；
- 需要执行多少轮工具调用；
- 是否能快速定位相关模块；
- 首次实现失败后要返工多少次。
Databricks 给出的典型对比如下：
| 指标 | Sonnet 5 | Opus 4.8 |
| — | — | — |
| 相对 token 单价 | 约便宜 1.7 倍 | 基准 |
| 平均任务成本 | 2.09 美元 | 1.94 美元 |
| 任务完成率 | 81% | 87% |
| token 消耗 | 约为 Opus 的 1.9 倍 | 基准 |
Sonnet 5 的 token 更便宜，却因为工作时间更长、读取内容更多，最终每个任务反而更贵，完成率还低 6 个百分点。
因此，评估 Coding Agent 成本时，至少要同时记录：
任务完成率
单任务总成本
总输入 / 输出 token
总上下文重复回灌量
Agent 轮数与工具调用次数
任务复杂度
模型 + harness 组合
只比较 token price，相当于只比较汽车的每升油价，却忽略百公里油耗和是否能到达目的地。
5. Harness 不是包装层，而是系统能力的一部分
Databricks 用相同模型、相同 thinking effort，对比 Claude Code/Codex 与 Pi 等不同 harness。结果显示，质量可能相近，但单任务成本在部分组合中相差两倍以上。
图 3：同一模型通过不同 harness 执行时，任务成本可出现明显差异。来源：Databricks。
主要原因不是模型本身，而是每轮发送给模型的上下文规模。
图 4：Pi 每轮发送的上下文约少 3 倍，并以更紧凑的 working set 完成任务。来源：Databricks。
Pi 在这组任务中每轮发送的上下文约少 3 倍。它更积极地控制 working set，也用更少的运行轮次完成任务。
这里不应得出“简单 harness 永远更便宜”或“模型厂商自己的 harness 更差”的结论。不同仓库、工具权限和任务形态可能给出不同结果。更稳健的结论是：
Coding Agent 的评测单位不应只有 model，而应是 model × harness × 配置。
这也是 Databricks 投资 Omnigent 的原因之一：让团队能够替换模型和 harness，而不必把工作流锁定在单一组合上。
6. 他们如何从真实 PR 构造 benchmark
Databricks 通过 Unity Gateway 收集 Coding Agent 交互日志，先分析工程师真实任务的复杂度分布。约四分之一任务被标记为低复杂度，约 60% 为中等复杂度。
图 5：内部 Coding Agent 请求以低、中复杂度任务为主。来源：Databricks。
随后，团队从每天合并的数千个代码变更中选择候选 PR。一个高质量 PR 天然包含三类信息：开发者的迭代提交、人工 review 过程，以及验证变更意图的测试。但 PR 不能未经处理直接变成 benchmark，候选任务需要经过以下过滤：
6.1 候选 PR 的五项筛选条件
- 足够新：使用近期历史，让任务反映当前框架、编码模式和工程约定。
- 由人编写：排除 bot、service account、全 AI 生成和自动生成的变更。
- 有高质量测试：原 PR 必须包含能够验证行为的测试。
- 相对自包含：改动集中在少数模块，避免依赖无法还原的外部过程。
- 代表真实任务分布：覆盖 Scala、Rust、React/TypeScript、Protobuf、gRPC 和 Bazel 等全栈工作。
图 6：候选 PR 经筛选、任务描述重写、测试隔离和人工审核后进入 benchmark。来源：Databricks。
6.2 从“已有解法”还原成“只给问题”
选出候选 PR 后，团队会阅读变更以理解真实意图，再把它改写成 Agent 可以执行的 prompt。这个过程要：
- 描述问题或期望结果；
- 明确必要约束；
- 删除具体解法；
- 删除“为什么某种修复是正确的”等泄漏答案的信息。
一个简化后的任务记录类似这样：
{
"id": "go_bugfix_01",
"category": "Go — bugfix",
"base_commit": "fga6rfb27…",
"prompt": "deploy 服务使用内存缓存对工作流提交去重。两个不同模板同时提交时可能命中同一个缓存 key，导致其中一个提交被静默丢弃。请修改去重 key，使本应被视为不同的提交能够区分开。",
"source_files": [
"services/deploy/cache/recent_cache.go",
"..."
],
"test_targets": [
"//services/deploy/integration/gateway:gateway_test"
]
}
6.3 把测试从工作区中拿走
非测试文件是模型需要独立重现的实现，原 PR 中的测试文件则被单独保留。Agent 运行期间看不到这些测试；结束后，评测系统再把测试 patch 回工作区，并运行所有依赖于原变更文件的测试 target。
团队使用脚本和 AI 生成候选任务，但 每个样本都由人工评估。部分原始测试过度依赖某个实现细节，或只做精确字符串匹配，无法接受行为正确的替代实现。遇到这种情况，团队会手工重写测试，使其评估行为而非复刻原答案。
图 7：原测试依赖精确字符串，重写后改为验证非确定性输出的行为。来源：Databricks。
7. 如何执行和判定一次任务
模型与 harness 使用开箱即用的标准配置，并提供 Databricks 工程师通常可用的公共工具。
图 8：Agent 声明完成后冻结代码、恢复保留测试，并以测试结果判定通过。来源：Databricks。
一次评测的关键步骤是：
- 在指定 base commit 创建隔离工作区。
- 向 Coding Agent 提供任务 prompt 和常用工具。
- 让 Agent 自主浏览、编辑、构建和检查代码。
- 当 Agent 明确声明完成时，checkpoint 当前代码。
- 将预先保留的测试 patch 回工作区。
- 编译并运行完整的相关测试 target。
- 以测试是否通过判定该 model + harness 组合是否完成任务。
Databricks 明确没有使用 LLM judge 判断正确性。他们的经验是，LLM judge 容易奖励“听起来正确”的回答，而测试更接近“实际上正确”。
这套方法也不是绝对完美：测试本身可能遗漏行为，复杂系统还可能依赖难以复现的环境。但与纯文本 judge 相比，它提供了更稳定、可审计的验收边界。
8. 一个差点让 benchmark 失效的泄漏漏洞
早期实验中，部分模型的成绩好得不合理。团队手工检查 Agent trajectory 后发现：标准答案仍然可以从 worktree 的 Git 历史中恢复。
每个任务都来自一个已经合并的 commit。只要 Agent 拥有 shell，就可以沿 Git history 向前搜索，直接找到原始实现，而不是自己解决问题。
图 9：为防止 Agent 从仓库历史恢复标准答案，运行期间必须封闭 Git history。来源：Databricks。
修复方式是在每次运行期间把工作副本与原仓库彻底断开，封闭 Git 历史。
这个案例说明，Agent benchmark 的防泄漏不能只检查 prompt。只要 Agent 能使用 shell、网络、代码搜索或内部工具，就必须审计整个可观测环境：
- Git objects 和 refs；
- commit message 与 PR 元数据；
- 测试文件和 snapshot；
- 构建缓存与生成产物；
- 内部代码搜索；
- 网络和制品仓库；
- 其他工作区残留。
否则，评测测到的可能不是编程能力，而是答案检索能力。
9. 这套方法最值得复用的部分
9.1 用自己的任务分布评测
每个拥有历史 PR 和测试体系的团队，实际上都坐在一套潜在 benchmark 上。内部 PR 具有三个优势：模型大概率没见过、任务与真实生产高度一致、团队已经写好了验收测试。
9.2 以“任务成本”替代“token 价格”
真正可用于预算和路由的指标是：完成一个任务花多少钱，以及在这个价格下成功率是多少。token 单价只是一项输入参数。
9.3 把 harness 纳入评测对象
模型的能力无法脱离上下文管理、工具协议、文件检索和循环策略单独衡量。升级模型但固定低效 harness，可能得不到预期收益；优化 harness，有时无需更换模型就能显著降本。
9.4 以测试为主，人工 review 为质量门
测试负责规模化判定，人工 review 负责检查任务描述是否清晰、测试是否偏向原实现、环境是否泄漏答案。两者缺一不可。
9.5 不要过度解读几个百分点
原文特别提醒，某次结果相差几个百分点，在真实任务中可能被随机性抵消。比单点排名更重要的是稳定模式：能力层、成本—质量前沿、任务复杂度分布，以及不同 harness 的相对效率。
10. 落地内部 Coding Agent benchmark 的最小方案
如果团队准备复用这套思路，可以从小规模版本开始：
1. 从最近 1–3 个月的人工 PR 中抽样
2. 排除自动生成、跨系统依赖过重和测试不足的变更
3. 按语言、模块、任务类型、复杂度分层
4. 将 PR 意图重写成不泄漏实现的 prompt
5. 隔离实现 patch 与测试 patch
6. 封闭 Git 历史和其他答案通道
7. 固定 model × harness × thinking effort 配置
8. 运行相关测试，以通过 / 失败判分
9. 记录完成率、任务成本、token、轮数和上下文回灌量
10. 人工复核异常高分、异常低分和失败轨迹
第一版不需要追求成百上千个任务。几十个经过严格人工审核、覆盖主要任务类型的样本，通常已经能发现：默认模型是否过度配置、某个 harness 是否重复喂入过多上下文、低价模型可以承担哪些工作。
随着任务集扩大，还需要维护版本和治理：
- 定期加入近期 PR，避免 benchmark 老化；
- 将已经用于调参的任务与最终 holdout 分离；
- 记录任务和测试的修改历史；
- 对模型、harness、工具权限和环境生成可复现 manifest；
- 防止 benchmark 结果反向泄漏进训练与提示模板。
11. 解读边界与最终判断
阅读这些结果时需要保留三项边界：原文没有公开完整任务集、置信区间和全部运行配置，外部团队无法复现精确排名；结果来自 Databricks 自身的多语言代码库，不能直接迁移到其他任务分布；几个百分点的局部差异，不如跨任务呈现出的能力层和成本趋势可靠。
因此，最合理的做法不是照抄 Databricks 的模型排名，而是复用其评测原则：使用真实、近期且未泄漏的内部任务，以行为测试验收结果，把 model 与 harness 作为组合共同评估，同时衡量质量与端到端成本，并人工审计异常轨迹。
Databricks 的内部 benchmark 揭示了 Coding Agent 进入生产阶段后的一个关键变化：竞争单位已经从单个模型，变成模型、harness、上下文管理、工具和路由策略组成的完整系统。
最强模型仍然适合高复杂度设计和跨模块推理，但大量日常工作可以交给更便宜的能力层。开源模型已经足以进入主力候选；昂贵模型也未必带来更高任务成本，因为推理效率可能抵消 token 单价；而 harness 对上下文的管理方式，有时比换模型更影响成本。
对工程团队而言，最有价值的资产不是一张外部排行榜，而是一套基于自身 PR、测试和任务分布持续更新的内部评测系统。只有测量“我们实际交付的代码”，模型选择、自动路由和成本优化才有可靠依据。
参考资料
- Databricks：Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase（https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase）
- Databricks Unity AI Gateway（https://www.databricks.com/product/artificial-intelligence/unity-ai-gateway）
- Omnigent（https://omnigent.ai/）
- SWE-bench（https://www.swebench.com/）
- Terminal-Bench（https://www.tbench.ai/）
版权与来源说明：本文是对 Databricks 原文的中文翻译、结构化转述与分析，不是逐句复刻。原始数据、图表与观点归 Databricks 及原作者所有；图表在此仅用于技术解读。所有来源内容均已重新表述，以遵守内容许可限制。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：DCOS zouyee
zouyee《Databricks 如何在数百万行代码库上评测 Coding Agent》