同样一个开发任务、同一个模型，不同的 Coding Agent 会因为它们的执行策略不同，而产生截然不同的结果。有的 Agent 能够快速定位问题，并完成修改；有的 Agent 会反复搜索文件、尝试各种修复方式，花费大量 Token 最终完成相同的任务。
因此，如何让 Agent 更高效地执行任务成了 Harness 优化研究关注的问题。上周，清华大学、智谱等机构的研究人员在论文「HarnessPro: Recursive Harness Self-Improvement with Pareto Optimization for Performance-Cost Trade-offs」中提出的 HarnessPro 探讨的正是这一问题。
通过分析 Harness 的执行轨迹，不断迭代和优化 Harness，并结合生成的测试与 Pareto 优化筛选候选方案，Harness Pro 尝试在任务成功率和执行成本之间找到更合适的平衡。
Harness 自我优化中的成本问题
RHO（Retrospective Harness Optimization，回溯式 Harness 优化，是微软亚洲研究院提出的一种 Agent Harness 自我优化方法） 其实已经在尝试利用历史执行轨迹去优化 Harness，但任务成功率的提升也伴随着更高的运行成本。例如，在 SWE-Bench Pro 上，RHO 将 GPT-5.5 + Codex 的成功率从 59.0% 提升至 80.0%，平均单任务成本也从 1.88 美元增加到 2.68 美元。
这也反映出 Harness 优化面临的一个难题：增加探索、推理和验证步骤，有助于提高任务成功率，却也可能产生大量冗余操作；如果过度限制推理强度或工具调用次数，Agent 又可能因为信息不足而无法完成任务。
针对这一问题，HarnessPro 要求候选 Harness 的验证成功率不低于初始版本，并保留不同性能与成本组合的候选方案，以适应不同的执行预算。
HarnessPro 的递归优化流程
HarnessPro 的优化过程分为三个阶段：执行轨迹诊断、优化计划与修改、候选评估与筛选。
系统会先让初始 Harness 执行一组具有代表性的任务，分析其中的失败原因和冗余开销，并据此生成不同的修改方案。经过评估和筛选之后，表现好的 Harness 会进入下一轮的优化。
整个过程不改变模型权重，主要调整 Harness 中的指令、工具、Skill、Hook 和验证规则等组件。
图 1：HarnessPro 整体架构
从执行轨迹中定位问题
HarnessPro 会先通过 DPP（Determinantal Point Process，行列式点过程）筛选训练任务，兼顾任务难度和多样性，同时控制执行轨迹的收集与分析成本。论文实验中，每个基准测试选取 10 个训练任务，每个候选 Harness 对每项任务独立执行三次。
系统会记录完整的执行过程，包括模型响应、工具调用、环境反馈和最终产物，并统计任务结果、Token 消耗和执行延迟。轨迹分析器（架构图的 Trajectory Analyzer）根据这些信息，分析影响任务成功率或增加执行成本的问题。
轨迹分析器会对比同一任务的多次执行结果，识别反复出现的问题，并区分偶发的环境异常。例如，Agent 多次在同一个步骤失败，可能意味着 Harness 缺少必要的执行指导；如果任务已经完成，Agent 却仍在反复读取无关文件或运行相同测试，则可能存在冗余操作。
分析结果会整理成结构化的诊断记录，包含问题描述、对性能和成本的影响，以及对应的执行证据。每条证据都会关联具体的轨迹文件和事件位置，方便后续检查。
这些诊断记录会提供给后续的优化规划器（架构图的 Evolution Planner）。为了减少上下文的开销，系统会优先提供汇总后的诊断结果。等需要进一步了解问题时，系统再根据记录中的路径去查看原始的轨迹。如果诊断内容超过 64K Token，HarnessPro 会对内容进行摘要处理，避免分析结果占用过多的上下文。
从诊断结果生成优化方案
优化规划器接收当前 Harness 的完整实现、轨迹分析器的诊断结果，以及各候选 Harness 的执行指标和代码差异。通过比较不同候选的修改内容与实际表现，优化规划器可以判断哪些调整可能有效，并确定下一轮的优化方向。
例如，某个候选通过压缩工具输出降低了成本，但任务成功率有所下降；另一个候选保留了完整日志，虽然成本较高，却能完成更多任务。优化规划器可以结合两者的代码差异和执行结果，分析不同策略的效果，寻找进一步改进的空间。
针对每个候选 Harness，优化规划器会生成三份计划，分别侧重降低成本、平衡性能与成本，以及提高任务成功率。以探索步骤过多为例，成本优先的方案可能收紧工具调用预算，性能优先的方案则可能保留更多探索空间，同时减少重复检查。
每份计划都需要明确修改对象、实施方式和预期效果。研究人员还要求优化策略具有一定的通用性，避免针对训练集中的个别任务添加硬编码规则。
优化规划器可以查看训练任务的执行轨迹，但无法访问验证集和测试集的信息。其中，验证集用于候选筛选，测试集仅在优化结束后使用，以防止 Harness 针对评估任务进行定向优化。
将修改方案落实到 Harness
Harness 编辑器（架构图的 Harness Editor）根据优化计划修改 Harness 的文件和运行组件，包括提示词、配置文件、Skill、工具脚本和 Runtime Hook 等。
例如，如果优化规划器发现 Agent 在环境检查时反复执行相同命令，Harness 编辑器就可以增加统一的环境探测工具；如果工具输出过长，也可以调整返回结果的处理方式，减少不必要的上下文消耗。
每份优化计划都会在独立的工作空间中实施，并通过 Git 提交保存修改记录。这样不仅能让多个候选 Harness 并行演化，还方便优化规划器在下一轮比较不同方案的代码差异。
对于每个父代 Harness，优化规划器会提出三个优化方向，Harness 编辑器据此生成三个新候选。假设当前保留了三个不同的父代，就会产生九个新候选。加上原有的三个父代，共有十二个 Harness 参与评估。
原有的父代也会保留在候选集合中，避免新方案效果不佳时丢失此前表现较好的配置。
HarnessPro 如何修改 Harness
论文附录提供了真实的执行诊断和优化计划。从这些记录中，可以更具体地看到 HarnessPro 如何分析执行行为，以及修改最终落实到了哪些组件。
Mailman：成功任务中的冗余开销
在 Terminal-Bench 2 的 Mailman 任务中，Agent 需要配置 Mailman 和 Postfix，实现邮件列表的加入、退出及邮件投递功能。同一个 Harness 独立执行了三次，全部通过了自动生成的测试，但轨迹分析器仍发现了明显的冗余开销。
首先，Agent 在确认主要配置范围后，继续读取大量 Mailman 和 Postfix 的配置文件及源码。三次执行的输入 Token 总量分别达到约 106 万、176 万和 252 万，其中部分源码检查并未对最终任务结果提供明显帮助。
其次，Agent 在完成邮件投递测试后，又多次运行已有测试覆盖的验证程序。这些操作涉及创建 Unix 用户、处理邮件队列和等待重试，增加了 Token 消耗和执行时间。
轨迹分析器还发现了一些偶发异常。例如，一次执行因邮箱文件权限问题导致邮件退回，Agent 为此额外检查日志并重新测试；另一次则因服务启动命令未正常结束，增加了进程状态检查步骤。
轨迹分析器将这些问题分别记录，并关联到具体的执行轨迹。虽然三次执行都完成了任务，但其中存在的冗余探索、重复验证和额外环境处理开销，仍然为 Harness 优化提供了依据。
Evolution Planner：一份真实优化计划
论文附录还展示了 Terminal-Bench 2 中的一份 Medium 优化计划，说明优化规划器如何将改进方案落实到具体的 Harness 组件。这份计划与前面的 Mailman 诊断记录属于两个独立示例。
任务执行指令： 修改 README.md，要求 Agent 在开始任务前明确目标和交付结果，优先检查相关文件和环境信息，并围绕实际修改内容进行验证，减少不必要的重复检查。
推理预算路由： 在 runtime.json 中增加运行配置，通过 router_prompt.txt 根据任务描述选择推理强度。简单任务可以使用较低预算，复杂的代码修改和调试任务则分配更多推理资源。
工具输出控制： 新增 guarded-run 工具，为命令执行设置超时，并将完整日志保存到文件中。工具只向 Agent 返回执行状态、耗时、日志路径和部分输出，减少长日志对上下文的占用。
环境检查： 新增 quick-probe 工具，一次性获取工作目录、Git 状态和常用开发工具的可用情况，减少重复的环境检查操作。
优化计划还考虑了潜在风险。例如，推理预算路由可能误判任务难度，导致资源分配不足；压缩工具输出也可能遗漏重要的错误信息，因此需要保留读取完整日志的方式。
这些修改分别作用于任务执行、推理资源分配、工具输出和环境检查。HarnessPro 可以通过组合不同策略调整 Agent 的运行方式，再通过后续评估判断修改效果。
图 2：真实诊断与优化计划
自动生成测试与候选选择
完成 Harness 修改后，HarnessPro 还需要评估各候选方案的实际效果。但在缺少官方测试和标准答案的情况下，如何准确判断 Agent 是否完成任务，成了候选评估面临的一个难题。
Test Synthesizer：为任务生成固定测试
此前的 RHO 主要依靠 LLM 判断执行轨迹，但研究人员发现，这种方式可能高估任务成功率。例如，Agent 完成代码修改后报告任务结束，执行过程中也没有明显错误，但实际功能可能仍存在缺陷，LLM 却将其判断为成功。
为了解决这一问题，HarnessPro 引入测试生成器（Test Synthesizer），根据任务描述和初始 Harness 的执行轨迹生成测试，用于检查任务的最终产物。这些测试在优化开始前生成一次，并在后续迭代中保持不变，确保不同候选 Harness 使用相同的评估标准。
HarnessPro 还对训练集、验证集和测试集进行了划分。训练集用于收集执行轨迹，为 Harness 修改提供依据；验证集用于评估和筛选候选方案，其结果不会提供给优化规划器；测试集仅在优化结束后使用，通过官方测试评估最终效果。
每轮评估时，各候选 Harness 分别执行验证任务，再使用固定的生成测试检查结果，统计任务成功率和执行成本。
图 3：LLM 判断与生成测试的对比
研究人员还在 Terminal-Bench 2 和 SWE-Bench Pro 的部分训练任务上比较了两种评估方式。结果显示，LLM 直接判断的失败识别召回率为 41.7%，使用生成测试后提升至 83.3%。
这表明，在该组实验中，生成测试能够识别更多实际失败的任务。虽然仍可能存在测试覆盖不足的问题，但固定的测试条件能够提高评估的一致性，减少对 LLM 主观判断的依赖。
Pareto 筛选：保留不同性能与成本的候选
候选评估完成后，HarnessPro 会得到每个 Harness 的验证成功率和平均执行成本。系统首先淘汰成功率低于初始 Harness 的候选，避免为了降低成本而牺牲任务完成能力。
接下来，系统通过 Pareto 支配关系进一步筛选。例如，候选 A 的成功率为 80%，成本为 1.5 美元；候选 B 的成功率为 78%，成本为 1.8 美元。由于 A 在两项指标上都优于 B，B 就会被淘汰。
如果候选 C 的成功率为 83%，成本为 2 美元，那么 A 的成本更低，C 的成功率更高，两者各有优势，都可以保留在 Pareto 前沿上。
考虑到 Pareto 前沿可能包含较多候选，HarnessPro 还会进一步筛选。系统先对成功率和成本进行归一化处理，再计算各候选与理想成功率、最低成本之间的加权平方距离，从中选择最符合不同优化目标的方案。
图 4：Harness 的递归更新与筛选，展示多轮迭代中候选的更新、筛选和三种配置的形成过程
具体来说，Lite 优先考虑成本，Heavy 更看重成功率，Medium 则兼顾两项指标。三种模式采用不同的权重，各自选择加权距离最小的候选，作为下一轮优化的起点。
由于三种模式独立选择，也可能选中同一个 Harness，因此每轮最终保留的不同候选数量可能少于三个。这种方式既能保留不同的性能与成本配置，也能控制后续迭代需要评估的候选数量。
演化后的 Harness 采用了哪些机制
研究人员分析了 HarnessPro 最终生成的 Harness，发现系统主要通过动态分配推理资源、控制工具调用和压缩上下文等方式降低运行开销。
其中一项优化是根据任务描述动态调整推理强度和工具调用预算。对于简单任务，Harness 可以减少推理和探索开销；面对复杂任务，则保留更多推理与验证资源。不同运行模式也有各自的任务判断规则。
部分 Harness 还通过 Runtime Hook 控制执行过程。例如，在 Terminal-Bench 2 的 Medium 模式中，当系统选择标准执行配置后，Hook 会根据工具调用次数采取不同措施：
-
达到 14 次： 提醒 Agent 避免重复检查，并考虑并行调用工具。
-
达到 26 次： 提醒 Agent 集中完成任务和最终验证。
-
达到 44 次： 阻止 Agent 继续调用工具。
这些阈值来自特定 Harness 的演化结果，并不适用于所有任务。通过这种方式，Agent 可以在任务前期进行必要探索，接近预算上限时则逐步收敛，集中完成剩余工作。相关提醒会附加在工具返回结果中，尽量保持提示词前缀稳定，以便复用 Prompt Cache。
在上下文管理上，部分 Harness 参考了 RTK 的做法，对工具输出进行压缩。比如，删掉日志中的重复内容，缩短过长的输出，同时精简 Developer Instructions 中反复出现的指令，减少 Token 消耗。
但压缩和限制也要平衡。Agent 如果过早停止探索，可能会漏掉解决问题所需的信息；工具输出压缩得太多，也可能把重要的报错信息一并删掉。论文的对照实验就发现，将 RHO 的推理强度统一调低后，虽然执行成本明显下降，但在 Terminal-Bench 2 和 SWE-Bench Pro 上，任务成功率分别降至 62.7% 和 59.0%。
这也说明，单独采用某项成本优化策略，可能影响任务完成效果。HarnessPro 因此需要结合候选评估结果，寻找更合适的策略组合。
实验结果与分析
研究人员在 Terminal-Bench 2、SWE-Bench Pro 和 ProgramBench 三个基准测试中评估了 HarnessPro，分别涉及终端操作、代码仓库问题修复和程序重建任务。
实验采用 GPT-5.5 + Codex 和 GLM-5.2 + Claude Code 两种组合，并与初始 Harness、RHO 等方法进行对比。
以 GPT-5.5 + Codex 为例，HarnessPro Heavy 与 RHO 的结果如下：
从结果来看，Heavy 模式在三个基准测试中均取得了更高的成功率，同时降低了单任务执行成本。
对于更关注成本的场景，Medium 模式也取得了不错的效果。例如，在 SWE-Bench Pro 上，其成功率达到 79.00%，接近 RHO 的 80.00%，而平均单任务成本从 2.68 美元降至 1.26 美元。
多轮演化与组件作用
论文还记录了 HarnessPro 在不同迭代轮次中的表现。在 Terminal-Bench 2 上，Heavy 模式的成功率从第一轮的 74.6% 提升至第三轮的 80.8%，平均单任务成本则从 0.91 美元降至 0.72 美元。
不过，成功率和成本并非每轮都能同步改善。例如，在 SWE-Bench Pro 上，Medium 模式从第一轮到第二轮，成功率由 70.0% 提升至 77.0%，成本也从 1.57 美元增加到 1.66 美元。到了第三轮，成功率进一步提升至 79.0%，成本则降至 1.26 美元。
这表明，HarnessPro 在迭代过程中可能经历阶段性的性能与成本取舍，并通过后续优化改善候选方案的表现。
图 5：多轮迭代的性能与成本变化
消融实验进一步检验了各组件的作用。在 SWE-Bench Pro 上，移除优化规划器后，Medium 模式的成功率从 79.0% 降至 73.0%，平均单任务成本从 1.26 美元增加到 1.42 美元。移除测试生成器后，不同模式的任务成功率也有所下降，说明这两个组件对优化结果都有一定影响。
需要注意的是，论文中的执行成本主要根据模型 Token 用量及对应价格计算，尚未完整计入 HarnessPro 自身在多轮优化中产生的计算和运行开销。
结语
HarnessPro 通过执行轨迹诊断、自动迭代 Harness、生成测试和多目标筛选等方式，让 Agent 能够根据历史的执行反馈持续地优化运行策略。
从实际演化结果来看，动态预算、工具调用控制和输出压缩等策略已有一定的工程实践基础。HarnessPro 进一步探索了如何自动发现、组合和评估这些策略，并从中选择性能与成本更均衡的 Harness 配置。
目前，相关实验主要集中在 Coding Agent 场景。生成测试的可靠性、跨任务的泛化能力，以及递归优化本身的计算成本，仍有待进一步验证。