打脸Agent自动演化：同等算力下不如简单重试，泛化提升仅0.6%

Rethinking the Evaluation of Harness Evolution for Agents

当前，让大语言模型自己优化其工具和提示词（即自动 Harness 演化）被视为通向更强 Agent 的前沿方向。许多研究宣称，通过让 Agent 分析自身失败轨迹并自动修改代码外壳，能在各类基准测试中取得显著的性能飞跃。

ArXiv URL：http://arxiv.org/abs/2607.12227v1

然而，来自 Allen AI 等机构的一项最新研究无情地戳破了这一幻象。该研究指出，现有评估协议存在严重的过拟合风险。在同等算力预算下，所谓的“自动演化”甚至不如简单粗暴的多次重试。更致命的是，在未见过的任务上，其泛化性能提升平均仅为惊人的 0.6%。

本文将深度解读这篇反思之作，揭示当前 Agent 自动演化研究中的评估漏洞，并探讨在工程实践中，算力究竟该花在“改外壳”上，还是“多解题”上。

核心争议：是设计变好了，还是算力堆出来的？

在构建复杂 LLM Agent 时，开发者通常会为其套上一个“外壳”（Harness）。这个外壳包含了系统提示词、可用工具、记忆机制、验证程序以及控制逻辑，决定了模型如何观察和行动。

近年来，业界提出了自动 Harness 演化算法。其核心思路是：让 Agent 收集基准测试中的历史轨迹和报错信息，然后自己写代码来修改外壳配置，并在相同的基准测试上反复验证。

这里隐藏着两个致命的评估漏洞：

算力分配不公：演化算法在训练阶段反复调用模型来搜索最优外壳，消耗了大量算力。如果在最终测试时，仅仅用一个静态的初始外壳与之对比，显然不公平。这就像一个经过长期考前集训的考生，去对比一个裸考的考生。
严重的过拟合风险：多数研究在同一个基准测试（如 Terminal-Bench）上既做外壳搜索，又做最终评估。这种“在测试集上训练”的做法，极易让 Agent 仅仅记住了特定任务的解法，而不是真正提升了通用的外壳设计能力。

为了解答“究竟是外壳设计变好了，还是算力堆出来的”这一问题，研究团队提出了一个统一预算下的评估框架。

统一算力预算下的四大策略对比

研究团队引入了一个非常形象的对照组概念。如果把模型当做考生，把任务当做考题，那么 Harness 就是考生的“文具和答题规范”。在固定总调用次数（预算 $K$）的前提下，我们有四种花掉算力的策略。

Figure 2: 四种在测试时消耗算力的方法对比。核心差异在于修改的是“轨迹”还是“外壳”，以及优化的范围是“实例级”还是“数据集级”。

1. 简单重试：并行采样

并行采样（Parallel Sampling）是最简单的 测试时扩展（Test-time Scaling）方法。相当于给考生发 $K$ 张同样的卷子，让他独立做 $K$ 次，最后挑最好的一张。

数学上，对于给定的初始外壳 $h$，独立抽取 $K$ 条轨迹：

\[y_1,\dots,y_K \sim \pi_{\theta}(\cdot\mid x;h)\]

如果有单元测试，最终输出 $\hat{y}$ 直接选择任何通过测试的轨迹即可。

2. 错题本重做：顺序优化

顺序优化（Sequential Refinement）同样不改外壳，但注重前后关联。考生做完第一遍后，根据报错信息（错题本）再做第二遍。

模型基于特定的摘要映射 $\Phi$ 来反思前一次的经验。对于第 $k$ 次尝试，轨迹生成依赖于之前的反思：

\[y_k \sim \pi_{\theta}\big(\cdot\mid x,\ \Phi(y_{k-1},R(y_{k-1},g));\ h\big)\]

这里的 $R(y,g)$ 表示轨迹在测试用例 $g$ 上的奖励。这种方法将算力投资在了深度探索上。

3. 考前总结答题规范：Harness 演化

外壳演化（Harness Evolution）是当前最火的方向。它利用一批训练任务提取共性问题，让元 Agent（Meta Agent）修改整个全局外壳。

在每一轮 $k$ 中，模型生成批量轨迹后，将其存入经验库 $\mathcal{C}_k$。随后，更新全局外壳：

\[h_k = \mathcal{M}\big(\Phi(\mathcal{C}_{k-1})\big)\]

其目标是最大化整个任务分布上的期望收益。

4. 现场改文具：Harness 扩展

外壳扩展（Harness Scaling）是本文提出的一个对照基线。它不追求全局通用，而是针对当前正在评估的这单个任务，现场让模型去修改外壳。

核心实验：严苛对照下原形毕露

研究团队在修复版的 Terminal-Bench 2.1 上，使用了 GPT-5.4 和 Claude Opus 4.6 进行了严谨的实验。他们将总步数预算限制为 $K=5$，并在三种不同设定下“扒下”了自动演化的外衣。

场景一：缺乏外部验证器时，自反馈噪音过大

在真实世界中，很多任务是没有完美的单元测试（Unit Test）来告诉你对错的。此时，Agent 只能靠自己判断。

实验表明，在此场景下，自动 Harness 演化表现最差。例如，Claude Opus 4.6 的初始通过率是 31.5%，演化后反而下降到 30.3%。这说明强如当代模型，也无法可靠地从自己的错误轨迹中提取出正确的指导信号来修改外壳，错误的反馈反而污染了全局配置。相对而言，直接进行并行采样达到了 39.3%。

Figure 1: 在无单元测试反馈的情况下，自动演化算法（蓝色）甚至跑输了极其简单的并行采样（紫色）。

场景二：拥有单元测试时，优势仍是“算力幻觉”

如果有明确的测试用例告诉你哪里错了，自动演化会变好吗？

数据依然打脸。虽然有了真实反馈，Harness 演化看起来进步了，但在 $pass@1$（一次通过率）指标上，依然跑输了简单的顺序优化。这说明所谓“进化”出的优秀外壳，并没有让 Agent 学会一次性做对以前不会的题。它能取得高分的唯一原因，是因为在测试集上反复刷题，本质上还是算力堆叠的结果。直接把多余的算力拿去优化具体的任务步骤，收益远高于去修改那个庞大的外壳。

场景三：泛化测试宣告“伪神”破灭

为了彻底验证是不是过拟合，研究者做了一个最关键的测试：将寻找外壳的任务集和最终测试的任务集完全隔离开来。

结果令人震撼。在全新的测试集上，经过长时间演化得出的“黄金外壳”，仅仅让 Claude Opus 4.6 提升了 1.2 个百分点，而对 GPT-5.4 甚至带来了 0 提升。平均泛化增益只有可怜的 0.6%。

这意味着，以前论文里动辄十几个点的提升，几乎全是因为他们在训练集上做测试！演化出的外壳根本没有提炼出通用的方法论，只是死记硬背了那些题目的专属解法。

为什么看似合理的修改毫无用处？

研究人员深入分析了 Meta Agent 在演化过程中到底修改了什么，发现其修改逻辑其实非常“合理”，但为何就是不见效？

从建议到强制：Meta Agent 初期会在系统提示词里加一些规则（比如“注意预算”、“多检查”）。当这些不奏效时，它会修改中间件，比如加入强制打断机制，或者拦截过大的工具输出。
死记硬背式优化：在任务级修改中，模型非常喜欢把上一次失败得到的经验直接硬编码到新提示词里。比如，强行记住某个库的安装路径，或者把几个命令打包成一个脚本。

这些修改确实解决了一些因为超时或配置错误导致的低级失败。但是，这些知识本来就是 Agent 在单次任务探索中就能自己发现的。把它们持久化到外壳里，顶多是帮模型省了一点时间，并不能让原本无法推导出的高难度逻辑题迎刃而解。

更糟糕的是，随着死记硬背的规则越来越多，提示词变得异常臃肿（Context Bloat）。过长的外壳反而分散了模型的注意力，抵消了那一点点省时间的收益。

对当前 Agent 开发的工程启示

这篇论文虽然像一盆冷水，但对一线开发者具有极强的指导意义：

首先，不要盲目迷信外壳自动演化。如果你的业务场景算力充裕，并且有可靠的验证手段，请直接使用测试时扩展（Test-time Scaling）。简单地让模型多做几次并行采样，或者基于报错串行重试，往往比费尽心机设计一个自动修改 Prompt 的系统要有效得多。

其次，规范 Agent 评测标准。如果你在做工具链优化，必须严格区分训练集和测试集。在你看不到的任务上取得提升，才是真正的系统级进步。

最后，警惕任务瓶颈的误判。目前的基准测试往往只需要基础的 Shell 工具即可完成。如果任务的瓶颈在于模型本身的推理能力（比如看不懂复杂的代码逻辑），哪怕你把外壳优化出花来，也无济于事。只有在那些极端依赖特定工具集配合的场景下，Harness 设计的价值才能真正显现。