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表示，DeepSeek V4 Flash在其他Harness中的缓存命中率通常为94%至97%，到了Pi中却能持续达到99%以上。Mario对此评论道：“使用本地模型时，这一点尤其好用。” 社区里这种案例还有不少。 这也让人想起Mario今年5月对Pi与DeepSeek V4这一组合的评价：“pi + ds4 == sovereign AI enterprise ready clearly.”换成更符合中文语境的话，大概就是：“Pi + DeepSeek 4，企业级AI这不就成了吗。” 当时，这只是他看到开发者用Pi搭配DeepSeek V4跑通一个终端俄罗斯方块后的一句调侃。三个月后，一项公开横向测试，却意外给这句话补上了数据。 Pi 搭配 DeepSeek，跑赢了Claude Code？ Composio 是一家为 AI 智能体开发工具的公司，最近进行了一项公开对比测试。他们选用同一个模型 DeepSeek V4 Flash，让它分别运行在 8 种不同的智能体 Harness 中，完成 30 项高难度的智能体任务。这些任务要求智能体采取行动、调用工具，并独立完成整个工作。 拿下第一名的是 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中，再用真实任务检验两者的组合。 DeepSeek V4 Flash顾名思义是一款Flash模型，定位更侧重速度和运行效率，并不以赢得模型智能竞赛为目标。轻量化配置的Pi此次占优，原因其实也简单。每增加一层，智能体就多了一个可能迷路的地方；每增加一个工具，它就多了一项需要做出的选择；每增加一份庞大的指令文件，它在行动前就要阅读更多噪声。 因此，干净的 Harness 会给模型提供一条从接收任务到完成任务的短路径，臃肿的 Harness 则会让它四处绕路。这就是默认安装能够击败重量级配置的原因：路径更短，走错方向的机会也更少。 99.9%的缓存命中率是怎么做到的？ Pi本身并不是一款专门为DeepSeek设计的Harness。它更像是一套面向开发者开放的Agent底座：Pi允许开发者通过扩展修改系统提示词、筛选对话历史、自定义上下文压缩，并动态增删或启停工具；在请求发给模型之前，开发者甚至可以直接检查和改写最终载荷。这种可编程性给DeepSeek的缓存优化留下了很大空间。 DeepSeek API会缓存请求中提示词的前缀。如果下一次请求开头的Token序列与上一次完全相同，服务端就会直接从缓存中读取这些Token，并以远低于普通输入Token的价格计费。缓存命中的价格，要比缓存未命中低得多。 关键在于，这是一种前缀缓存，匹配需要从第一个Token开始。如果上下文前部发生变化，其后的大量Token就可能无法继续命中原有缓存。前缀越早发生变化，后面被“连坐”的Token就越多。 一套典型的Agent请求里，通常包含系统提示词、工具定义、对话历史和本轮新增内容。Agent每执行一步，都要再次携带前面已经出现过的大量上下文。会话越长，重复内容越多，理论上越适合使用缓存。但如果Harness每轮都重新整理这些内容，加入新的时间戳、改变工具顺序或者重写历史摘要，再长的上下文也很难被稳定复用。 这也催生了一批专门优化DeepSeek缓存的Harness项目。开源Reasonix是一款围绕DeepSeek前缀缓存设计的终端编程Agent，其缓存表现受到不少开发者关注。一名更喜欢Pi的开发者甚至专门制作了DeepPi，试图把Reasonix的缓存优化方法移植到Pi中。他称，DeepPi在调用DeepSeek API时，缓存命中率可以稳定达到99.7%至99.9%。 我尝试将 Reasonix 的一些性能优势移植到针对 Pi 优化的 Deepseek 软件包中。它只有在使用 Deepseek API 时才会激活，但激活后，我的缓存命中率稳定在 99.7% 到 99.9% 之间。 Reasonix的核心设计原则是：保持上下文前端稳定，采用追加而非修改的方式，并将变更成本降至最低。 具体实现上，Reasonix