本文数据引自 Databricks 官方博客《Benchmarking Coding Agents on Databricks' Multi-Million Line Codebase》(2026-07-08),配图均引自原文。

最近 Databricks 发了一份很有分量的基准报告——他们在自己百万行级、横跨十余种语言的代码库上,用工程师真实做过的编码任务评测了一批编程智能体。完整译文我放在了这里。这份报告里最让我这个 Pi 拥护者振奋的,不是哪个模型夺冠,而是一个被很多人忽视的结论:换一个 harness,成本能差 2 倍以上,而质量不变。胜出的,正是 Pi。

Databricks 基准里关于 Pi 的硬数据

Databricks 团队做了一个相当干净的对照实验:用同一个模型、相同的思考强度,分别跑两个 harness——Claude Code/Codex 与 Pi,在同一批真实任务上对比。这样一来,「模型差异」和「思考强度差异」两个变量都被摁住了,剩下的差别只能归到 harness 身上。结果很干脆:

  • 单任务成本:Pi 比 Claude Code/Codex 低 2 倍以上(某些情况下超过 2 倍)。
  • 质量:两者持平,没有任何下降。
  • 每轮上下文量:Pi 每轮喂给模型的上下文,大约只有前者的三分之一。
不同 harness 的单任务成本对比
同一模型经不同 harness 调用时的单任务成本差异(图源:Databricks)。

换句话说,Pi 没有换模型、没有降低思考强度,却把成本砍到了不到一半,质量一点没掉。这在「模型越贵越好」的主流叙事里,是个相当反直觉的结果——而且它不是某个边缘任务上的偶然,而是 Databricks 在百万行级、跨十余种语言的真实代码库上跑出来的系统性结论。Databricks 甚至在总结里直接写明:「像 Pi 这样简洁的 harness,在我们的工作负载上效果最佳」。

Pi 的差异化到底在哪

Databricks 给出的解释很直接:差异主要来自每个 harness 每轮喂给模型的上下文量。Pi 每轮发送的上下文大约只有前者的三分之一。

每个任务回填给模型的上下文总量
每个任务回填给模型的上下文总量(图源:Databricks)。

拆开看,Pi 的优势集中在三件事上,而且三者是互相叠加的:

① 更紧凑的工作集:Pi 更善于管理上下文,不把无关历史一股脑塞回去,让模型每轮都聚焦于必要内容。上下文一长,模型既要多读、也容易分神,Pi 从源头把这层开销压住。
② 更少的轮次:因为每轮喂得准,它用更少的对话轮次就能完成任务。轮次一少,省的不只是每轮的上下文,还有每一轮固定的模型调用开销——这两层叠加,才是成本差出 2 倍的真正原因。
③ 简洁即胜出:Databricks 明确写道,「像 Pi 这样简洁的 harness,在我们的工作负载上效果最佳」——胜出的不是最重的框架,而是最会管上下文的那个。这和很多人「框架越重越强」的直觉正好相反。

这三点合起来,就是 Pi 与一众「原生 harness」最本质的差别:它不靠堆模型、堆算力,而是靠把上下文管好,让同一个模型发挥得更高效。

值得一提的是,这个结论和 Databricks 基准的另一条发现互为印证——「token 单价很难反映真实成本」。原文里,Sonnet 5 每 token 比 Opus 便宜,却因为「更费劲」、多读了 token,单任务反而更贵。Pi 走的正是反向的路:不追求更便宜的 token,而是让每个 token 都花在刀刃上。换句话说,模型选型决定了单价的上限,harness 才决定真实成本的下限。

这和我日常的体验完全一致

我是 Pi 的拥护者,也是 Pi 社区的长期使用者。日常工程里用 Pi 跑真实任务时,我和 Databricks 团队有着几乎一致的切身经历:它靠更紧凑的工作集、每轮只喂必要的上下文,确实能在不掉质量的前提下,把 token 消耗和单任务成本压下来一大截。

所以在看到 Databricks 这份数据时,于我而言不是冷冰冰的基准数字,而是每天都在发生的事,被一家头部公司用严谨的实验确认了一遍。这种「外部硬数据印证个人体感」的时刻,对一个社区使用者来说挺难得。

对选型的启示

这份基准真正想传递的,不是「Pi 永远更便宜」——Databricks 自己也强调,这里的经验并非某个 harness 永远更便宜,也不是原生 harness 就一定更差。它指向三个更实用的判断:

  1. 模型选择只是其中一环。harness 对成本与质量的影响,常常不亚于模型本身,甚至更关键。同一模型换个 harness,成本就能差出 2 倍——这个量级,已经追上换一档模型带来的差异。
  2. 别只盯 token 单价。Databricks 的数据里,更便宜的模型反而因为「更费劲」、多读了 token,单任务更贵。真正该看的是单任务真实成本,而它高度取决于 harness 把上下文管得多好。
  3. 把「换模型、换 harness」做成一种能力。这也是 Databricks 投资 Omnigent 的出发点——让切换不再有摩擦,才能在不同任务上用对工具。

顺带说一句:我们也在生产里用 Pi

Pi 在基准里的优势不是停留在纸面——我们把它部署成了 pi.gottao.com,作为企业智能体的执行平台在云端常驻运行,Livo 的会议行动项也一键交给它执行。原因很简单:Agent 有会话、有状态,需要稳定在线的运行时;而 Databricks 测出的「每轮只喂三分之一上下文、成本更低」,只有在真实流量里持续跑,才会变成真正的成本节省。

同一套引擎,也是《Harness-Agent-Book》的代码实例。Pi 全名「Pi Agent Harness」,把 Harness 抽成独立的 harness/ 模块,书里每个概念都能指到真实文件——ReAct 对应 agent-loop.ts、上下文对应 compaction/、会话对应 session/,书末附录 F 还有一张完整代码地图。选它,是因为代码可读、边界清晰,而且就是 pi.gottao.com 上跑的同一套 harness——读者学的不是玩具代码,而是被真实流量和这份基准双重印证过的引擎。

结语

Pi 的差异化,说到底是一句朴素的话:把上下文管理做到位,比换更贵的模型更划算。对在大型代码库上用编程智能体的团队来说,这意味着评测时不能只比模型,一定要把 harness 纳入对照——而 Pi,是一个值得放进每一轮对比的选项。

想看 Databricks 完整基准的全貌(模型梯队、开源 GLM、token 单价陷阱等),可以读这篇完整译文