Databricks：代码 Agent 评测，关键是模型和 Harness 组合

Databricks 在 2026 年 7 月 8 日发布了内部 coding agent benchmark 的方法和结果。文章最值得关注的不是谁排第一，而是他们把“模型”和调用模型的 agent harness 放在一起评测。

在真实开发里，一个 coding agent 不是裸模型。它还包括上下文选择、工具调用、终端执行、文件读取、回合管理和停止条件。Databricks 想衡量的正是这些组合在端到端任务中的质量和成本。

第一张总览图把每个模型和 harness 组合放到同一个成本-通过率平面里。它比单列表格更清楚：有些组合成本更高但没有明显质量优势，有些组合则落在更接近 Pareto frontier 的位置。

原文中最直接的发现之一是：同一个模型、同样的 thinking effort，通过不同 harness 调用时，成本可能差异很大，质量却未必同步变化。Databricks 观察到，一些组合的任务成本相差超过 2 倍。

差异主要来自每一轮给模型喂入多少上下文、是否能保持紧凑的工作集，以及需要跑多少轮才能完成任务。文章提到，Pi 在他们的工作负载上每轮发送的上下文约少 3 倍，因此在不少任务里更高效。

这说明选 coding agent 时不能只问“底层模型是谁”。Claude Code、Codex、Pi 或其它 harness 可能让同一个模型表现出不同的成本曲线和工作节奏。

Databricks 的一个重要结论是，token 单价不能直接代表真实成本。模型在一个任务里读了多少上下文、绕了多少路、是否能尽快收敛，都会影响最终的 price-per-task。

原文举例说，在他们的任务中，Sonnet 5 的 token 单价低于 Opus 4.8，但端到端任务成本反而更高，完成率也更低。原因不是单纯“贵模型更好”，而是不同模型在完成同一类任务时的推理效率、上下文消耗和执行路径不同。

因此，模型选择要和 harness 选择一起看。便宜 token 如果换来更多轮次、更长上下文和更多试错，最后未必便宜；更强模型如果更快收敛，端到端成本也可能更低。

Databricks 的结果还显示，代码任务的 Pareto frontier 同时包含 OpenAI、Anthropic 和开源模型。文章也提到，GLM 5.2 在他们的评测中进入高能力层，并且任务成本低于部分旗舰模型组合。

这带来的管理启发是：团队不应该把所有任务默认交给最贵模型。常见配置修改、低复杂度 bug、局部前端改动和文档更新，可以用成本更低但足够稳定的组合；复杂设计、跨模块改动和高风险修复，再交给更强模型与更严谨的 harness。

真正有价值的是按任务路由模型和 harness，而不是固定相信某一个模型、某一个编辑器或某一个榜单。能力层级图也说明，接近同一质量区间的组合不止一个，成本差异反而可能很大。

Databricks 之所以用自己的多百万行代码库，是为了让评测足够接近真实工作负载。文章中他们从近期 PR 中筛选任务，保留测试做验收，并人工复核任务质量，还处理了 Git 历史泄漏这类容易让 agent 偷看到答案的问题。

但这个方法服务的核心问题仍然是：哪种模型和 harness 组合，能在你的任务上以合理成本稳定完成工作。代码库本身不是结论，模型组合、上下文管理和任务路由才是结论。

对学习者和小团队来说，可以先做一个很小的任务集：同一批 bug fix、配置修改、测试补充和组件调整，分别用不同 coding agent 跑一遍，记录完成率、人工返工量、运行轮次和大致成本。这样才能看清哪个组合适合日常使用。