编码智能体的关键不只是模型，而是如何设计 Harness

导语

编码智能体能否完成一个多步骤软件工程任务，不只取决于底层模型会不会写代码，还取决于外围 Harness 如何安排规划、工具调用和上下文。现有评测往往把这些部分打包成一个完整系统，难以判断某项机制究竟贡献了多少。论文《An Empirical Study of Harness Design for Coding Agents》尝试拆开这些组件，在固定执行循环的前提下逐项比较。

研究如何进行

研究团队构建了一个轻量级编码 Harness，保持主循环不变，只改变三类因素：规划机制、动作空间，以及上下文管理策略。实验覆盖四个模型，在 SWE-Bench Verified 和 Terminal-Bench 2.1 上测试，共比较 176 组匹配设置；上下文部分进一步涵盖五种管理策略和四档上下文窗口预算。研究不仅关注成功率，也观察成本与智能体轨迹，试图解释不同配置为什么有效。

四个核心发现

• 上下文越紧，管理越重要。 当可用上下文预算较小，智能体更容易因上下文溢出而提前终止。上下文管理的主要价值，是让执行继续推进到修改代码和验证结果，而不是显著改变智能体原本的行为。窗口变大后，这种准确率收益会减弱。
• 先规则压缩，再调用模型总结更划算。 在多种方案中，先用规则删除或省略低价值内容，再进行必要的 LLM 总结，在效率上表现最好。让被省略内容可恢复会增加系统复杂度，但模型很少主动使用这一能力，也没有带来准确率提升。
• 规划的角色取决于模型能力。 对较弱模型，规划像一种准确率支架：它帮助轨迹维持更久，使智能体至少能走到代码编辑阶段，但会增加额外成本。对更强模型，规划对准确率影响较小，主要作用转为减少编辑后的重复验证，从而节省成本。
• 工具接口不应一刀切。 预定义工具能帮助 Bash 能力较弱的模型，减少其对复杂 shell 操作的依赖。具备较强 Bash 能力的模型则可以仅通过 Bash 完成有效操作，并在尤其依赖命令行的任务上显著降低成本。工具越丰富并不必然越好，关键在于接口是否匹配模型和任务。

意义与影响

这项研究给编码智能体工程带来的启示，是把 Harness 看成“模型能力的放大器”，而不是固定模板。部署时可以先判断模型的 Bash 熟练度、任务是否命令行密集，以及上下文预算是否紧张，再决定是否加入规划器、预定义工具和摘要模块。评测也应报告成功率之外的成本、上下文溢出和执行轨迹，否则很难区分某个组件是在真正提升推理，还是只是在避免系统过早停止。

研究并未证明某一种配置适用于所有模型，而是说明 Harness 设计存在明显的条件依赖。未来更有价值的方向，可能是让系统根据模型能力、任务类型和实时上下文压力动态切换策略。

来源：Hugging Face Daily Papers