HarnessTax：Harness 对编码代理有多重要？

【HN用户评论摘要】 我们确实需要更好的利用基准。似乎没有可靠的来源可以根据所有开源模型对主要工具进行基准测试。我也希望围绕 Pi 的讨论不要总是使用成本/代币计数作为衡量标准。它的令牌效率惊人，但是如果您不关心令牌计数，它如何再次叠加 opencode 和其他代码？我的经验是，该工具主要是为了防止失败的工具调用、错误的编辑等类似的事情而进行改进，但对 更重要的是您使用对目标模型进行微调的工具。要使用 Claude 模型编辑文件，您应该使用 Edit(file_path, old_string, new_string, Replace_all) 但对于 GPT 模型，您应该使用 apply_patch_call(patch) （其中 patch 是具有自定义语法的自定义补丁字符串）。看起来较新的模型在 narive 工具调用方面表现更好，而在看起来与默认类似的自定义工具方面表现较差工具。https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/ 我认为这非常重要，尤其是当您查看该工具所做的一切时，从执行循环和上下文管理到反馈。线束基本上是事实的底层来源。通过编码代理，我注意到简单的任务通常可以用相当简单的线束来处理。但隐藏的成本实际上是围绕环境而定的。我看到的更有趣的事情之一是，两个不同的工具可以进行相似数量的模型调用，同时消耗非常多的资源。 这里的“利用”一词对于“代理”一词来说是超载的，这是令人担忧的。撇开这一点不谈，还有很多因素很重要。 “利用”上下文、执行模式（并行与顺序）、委托给其他模型的能力等。最佳利用使用并发执行+子代理，并且不会停留在一个模型上。无论本机代理上下文（指令）如何，这些策略都会极大地影响成本和性能。这种单线束分析是sh 我自己的发现与这项研究是一致的：拥有一个编码工具很重要，但它们之间的差异被夸大了。就我个人而言，我用 Pydantic-AI 的薄包装取代了 OpenCode，作为 Pi-Agent 的 Python 模拟，通过 Hermes 进行无头使用。它们都会完成这项工作 - 我只是更喜欢划分访问控制。保持工具的表面积很小还有一个额外的好处，即保留我的理解并能够轻松地将其适应我喜欢的工作流程 原始链接：https://harnesstax.github.io/