为什么越来越多厂商，选择用 PI 来做模型基准测试？ 我觉得最主要的原因还是因为整个Harness都非常的纯净，几乎没有什么对模型影响的因素，这样反而能真正的测试到模型的能力 很多时候我们说一个模型 Coding 很强，实际上测到的可能已经不是模型本身了，很多时候其实是背后 harness 的功能 这里最具代表性的就是 Claude Code 专门对 Claude 模型做了优化 总结下来这几个点： 1、默认给模型的东西很少 核心就是 read、bash、edit、write 几个工具，System Prompt 也比较克制。 模型拿到任务以后，需要自己判断先看哪里、怎么改、什么时候测试，很多行为不会被 Harness 提前安排好。 这时候模型规划能力行不行，很快就能看出来 2、Tool 越少，测试变量也越少 最近有人拿同一个 Qwen3.8-27B，对比 Pi 和 DeepSeek Harness。 一边每轮暴露 4 个 Tool Schema，另一边是 19 个，光输入 Token、TTFT 和整个运行过程就已经出现明显差异 所以有时候我们以为自己在比较模型，其实从第一轮开始，两边拿到的“试卷”就已经不一样了 更有意思的是，Qwen 社区甚至有人发现，只是在请求里面加入 Tool Schema，都可能直接改变模型的 reasoning 长度 这也是我最近特别有感触的一点： Harness 不是模型外面一个无关紧要的壳，它本身就在改变模型怎么思考 3、模型的问题在 Pi 里面也更容易暴露 规划差，会来回读同几个文件 Tool Call 不稳定，很快就开始报错、重试 Context 能力不行，任务做长以后开始忘前面的判断 如果外面有一套很重的 Workflow 或 Sub-agent 帮忙兜底，这些问题有时候反而没那么容易看出来。 这也就回答了我前面有人问我的问题：为什么我没有把 PI 当做我的主力去做使用，而是大部分时间拿来当做一个测试平台 因为我很多工作都在 Codex 上 像 Computer Use 只有在 Codex 上使用才可以如此丝滑 还有很多多端同步的特性也只能在 GPT 这样完整的生态上使用 其实就像苹果生态一样：生态+模型绑定了