重新审视「Agent Harness 自动演化」：它赢得还是 test-time scaling 赢了？

关联论文：2607.12227
作者：spark
更新：2026-07-19

一句话结论

在 Terminal-Bench 2.1 上，用 GPT-5.4 与 Claude Opus 4.6 做后端的实验显示，自动 harness evolution 并不一致地胜过简单的 test-time scaling 基线，且演化得到的 harness 在「未见过的任务」上泛化有限——也就是说，过去报告的 harness 演进增益很可能一部分来自「多跑几次」本身而非「设计得更好」，需要更公平的评估协议。

解决的真问题

过去一年，自动 harness evolution 在 agent 圈非常流行。核心套路是：

让 LLM 在「prompt 模板、工具描述、子 agent 编排、retry 策略」等 harness 配置空间里搜索，用任务反馈驱动迭代，再用「同一份公开 benchmark」上的最终通过率证明 harness 变好了。

这一协议有两个被本文显式提出的隐患：

混淆了「harness 设计变好」与「搜索本身多消耗了反馈与推理预算」。harness evolution 本身就是一种迭代搜索，它反复评估候选 harness、使用任务反馈——和 agentic test-time scaling（同一个任务多轮重试 / 树搜索）的算力账是一回事。在没有控制预算的情况下对比，harness evolution 看起来的「提升」很可能只是「多花了算力」。
搜索集与评估集同一份 benchmark，过拟合风险高。报告的增益极有可能只是过拟合这一份任务集合，而不是「学到了可迁移的 harness 原则」。

换句话说：并不是说 harness evolution 一定没用，而是「我们以前测得太浅，无法说它有用」。 本工作要做的是给它换上更严格的考试。

核心方法

研究设计

作者把比较重新对齐到「反馈预算 × 推理预算」两个轴上：

相同反馈预算：控制 harness evolution 在搜索阶段调用的「任务反馈次数」等于 test-time scaling 基线使用的次数。
相同推理预算：在最终评估阶段，每个候选 / 每个尝试消耗的总 token 一致。

在此约束下，分三组比较：

实验组	描述
Harness Evolution	搜索 harness 配置空间，跑多轮 harness 更新
Task-level search (TTS baselines)	同一任务内 test-time scaling：多次采样 / Best-of-N / 反思-重做等
Held-out evaluation	用 evol 出来的 harness 跑「演化阶段没用过的任务」，检验迁移性

两个评测场景

同分布性能：Terminal-Bench 2.1 公开任务集合上的端到端通过率。
分布外泛化：在演化 / 训练阶段被 held-out 的任务子集上的通过率。

实验用 SOTA 模型 GPT-5.4 与 Claude Opus 4.6，覆盖当时最强闭源 Agent 后端。

评测指标

通过率（pass rate）：Terminal-Bench 任务成功的比例。
泛化比率（原文未明确的具体名称，原文未给出）：held-out 任务通过率 / 训练任务通过率。

关键结论（按 abstract 表述）

Harness evolution 没有一致地击败简单的 test-time scaling——在多数任务 / 模型组合上，两者差距落入统计噪声。
在 held-out 任务上，自动演化得到的 harness 表现出有限的泛化。
这意味着：先前 SOTA 报告的「harness 进化带来多大增益」应被谨慎解读，至少需要把 test-time scaling 当成必须报告的对照。

关键实验与数据

基准：Terminal-Bench 2.1（命令行 / 软件工程类 benchmark，原文未明确子集数，需查正文）。
模型：GPT-5.4、Claude Opus 4.6。
对比对象：自动 harness evolution、简单 TTS 基线（多次采样、反思-重做等）、held-out 任务迁移评测。
核心数字（abstract 内核）：
Harness evolution 增益不稳定、与 TTS 重叠。
Held-out 任务泛化有限。
具体 pass@1 / pass@k 增量数字 abstract 未给出（原文未明确），需查 PDF（仅 113 KB，正文不长）。
开源：代码见 https://github.com/rethinking-harness-evolution。

亮点与局限

亮点

直击当下热门方法的评估漏洞：2024–2026 大批论文都讲「我的 harness / framework 提升了多少点」，本文相当于给这类评测上一堂方法论课。
实验设置本身就是贡献：「matched feedback and inference budget」「held-out evaluation」会成为后续 harness-evolution 论文的事实新规范。
可复现、低门槛：113 KB 小文 + 公开代码 + 主流闭源 API 即可复现。

局限

只用了 Terminal-Bench 2.1 一个 benchmark。结论能不能推广到 SWE-bench、WebArena、GAIA 等任务族，原文未明确。
只用了 GPT-5.4 / Claude Opus 4.6 两个模型。其他模型（开源、较弱的）上 harness evolution 是否更值钱，原文未明确。
没有给出「什么类型的 harness 改动对哪类任务真的有效」的更细致归因——虽然 negative result 也是 result。
仅评估了「自动演化」类方法，没有覆盖人工设计的 harness（如 LangChain、Aider、Claude Code 等），无法回答「自动演化 vs 经验丰富的人工 harness」。

对工程落地的启发

在自家 agent 框架上加任何 harness 改动前，先建 TTS 基线。如果你跑了 3 轮反思重做就追平了你新加的 prompt 模板改进，那这模板就不是必须的，砍掉它省 token。
过拟合自家 benchmark 是真的风险。在 paper 内部 benchmark 上跑 5% 通过率提升，几乎不能外推到客户场景。读完 benchmark，先留 20% 做 held-out 评估。
控制反馈与推理预算应该成为 agent 评测报告的标配字段，就像 LLM 评测里要报 wall-clock 一样——本文有望推动这个习惯。
不要迷信 harness evolution 的「金句」：harness 真的更像 prompt engineering + 一些 retry 模板，而非某种独立科学。投资回报要看任务复杂度是否真的值得演化。

与同方向工作的关系

与 ADAS / AIDE / GEPA / PromptAgent 等「自动 prompt / harness 演化」工作形成正面挑战：本工作不是否定它们，而是要给出一个「你是不是真的比 Best-of-N 强」的更公平打分。
与 agentic test-time scaling 路线（Self-Refine、Reflexion、Tree of Thoughts、Best-of-N 等）形成互补：本工作提供的论据是「TTS 是免费的对照」。
与 agent benchmark 方法论批评（Leakage / overfitting in benchmarks）一脉相承，把「评估协议本身」当研究对象。

适合谁读

任何在做 agent framework / harness 的工程师——你需要一个最低门槛的「我们这个优化到底有用没用」的实验范式。
Agent benchmark 设计者——本文是 SWE / Terminal 类评测必须内化的批评。
写 prompt-evolution / agent-zoo 论文的研究者——这部分读者最该读，因为它直接挑战你。
投资人 / PM：判断一家 agent 公司的「harness 进化论」是否真有壁垒，可以拿本文的 5 个问题去问。

不确定处

Terminal-Bench 2.1 的任务数、子集划分、held-out 划分比例，原文 abstract 未给（原文未明确）。
与 TTS 基线的具体 pass rate 差额、置信区间、方差，原文未明确。
是否测试了开源模型（如 DeepSeek / Llama 4 / Qwen 3 等），原文未明确。
与人工设计 harness 的对照是否在补充材料里，原文未明确。

工程落地与核查（Jay）

1. 事实核查

断言	核查结论
Terminal-Bench 2.1	✅ 已确认：arXiv HTML 版摘要明确引用 Terminal-Bench 2.1。
GPT-5.4 / Claude Opus 4.6	✅ 已确认：arXiv HTML 摘要明确列出两个模型。
harness evolution 未一致胜过 TTS	✅ 已确认：摘要原话 "does not consistently outperform simple test-time scaling methods"。
held-out 任务泛化有限	✅ 已确认：摘要原话 "exhibits limited generalization"。
GitHub: rethinking-harness-evolution	✅ 已确认：arXiv HTML 与 HuggingFace Papers 页面均可验证。
113 KB 正文	⚠️ 存疑：原文未明确标注正文大小，此数字未在上文标出，建议读者以实际下载文件大小为准。
PDF 大小（113 KB）	ℹ️ arXiv HTML 页面未显示文件大小；正文实际字数建议以 PDF 下载后确认为准（解读作者注）。

2. 可读性精修

"Harness" 术语：全文出现 10+ 次，首次出现应加注：Harness = agent 执行环境配置（含 prompt 模板、工具描述、retry 策略、output parser 等），读者若不熟悉 agent 系统会感到概念模糊。
"test-time scaling（TTS）"：首次出现应加注简称全称：Test-time scaling（TTS），本文指「推理时通过多次采样/树搜索等手段提升单次任务成功率」，有别于 pre-training 阶段的 scaling。
"pass@k / pass@1"：正文未给出具体数字，但「通过率」在 agent benchmark 语境下常指 pass@1，应统一为 pass@1 以避免歧义。
行文逻辑：「AB 对比」一节拆得过散，核心论点（反馈预算混淆 + 过拟合）在前两段已经完整，后续评测指标和实验设计与关键结论可以精简合并，减少读者跳读成本。
"Held-out evaluation"：建议译为「留出任务评测」或「留出集评测」，更直观。

3. 工程落地：真实系统怎么用，坑在哪

谁真的需要关心这个研究？

直接相关： - 正在用 / 考虑用 harness evolution 方案（FMs like PromptAgent、GEPA 等）的 agent 平台团队。 - 自建 agent benchmark 并用它来做 harness 选型的工程团队。

较远但应了解： - Agent 应用 PM / 技术负责人——判断供应商的「框架进化」是否值得买。

如何把本文结论落地成实践？

步骤 1：建立 TTS 基线（任何 harness 改动前必做）

# 最简 TTS 基线参考实现（伪代码）
def tts_baseline(task, model, n_trials=5):
    """Best-of-N：同一个 task prompt 发 n_trials 次，返回任意成功即成功"""
    for i in range(n_trials):
        result = model.run(task)
        if result.passed():
            return {"passed": True, "trials": i+1}
    return {"passed": False, "trials": n_trials}

# 对比：你的 harness 方案
def harness_evolution(task, model, evolution_budget=50):
    # 运行 harness evolution，消耗 evolution_budget 次任务反馈
    best_harness = run_evolution(task, budget=evolution_budget)
    return model.run(task, harness=best_harness)

坑 1：反馈预算不对齐就对比——若 harness evolution 跑了 50 次任务评估，你的 TTS baseline 也必须跑 50 次 trials，否则「多花了 50 次反馈」本身就足以解释任何提升。

步骤 2：留出 20% 任务做 held-out 评估

benchmark 划分比例（建议）：
  - 演化集：60%（用于 harness 搜索）
  - 验证集：20%（用于超参调优 / early stop）
  - 留出集：20%（用于最终报告，只用一次）

⚠️ 坑：大多数内部 benchmark 任务不够，
   20% 留出后剩余训练任务太少，
   演化无法收敛。建议先用已有公开 benchmark
   做初步结论，再迁移到内部场景。

步骤 3：区分「harness 有效」和「任务足够简单」

若 TTS 在某个任务上 pass@5 就 > 90%，说明该任务本身不需要 harness 优化——是「任务简单」而非「harness 有效」。真正有价值的场景是 TTS 收敛慢（需要 20+ trials 才稳定）但 harness 能在 5 次内收敛。

步骤 4：不要把本文结论用于否定人工设计 harness

本文只比较了「自动演化 harness vs TTS」，没有对比「人工设计 harness vs TTS」。经验丰富工程师手写的 harness（如 Claude Code / Aider 的默认配置）可能仍然显著优于两者。

最大的工程陷阱

拿着负面结论反向推导——读完本文容易得出「harness evolution 没用」的结论，这是过度泛化。本文只证明了：在 Terminal-Bench 2.1 + 两个最强闭源模型的设定下，自动演化的优势不显著。在以下条件下，harness evolution 仍可能有价值：

任务空间大且 harness 配置空间复杂（手工调参不现实）
开源 / 较弱模型（自动搜索能找到人工难以发现的 prompt 模式）
法规 / 安全类场景（harness 配置需要可审计，手工设计反而更难保证覆盖度）

从研究到工程的最短路径

结论引用清单（可直接写进工程文档）：
1. 对比 harness 方案时，必须同时报 TTS baseline + 相同反馈预算
2. 任何 harness 改动必须用 held-out 任务验证泛化
3. agent benchmark 评测报告模板应包含：
   - 模型名称 + 版本
   - feedback budget（搜索阶段调用次数）
   - inference budget（最终评估 token 数）
   - 同分布 pass@1 / pass@5
   - 留出集 pass@1
   - 统计显著性（confidence interval 或 bootstrap）

这不是一篇文章能回答的问题——但它给工程团队提供了方法论起点：用更少的工程资源（不需要训新模型，不需要额外标注），就能验证「我的 harness 改动到底有没有用」。