DeepSeek + Pi 王炸组合跑赢 Claude Code？Pi创始人：这套组合我早押中了
8 月 11 日，Pi Harness 创始人 Mario Zechner 转发了一组数据：
开发者 0xEvan 用 Pi 调用 DeepSeek V4 Flash，处理了近 10 亿输入 Token，缓存命中率达到 99.93%，最终只花了 2.65 美元。如果没有缓存，同等用量预计需要 132 美元。
同一天，另一名开发者 Shantanu Goel 表示，
社区里这种案例还有不少。
这也让人想起 Mario 今年 5 月对 Pi 与
当时，这只是他看到开发者用 Pi 搭配
Pi 搭配 DeepSeek，跑赢了 Claude Code？
Composio 是一家为 AI 智能体开发工具的公司，最近进行了一项公开对比测试。他们选用同一个模型
拿下第一名的是 Pi Agent：30 项任务通过 20 项，成功率达到 66.7%；Oh My Pi 通过 17 项，排名第二；Claude Code、Codex 和 Deep Agents 均通过 16 项；Prime Agent 通过 15 项，另有 6 次运行未被计分，其中 2 次因评分器处理超时而无法评分，另外 4 次没有留下记录；Hermes Agent 同样通过 15 项；OpenCode 通过 14 项，排名最后。
同一个模型，仅仅更换外面的 Harness，成功率便从 46.7% 升至 66.7%，相差整整 20 个百分点。
成本差距更加明显。Pi 平均完成一项成功任务只花费 0.028 美元，Claude Code 需要 0.195 美元，接近前者的 7 倍。
Pi 完成任务的中位时间为 132.2 秒，虽然略慢于 Claude Code 的 122.7 秒和 OpenCode 的 129.7 秒，但综合成功率、速度与成本来看，它交出了这轮测试中最突出的成绩。
这项测试体现了所谓的“Harness 乘数效应”：围绕 AI 搭建的工具会放大或削弱模型的实际表现。选对 Harness，同一个模型可以同时变得更可靠、更高效；选错 Harness，即使底层模型的智能水平完全相同，任务成功率和运行效率也可能明显下降。
Composio 因此强调，不应孤立评测模型；如果一份 Agent 排行榜只写模型名称，却没有交代使用了哪套 Harness，那么这个分数就是不完整的。
极简的 Pi，为什么反而赢了
Composio 公司的测试还有一个值得注意的细节：Pi 几乎没有添加额外配置，采用的是全新、未经修改的默认安装，只接入了测试所需的 MCP 服务器插件。除此之外，Pi 没有进行自定义设置、调优或特殊配置。正是这样一套接近开箱即用的方案，最终通过了最多的任务。
再看 Prime Agent。它在八种 Harness 中产生了最庞大的会话，部分会话消耗多达 350 万 Token，并进行了 33 次工具调用。可以把它想象成一个智能体还没有真正开始工作，就先给自己列出了一份电话簿那么长的任务清单。
这些会话规模过于庞大，评分器仅仅为了处理它们就发生了超时。两次运行无法评分，另外四次没有留下记录，因此共有六次运行未被计入成绩。即使只看有效运行，Prime 通过的任务数量也只与 Hermes 相当，耗时却接近 Pi 的两倍。
这组数据呈现出一个明显的反差：功能和会话最为庞杂的 Prime，最终被自身的运行负担拖慢；更加轻量的 Pi 则以较低开销通过了最多任务。至少在这项测试中，增加更多层并没有换来更好的结果。
这也对过去“配置越多，效果越好”的思路提出了挑战。人们通常会选择最大的模型，叠加每一个插件、每一个扩展以及各种复杂的功能层，默认功能越多，智能体就越强。这项测试提供了另一种思路：选择一款速度快、成本低的模型，把它放进干净、轻量的 Harness 中，再用真实任务检验两者的组合。
因此，干净的 Harness 会给模型提供一条从接收任务到完成任务的短路径，臃肿的 Harness 则会让它四处绕路。这就是默认安装能够击败重量级配置的原因：路径更短，走错方向的机会也更少。
99.9% 的缓存命中率是怎么做到的？
Pi 本身并不是一款专门为
关键在于，这是一种前缀缓存，匹配需要从第一个 Token 开始。如果上下文前部发生变化，其后的大量 Token 就可能无法继续命中原有缓存。前缀越早发生变化，后面被“连坐”的 Token 就越多。
一套典型的 Agent 请求里，通常包含系统提示词、工具定义、对话历史和本轮新增内容。Agent 每执行一步，都要再次携带前面已经出现过的大量上下文。会话越长，重复内容越多，理论上越适合使用缓存。但如果 Harness 每轮都重新整理这些内容，加入新的时间戳、改变工具顺序或者重写历史摘要，再长的上下文也很难被稳定复用。
这也催生了一批专门优化
我尝试将 Reasonix 的一些性能优势移植到针对 Pi 优化的 Deepseek 软件包中。它只有在使用 Deepseek API 时才会激活，但激活后，我的缓存命中率稳定在 99.7% 到 99.9% 之间。
Reasonix 的核心设计原则是：保持上下文前端稳定，采用追加而非修改的方式，并将变更成本降至最低。
具体实现上，Reasonix 在启动时会注入一份精简、稳定的环境摘要，而不会在每轮对话中重新生成。过时的工具输出会在触发摘要压缩之前被截断和清理，因此，二十轮前一次 cat 命令产生的大量结果，不会一直留在提示词前缀中。Reasonix 还对内置工具的 Schema 契约进行了文档化，并在变更时进行回归审查，因为工具定义一旦在没有提示的情况下被重新调整，就会导致缓存失效，而且表面上看不出任何异常。
在双模型模式下，执行模型和规划模型会分别运行在各自独立且缓存稳定的会话中，而不会被交错放进同一个上下文。这一点是这个项目中最巧妙的设计。引入规划模型最简单的做法，是把规划轮次直接插入同一段对话，但这会破坏两个角色的缓存稳定性。将它们放在独立会话中，可以让各自的提示词前缀保持不变。
Pi 生态中也出现了不少类似的第三方扩展。以 pi-deepseek-cache 为例，它同样将
Reasonix 强调“启动时注入稳定的环境摘要”，pi-deepseek-cache 的 P0 层做的正是同一件事——在 Agent 启动时冻结日期和当前工作目录，从根源上杜绝了 Pi 默认系统提示词中 Current date: YYYY-MM-DD 和 Current working directory: 这类动态内容导致的缓存失效。
Reasonix 强调“过时的工具输出要在压缩之前被剪枝和清理”，pi-deepseek-cache 的 P3 层则通过缓存友好的压缩来实现这一点——当对话历史过长需要总结时，使用 deepseek-v4-flash 在 temperature 为 0 的条件下进行确定性摘要，并对摘要结果做哈希缓存，确保相同的历史输入始终复用字节一致的摘要结果，避免因摘要文字波动而破坏前缀。
Reasonix 还提到“工具 Schema 契约文档化并在变更时回归审查”，pi-deepseek-cache 的 P2 层提供了类似的防护机制——通过 SHA-256 哈希对前缀进行诊断，追踪前缀何时发生变化，让开发者能及时发现缓存失效的根因。
这个扩展的降本效果非常直观：以 deepseek-v4-flash 为例，输入 Token 成本从每百万 Token 0.14 美元降至 0.003 美元，降幅达 98%；deepseek-v4-pro 则从 3.00 美元降至 0.025 美元，降幅达 99%。
写在最后
有趣的是，
官方 Harness 能带来什么特别之处？最核心的一点可能还是“原生适配”。第三方 Harness 只能通过公开 API 做逆向优化，而官方团队可以和模型训练团队背靠背协同，让模型针对 Harness 的调用模式做针对性优化，Harness 也能利用模型内部的非公开信息。这种深度整合，是任何第三方都做不到的。
本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：Tina，36氪经授权发布。
