Pi vs Claude Code vs Codex 正确读法：6 组同模型匹配 + 2.08×/1.46×/1.20×/1.54×/1.22×/1.44× 成

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

TL;DR

场景：Databricks 2026-07-08 公布内部 Coding Agent Benchmark：用真实合并 PR、数百万行多语言代码库构造任务，比较多个模型与多个 Agent Harness 的端到端表现。
结论：在六组同模型、同推理强度配对里，Pi 任务成本标签均更低（1.20×---2.08×）；但质量点估计有高有低（−7 至 +3 pt），公开材料没有逐任务分布、置信区间或重复运行，不能宣布统计胜负。真正值得复制的是同模型配对 + 隐藏测试 + 版本锁定 + 轨迹记录的评测方法。
产出：可复刻的五步评测流程、两张结论表（任务经济性 / 产品治理）、6 维度对 Harness 路径的拆解、12 条错误速查卡，目标是让"模型对比"和"Harness 对比"不再被混在一起讲。

版本矩阵

功能 / 事实	状态	说明
Databricks 内部 Coding Agent Benchmark 公布日期 2026-07-08 16:30	✅ 已验证	og:title "Benchmarking Coding Agents on Databricks' Multi-Million Line Codebase" / article:published_time "Wed, 07/08/2026 - 16:30" / article:modified_time "Wed, 07/08/2026 - 22:14"
任务来自真实合并 PR，过滤机器人 / 服务账号 / 全 AI 生成 / 自动生成	✅ 已验证	原文（databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase）
任务覆盖 Scala / Rust / Java / Python / React / TypeScript / Protobuf / gRPC / Bazel	✅ 已验证	原文
判定以行为测试 Pass/Fail 为主，不使用 LLM Judge 替代	✅ 已验证	原文
早期实验发现 Git 历史泄漏已合并实现，研究者切断工作副本与仓库历史	✅ 已验证	原文
六组同模型同推理强度配对	✅ 已验证	Databricks Harness 配对图（dumbell.png）
Opus 4.8 high 配对：Pi 成本更低 2.08×、85% vs 87%（-2 pt）	⚠️ 数字源自图	来自官方 dumbell.png 可见标签；公开材料未给出逐任务分布与置信区间
Opus 4.8 xhigh 配对：Pi 成本更低 1.46×、90% vs 88%（+2 pt）	⚠️ 数字源自图	同上
Opus 4.8 max 配对：Pi 成本更低 1.20×、82% vs 89%（-7 pt）	⚠️ 数字源自图	同上
GPT-5.5 medium 配对：Pi 成本更低 1.54×、83% vs 80%（+3 pt）	⚠️ 数字源自图	同上
GPT-5.5 high 配对：Pi 成本更低 1.22×、81% vs 83%（-2 pt）	⚠️ 数字源自图	同上
GPT-5.5 xhigh 配对：Pi 成本更低 1.44×、78% vs 80%（官方括号标 -1 pt）	⚠️ 数据冲突	百分比与 pt 标注内部不一致；本文保留可见值不替官方推算
上下文重发中位数：Opus 路径 Claude Code 742k → Pi 236k（约 3.2× 减少）	⚠️ 数字源自图	来自官方 cost-1.png 中位数图
上下文重发中位数：GPT 路径 Codex 1235k → Pi 665k（约 1.9× 减少）	⚠️ 数字源自图	同上
上下文图是中位数、成本图是平均成本 proxy，统计口径不同	✅ 已验证	原文未给分位数与逐任务关联，本文按中位 / 平均标注
Pi Harness GitHub 仓库	✅ 已验证	github.com/earendil-works/pi（Pi Releases）
OpenAI Codex GitHub 仓库	✅ 已验证	github.com/openai/codex（Codex Releases）
Databricks Harness 配对图	✅ 已验证	databricks.com/sites/default/files/inline-images/dumbell.png?v=1783530297
Databricks 上下文重发图	✅ 已验证	databricks.com/sites/default/files/inline-images/cost-1.png?v=1783548879
公开材料没有逐任务分布、置信区间与重复运行方差	✅ 已验证	原文未披露，Databricks 自己也写"this study is not comprehensive"
Databricks 正文中"质量保持同一水平"是方向性判断	✅ 立场	原文写"现实任务中几个百分点的差异可能被抹平"，本文按"方向性判断"处理而非"统计等效性"
公开证据允许说"Pi 质量点估计接近但分叉"，不允许说"统计上完全相同"或"已经分出稳定胜负"	✅ 立场	本文按"公开点估计 + 缺少统计量"显式分清
上下文差异"很可能是 Pi 成本更低的重要组成部分"	✅ 立场	本文保留原文措辞，标注尚未做逐轮 Trace 与消融实验
六组倍数可"直接平均成节省 X%"	✅ 反对	本文明确反对（不同任务 / 模型 / 推理档位绝对基线不同）
公开证据能直接宣告"Pi 全面胜出"或"Pi 已被证明质量更差"	✅ 反对	本文两个极端都否定

摘要

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

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

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

关键词

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

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

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

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

至少要把三个层次分开：

层次	主要变量	本次基准覆盖程度
基础模型	模型快照、推理强度	在六组配对内被控制
Agent Harness	Prompt、工具、上下文、重试、压缩、终止	配对实验的核心变量
完整产品	权限、审批、IDE、云任务、协作、审计、企业策略	没有被系统覆盖

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

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

2. 六组数据能证明什么

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

模型与推理强度	Pi 任务成本标签	Pi 通过率	对照 Harness 通过率	可见点差
Opus 4.8，high	2.08× 更低	85%	Claude Code 87%	-2
Opus 4.8，xhigh	1.46× 更低	90%	Claude Code 88%	+2
Opus 4.8，max	1.20× 更低	82%	Claude Code 89%	-7
GPT-5.5，medium	1.54× 更低	83%	Codex 80%	+3
GPT-5.5，high	1.22× 更低	81%	Codex 83%	-2
GPT-5.5，xhigh	1.44× 更低	78%*	Codex 80%	官方括号写 -1*

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对应组合	原生 Harness	Pi	图中关系
Opus 4.8	Claude Code 742k	236k	Pi 约少 3.2×
GPT-5.5	Codex 1235k	665k	Pi 约少 1.9×

来源：Databricks 上下文重发图

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

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

text 复制代码

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

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

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

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

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

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

构造流程大致是：

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

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

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

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

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

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

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

yaml 复制代码

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 的端到端表现。复制同模型配对、隐藏测试、版本锁定和轨迹记录的方法，比复制一次排名更有价值。

参考资料

错误速查卡

症状	根因	定位	修复
把"六组 Pi 成本更低"读成"Pi 全面胜出"	漏看了质量点估计的方向与不确定度	重新读 6 组 pass rate 差值	显式区分"成本方向可被支持"与"质量点估计接近但分叉"
把 6 组倍数平均成"Pi 节省 X%"	把 6 个不同条件配对当成同分布样本	列出每组模型与推理档位	改用"在哪些配置下偏 Pi"的范围表达
把 GPT-5.5 xhigh 78% vs 80% 与 -1 pt 改成 79%	替官方修正可见数据冲突	回到原图核对	保留原图可见值，并标注"百分比与 pt 标注内部不一致"
把 Databricks "质量同一水平"读成"统计等效"	把方向性判断当统计结论	看官方是否给置信区间	改为"方向性判断"表述，附"未公开置信区间"的边界
把上下文重发更少读成"已经证明 Compaction 是主因"	缺少逐轮 Trace + 消融	对比 Prompt / 工具裁剪 / 重试 / 终止 4 个变量	在自家评测里加单变量消融再谈因果
拿 Databricks 排名改写团队选型结论	把 Harness 配对 + 私有任务集当成完整产品评测	检查 IDE / 审批 / 协作 / 审计是否被覆盖	任务经济性 / 产品治理拆成两张结论表
让 Agent 从 Git 历史找回合并实现	没切断工作副本与仓库历史	看异常高分 Trace	在私有任务设计里切断 Git 历史 / 缓存 / 构建产物访问
只评"模型名"或"产品名"	把变量全部混在一起	看评测单位定义	把模型 / Harness / 工具 / 预算 / 任务集全部锁版本写进 evaluation_unit
只公布平均通过率，不报方差	任务样本量小且具有随机性	看是否做了重复运行	强制 repeated_runs: required_for_stochastic_paths
把 LLM Judge 当行为测试用	测试集不充分，转用模型评判	看是否使用真实行为测试	用 hidden test + 行为 Pass/Fail，不替代
把 Databricks 的筛选规则当成通用结论	自包含 + 高质量测试弱化了一类任务	看筛选定义	显式标注"筛选规则定义了外推边界"
复制一次私有排名就改预算与采购	把单一组织 / 单一时间窗的结论当成行业基准	评估配对条件 + 任务分布	复制配对方法而不是结果；自家任务分布自己跑