你的Claude模型真的需要Claude Code吗？
HarnessTax: How Much Does the Harness Matter for Coding Agents?
UC Berkeley团队最新研究揭示了一个被忽视的“Harness Tax”：在Coding Agents中，框架选择对任务成功率影响甚微，却可能导致成本高达5倍。测试显示，简单的开源框架Pi在成本和成功率上均能媲美Claude Code和Codex CLI。更令人意外的是，模型在自家框架外往往表现更佳，例如Claude模型在Pi上运行成本更低且效果相当。这意味着盲目接受默认框架可能让你白白多花钱，选择开源替代方案或许能释放模型真实潜力。
事实证明，你的Claude模型可能并不需要Claude Code。
HN 评论区
71- nojs
我们真的需要更好的 harness 基准测试。目前似乎没有可靠的来源能针对所有开源模型对主流 harness 进行基准测试。
我也希望围绕 Pi 的讨论不要总是把 cost/token 数作为衡量标准。它确实极其节省 token，但如果你不在乎 token 数，它在 opencode 和其他模型面前表现如何呢？
我的经验是，harness 主要起润色作用，防止工具调用失败、糟糕的编辑之类的问题，但对整体“智能”水平影响不大。不过 opencode 似乎比开箱即用的 Pi 更能抵御愚蠢的错误，这得益于它强制在每个线程中注入的额外上下文。
- lukax
更重要的是，你要使用目标模型微调时所用的工具。
例如，用 Claude 模型编辑文件时，应该用 Edit(file_path, old_string, new_string, replace_all)；而用 GPT 模型时，则应该用 apply_patch_call(patch)（其中 patch 是带有自定义语法的自定义 patch 字符串）。
看起来，新模型在原生 harness 工具调用上表现更好，但在那些看起来与默认工具相似的自定义工具上表现反而更差。
https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/
- Yashjain413
我认为这真的非常重要，尤其是当你审视该工具的所有功能时，从执行循环、上下文管理到反馈机制。harness 基本上就是底层的唯一事实来源。
在使用 coding agents 时，我注意到简单的任务通常可以用相当简单的 harness 来处理。但隐藏的成本其实在于上下文。我见过的一个有趣现象是，两个不同的 harness 可能发起相似数量的模型调用，但消耗的上下文量却大相径庭。
我最近好像看到过一篇比较 Claude Code 和 Pi 的论文，就提到了这一点。更多的上下文、更多的工具、更聚焦的上下文、更简单的循环，所有这些即使模型调用次数看起来相似，也会导致成本和性能的巨大差异。
- Supermancho
这里的术语“harness”被过度负载用来指代“agent”，这让人担忧。撇开这一点不谈，还有很多因素至关重要。比如“harness”的上下文、执行模式（并行还是串行）、委托给其他模型的能力等等。
最优的 harness 会采用并发执行 + 子 agent，并且不会局限于单一模型。无论原生 agent 上下文（指令）如何，成本和性能都会受到这些策略的巨大影响。这种单 harness 分析既肤浅又具有误导性，尽管“特定提供商的优化并不能保证最佳配对”这一发现可能是正确的，具体取决于你的衡量方式。
这只是一个起点。
- corv
我自己的发现与这项研究一致：
拥有 coding harness 至关重要，但它们之间的差异被夸大了。
个人而言，我已经用 Pydantic-AI 的一个轻量级封装替代了 OpenCode，作为 Pi-Agent 的 Python 风格对应物，通过 Hermes 用于无头（headless）场景。
它们都能胜任工作——我只是更喜欢为了访问控制而进行模块化隔离。
保持 harness 的表面积极小，额外的好处是让我能保持对它的理解，并能毫不费力地将其适配到我偏好的工作流中。