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 很容易积累与具体任务相关的命令顺序、文件路径、已知错误和验证方式。它在当前任务集上的表现可能因此提高，但这些改动能否迁移到新任务，还需要单独验证。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/45c8c9e94c3b88a52ec0ffc830b805db.png)

图 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 的执行预算，区别只在于预算如何分配，以及每轮更新的对象。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/13819362213546c4582817b8afb5b086.png)

图 2：四种方法的总览

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

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

![](https://developer.qcloudimg.com/http-save/yehe-12464096/dbb9563a9f2bd74efebab3fa6addd1ec.png)

图 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 只根据自己生成的轨迹判断结果好坏。并行采样会让模型从五条候选轨迹中自行选出一条，顺序精炼则返回最后一轮修订的结果。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/91679dd978c03c15117e122761ca2e51.png)

图 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 衡量五次尝试中至少成功一次的任务比例，两者之间的差距可以反映重复采样带来的额外覆盖。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/d3c8772379be94b77970410bf5ba14e1.png)

图 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。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/04cb13d90bd32c0e3cd7960ce2ede913.png)

图 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。这些修改主要解决具体任务中的操作顺序、参数和禁区，跨任务复用范围相对有限。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/6c4d96e550b66c7687525bdc3fef9819.png)

图 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 的变化才更接近可复用的系统能力。

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

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

人工智能

架构设计

算法

2026年研究发现，Agent领域"Harness自进化"方法在Terminal-Bench2.1测试中表现不佳，其性能提升主要来自额外尝试而非Harness改进。实验对比了并行采样、顺序精炼等方法，发现Harness自进化在相同预算下甚至低于初始Harness表现。研究揭示了评估中的两个盲区：搜索预算混淆和任务重合问题，指出当前Harness修改多为任务特定修复，跨任务泛化能力有限。

单元测试

中间件

数据库

SQLite

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

2026年研究发现，Agent领域"Harness自进化"方法在Terminal-Bench2.1测试中表现不佳，其性能提升主要来自额外尝试而非Harness改进。实验对比了并行采样、顺序精炼等方法，发现Harness自进化在相同预算下甚至低于初始Harness表现。研究揭示了评估中的两个盲区：搜索预算混淆和任务重合问...

重新评估 Harness 自进化：提升来自更好的 Harness，还是更多次尝试？-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐