在多百万行代码库上基准测试编码智能体：Databricks 的实践经验
Databricks 基于内部代码库构建了编码智能体基准测试，发现不同模型和工具组合在成本和性能上存在显著差异。关键结论包括：前沿模型（如 OpenAI、Anthropic 和开源模型）组成帕累托前沿；开源模型如 GLM 5.2 已达到顶级任务难度；每任务成本比每 token 成本更能反映实际开销；调用框架（harness）对效率和成本影响巨大。Databricks 已据此优化内部开发效率。
在 Databricks，软件开发方式正在迅速变化，因为公司积极采用 AI 辅助工程。过去一年，代码编写模型和工具的数量激增，给开发者带来了更多选择。但如何选择最优的编码智能体？为此，Databricks 内部构建了一套编码基准测试，基于工程师在真实代码库上完成的任务来评估工具。
该基准测试针对 Databricks 的多百万行代码库，涉及 Python、Go、TypeScript、Scala 等语言。每个任务都对应一个真实的 PR，经过人工审查确保准确性。测试包含不同复杂度的任务，从简单的配置修改到复杂的设计探索。
主要结论如下：首先，编码任务的帕累托前沿由 OpenAI、Anthropic 和开源模型共同构成，意味着单一工具无法在所有场景下提供最佳性价比。其次，开源模型如 GLM 5.2 已跻身顶级能力层级，在质量上与 Opus 4.8 统计持平，但每任务成本更低（$1.28 vs $1.94）。第三，每 token 价格并非任务成本的良好指标。例如，Sonnet 5 的 token 单价是 Opus 4.8 的 1.7 倍便宜，但实际每任务成本反而更高（$2.09 vs $1.94），因为它消耗了更多 token。最后，调用框架对效率影响巨大：同一模型通过不同框架（如 Claude Code 与 Pi）运行时，成本可相差 2 倍以上，而质量不变。Pi 框架通过更紧凑的上下文管理减少了每轮 token 使用。
Databricks 强调，构建内部基准测试而非依赖公共基准（如 SWE-Bench）的原因是：公共任务可能泄露到训练数据中，且结果不适用于其多语言、多服务的代码库。他们从内部 PR 中筛选任务，确保测试用例质量高、任务自包含且代表典型工作。
在测试过程中，团队发现早期结果过于乐观，原因是智能体可以从 git 历史中恢复“正确”实现。为此，他们通过密封 git 历史来防止作弊。未来，Databricks 计划添加更多任务，并利用 Unity AI Gateway 和 Omnigent 实现智能路由，自动选择最合适的模型和框架。他们总结道：“任何公司都可以这样做——任何拥有已合并 PR 的团队都拥有一个尚未被模型训练过的基准测试，并由团队编写的测试来评分。”