重新评估 Harness 自进化：提升来自更好的 Harness，还是更多次尝试？

2026 年上半年，Agent 领域出现了一批“Harness 自进化”研究。它们通常会引入一个专门负责优化系统的 Meta Agent，用来先分析目标 Agent 的执行轨迹和任务反馈，再根据结果来调整对应 Harness，这里的 Harness 包括 Prompt、工具、中间件、记忆和控制逻辑。相关自进化研究给出的实验结果都相当亮眼。

「Rethinking the Evaluation of Harness Evolution for Agents」这篇论文关注的是一个更基础的评估问题：到底这些性能提升，是来自 Harness 本身的改进，还是来自更多的采样、反馈与重试？

为此，作者把 Harness 自进化与并行采样、顺序精炼等更简单的方法放在相同条件下比较。让它们使用同一个底层模型和初始 Harness，每个任务都拥有 5 次执行机会，只是使用这些机会的方式不同。与此同时，分开优化 Harness 的任务与最终评估任务，来检验演化结果是否能迁移到新任务。

实验结果表明，在 Terminal-Bench 2.1 上，“Harness 自进化”没有超过最简单的重复采样；当演化得到的 Harness 被用于未参与优化的新任务时，带来的平均提升也几乎可以忽略。

Harness 自进化的评估盲区

现有的 Harness 自进化评估中有两个容易混淆性能来源的盲区。

第一个是搜索预算。Harness 自进化本身就是一个反复执行、分析反馈、修改 Harness、再次验证的搜索过程。和直接使用初始 Harness 运行一次相比，这一过程天然会消耗更多的推理资源。如果只比较最终任务的成功率，额外搜索带来的收益就很容易被算到 Harness 的改进上。此时看到的性能提升，可能来自更好的 Harness，也可能只是 Agent 获得了更多尝试机会。

第二个盲区是任务重合。许多方法会利用公开 Benchmark 中的任务轨迹和单元测试反馈来优化 Harness，最终仍在同一批任务上报告成绩。经过多轮修订后，Harness 很容易积累与具体任务相关的命令顺序、文件路径、已知错误和验证方式。它在当前任务集上的表现可能因此提高，但这些改动能否迁移到新任务，还需要单独验证。

图 1：无单测反馈时四种方法的平均 pass@1。虚线表示初始 Harness 的 68.2 分

作者给出了一组结果数据：在没有单元测试反馈时，，并行采样（Parallel Sampling）的平均 pass@1 为 72.3（上图蓝色柱状图），Harness Scaling 为 71.8（上图粉色柱状图），顺序精炼（Sequential Refinement）为 69.3（上图黄色柱状图），Harness 自进化只有 67.4（上图绿色柱状图），甚至低于初始 Harness 的 68.2。

这说明，增加 Harness 修订过程并不会自然带来更高的任务成功率。

四种方法的统一预算

为了区分“多试几次”和“改进 Harness”带来的收益，实验将四种方法放在同一预算下比较。每个方法使用相同的底层模型和初始 Harness，每个任务都拥有 K=5 的执行预算，区别只在于预算如何分配，以及每轮更新的对象。

图 2：四种方法的总览

其中，并行采样把预算用在宽度上，通过多次独立尝试覆盖更多行动路径；顺序精炼把预算用在深度上，让后一轮根据前一轮的执行轨迹来调整方案。这两种方法都不直接修改 Harness，主要优化当前任务的解法。

Harness 自进化则将一批任务的执行轨迹存入经验库，再由 Meta Agent 总结反复出现的失败模式，逐轮修改共享 Harness，目标是形成一套可以跨任务复用的设计。Harness Scaling 是为这项研究专门加入的对照组：它同样修改 Harness，但每次只针对当前任务。这个对照会把“修改 Harness”与“获得通用 Harness”区分开。如果任务级的 Harness Scaling 已经获得相近的收益，那么跨任务演化积累下来的内容，就更可能只是针对具体任务的临时修复。

图 3：并行采样、顺序精炼、Harness 自进化 与 Harness Scaling 的机制对比。来源：原文 Figure 2。

实验设计与对照条件

实验采用 Terminal-Bench 2.1 作为评测集，包含 89 个命令行任务。该版本修复了 Terminal-Bench 2.0 中 28 个任务存在的外部依赖漂移、资源预算错配以及指令与测试不一致等问题。实验覆盖 Claude Opus 4.6、GPT-5.4 和 GPT-5.4 mini，统一使用 high reasoning effort，每轮最大生成预算为 128k Token，最终结果取两次独立运行的平均值。

为了保证对比公平，四种方法都从同一个极简 Harness 出发：Agent 只有一个 Bash 工具，不包含 Skill、中间件和持久记忆。所有方法的计算预算统一为 K=5；AHE 在每个 Harness、每个任务上只执行一次 Rollout，使总执行次数与其他方法保持一致。

实验还关闭了 AHE（Agentic Harness Engineering）原有的 Explore Agent。该组件会从外部检索针对当前 Benchmark 调整过的 Harness，保留它会让外部检索收益与反馈驱动的 Harness 自进化混在一起。关闭后，实验更集中地检验 Meta Agent 能否仅凭任务轨迹和反馈，逐步形成更有效的 Harness。相应地，最终结果评估的是 AHE 的 propose-and-refine 演化循环，不代表包含外部检索的完整系统。

三组实验的结果

缺少单元测试反馈的场景

在这个场景设置中，Agent 只根据自己生成的轨迹判断结果好坏。并行采样会让模型从五条候选轨迹中自行选出一条，顺序精炼则返回最后一轮修订的结果。

图 4：无单元测试反馈时的 pass@1

如上所示，并行采样是唯一在三个模型上均有提升的方法，平均分从 68.2 提高到 72.3。Harness Scaling 的平均分为 71.8，并在 Claude Opus 4.6 上取得 76.0 的单项最高分，但在 GPT-5.4 mini 上几乎没有收益。Harness 自进化的平均分降至 67.4，其中 GPT-5.4 从 75.3 降到 69.7，下降了 5.6 分。

这个结果反映出自我反馈的稳定性问题。Meta Agent 需要从执行轨迹中判断失败原因，再据此修改 Prompt、工具或中间件。一旦判断存在偏差，早期误判就可能被写入下一轮 Harness，并持续影响后续执行。并行采样的五次尝试彼此独立，单次错误不会干扰其他轨迹，因此在缺少外部正确性信号时会更加稳定。

具备单元测试反馈的场景

在这里，单元测试起到的作用是为后续迭代提供明确反馈，并帮助系统从多条轨迹中选出通过测试的结果。此时，pass@1 用来衡量单次执行的平均成功率，pass@5 衡量五次尝试中至少成功一次的任务比例，两者之间的差距可以反映重复采样带来的额外覆盖。

图 5：有单元测试反馈时的 pass@1 与 pass@5

有了可验证的反馈后，所有方法都明显超过初始 Harness，说明可靠的外部信号本身很有价值，但两种 Harness 方法依然没有超过简单基线。并行采样的平均 pass@1 最高，为 86.0；顺序精炼的平均 pass@5 最高，为 91.8。Harness 自进化的平均 pass@1 只有 75.8，接近初始 Harness 的 72.9；当允许五次尝试后，它的 pass@5 才提高到 86.2。

这里最值得关注的是 pass@1。如果多轮 Harness 修订形成了更好的 Harness，新 Harness 应该提高下一次独立执行的成功率，并直接反映在 pass@1 上。实际结果中，较明显的收益主要出现在 pass@5，说明系统依靠多次尝试覆盖了更多解法，但单次执行质量并未同步提高。将相同预算用于并行采样或顺序精炼，收益反而更加稳定。

搜索任务与测试任务分离的场景

为了检验 Harness 是否具备跨任务的复用能力，89 个任务被拆分为 45 个训练任务、10 个验证任务和 34 个测试任务。Harness 自进化在训练任务上收集反馈，根据验证集表现选择最佳版本，最终只在未参与搜索的测试任务上报告 pass@1。

图 6：Harness 自进化在独立测试任务上的泛化结果

演化后的 Harness 让 Claude Opus 4.6 从 63.3 提高到 64.5，增加 1.2 分；GPT-5.4 仍为 72.1，没有变化；平均提升只有 0.6 分。此前在同一批任务上搜索和评估时出现的收益，换到独立任务后几乎消失。这说明当前演化过程积累了较多与训练任务绑定的修复信息，能够迁移到新任务的 Harness 设计原则仍然有限。

Meta Agent 修改 Harness 的实际内容

从修改内容看，Meta Agent 的行为并不混乱，很多编辑都有明确的工程动机。Harness 自进化通常先从 Prompt 和长期记忆入手，加入跨任务反复出现的行为规则，例如关注剩余轮次与时间预算、尽早生成可交付结果、修改脆弱状态前先备份、结束前核对任务约束。当提示层收益趋缓，它会继续修改 Middleware：加入轮次预算追踪器，在接近阈值时提醒 Agent 收尾；截断过长的工具输出；通过 Finalization Gate 阻止 Agent 在交付物缺失或未经验证时结束。工具层的调整则包括修正容易误导模型的说明，并在命令失败时补充恢复提示。

Harness Scaling 的编辑会更贴近当前任务。Meta Agent 会把上一轮 Rollout 暴露出的具体信息写入下一版 Prompt 或记忆，包括已知 Bug、实现模板、文件路径、命令顺序和验证检查项。它也会压缩执行流程，将重复轮询、探索性命令和缓慢的安装步骤替换为更紧凑的命令计划，并要求提交前完成语法检查、单元测试或本地校验。

这些修改单独看都很合理，但整体收益依然有限。关键在于，大量编辑保存的是“这次任务该怎么修”，能够抽象为“以后遇到同类任务该怎么做”的策略较少。许多被写入 Harness 的信息，本来就能由具备基本探索能力的 Agent 在单次 Rollout 中重新发现。持久化这些内容可以节省时间，却很少让原本无法解决的任务变为可解。与此同时，真正困难的任务往往受限于底层模型的领域推理能力，或 Harness 无法控制的外部条件；持续增长的 Prompt 和记忆还会占用上下文，抵消部分收益。

附录中的案例很能说明这种差异。caffe-cifar-10 的失败来自前台安装、重复轮询和训练启动过晚，修改后的 Harness 固定了后台安装和更紧凑的执行路径；db-wal-recovery 中，Agent 在备份前打开 SQLite 并触发 wal_checkpoint，导致损坏的 WAL 被删除，后续版本便加入“备份 .db、.db-wal、.db-shm 之前禁止打开数据库”的规则；cancel-async-tasks 将“不得削弱测试”写入 Harness；mteb-retrieve 则记录 query 与 passage 需要使用不同的 PromptType。这些修改主要解决具体任务中的操作顺序、参数和禁区，跨任务复用范围相对有限。

图 7：Harness Scaling 在六个任务中写入的失败修复信息

结论的适用范围

这些结果无法覆盖所有 Agent 场景。Terminal-Bench 2.1 中，极简 Prompt 加一个 Shell 工具已经能解决大部分可解任务，Claude Opus 4.6 和 GPT-5.4 的初始成绩也相对较高。剩余失败中，一部分可能来自模型自身的推理上限，继续调整 Prompt、工具配置或中间件的提升空间自然有限。这个 Benchmark 对 Harness 设计的敏感度也可能偏低，专用 Skill、复杂工具组合和多阶段工作流并非多数任务的关键条件。

评估设置同样存在边界。K=5 对自动 Harness 搜索来说并不算长，更多轮次能否形成更稳定的抽象仍需验证；每个 Harness 在每个任务上只有一次 Rollout，Meta Agent 判断版本优劣时仍会受到随机性影响；关闭 Explore Agent 有助于隔离演化收益，也意味着实验没有覆盖 AHE 的完整工作方式。因此，更准确的结论应限定在当前模型、当前预算和 Terminal-Bench 2.1 这类任务上：自动 Harness 自进化的收益尚未稳定超过简单的 Test-Time Scaling，跨任务泛化能力也相对有限。

更适合检验 Harness 自进化的任务集，需要同时保留足够大的提升空间，并让 Harness 成为影响成败的关键变量。例如，当任务必须依赖专用工具、Skill、权限管理、长流程状态维护或复杂验证机制时，更好的 Harness 才可能真正扩大 Agent 能够解决的问题范围。

Agent 工程中的评估启示

预算对齐决定改进是否成立。 当新 Prompt、工作流或记忆机制带来成绩提升时，还需要比较相同 Token、Rollout 和时间预算下的重复采样基线。直接多运行几次往往很强，却容易被忽略。只有在相同成本下仍取得更高的 pass@1、稳定性或泛化表现，才能说明系统设计本身带来了额外价值。

pass@1 与 pass@k 可以帮助判断收益来源。 当 pass@k 明显提高、pass@1 变化很小时，收益主要来自更大的搜索覆盖，瓶颈仍在单次执行的稳定性和结果选择；两项指标同步提高，才更接近策略或 Harness 层面的质量改善。团队在评估反思循环、Verifier、Subagent 或多路径执行时，也可以用这组指标区分“单次执行更可靠”和“多次尝试后更容易成功”两类收益。

持久化知识需要控制颗粒度。 Agent 在单次探索中能够低成本重新发现的信息，没有必要全部写入长期记忆或系统提示。真正值得沉淀的，通常是无法从公开环境直接推断的组织约束、私有接口语义、稳定的跨任务策略，以及操作失误后难以恢复的高代价禁区。持久化层越大，维护成本和上下文占用越高，因此写入标准需要比“这次修复有效”更严格。

搜索任务与最终评估任务也应分离。 Agent Benchmark 的样本量通常有限，切分后可用任务会进一步减少，但完全复用同一批任务，容易让具体修复、命令模板和失败经验进入 Harness，最终把任务适配误判为系统进步。即使无法进行大规模独立测试，也应保留一组从未用于 Prompt、记忆和 Harness 调整的任务，作为最终验收集。

对 Agent “自我改进”的重新理解

Harness 自进化仍然值得继续探索。现有研究已经表明，Meta Agent 能够读取执行轨迹、定位工程问题，并在 Prompt、Middleware 和工具层提出合理修改。当前更缺少的是可靠证据，证明这些修改能够在固定预算下稳定提升单次执行质量，并迁移到未参与搜索的新任务。

因此，评价一个“会自我改进”的 Agent，不能只看多轮搜索后的最高成绩，还需要回答三个问题：相同预算下，它是否优于简单重复采样；新 Harness 是否提高 pass@1；搜索阶段获得的改进能否迁移到独立任务。只有这三层证据同时成立，Harness 的变化才更接近可复用的系统能力。