（来源：让你更懂AI的 PaperWeekly）

最近 Agent 领域有一个越来越热门的方向：Harness Evolution，也就是让 Agent 自动改进自己的运行框架。

这里的 Harness 包括 Prompt、工具、Memory、验证机制、控制逻辑，以及模型如何观察环境、调用工具和继续执行任务。

同一个模型，仅仅换一套 Harness，最终效果就可能差很多。

于是，一个很自然的想法出现了：既然工程师可以通过观察 Agent 的执行轨迹、分析失败原因，然后不断调整 Prompt、工具和工作流，那么能不能让 Agent 自己完成这件事？

Meta Harness、AHE、AEVO 等工作都在探索这个方向。典型流程大致是：先运行 Agent，观察 trajectory 和结果，再分析错误，修改 Harness，然后重新测试，如此循环。

Harness Evolution 开始被讨论为模型实现递归自我改进的一条可能路径。

但最近一项研究提出了一个非常关键的问题：Harness Evolution 带来的提升，究竟来自 Harness 真的变好了，还是因为系统实际上只是获得了更多次尝试机会？

目前很多 Harness Evolution 工作采用这样的实验方式：先在某个 benchmark 上运行 Agent，根据 benchmark 返回的结果不断修改 Harness，最后再用修改后的 Harness 在同一个 benchmark 上报告成绩。

问题就在这里。因为 Harness Evolution 本身就是一种搜索。

系统不断生成候选 Harness，不断执行任务，不断获取反馈，再决定下一轮怎么修改。这意味着它在整个过程中实际上消耗了大量额外 inference compute。

如果普通 Agent 也获得同样多的推理预算呢？比如不修改 Harness，而是简单地把同一个问题做五遍，然后从五个答案里选一个最好的。

又或者让 Agent 在第一次失败之后继续修改答案，再尝试第二次、第三次。这些方法通常被归入 test-time scaling，也就是测试时计算扩展。

因此，真正公平的问题应该是：在相同反馈和相同 inference budget 下，Harness Evolution 是否仍然优于简单的重复采样和迭代修正？

研究者认为，这才是判断 Harness Evolution 本身是否真正有效的关键。

作者在 Terminal Bench 2.1 上设计了一组对照实验。所有方法都从同一个极简 Harness 开始，只提供一个 bash 工具，没有额外 Skills，没有 Middleware，也没有持久化 Memory。

每个任务的计算预算统一设置为 (K=5)。实验使用 Claude Opus 4.6、GPT 5.4 和 GPT 5.4 mini。这五次计算预算可以有四种不同的花法。

论文标题：

Rethinking the Evaluation of Harness Evolution for Agents

论文地址：

https://arxiv.org/abs/2607.12227

代码地址：

https://github.com/rethinking-harness-evolution

博客地址：

https://yikee.github.io/harnessevolution/

第一种：Parallel Sampling

Harness 完全不动。Agent 独立执行任务五次，然后从多个结果中挑选最终答案。本质上就是：多试几次。这是横向增加搜索宽度。

第二种：Sequential Refinement

Harness 依然不动。但 Agent 可以看到之前一次执行的结果，然后在此基础上继续修改和完善。也就是说：第一次做错了，看看哪里错了，然后继续做。这是纵向增加搜索深度。

第三种：Harness Evolution

传统意义上的 Harness Evolution。系统不是直接优化某一个任务的答案，而是根据一批任务产生的经验修改一个共享 Harness，希望新的 Harness 能让之后的任务整体表现更好。作者使用 AHE 作为具体实现。

第四种：Harness Scaling

作者还设计了一个很有意思的中间方案。每执行一次具体任务，就根据刚刚的 trajectory 修改这个任务自己的 Harness。也就是说，它不是面向整个数据集学习一个通用 Harness，而是针对当前任务即时调整 Harness。

结果一

没有 Unit Test 时，Harness Evolution 甚至打不过 Test-Time Scaling。

第一组实验不给 Agent 提供 Unit Test。也就是说，系统并不知道答案到底对不对，只能根据模型自己产生的执行轨迹判断应该如何修改。

最简单的 Parallel Sampling 反而表现最好。从 68.2 提升到 72.3，并且三个模型全部获得提升。

传统 Harness Evolution 的平均分则只有 67.4，甚至低于最初那个什么都没有优化的 Harness。

这个结果其实并不难理解。如果没有外部 verifier，Agent 必须自己判断自己的 trajectory 哪里出了问题。

但模型自己的判断本身可能就是错的。于是一旦第一轮分析方向出现偏差，后面的 Harness 修改就可能继续把这个错误放大。

相比之下，Parallel Sampling 什么都不学。既然模型有随机性，那我干脆多跑几遍。结果反而更加稳定。

结果二

给了 Unit Test，Harness Evolution 还是没赢。

接下来研究人员给所有方法加入 Unit Test。这时候 Agent 不再需要完全依靠自我判断。它能够得到一个比较可靠的 correctness signal。

结果确实所有方法都明显变强了。但冠军仍然不是 Harness Evolution。

在 Claude Opus 4.6 和 GPT 5.4 上，Parallel Sampling 的平均 pass@1 达到 86.0。Sequential Refinement 的平均 pass@5 达到 91.8。

相比之下：Harness Evolution 的平均 pass@1 是 75.8。Harness Scaling 是 82.6。这里有一个尤其重要的观察。

如果 Harness Evolution 真的学到了一个更好的 Harness，那么新的 Harness 在第一次执行任务时就应该更强。

也就是说，提升应该明显反映在 pass@1 上。

但实验并没有看到这一点。大量收益是在允许多次 trajectory，然后从中选择成功结果以后才出现的。

这说明一个可能性：所谓 Harness Evolution 的收益，很大一部分并不是来自“Agent 学会了一套更优秀的工作方式”，或者“解决了之前不能解决的问题“。

而只是：系统获得了更多次尝试机会。而 Test-Time Scaling 用一种简单得多的方式就实现了同样的事情。

更关键的问题：进化出来的 Harness 能泛化吗？

前面的实验还存在一个问题。Harness 是在 benchmark 上优化的，最后还是在这个 benchmark 上测试。

那它究竟是在学习一种通用 Agent 能力，还是在适应这一批具体题目？

为了验证这一点，作者把 Terminal Bench 2.1 拆成三部分：45 个训练任务。10 个验证任务。

34 个完全隔离的测试任务。Harness Evolution 只能看到训练任务。最后通过 validation set 选择最好的 Harness，然后在从未见过的 test set 上测试。

结果非常有意思。Claude Opus 4.6 从 63.3 提升到 64.5。GPT 5.4 从 72.1 变成 72.1。

两个模型平均下来：67.7 变成 68.3。也就是只提高了 0.6 个百分点。这和 Harness 在自己参与优化的那些任务上表现出来的提升形成了非常明显的反差。

作者因此认为，当前 Harness Evolution 学到的东西很可能存在较强的task specific adaptation。

换句话说，它更像是在适应 benchmark，而不是发现一种真正能够迁移到新任务上的 Harness 设计原则。

Harness Evolution 没用了吗？

倒也不能这么理解。这项工作的结论更准确地说是：我们可能高估了当前 Harness Evolution 实验所证明的东西。

一个重要原因可能来自 Terminal Bench 本身。

目前强模型在 Terminal Bench 上已经能取得相当不错的成绩。很多可以解决的任务，只需要 shell 加一个基础 Prompt 就已经能够完成。

剩下解决不了的问题，可能更多受到模型自身能力限制，而不是 Harness 设计限制。

如果底层模型根本不会解决某个问题，再聪明的 Harness 也不一定能够凭空创造出这种能力。

因此，真正适合研究 Harness Evolution 的 benchmark，也许应该满足两个条件。

第一，当前 Agent 还有足够大的提升空间。

第二，任务成功与否应该真正依赖工具、Skills、Memory、工作流和控制逻辑等 Harness 设计。

只有在这种情况下，我们才能真正看到：一个更好的 Agent 架构，是否能够让同一个模型获得新的能力。

这项研究最值得关注的地方，并不是它给 Harness Evolution 泼了一盆冷水。

更重要的是，它提出了一套对于 Agent 研究非常关键的评测思路：任何带有搜索、反思、Memory、Self Improvement 或迭代优化机制的 Agent 系统，都应该和相同计算预算下的简单 test-time scaling 做比较。

否则，很容易出现这样的情况：论文设计了一套非常复杂的 Agent 架构。里面有多个 Agent，有 Memory，有 Reflection，有 Evaluator，还有自动修改 Prompt 的模块。

最终 benchmark 提高了五个点。看起来这个系统设计非常有效。但如果把同样的 token 和 inference budget 给一个最简单的 Agent，让它直接做五遍，结果也提高五个点，那么真正带来提升的可能并不是那个复杂架构。

只是因为：模型多试了几次。

这其实是当前 Agent Evaluation 中一个越来越值得重视的问题。随着 Agent 系统越来越复杂，“用了更多计算”和“算法真的更聪明”这两件事，也会越来越难区分。

原文发表于 2026 年 7 月 17 日，研究代码和论文链接也附在原页面中。