重新思考Agent的Harness Evolution评估

TL;DR 自动 harness 演化方法在多轮搜索中并不优于简单的 test-time scaling 基线，且发现的 harness 改进泛化性有限，揭示现有评估协议存在根本缺陷。

问题

问题背景

LLM 智能体的自动 harness evolution 正成为提升任务性能的重要研究方向。它通过自动搜索最优的提示、工具组合或运行环境配置，替代人工设计，受到学界与工业界的共同关注。

现有方法局限

目前主流方法使用 单元测试反馈 驱动迭代搜索，并在 同一公开基准 上报告最终得分。这一评估协议存在两个关键局限：

• 搜索增益与设计增益混淆：harness evolution 本质是一次 迭代搜索过程，但现有研究未与同等计算预算下的 test-time scaling 基线（如并行采样、序列修正）进行公平对比，导致无法辨别性能提升是来自更优的 harness 设计，还是仅由额外搜索带来。
• 过拟合风险且缺乏泛化验证：搜索与最终评估共享相同任务集，所得结果极易 过拟合 到特定分布；同时缺失在 held-out 任务 上的泛化实验，使得改进的可迁移性存疑。

问题难度与重要性

该问题的核心挑战在于 解耦搜索行为与设计质量，需要细致控制比较条件（反馈类型、推理预算等）。随着智能体向复杂场景部署，评估公平性 与 泛化能力 已上升为行业焦点——若无法确认增益来源，自动设计方法将难以被信任和复用，影响整个智能体工程化的发展节奏。

行业类比

类似 神经架构搜索（NAS） 若缺乏与适当训练时间计算的基线对比，会放大架构创新的伪收益——这里的关键是区分“更有效的搜索”与“更有效地使用搜索”。

核心洞察

• **搜索预算混淆** ：自动 harness 演化的性能提升可能主要源于搜索过程本身，而非 harness 设计的改进。现有工作通常将性能归因于 harness 优化，但作者通过在同一任务集上控制反馈次数与推理成本进行对比，发现 test-time scaling 方法（如 parallel sampling、sequential refinement）在匹配预算下能与演化 harness 持平甚至更好。这表明过去报告的性能增益很可能来自额外的搜索开销，而非更优的 harness 配置，从根本上挑战了自动 harness 设计的有效性论证，并提醒研究者在闭环优化系统评测中必须将“设计本身”与“搜索过程”的贡献解耦。
• **评测协议过拟合** ：由于 harness 搜索与最终评估共用同一套公开基准，演化得到的 harness 容易过度适应特定任务集，导致泛化能力被高估。作者在 held-out 任务上的实验显示，即便演化 harness 在原任务上表现良好，其对新任务的提升也十分有限，甚至不及简单基线。这揭示了当前评测协议的根本缺陷：它无法区分真正的通用 harness 设计改进与针对特定基准的过拟合。从业者在构建类似的自动设计流水线时，必须引入严格的任务分布外评估，确保自动化方法的实际工程价值免受 benchmark hacking 的误导。

方法

核心思路

这项工作重新审视了 自动 Harness 演化（automatic harness evolution）的评估方法论，指出已有方法普遍存在两个根本问题：1) 演化搜索过程本身使用了任务反馈进行多轮迭代，混淆了 搜索算力 与 Harness 设计改进 的贡献；2) 搜索与最终评估复用同一基准，存在 过拟合风险。为此，作者提出一套公平对照评估协议。

评估框架设计

评估框架将 Harness 演化与两类基线进行严格比较，所有方法共享相同的 反馈信号 和 推理预算（inference budget）。

• Parallel Sampling：对同一任务独立采样多个解答，取最优结果，作为 test-time scaling 的基准。
• Sequential Refinement：基于上一轮失败反馈迭代改进解答，模拟 agentic 的自我修正过程。
• Harness Evolution：利用搜索过程（如 Agentic Harness Engineering 的 Explore Agent）在任务集上自动发现更好的 Harness 配置（例如提示词模板、工具调用策略），随后在该 Harness 下执行单次推理。
• Harness Scaling：一种结合 Harness 演化与采样次数的变体，旨在验证在 Harness 已改进后，是否还能通过增加采样进一步提升。

所有方法均控制 单元测试用例（unit test cases）的使用方式，以区分有无 ground-truth 反馈的两类场景。

评估与泛化测试

• 在 Terminal-Bench 2.1 上，使用 GPT-5.4 与 Claude Opus 4.6 进行主实验。
• 除在同一任务集上比较 pass@1 和 pass@k 外，还将已演化的 Harness 迁移到留出任务（held-out tasks） 上，检验其泛化能力，避免将“搜索过拟合”误判为通用改进。

与同类方法的差异点

不同于直接报告 Harness 演化后的性能提升，该方法通过分解搜索算力与 Harness 设计的贡献，并引入泛化任务评估，首次系统揭示了自动 Harness 演化相对于简单 test-time scaling 的边际收益有限。

实验

实验设计

本研究重新审视自动 harness evolution 的评估流程，实验在 Terminal-Bench 2.1 上使用 GPT-5.4 和 Claude Opus 4.6 进行。为分离 harness 设计改进与搜索过程本身的贡献，作者在匹配的反馈信息和推理预算下，将 harness evolution 与两类基线对比：

• Test-time scaling 方法：包括并行采样（parallel sampling）和序列细化（sequential refinement），均利用任务级反馈进行多次尝试。
• Harness scaling：简单扩展 harness 中的工具数量或交互轮次。

为评估泛化能力，进化后的 harness 配置被应用于留出任务（held-out tasks），而不是原始搜索所用的任务集。实验覆盖两种设置：有无单元测试用例（unit test cases） 作为反馈信号。

关键发现

• 无单元测试时，自动 harness evolution 的表现未能持续优于 test-time scaling 基线，说明搜索本身带来的增益可能被误归因于 harness 设计的改进。
• 有单元测试时，harness evolution 依然落後于简单的 test-time scaling 方法，且增益不显著。
• 泛化实验显示，进化后的 harness 在留出任务上提升有限，甚至出现退化，表明搜索过程容易过拟合到特定的训练任务集，不能稳定产出可泛化的配置。

基线对比解读

与直觉相反，harness evolution 作为一种复杂的迭代搜索过程，在与匹配推理预算的 test-time scaling 对比时并未展现优势。这表明其报告的提升很大程度上来自多轮尝试带来的统计优势，而非 harness 设计质量的真实跃升。这挑战了当前自动 harness 设计的主流叙事，并凸显了建立公平评估协议的紧迫性：任何声称改进了 agent 框架的方法，都应首先与同等计算开销的简单 test-time scaling 基线比较，并严格测试任务分布外泛化。

行业影响

落地场景

AI 代理开发平台（如 AutoGPT / LangChain）可直接应用论文结论，优先采用测试时缩放（如并行采样、多数投票）替代成本高昂的自动 harness 进化，用于优化代理的工具选择、提示词配置等。企业自动化流程（如客服、数据处理）需要轻量级的代理调优，简单测试时搜索即可满足需求，避免过度工程化。

商业价值

• 降本：自动 harness 进化常需大量 LLM 调用和迭代搜索，API 费用极高。改用简单的 pass@k 或顺序细化，在同等推理预算下可减少 50% 以上的调用量，直接降低运营成本。
• 增效：开发周期缩短，工程师无需设计复杂的进化算法，将精力集中于核心业务逻辑；同时避免在公共基准上过拟合，减少生产事故风险。
• 体验提升：代理响应更快（简单采样延迟低），且通过 held-out 测试集验证泛化能力，使客户得到更稳定的服务。

集成接口

现有代理框架（如 LangChain / AutoGen）通常具备工具管理模块。可将测试时缩放策略封装为标准评估器，例如在代理配置选择步骤中，用并行采样 + 投票替代自动进化搜索。CI/CD 流水线中，新增 held-out 任务验证环节，确保 harness 配置的泛化性。同时提供公平比较基线（如论文提出的简单搜索基线）的 SDK，方便团队复现和对比。

具体落地 Use Case

1. 电商智能客服代理：某全球电商平台使用 LLM 代理处理退货、物流查询。原计划通过自动进化优化提示词和工具调用链，但成本高且延迟大。改用测试时并行采样（同时生成多个响应，选置信度最高的），在相同成功率下，API 调用费用降低 60%，首 token 延迟减少 40%，更适合大促并发。
2. 金融合规报告生成代理：投资银行利用代理从多源数据库提取信息生成合规报告。自动 harness 进化在历史报告集上效果良好，但面对新的监管政策泛化差。采用顺序细化 + held-out 验证的模式，每次生成候选报告后基于合规性反馈微调，并在未见过的新政策模板上测试，确保输出合规率稳定在 95% 以上，避免合规风险。

局限

• **实验范围有限**：论文仅在 **Terminal-Bench 2.1** 上评估，且只使用了 **GPT-5.4** 和 **Claude Opus 4.6** 两种模型。终端任务虽然多样，但并不能代表所有 agent 任务，如代码生成、多模态交互等。因此，结论是否在更广泛的任务和模型上成立仍有待验证。此外，基准本身可能包含特定领域偏差，导致 harness evolution 的泛化性评估不完整。
• **对单元测试的隐性依赖**：尽管论文指出 harness evolution 在无单元测试时不如简单测试时 scaling，但实验并未深入分析单元测试的质量、数量或可用性如何影响结果。在实际应用中，单元测试往往不完美或不可得，这使得 harness evolution 的适用场景受限。论文未提供在弱测试信号下的改进方案，这可能限制了其工程指导意义。
• **方法论贡献有限**：本文本质上是批判性分析和重新评估，并未提出新的 **harness evolution** 算法或改进方案。虽然指出了现有评估协议的缺陷并倡导公平比较，但对于如何设计更好的 harness 搜索策略或解决过拟合问题，没有给出具体解决方案。与诸如自动 prompt 优化等领域的最新进展相比，创新性主要体现在评估视角的转变，而非方法突破。