HarnessTax 研究显示，选择编码代理的 harness 主要影响成本，而非成功率

TL;DR

选择不同的编码代理 harness 可使解决问题的货币成本最高相差五倍，而成功率几乎不受影响，且一个极简的开源 harness（Pi）通常与专有系统同样有效。

HarnessTax 评估概览

HarnessTax 项目评估了 21 个模型–harness 组合，涵盖 七种语言模型（Claude、GPT‑5 系列、Kimi K3 等）和 三种编码代理 harness（Claude Code、Codex CLI 和开源的 Pi）。每组组合在两个公开基准测试——SWE‑bench Lite 和 Terminal‑Bench 2.0 中随机选取了 30 个任务，每个任务运行 三次 以捕捉变异性。成本以 token 美元为单位，使用 2026 年 9 月 1 日的价格清单进行测量，成功率则使用各基准测试的官方评估器进行衡量。

该研究报告了三个关键发现，每个发现均在下方独立章节中详细描述。

发现 1：harness 选择主要影响成本，而非正确性

结论： 相同模型在不同 harness 下的成功率几乎相同，但 token 成本最高可相差 5×。

  • 在给定模型下更换 harness 时，SWE‑bench Lite 的成功率仅变化 ±2 %，Terminal‑Bench 2.0 的变化为 ±5 %。
  • 成本比率（几何均值）显示，在 SWE‑bench Lite 上，Claude Code 的成本约为 Pi 的 2.0×，Codex 的 1.6×；在 Terminal‑Bench 2.0 上，Claude Code 的成本约为 Pi 的 1.5×。
  • 示例：Claude Fable 5 在 Claude Code 中解决了 97.8 % 的尝试，在 Codex 和 Pi 中均为 96.7 %，但 Claude Code 每次尝试的成本为 $1.33，而 Pi 仅为 $0.67。

“为几乎相同质量支付额外费用，仅仅因为使用了不同的 harness，就像支付了一笔……Harness Tax 💰” – 作者，HarnessTax。

启示： 仅关注成功率的用户可能无意中承担了隐藏的“harness 税”。评估时应始终比较不同 harness 之间的 成本调整后性能。

发现 2：极简 harness 也能具有竞争力

结论： 轻量级开源 Pi harness（仅提供四个工具：read、write、edit、bash）在两个基准测试中均达到了帕累托前沿。

  • 轮次数量 在不同 harness 间相似（例如，Fable 5 在 SWE‑bench Lite 上，Pi 和 Claude Code 平均约为 15.4 轮 vs. 15.3 轮），但 Claude Code 的每轮 token 使用量约为 Pi 的两倍。
  • 初始上下文大小 是主要成本驱动因素：Claude Code 的首次模型调用包含的指令和工具模式字符数比 Pi 多出 10 倍以上，在模型输出前就显著增加了 token 消耗。
  • 更简单的 harness 降低了开销，同时未牺牲成功率，表明 丰富的专有 harness 功能对许多任务并非绝对必要。

“Pi 和 Codex 的有效性表明，利用现有模型进行开源 harness 研究存在巨大机会。” – 作者，HarnessTax。

启示： 开发者可通过构建或采用轻量级 harness 实现成本效益高的编码辅助，尤其当安全或对齐约束在其他地方处理时。

发现 3：模型在非原生 harness 中表现往往更好

结论： 提供商特定的 harness 优化 并不能保证 最优的模型–harness 配对；在 12 次跨模型比较中的 9 次，替代 harness 达到了最高成功率。

  • Anthropic 的 Claude 模型在 Codex CLI 和 Pi 中表现相当甚至更优，尽管它们是为 Claude Code 优化的。
  • OpenAI 的 GPT‑5.6 Sol 在 Pi 中实现了 83.3 % 的成功率，而在 Codex 中为 78.9 %，成本仅为后者的 ≈50 %。
  • Sonnet 4.6 在 Codex 中解决了 68.9 %，在 Claude Code 中为 66.7 %，成本相近。

“模型的能力具有兼容性、可泛化性，可以迁移到其他 harness 中。” – 作者，HarnessTax。

启示： 实践者应 为给定模型尝试多种 harness，而非假设提供商默认的 harness 是最优的。

Hacker News 社区反响

  • 成本 vs. 健壮性： 多位评论者指出，尽管 Pi 成本低廉，但 Claude Code 和 Codex 可能因更丰富的系统提示而对格式错误的工具调用更具 健壮性。
  • 基准测试局限性： 用户指出，这两个开源基准测试可能偏向于在训练中见过类似数据的模型，而真实工作负载可能展现出不同的成本-准确率权衡。
  • 工具调用兼容性： 有评论强调，使用 原生工具签名（如 Claude 的 Edit，GPT 的 apply_patch_call）对性能的影响可能大于 harness 本身。
  • 安全考量： 一些人认为，专有 harness 中的额外上下文通常包含安全指令，虽然成本较高，但在生产环境中可能是必需的。
  • 未来方向： 讨论强调了对 并发 harness 设计、动态 harness 选择 和 同时捕捉 token 成本与健壮性的标准化基准测试 的兴趣。

开发者与研究人员的实用建议

  1. 衡量成本，而不仅仅是成功率。 在评估编码代理时，记录 token 美元的同时也记录通过/失败指标。
  2. 从轻量级 harness 开始。 Pi 的四工具设计表明，极简主义对许多任务已足够；仅在需要特定安全或工具功能时才增加复杂性。
  3. 测试跨 harness 配对。 即使模型以专有 harness 推广，也应尝试替代方案（如在 Codex CLI 中运行 Claude 模型），以发现更便宜且同样有效的配置。
  4. 关注初始提示大小。 大型系统提示可能主导成本；精简不必要的指令和工具模式可立即节省成本。
  5. 预期不同工作负载的变异性。 报告结果适用于 SWE‑bench Lite 和 Terminal‑Bench 2.0；不同领域（如科学代码、大规模重构）可能表现出不同的成本-准确率曲线。

未来研究方向

  • 基准扩展： 创建更广泛的任务集，包括长周期和多会话工作流，以测试超越当前开源基准的 harness。
  • 自动化 harness 选择： 开发元代理，根据任务特征和实时反馈动态选择最具成本效益的 harness。
  • 安全与成本权衡： 量化安全相关上下文（如对齐提示）对成本和失败模式的影响。
  • 开源 harness 生态系统： 鼓励社区贡献轻量级 harness，促进跨提供商和模型的互操作性。

引用

如果您在工作中使用 HarnessTax 的结果，请引用：

@misc{pan2026harnesstax,
  title  = {{HarnessTax: How Much Does Harness Matter for Coding Agents?}},
  author = {Pan, Melissa Z. and Yang, Shuo and Arabzadeh, Negar and Chiang, Wei-Lin and Stoica, Ion and Zaharia, Matei},
  year   = {2026},
  url    = {https://harnesstax.github.io/},
}

Sources

相关