手术刀与瑞士军刀

全文约1650字，阅读需4分钟

上周刷到一条让我停下来的数据：Databricks 拿自家百万行代码库做了一场内部 benchmark，同一个模型、同一套思考配置，换一个调用框架（他们叫 harness），任务成本差了两倍以上。

两倍。模型没变，题没变，变的是"怎么跟模型说话"。

这让我想起老子的那句话——少则得，多则惑。放在 coding agent 的语境里，可以翻译成：你往模型脑子里塞的废话越少，它干得越好。

你的 agent 在替你读垃圾

Databricks 这篇报告（7 月 8 日发布，五位作者包括联合创始人 Matei Zaharia）最精彩的部分不是哪个模型赢了，而是一个被大多数人忽略的变量：harness。

他们测试了 Claude Code、Codex 和 Pi 三种 harness。结论很明确——在相同模型、相同思考力度下，Pi 的每任务成本最低，有些组合便宜了一倍还多。原因只有一个：Pi 每轮喂给模型的上下文大约是 Claude Code 的三分之一。

Databricks 画了一张哑铃图。Claude Code / Codex 那头，每轮往模型里塞大量上下文——文件内容、工具说明、历史对话——模型被迫在巨量信息里找线索。Pi 那头，上下文紧凑，工作集小，几轮就收工了。

更说明问题的是一个反直觉的案例。Sonnet 5 每 token 单价是 Opus 4.8 的 0.58 倍——便宜近一半。但 Databricks 的实测结果是：Sonnet 5 每个任务花了 $2.09，Opus 4.8 花了 $1.94。便宜的那个反而更贵。为什么？因为 Sonnet 5 吃了 1.9 倍的 token 才完成同样的任务——它工作得更久，读了更多文件，绕了更多弯路。质量还低 6 个百分点（81% vs 87%）。

Databricks 原文里这张 Pareto 图把这层关系画得很清楚——横轴是每个任务的成本，纵轴是通过率，Pi（蓝色点）几乎全部压在 Pareto 前沿上，同样通过率下成本更低。Claude Code（灰色点）的分布明显偏右偏贵。GLM 5.2 + Pi 的组合尤其亮眼：$1.25/任务，通过率 87.5%——和 Opus 4.8 的 87% 持平，价格却便宜了三分之一多。

这组数据直接戳破了一个常见假设：看 token 单价选模型。真相是，token 单价和任务成本之间隔着一个"推理效率"的变量，而这个变量很大程度上取决于 harness 怎么管理上下文。

Pi 的系统提示词大概 200 到 1000 个 token。Claude Code 的系统提示词大约 14000 个 token。多出来的那些在干什么？大部分是关于工具怎么用、边界在哪、什么能做什么不能做。这些内容对新手友好——模型不容易"翻车"——但对有经验的用户来说，它们就是噪音。模型每轮都要处理这些噪音，token 账单就这么涨上去了。

有位评测者说得很到位：“Pi 是你自己的镜像。如果你的流程有瑕疵，你会立刻在 token 消耗上看到。Claude Code 的 14000 token 系统提示词是个安全网，它默默吸收了你的低效。”

翻译一下：瑞士军刀什么都帮你兜着，但你永远不知道自己哪步走了弯路。手术刀不会替你思考，每一刀都是你自己的手感。

干净是干净的代价

那 Pi 是不是就该人人都用？也不是。

Databricks 的报告里有一条容易被跳过的发现：他们把模型分了三个能力梯队。顶层最强但也最贵，中层和下层对日常任务足够且便宜得多。他们的决策是——把更多工作推给 Haiku 和 GPT 5.4 Mini 这个级别的模型，贵的留给深度设计探索。

有意思的是，他们没有选 Pi 作为全员默认工具，而是投资了一个叫 Omnigent 的中间层，根据任务复杂度自动切换模型和 harness。

这说明什么？说明 Databricks 内部也承认 Pi 的哲学成立，但他们需要一个更工程化的解法——不是让每个工程师都学写精确的 prompt，而是让系统去路由。

Pi 的负面也确实存在。 Hacker News 上有人直说：“Pi 在写得好的 prompt 下表现好，在草率 prompt 下比原生 harness 差得多——后者更擅长’乱撞着往前走’。” 一个深度用户用了两个月后发帖吐槽 TUI 体验：每次思考或工具执行都全量重绘，长会话中令人崩溃；引用文件会导致终端乱码，得 reset 才能修。有篇六工具横评的作者总结得更干脆：“I love Pi, but I can’t use it.”

这些不是 bug，是取舍。Pi 的设计哲学决定了它对用户的要求更高——你得清楚自己在干什么，你的 prompt 得准确，你的流程得干净。它不会替你兜底。

对于 Databricks 这种体量的公司，解法是用路由层把不同工具分派到不同场景。对于个人开发者，更现实的思路可能是：日常小任务用 Pi 或轻量 harness 跑便宜模型，碰到复杂架构设计再上 Claude Code 配 Opus。别指望一个工具全搞定，也别被 token 单价误导——算算每任务的真实成本，答案可能完全不一样。

写在最后

Databricks 这篇报告最有价值的不是结论，是方法。他们从自家合并的 PR 里建 benchmark，每个样本人工审核，测试套件手动改写，甚至发现了 agent 能通过 git 历史偷看答案这个坑，直接封印了 git 记录。

这种"拿自己的代码测自己的工具"的思路，任何团队都能复现。他们原话说得好：“任何有合并 PR 积累的团队，已经坐拥一个没有任何模型训练过的 benchmark。”

回到 Pi 和 Claude Code 的选择。手术刀还是瑞士军刀，取决于你要的是控制力还是安全感。但要算清楚一件事：安全感是有价格的，而且那个价格可能比你以为的高两倍。

GitHub: earendilworks/pi Databricks 原文: Benchmarking Coding Agents