Meta-Harness 深度拆解：当 Agent 开始优化 Agent 的脚手架

论文：Meta-Harness: End-to-End Optimization of Model Harnesses
作者：Yoonho Lee, Roshen Nair, Qizheng Zhang (Stanford), Kangwook Lee (KRAFTON), Omar Khattab (MIT), Chelsea Finn (Stanford)
arXiv：https://arxiv.org/abs/2603.28052
标签：#MetaHarness #HarnessEngineering #LLM优化 #Stanford #KRAFTON #MIT #小凯

一、一个反直觉的发现：压缩反馈反而有害

斯坦福 IRIS Lab、MIT 和 KRAFTON 联合发表的 Meta-Harness 论文，开头就扔了一个炸弹：

"加上摘要，效果反而更差。"

他们在在线文本分类任务上做了一组消融实验：

中位数候选（50.0%）甚至超过了前两种条件的最佳候选。 摘要不仅没有帮助，反而通过压缩掉诊断有用细节而造成了损害。

这个发现直接指向了 Meta-Harness 的核心命题：

Harness 优化不是 prompt 优化。它需要的是系统级诊断，不是文字反馈。

二、问题：为什么 OPRO、TextGrad 们在 Harness 上集体失效？

2.1 什么是 Harness？

Harness 是围绕 LLM 的代码——不是模型权重，不是训练数据，而是决定：

• 存储什么信息（what to store）
• 检索什么信息（what to retrieve）
• 如何呈现给模型（how to present）
• 何时做总结、何时做路由

论文引用了一个惊人的数字：同一个模型，不同 harness，性能差距可达 6×。

2.2 传统文本优化器的三重缺陷

差距：约 3 个数量级。

2.3 Harness 优化的特殊挑战：信用分配困难

Harness 是长程程序——第 3 步关于"存储什么"的决策，可能到第 47 步才显现出影响。当你把反馈压缩成一个标量分数或一段摘要时，你扔掉的正是将"下游失败"追溯到"早期 harness 决策"所需的信号。

Meta-Harness 的解决方式简单粗暴：不压缩。让 proposer 直接看原始轨迹。

三、Meta-Harness 架构：外循环搜索 + Filesystem-First 诊断

3.1 形式化目标

H* = argmax_H E[x~X, τ~p_M(H,x)] r(τ, x)

• H: harness（状态化程序）
• M: 固定的语言模型
• X: 任务分布
• τ: rollout 轨迹
• r(τ, x): 任务特定奖励

3.2 搜索循环

输入: 任务 X, LLM M, Proposer P, 迭代次数 N
初始化: 种群 H（初始有效 harness 集合）
初始化: 文件系统 D ← ∅

1. 对 H 中每个 harness:
   - E_H ← Evaluate(H, M, X)
   - D ← D ∪ {(H, E_H)}

2. 对 t = 1...N:
   a. Proposer P 查询文件系统 D
      → 用 grep/cat 检查先前 harness 和分数
   b. Proposer P 提出 k 个新 harness {H₁,...,Hₖ}
   c. 对每个 H ∈ {H₁,...,Hₖ}:
      - 若 H 通过接口验证:
        D ← D ∪ {(H, Evaluate(H, M, X))}

3. 返回 D 中存储的 harness 的 Pareto 前沿

3.3 Proposer：不是 raw LLM，是 Coding Agent

这是 Meta-Harness 的关键工程决策：

"Proposer 不是操作固定 prompt 的原始 next-token 模型；它是一个 Agent，检索信息、导航历史产物、编辑代码——搜索本身就是它的一部分。"

论文用的是 Claude Code + Opus 4.6。

Proposer 的能力要求（2026 年初才实用化）：

• 调用开发者工具（grep, cat 等）
• 修改代码
• 决定检查什么信息
• 通过直接代码库交互验证编辑

3.4 Filesystem-First Trace Analysis

每个评估的 harness 在文件系统中留下一个目录，包含：

• 源代码
• 评估分数
• 执行轨迹（prompts、tool calls、model outputs、state updates）

Proposer 通过标准终端工具检索，而非作为单一 prompt 摄入：

关键特性：非马尔可夫访问模式

Proposer routinely 检查大部分可用历史，而非只 conditioning 在最近父节点上。它会在第 10 次迭代时引用第 2 次迭代的结果，因为"理解为什么失败往往比理解为什么成功更有指导意义"。

四、实验结果：三个 Benchmark 全面碾压

4.1 在线文本分类（Online Text Classification）

设置：GPT-OSS-120B，LawBench (215类)、Symptom2Disease (22类)、USPTO-50k (180类)

关键结果：

• 比 ACE +7.7 点
• 比 MCE +8.6 点
• 使用 4× 更少上下文 token（11.4K vs 50.8K）

OOD 泛化（9 个未见数据集）：Meta-Harness 平均 73.1%，ACE 仅 70.2%，在 6/9 数据集上最佳。

收敛速度：Meta-Harness 在 4 次评估内达到 OpenEvolve 和 TTT-Discover 的最终准确率，最终超过 10 个百分点。

4.2 检索增强数学推理（Retrieval-Augmented Math Reasoning）

设置：检索语料 ≥500,000 已解决问题，搜索 40 迭代，测试 200 IMO 级别问题

发现的 Harness 结构：四路 BM25 路由——组合数学、几何、数论、默认（代数/其他），每路由不同检索策略。

关键结果：

• 相比无检索：+4.7 点平均
• 相比 BM25：+1.3 点
• 所有 5 个 held-out 模型上提升，避免了 Dense Retrieval 在某些模型上的回归

4.3 TerminalBench-2 Agentic Coding

Opus 4.6 结果：

Haiku 4.5（较弱模型，提升更大）：

排名：

• Opus 4.6：#2（所有报告 agent 中）
• Haiku 4.5：#1（所有报告 agent 中）

五、消融实验：为什么"完整轨迹"是唯一答案

在线文本分类上的消融（控制代码和分数不变，只改变反馈形式）：

三个关键发现：

1. 摘要有害：加上 LLM 生成的摘要后，最佳准确率从 41.3% 降到 38.7%
2. 轨迹是关键：完整执行轨迹是中位数提升 44%（34.6→50.0）的唯一变量
3. 非线性跳跃：不是渐进改善，而是"有轨迹 vs 无轨迹"的质变

"访问原始执行轨迹是启用 harness 搜索的关键成分。"

六、案例：TerminalBench-2 上的搜索轨迹

附录 A.2 记录了 Meta-Harness 在 TerminalBench-2 上的真实搜索轨迹，非常有启发性：

6.1 "evo env bootstrap" — 纯加法修改的力量

迭代 7 的最佳候选是一个纯加法修改：

# 概念性描述
在第一次 LLM 调用前，通过单个 shell 命令收集环境快照
（工作目录、文件清单、可用语言/工具、包管理器、内存）
将其附加到初始提示中
不改变其他方法

设计原理：

• 避免修改之前证明脆弱的完成机制
• 消除依赖重型任务上的 3-5 个浪费探索回合
• 对已通过的 task 无回归风险

这与迭代 1-6 的"修改完成流、提示模板或观察处理"全部失败形成鲜明对比。

6.2 正交修复的组合

迭代 8 的洞见：

"组合两个正交修复——环境快照（节省早期探索回合）+ marker stripping with no-tool-call loop breaker——将产生 +1-3pp，因为它们解决了独立的失败模式，而不触碰提示或确认流程。"

这说明 Meta-Harness 不仅能找到单个修复，还能识别独立失败模式并做正交组合——这是人工调试很难做到的。

七、计算成本：贵，但值得

7.1 搜索效率

7.2 上下文成本

Meta-Harness 不是"更便宜"——它每次迭代消耗约 1000 万 tokens 的诊断信息。但它用这些信息换来了：

• 评估效率：达到最终准确率仅需 ~4 次评估，而 OpenEvolve/TTT-Discover 需要 ~40 次
• 上下文效率：发现的 harness 本身使用更少 token（文本分类上 4× 减少）
• 泛化能力：单个 harness 跨 5 个模型提升

7.3 成本权衡

八、局限与未来方向

8.1 当前局限

1. 依赖强编码 Agent：Proposer 需要能调用工具、修改代码、验证编辑——这对底层模型能力要求很高。2026 年初的 Claude Code + Opus 4.6 才勉强够用
2. 计算成本高：每次搜索需要数小时和数百万 tokens——不适合频繁重训练
3. 搜索空间限制：当前只在相对结构化的 harness 空间搜索，未涉及模型架构层面的改动
4. 评估过拟合风险：TerminalBench-2 的搜索和评估在同一 benchmark 上（论文检查过拟合，但仍需注意）
5. 非确定性：Proposer 的非马尔可夫访问模式导致搜索结果有一定随机性

8.2 未来方向

1. 跨任务迁移：当前每个任务独立搜索，未来可以探索跨任务 harness 知识的迁移
2. 与模型训练结合：同时优化 harness 和模型权重（类似 Anthropic 的宪法 AI）
3. 更细粒度的信用分配：开发专门的算法来更精确地追踪"哪个 harness 决策导致哪个失败"
4. 降低搜索成本：用 smaller/cheaper model 做初步筛选，只在最有希望的候选上用 Opus 验证

九、 Harness Engineering 的范式转移

Meta-Harness 代表了一个重要的范式转移：

从 Prompt Engineering 到 Harness Engineering

核心洞察的三层递进

1. 第一层：模型外面的代码和模型本身一样重要（6× 性能差距）
2. 第二层：优化 harness 需要系统级诊断，不是文字反馈（完整轨迹 > 摘要 > 分数）
3. 第三层：Harness 优化可以自动化——让 Agent 搜索 Agent 的脚手架

对行业的意义

对于正在构建 LLM 应用的团队，Meta-Harness 传递了一个明确信号：

"别光盯着模型本身了。你的 harness 可能才是最大的杠杆点。"

LangChain 的报告已经给出了实证：只调整 system prompt、tools 和 middleware，就能在 TerminalBench 2.0 上从 52.8% 提升到 66.5%（+13.7pp），而模型权重完全没变。

Meta-Harness 把这件事自动化了。它的搜索成本不低，但发现的最优 harness 在运行时使用更少的 token、在更多模型上泛化、在更多任务上表现更好。

参考

• Lee, Y., Nair, R., Zhang, Q., Lee, K., Khattab, O., & Finn, C. (2026). Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv preprint arXiv:2603.28052.
• LangChain. (2026). Improving Deep Agents with Harness Engineering.
• Trivedy, V. (2026). Better Harness: A Recipe for Harness Hill-Climbing with Evals.
• 相关项目：Terminus-KIRA (KRAFTON), DSPy (Stanford), Claude Code (Anthropic)

#论文 #MetaHarness #HarnessEngineering #LLM优化 #Stanford #MIT #KRAFTON #系统级诊断 #Agent优化 #小凯