Coding Agent 的 Harness 设计实证研究
An Empirical Study of Harness Design for Coding Agents
这篇研究深入剖析了 Coding harness 如何决定自主编码 Agent 的长期工程表现。研究固定执行循环，单独测试了 planning、action space 和 context management 三个组件。在 SWE-Bench Verified 和 Terminal-Bench 2.1 上，通过 176 组匹配设置对比发现：当 context-window 预算收紧时，context management 的价值凸显，主要防止溢出失败；先规则后 LLM 的摘要策略效率最高；planning 对弱模型是精度支架，对强模型则是成本节省器；bash 能力强的模型用纯 bash 接口成本更低。轨迹分析揭示了各组件对执行路径的具体影响，为模型和预算感知的 harness 设计提供了模块化框架。
Planning 从弱模型的精度支架转变为强模型的成本节省器，而精度几乎没有变化。
HN 评论区
59- kaufmann
让我完全困惑的一点是“harness”这个词的用法。
它是指让 LLM 能够使用工具并执行计划的“马具”，还是指通过多重护栏确保 LLM 遵循预期路径的“短绳”？
我看到这两种含义都在被使用。前者仍然说得通，但我看到很多人采用的是第二种解释。
- gps372
还没细读完整的 PDF，内容非常详尽，目前只有几点引起了我的共鸣。
基本上，如果汽车 A 的表现优于汽车 B（无论是速度、油耗还是总体表现），这未必是因为它的引擎更好。可能是轮胎更好、变速箱更优、车身更轻，或者功能易用性更佳等等。
即使使用相同的模型，你也可以通过不同方式实现 AI 功能（例如用于 BI 的 AI）——通过 ReAct 循环、规划与执行，或是混合模式。你可以选择无状态、有状态或基于 RAG 的架构，具体取决于你更看重结果准确性还是分析深度。你可以让 LLM 生成意图（需要的推理能力较少），或者直接生成查询语句（需要更强大的模型）。
你的 harness 可以适应底层模型的固有能力，也可以弥补其不足。例如，上述例子中的查询生成要求模型具备 MOE 能力，而意图生成则不需要。
- hosamsh
规划和工具是为执行而设计的，正因如此，它们无法决定最终的代码准确性。如果产品是面向用户的（也就是所有产品），那么应该由一个专门设计成模拟真实用户行为的“盲测” harness 来作为裁决者。
- lieret
很酷的研究，我们确实需要更多关于 harness 作用的严谨研究。我也要说，目前并没有太多基准测试能证明更复杂的 harness 始终优于极其简单的 agent。不过我本人也有偏见，因为我写了 https://github.com/swe-agent/mini-swe-agent/，这大概是现有最精简的 agent（起初只有 100 行代码，全部包含在内），它被用于许多基准测试，如 DeepSWE、terminalbench、programbench（看起来在 TB3 中仍排名靠前，但在 TB4 中并未使用最佳模型进行评估）。
- vblanco
这项研究是基于 Nemotron 模型和 Mistral 进行的，因此与当前前沿的廉价中国模型以及 Claude/GPT 的大模型关联不大。研究中未包含 Qwen 或 DeepSeek 是一个重大缺失。