同一个模型换个 harness，成本最多差 5 倍，成功率几乎不变

原文来源：HarnessTax（UC Berkeley Sky Lab） — 21 种「模型 × harness」组合的实测：harness 的选择几乎不影响任务成功率，却能让同一个模型的成本相差数倍，作者把这笔隐形开销称为 harness tax。

先说清楚 harness 是什么：它是管理模型工具调用、上下文和任务执行的那套软件系统——Claude Code、Codex CLI、Cursor 里那个循环，都是 harness。模型提供智能，harness 决定这份智能被用出来多少。所以当你「选一个编码智能体」时，实际上是在同时选模型和 harness，哪怕你的注意力只在模型上。

现在已经有数百万人在用编码智能体，但 harness 选择的影响一直不清楚。换一个 harness，同一个模型能不能解更多题、少花点钱？

UC Berkeley Sky Lab 和 Arena 的团队做了一个实验：把 21 种「模型 × harness」组合——7 个模型配 3 个 harness（Claude Code、Codex CLI、Pi）——放到 SWE-bench Lite 和 Terminal-Bench 2.0 两个基准上跑。三个结论都有点反直觉：

1. 在他们测的两个基准上，harness 的选择对任务成功率几乎没影响，但会显著影响成本——同一个模型的成本最多能差 5 倍。
2. 简单的 harness 一样能打。 Pi 是一个极简的开源 harness，在成本和成功率两方面都很有竞争力。
3. 模型在其他 harness 里可能跑得比自己家的更好。 也就是说，你的 Claude 模型未必需要 Claude Code。

实验怎么做

每个基准随机抽 30 道题，每种「模型 × harness」组合在每道题上跑 3 次，捕捉多次尝试之间的波动。配置上一律用各 harness 的原生设置，选高 effort 档，把每次尝试限制在 100 个 agent turn 以内，以控制长任务的成本；turn 的定义和 effort 档位都按各 harness 自己的口径。任务成败用各基准的官方评测器判定。

成本统计用一份固定价格表（2026 年 9 月 1 日的直连 API 价格），同一个模型在不同 harness 下用同样的价格计算。每道题的 3 次尝试先取平均，再对 30 道题取平均，置信区间用 10,000 次 bootstrap 重采样估计。SWE-bench Lite 上他们屏蔽了所有任务容器的外部网络访问，关掉 Claude Code 和 Codex 的默认联网工具，并在 API 请求层面拒绝托管工具的声明。

发现一：harness 主要影响成本，不是正确率

同一个模型往往能在成本相差很大的情况下取得差不多的成功率。 GPT-5.6 Luna 在两个基准上成本最低，Claude Fable 5 在 SWE-bench Lite 上成功率最高。开源权重的 Kimi K3 在 SWE-bench Lite 上紧贴帕累托前沿、离 GPT-5.6 Sol 不远，在 Terminal-Bench 2.0 上就落在前沿下方一点。但这些模型在不同 harness 之间的表现没有实质差异。

以 Fable 5 为例：在 Claude Code 里解掉 97.8% 的尝试，在 Codex 和 Pi 里各是 96.7%——而 Claude Code 的成本大约是 Pi 的两倍（$1.33 对 $0.67）。

成本差距不止发生在 Fable 5 身上。在共用的模型上，按成本比值几何平均计算：SWE-bench Lite 上 Claude Code 的成本约为 Pi 的 2.0 倍、Codex 的 1.6 倍；Terminal-Bench 2.0 上约为 Pi 的 1.5 倍。与此同时，harness 对成功率的平均影响在 SWE-bench Lite 上不超过 ±2%，在 Terminal-Bench 2.0 上大约 ±5%。

为了几乎一样的质量多付钱，就是所谓的 harness tax——同一个模型只因换了 harness 就多付的那笔隐形成本。当你接受一个编码智能体的默认 harness、从不比较其他选项时，可能就在交这笔税。所以模型评测应该把同一个模型在常用 harness 下的成本和成功率一起比，而不是只比模型。

发现二：四个工具的极简 harness 也能上前沿

Pi 只提供 read、write、edit、bash 四个工具，就在两个基准上都摸到了帕累托前沿。

为了搞清 harness 设计怎么影响花费，团队看了完成尝试的成本、记录的 turn 数和初始上下文。

agent 可以用差不多的 turn 数，花掉差很多的钱。 Fable 5 在 SWE-bench Lite 上，Pi 和 Claude Code 平均每次尝试分别是 15.4 和 15.3 个 turn，成功率只差 1.1%，成本却差一倍。也就是说，每个记录在案的 turn 花费更高——当然，不同 harness 对 turn 的定义本身也不一样。

harness tax 从第一次模型调用就开始了。 7 个模型全都如此：Claude Code 的平均初始上下文是 Pi 的 10 倍以上，指令更长，工具 schema 更大。这些额外上下文会推高成本，虽然总花费还取决于缓存、生成的 token 和后续调用。

Pi 和 Codex 的表现说明：用现有模型做开源 harness 研究是有机会的。 研究者不需要拿到闭源 harness，也不需要和模型一起联合训练，就能在 SOTA 编码 harness 这个层面做研究。更丰富的 harness 功能对别的模型、负载或交互场景可能仍然有价值，所以 harness 的复杂度应该被当成一个需要实证的 trade-off。

发现三：模型在自己家 harness 之外也能打

厂商针对自家编码环境做的优化，并不保证那是最佳搭配。

厂商确实会针对自己的编码环境优化模型——OpenAI 就说过 GPT-5-Codex 是为 Codex 里的软件工程场景优化的。但在 6 个 Anthropic 和 OpenAI 模型、两个基准的 12 组对比中，有 9 组是「别的 harness」拿到了最高的实测成功率。

• Sonnet 4.6 在 SWE-bench Lite 上，Codex 里解掉 68.9%，Claude Code 里是 66.7%，成本相近。
• GPT-5.6 Sol 在 Terminal-Bench 2.0 上，Pi 里成功率 83.3%，Codex 里是 78.9%，而成本大约是后者的一半（$0.42 对 $0.76）。

这些结果说明模型的能力是通用的、可以迁移到其他 harness 上的。同一家厂商并不保证最佳搭配。真正实际的问题仍然是：对给定的模型和负载，哪个 harness 在成本和成功率之间给出了最好的平衡。

结论与局限

结论可以压成一句：同一个模型能在成本相差悬殊的情况下拿到相近的成功率。 在他们测试的基准上，简单的开源 harness 有竞争力，模型在自己家的 harness 之外也表现良好。而只盯着任务成功率看时，harness tax 很容易被忽略。

跨模型来看，Pi 和 Codex 常常能以比 Claude Code 更低的成本拿到相近的成功率。这些结论只限于他们测的两个开源基准，而模型在训练中可能见过这些题目，换别的基准和负载结果可能不同。

这项研究延续了此前的一个判断：模型和系统配置应该放在一起选。对编码智能体来说，harness 选择是个更紧迫的问题，因为它用量大、分布广。下一步自然是把 harness 评测和自动选型搬进真实开发流程——那里需求不断变化，开发者会给出反馈，任务还会跨会话延续。

再往远看，harness 的必要性取决于编码智能体的角色定位。做日常任务时，编码智能体本质上就是通向模型智能的接口：管理上下文、访问工具、执行任务。模型越强，可能越用不着今天这套脚手架，通用编码智能体因此应该优先考虑成本效率和可靠性，很多任务并不需要花哨的附加功能。而在模型能力边界上的难题——比如科学发现——智能体仍然能从那些提供结构化引导的 harness 中受益：帮助探索想法、评估候选方案、从反馈中学习。

harness 研究可以被看作一种帮模型推进知识边界的方式，顺带解锁智能的下一个阶段。但不该让用户自己去调这些配置。真正该做的是一个会随着任务展开而自适应、同时保持通用的 harness。