编码代理的 harness 设计实证研究

执行摘要

编码代理的性能不仅仅由底层的大语言模型（LLM）决定，而是由模型与其「harness」——即规划、动作空间和上下文管理系统的交互所决定。研究表明，并不存在通用的「最佳」harness；相反，最优配置取决于模型的原生能力、具体任务类型以及可用的资源预算。

在上下文窗口预算紧张时，上下文管理最为关键。其主要价值在于防止上下文溢出失败，从而允许代理在不根本改变行为的前提下维持更长的执行轨迹。

关于上下文管理的关键发现包括：

预算敏感性： 当上下文窗口较小时，上下文管理的优势最为显著。例如，在 32k 窗口下，经过管理与未经管理的上下文之间的成功率差距可达 35.7 个百分点，而在 128k 窗口下则降至 2.7 个百分点。
最优策略： 在基于 LLM 的摘要之前，先进行基于规则的删减（移除不必要的上下文部分）能提供最高的整体效率。
可恢复性： 添加使删减内容可恢复的机制并不会带来准确率提升，因为模型很少使用这些功能。

随着模型能力的增强，规划组件的效用会发生变化。对于较弱的模型，规划充当准确率的支撑结构，防止其过早放弃任务。对于较强的模型，规划主要作为成本节约手段，通过减少冗余的验证步骤来降低开销，对最终准确率影响甚微。

这一趋势在工业实践中也有所体现；例如，一些新型前沿模型已移除了内置的任务跟踪工具（如 TaskCreate 或 TodoWrite），因为模型的原生推理能力已减少了对显式会话内规划工具的需求。

在预定义的结构化工具与原始的 bash 仅接口之间进行选择，取决于模型对 shell 命令的熟练程度。

具备 bash 能力的模型： 具有较高 bash 熟练度的模型在使用纯 bash 接口时表现更高效且成本更低。这在以命令行为中心的任务中尤为明显，因为它允许模型将多个代码修改合并为单个工具调用。
较弱的模型： 对于缺乏强大 bash 控制能力的模型，预定义工具能提高成功率，提供一种必要的结构来弥补模型在 shell 熟练度上的不足。

该研究得出结论，harness 设计应被视为一个条件性系统问题。开发者不应采用默认的一组组件，而应根据目标模型、任务类型和资源预算来选择组件。

行业从业者和研究人员强调了这些发现中的若干细微之处：

"如果一辆车 A 表现更好……这并不一定是因为它的引擎。也可能是由于更好的轮胎、更好的变速箱、更轻的车身……你的 harness 可以适应底层模型的原生能力，或弥补其缺失。"

一些批评者指出，该研究聚焦于 Nemotron 和 Mistral 模型，而非 Claude、GPT 或 DeepSeek 等提供商的当前前沿模型。然而，其他人认为，关于上下文窗口与管理策略之间关系的发现，对于现实世界中的使用模式（例如通过检查点机制来降低 API 成本）仍然高度适用。