Harness搜索执行轨迹深度解析：为何完整追踪至关重要

最近业界对 Harness 的关注度确实上来了。但问题也很现实：Harness 到现在基本还是靠手工调参——工程师盯着 bad case，改几行 Prompt，跑一遍测试，不行再改。那我们不妨往深了想一步：这个过程，有没有可能自动化起来？

斯坦福、MIT 的团队给出了一个答案——Meta-Harness。它不走压缩摘要的路子，也不依赖那些固定的变异算子，而是让一个编码 Agent 直接翻阅所有历史 Harness 的完整源代码和执行轨迹，自己诊断失败原因，自己写新版本。在文本分类、奥数推理、智能体编程三项任务上，自动搜索出来的 Harness 全面超越了人类手工设计的版本。

今天，我们从算法设计、搜索空间选择，以及执行轨迹的不可替代性这三个角度，来拆解一下 Meta-Harness 为什么能 work，以及它对 Harness 工程自动化意味着什么。

论文：Meta-Harness: End-to-End Optimization of Model Harnesses
作者：Yoonho Lee, Roshen Nair, Qizheng Zhang, Kangwook Lee, Omar Khattab, Chelsea Finn
机构：Stanford, MIT, KRAFTON
项目页：https://yoonholee.com/meta-harness/

1. 问题背景：Harness 工程的自动化困境

在基座模型固定的前提下，仅仅改变模型外部的 Harness——也就是决定信息存储、检索和呈现方式的代码——就能带来高达 6 倍的性能差异 [Tian et al., 2026]。这个现象已经被 OpenAI 和 Anthropic 的工程团队反复验证过。但现实是，Harness 的设计依然高度依赖手工迭代：观察失败案例、调整启发式规则、在小范围内测试，周而复始。

问题是，Harness 优化天然带有长程依赖性。早期关于存储什么信息、何时检索的决策，往往要等到几十步推理之后，才会对最终结果产生影响。这意味着，对 Harness 的任何修改，都很难通过局部反馈来有效指导——你改了一处，却要等到很后面才知道改得对不对。

一个很自然的想法是，能不能把近年来流行的文本优化器（比如 OPRO、TextGrad、GEPA、AlphaEvolve 这些）直接拿来优化 Harness？但论文中的 Table 1 揭示了一个关键的不匹配：

无论是只保留分数、依赖摘要还是滑动窗口，这些压缩反馈的机制，都会系统性地丢失追溯失败根源所需的结构化信息。

Meta-Harness 的设计动机正是源于此：既然反馈信息无法被压缩，那就让优化器自己通过文件系统，去选择性读取它需要的东西。

2. 形式化目标与搜索框架

对于一个固定的语言模型和任务分布，Harness 在执行任务实例时会生成一条轨迹，并最终获得一个奖励值。Harness 优化的目标就是最大化这个奖励。当存在多个目标（比如准确率和上下文开销）时，则以帕累托前沿作为评估依据。

Meta-Harness 的搜索过程由三个组件构成：

1. 一个编码 Agent 作为 Proposer（论文中使用的是搭载 Opus 4.6 的 Claude Code），它具备文件系统读写和命令行工具调用的能力。
2. 一个持续增长的文件系统，每个被评估过的 Harness 都有一个独立的目录，存放它的源代码、评估分数以及完整的执行轨迹。
3. 一个外部评估器，负责对 Proposer 生成的候选 Harness 执行评估，并把结果写回文件系统。

与现有的文本优化器不同，Meta-Harness 的外层循环几乎不包含人工设计的搜索启发式。没有固定的变异算子，也没有预设的父代选择规则。Proposer 自己决定要检查哪些历史记录、诊断哪些失败模式、进行何种粒度的修改——是局部修补还是结构性重写。这种设计把优化能力完全绑定在 Agent 的代码理解和推理能力上，也意味着，随着底层编码模型的进步，搜索效果会同步提升。

3. 为什么代码空间搜索比文本空间更适合 Harness

Harness 本质上是一段可执行程序。在代码空间中进行搜索，有三个结构性的优势：

1. 修改粒度匹配问题结构。 Harness 的修改通常是算法性的——改变检索策略、调整记忆更新逻辑、重构控制流——而不是调整几个短语的措辞。代码作为表达载体，天然适合这类修改。
2. 编码模型的先验偏置。 在代码数据上训练的模型，倾向于生成连贯、可复用的算法，而不是针对特定样本的硬编码补丁。这种偏置对泛化有利，后文的 OOD 实验结果也支持这一点。
3. 可执行性与可验证性。 代码空间中的每个候选都可以直接运行，它的行为可以被完整记录下来，形成可供未来诊断的轨迹。

从 Appendix A 提供的 Proposer 文件访问统计来看，在 TerminalBench-2 的 10 轮搜索中，Proposer 每轮读取的中位文件数为 82 个（范围 69–99），其中约 41% 是历史 Harness 的源代码，40% 是执行轨迹，只有 6% 是分数摘要。这组数据说明，Proposer 的访问模式明显是非马尔可夫的：它并不只依赖最近一次评估的结果，而是在多轮迭代中持续回溯更早的候选及其轨迹。

4. 关键消融：执行轨迹是不可替代的信号

Table 3 展示了一项决定性的消融实验（在线文本分类任务）。在控制其他变量相同的前提下，比较了三种 Proposer 接口：

结果很有意思：摘要条件不仅没能恢复缺失的信号，甚至在最优值上还不如仅分数条件（38.7% vs 41.3%）。这提示我们，摘要有可能压缩掉了那些关键的诊断性细节。而执行轨迹中原始的信息——每一步的模型输入输出、工具调用、状态变更——才是 Proposer 能够进行有效归因的关键。

5. 搜索轨迹中的因果推理：一个定性证据

Appendix A.2 从 TerminalBench-2 的一次实际搜索中提取了一段值得注意的交互记录。在早期迭代中，Proposer 同时修改了终端标记剥离（结构性修复）和提示模板（清理指令），结果性能显著下降。到了第三轮迭代时，Proposer 自行推理出：

“这两个修改可能是混淆在一起的。” 于是它回退了提示模板，只保留结构修复，损失大幅收窄（从 -5.6pp 收窄至 -1.1pp）。在后续几轮中，Proposer 继续试探完成流程和提示语言，都观察到了脆弱性，最终在第七轮转为纯加性修改（环境快照引导），成为那次搜索中的最优候选。

这种识别混淆变量 → 设计对照测试 → 根据结果调整策略的行为模式，只有在 Agent 能够完整回溯历史执行轨迹的条件下才能实现。而那些依赖压缩反馈的优化器，根本不具备构建此类因果假说的信息基础。

6. 实验结果中的几个技术观察

6.1 在线文本分类：帕累托前沿的自动发现

在 LawBench、Symptom2Disease、USPTO-50k 三个数据集上，Meta-Harness 搜索出的最优 Harness 比手工设计的 ACE 高 7.7 个百分点，同时使用的上下文 token 只有 ACE 的四分之一（Table 2）。

更重要的是，Figure 3 显示 Meta-Harness 能够生成一条平滑的准确率-上下文开销帕累托前沿，这意味着可以在不修改搜索目标的前提下，按需选择成本与精度的平衡点。

与文本优化器的对比（Table 4）显示，Meta-Harness 仅用 4 次评估就达到了 OpenEvolve 和 TTT-Discover 在 60 次评估后的准确率水平，最终精度高出 10 个百分点以上。这种效率差异直接印证了完整历史访问对搜索效率的提升。

6.2 数学推理：跨模型的检索策略迁移

实验在 200 道 IMO 级别的问题上进行（IMO-AnswerBench、IMO-ProofBench、ArXivMath），检索语料是 53 万道经过严格去污的题目。搜索出的 Harness 是一个四路路由的 BM25 程序（Figure 8），它的路由谓词、重排序项、去重阈值全部由外层搜索在 40 轮迭代中自主确定。

关键结果见 Table 6：同一套检索策略在五个完全没参与搜索的模型（GPT-5.4-nano、GPT-5.4-mini、Gemini-3.1-Flash-Lite、Gemini-3-Flash、GPT-OSS-20B）上全都获得了正向提升，平均绝对增益 4.7 个百分点。

相比之下，Dense 检索在某些模型上出现了明显退化（例如在 Gemini-3-Flash 上只有 0.3pp），随机 Few-shot 的跨模型稳定性更差。这说明在代码空间中搜索出的 Harness，捕获的是任务结构的通用信息利用模式，而不是对特定模型行为的过拟合。

6.3 TerminalBench-2：在竞争性榜单上的表现

TerminalBench-2 是一个包含 89 项任务的终端环境智能体基准，目前处于多方公开竞争的状态。从 Terminus-KIRA（64.4%）初始化，经过 10 轮搜索后：

• 在 Opus 4.6 上达到了 76.4%，排名该模型下的第二（仅次于无法完全复现的 ForgeCode）；
• 在 Haiku 4.5 上达到了 37.6%，位列该模型所有已报告 Agent 的第一（Table 7）。

性能提升主要来自 7 个特定任务（原型类、路径追踪类）。这些任务的共性是环境工具链不确定——Agent 需要先探测环境，才能制定有效策略。Meta-Harness 发现的环境快照引导机制（Figure 9）在循环开始前注入系统状态信息，节约了 2–4 个探索性轮次，在轮次预算紧张的任务中成为了决定性因素。

7. 泛化性检验与过拟合控制

代码空间搜索有一个潜在风险：对搜索集过拟合，比如生成针对特定样本 ID 的硬编码分支。论文通过两种方式验证了泛化性：

1. OOD 文本分类数据集（Table 5）。 在 9 个从未参与搜索的分类任务上，Meta-Harness 的平均准确率为 73.1%，比 ACE 高 2.9 个百分点，在 6/9 个任务上拿到了最高分。值得注意的是，Few-shot（all）在 7/9 个任务上出现了性能下降，这说明简单地增加上下文并非有效策略。

1. 数学推理中的跨模型迁移。 如前所述，搜索出的 Harness 在所有五个未见过的模型上都带来了提升，且提升幅度超过了手工基线。

此外，代码空间的可审查性提供了另一层防护：任何对任务特定字符串的泄漏（比如硬编码类名），都可以通过正则审计或人工检查发现。论文在 TerminalBench 实验中报告了此类检查，未发现泄漏。

8. 工程实践层面的建议

Appendix D 给出了一些在实现 Meta-Harness 风格搜索时的重要经验，其中有两条值得特别关注：

1. 日志格式的可查询性。 评估代码输出的日志应使用机器可读格式（比如 JSON），并以一致的层次结构和命名规范存储。这会直接影响 Proposer 通过 grep 等工具检索历史信息的效率。论文还建议提供一个小的 CLI 工具，用于列出帕累托前沿、对比不同候选的代码差异等，这与编码 Agent 的训练工作流高度一致。
2. 轻量级验证。 在运行昂贵的全量评估之前，用一个极小的验证脚本测试候选 Harness 的基本可导入性和接口正确性。这能过滤掉大部分语法错误或接口不匹配的候选，把无效候选的成本压缩到接近于零。

9. 局限与延伸

论文的结论受限于以下因素，同时也指向了后续的研究方向：

1. Proposer 能力依赖性。 所有实验都使用 Claude Code + Opus 4.6 作为 Proposer。不同编码 Agent 的能力差异会如何影响搜索效果，目前还缺乏系统性的比较。一个合理的推测是，对于推理能力较弱的 Proposer，搜索收益可能会显著收窄。
2. 评估成本与预算分配。 虽然论文强调 Meta-Harness 在相同评估预算下效率更高，但单次评估本身可能就是昂贵的（例如 TerminalBench）。如何在有限预算下选择搜索集规模、评估样本数量以及候选数量，仍然是一个需要根据领域特性来调整的超参数。
3. 与权重更新的协同。 论文在结尾处提出了一个自然的延伸：能不能让 Harness 搜索与模型权重更新协同进行？这相当于把元学习的适应机制从参数空间部分迁移到上下文管理空间，可能会开辟新的优化维度。

10. 总结

Meta-Harness 的核心贡献不在于提出了一个全新的搜索算法，而在于识别并系统性地解决了一个被现有文本优化器忽视的瓶颈：长程 Harness 优化需要完整、未压缩的执行轨迹作为反馈信号。

通过把搜索构建为编码 Agent 对文件系统的自主探索，这个方法在三个任务域上都取得了超越手工设计和现有优化器的结果，并且展现出了令人信服的跨任务、跨模型泛化能力。

对于 Harness 工程这个日益重要的实践领域来说，Meta-Harness 提供了一条从手工迭代迈向自动化搜索的可行路径。它的设计极简——外层循环几乎不含启发式——这也意味着，随着底层编码 Agent 能力的持续增强，这个方法的收益曲线仍然处于上升通道中。