Pi 真的打赢 Claude Code 和 Codex 了吗？Databricks Harness 基准的正确读法

摘要

Databricks 在内部真实代码任务上比较了多种模型与 Coding Agent Harness。 最容易传播的说法是“Pi 打赢 Claude Code 和 Codex”，但公开证据支持的是一个 更窄、也更有工程价值的结论：

在六组保持基础模型与推理强度一致的匹配实验中，Pi 的任务成本标签均更低； 质量点估计有高有低，公开材料不足以宣布统计胜负。

这项研究真正提醒我们的，不是应该永远选择哪个产品，而是模型并不独自决定 Agent 的端到端表现。上下文选择、工具协议、重试、压缩和停止策略组成的 Harness，同样会改变成功任务成本。团队应复制 Databricks 的配对评测方法， 而不是复制它在特定私有任务上的一次排名。

关键词

Pi、Claude Code、Codex、Coding Agent、Agent Harness、私有 Benchmark、 成功任务成本、上下文管理

目录

1. 这场比较到底在比什么
2. 六组数据能证明什么
3. 为什么质量不能按“胜负场次”解读
4. 上下文重发是线索，不是单因果证明
5. 私有 Benchmark 为什么可信，又为什么不能外推
6. 团队应该怎样复刻这套评测
7. 选型时必须分开的两个门槛
8. FAQ

1. 这场比较到底在比什么

Databricks 于 2026 年 7 月 8 日公布了一项内部 Coding Agent Benchmark。 任务来自工程师已经完成的真实历史工作，覆盖数百万行、多语言代码库；官方 同时明确说明，这项研究并不全面。Databricks 官方文章

首先要纠正一个概念：Pi 在这里不是与 Opus、GPT 对位的基础模型。配对实验 比较的是同一个模型、同一个推理强度，通过不同 Harness 完成任务后的结果。

至少要把三个层次分开：

Harness 不是模型外面一层无关紧要的壳。模型每一轮看到哪些代码、带回多少 工具输出、何时摘要、失败后是否重试、满足什么条件才停止，都会改变调用轮数、 累计 Token、失败尾部和最终行为。

因此，“使用同一个 Opus”不等于端到端成本相同；同样，“某个 Harness 在任务 成本上更好”也不等于它在完整产品能力上全面胜出。

2. 六组数据能证明什么

Databricks 的 Harness 配对图给出了六组同模型、同推理强度对照。下表中的 倍数和通过率来自官方 PNG 的可见标签，不是公开原始数据集。官方 Harness 配对图

* 官方图最后一行同时写着 78% vs 80% 和 -1 pt，可见百分比与括号差值 内部不一致。本文保留可见的 78% 和 80%，不替官方推算成 79%。

成本侧的信号很整齐：六组全部指向 Pi 较低，幅度为 1.20× 至 2.08×。这足以 支持：

在这些模型、推理档位、Harness 配置和 Databricks 任务上，Pi 降低了模型 调用侧的每任务成本。

但它不支持三个常见扩写：

1. Pi 在任何代码库、任何版本下都更便宜；
2. 六组可以直接平均成一个通用“节省 X%”；
3. Token 成本已经等于许可证、集成、审计、运维和人工失败处理的完整拥有成本。

不同配置的绝对成本基线不同，公开材料又没有逐任务分布。把六个倍数直接平均， 看似得到一个更简洁的数字，实际上丢失了任务、模型和推理档位的条件。

3. 为什么质量不能按“胜负场次”解读

按官方图中可见百分比，Pi 的质量点估计两组较高、四组较低，差值范围为 +3 至 -7 个百分点。这里不能写成“六战两胜四负”。

通过率是有限任务样本上的估计值。要判断差异是否稳定，至少还需要：

• 每个配置实际跑了多少任务；
• 同一任务是否做了重复运行；
• 逐任务配对结果；
• 随机运行的方差；
• 置信区间或预先定义的等效边界；
• 失败是否集中在某种语言、任务类型或难度。

这些信息没有公开。我们不知道 -7 个百分点来自多数任务持续变差，还是少数 任务翻转；也不知道同一配置重跑时结果会波动多少。

Databricks 正文把这些配对概括为“质量保持同一水平”，并提醒现实任务中几个 百分点的差异可能被抹平。严谨的翻译应是：这是官方面向工程决策的方向性判断， 不是一项公开可复核的统计等效性检验。

因此，两个极端都不成立：

• 不能因为成本全部更低，就宣布 Pi 质量也全面胜出；
• 也不能因为四组点估计较低，就宣布 Pi 已被证明质量更差。

公开证据允许说“点估计接近但分叉”，不允许说“统计上完全相同”或“已经分出 稳定胜负”。

4. 上下文重发是线索，不是单因果证明

Databricks 还公开了两组每任务总重发上下文中位数：

来源：Databricks 上下文重发图

这与六组成本方向一致。长任务中，如果每轮都携带越来越多的历史、代码片段和 工具输出，累计输入量会快速膨胀。更紧的工作集、更少的运行轮次，很可能是 Pi 在该实验里降低成本的重要组成部分。

但“很可能是重要组成部分”不等于“已经证明唯一原因”。公开材料没有逐轮 Trace，也没有逐项关闭以下机制做消融：

Prompt 与系统指令
→ 工具定义与返回格式
→ 代码和文件的选择策略
→ 工具输出裁剪
→ 上下文压缩与摘要
→ 失败重试
→ 终止条件
→ 总运行次数

这些都属于 Harness 路径。只看两根上下文柱子，无法把成本差异精确分摊给 Compaction 或某一个算法。

还要注意统计口径：上下文图是中位数，成本图是平均成本 proxy。中位数描述 典型任务，平均值会被昂贵尾部影响。没有分位数和逐任务关联时，两张图只能 共同提供机制线索，不能拼成精确因果公式。

5. 私有 Benchmark 为什么可信，又为什么不能外推

这项研究的价值，来自它努力接近真实工程任务。

Databricks 从近期已合并 PR 构造任务，过滤机器人、服务账号、全 AI 生成和 自动生成改动，要求有高质量测试，并优先选择相对自包含的变更。任务覆盖 Scala、Rust、Java、Python、React、TypeScript、Protobuf、gRPC 和 Bazel 等 技术栈。

构造流程大致是：

1. 从 PR 中提炼目标和约束，去掉原解决方案提示；
2. 隐藏非测试实现，保留相关测试；
3. 人工逐项检查任务描述和测试；
4. Agent 表示完成后保存代码状态；
5. 补回保留测试并执行，以 Pass/Fail 判定；
6. 不使用 LLM Judge 代替行为测试。

早期实验还发现过一个严重泄漏：Agent 可以从 Git 历史找回已经合并的正确 实现。研究者在检查异常高分 Trace 后，切断了工作副本与仓库历史。这说明 “任务私有”不会自动产生可靠 Benchmark，泄漏控制和 Trace 审计同样重要。

不过，筛选规则也定义了外推边界。强调自包含和高质量测试，会自然弱化：

• 跨服务迁移和长期重构；
• 需求不完整、测试薄弱的任务；
• 依赖大量组织知识的变更；
• 安全、性能、可维护性和架构一致性；
• IDE、审批、协作与企业治理体验。

所以，这个通过率更接近“在被筛选的、可测试的 Databricks 历史任务上通过”， 而不是“自动化了全部工程工作”。

6. 团队应该怎样复刻这套评测

真正值得复制的是变量控制方法。评测单位不应只有“模型名”或“产品名”，而应 写成一组可复现配置：

evaluation_unit:
  model_snapshot: locked
  thinking_effort: locked
  harness_version: locked
  tool_policy: locked
  task_set: private_recent_prs
  budget_and_timeout: locked
  repeated_runs: required_for_stochastic_paths

record_per_run:
  - test_result
  - task_cost
  - total_context_refed
  - agent_turns
  - wall_clock_time
  - failure_type
  - human_intervention

一套最小流程可以分为五步。

第一步：从自己的任务分布取样

用近期已合并 PR、真实故障修复和配置变更构造任务。按语言、模块、难度和任务 类型分层，不能只挑测试最完善、最容易成功的样本。

第二步：隐藏答案，同时防止旁路泄漏

移除原实现，保留行为测试；隔离 Git 历史、缓存、构建产物、日志和任何可能 暴露答案的文件。公开测试可以用于基本反馈，最终判定使用隐藏测试。

第三步：做同模型匹配对照

先固定模型快照、推理强度、预算和工具权限，只替换 Harness。这样才能回答 “Harness 改变了什么”。之后再固定 Harness 比较模型，避免变量混在一起。

第四步：同时记录质量、成本和轨迹

至少记录每成功任务成本、测试通过、上下文重发量、轮次、延迟和失败类型。 对随机性明显的配置做重复运行，并报告区间和尾部，而不是只公布一个平均分。

第五步：把任务层与产品层分开验收

任务 Benchmark 之外，单独检查权限、审批、数据边界、审计、IDE 集成、团队 协作、运维和回滚。任务成本更低不应抵消治理门槛失败。

7. 选型时必须分开的两个门槛

最终选型至少需要两张结论表。

任务经济性门槛

回答：

• 在可接受质量下，每成功任务成本是多少；
• 哪些任务容易失败，尾部是否失控；
• 上下文、轮次和延迟为何增加；
• 结果对模型、推理强度和 Harness 版本是否敏感。

产品治理门槛

回答：

• 工具权限能否最小化；
• 高风险操作是否有审批；
• 数据、日志和代码是否满足边界；
• 是否具备审计、回滚和团队策略；
• IDE、云任务和协作流程是否满足实际使用。

某个 Harness 可以在第一张表里表现优秀，却因为第二张表不合格而不能部署； 也可能模型调用成本略高，但通过治理和集成降低了完整拥有成本。

这正是为什么不能把 Databricks 图改写成产品总排名。

8. FAQ

Pi 是否在这项 Benchmark 中更便宜？

在公开的六组同模型、同推理强度匹配配置中，官方图表标签都显示 Pi 的任务 成本较低。结论仅限这些配置和 Databricks 的任务分布。

Pi 的质量是否与 Claude Code、Codex 完全相同？

公开点估计接近但有高有低。缺少任务数、重复运行、方差和置信区间，不能声称 已经统计证明完全相同，也不能宣布稳定胜负。

成本差异是否就是上下文压缩造成的？

公开图显示 Pi 重发上下文更少，Databricks 也把更紧的工作集和更少运行视为 主要解释。但缺少逐轮 Trace 与消融实验，不能把全部差异归因于单一机制。

团队是否应该直接改用 Pi？

不能仅凭这项基准决定。应该在自己的代码库、任务分布和治理要求下做匹配测试， 再综合任务经济性与产品层门槛。

这项研究最值得带走的结论是什么？

模型并不独自决定 Agent 的端到端表现。复制同模型配对、隐藏测试、版本锁定和 轨迹记录的方法，比复制一次排名更有价值。

参考资料

• Databricks：Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase
• Databricks Harness 配对图
• Databricks 上下文重发图
• Pi Releases
• OpenAI Codex Releases

发布边界

本文不提供跨代码库、跨版本的产品总排名。图表数字按 2026 年 7 月 23 日可见 公开材料记录；正式发布前应再次核对官方正文和图表。