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 论文，开头就扔了一个炸弹：
> "加上摘要，效果反而更差。"
他们在在线文本分类任务上做了一组消融实验：
| 反馈条件 | 中位数准确率 | 最佳准确率 |
|---|---|---|
| 仅标量分数 + 代码 | 34.6% | 41.3% |
| 标量分数 + 代码 + LLM 生成摘要 | 34.9% | 38.7% |
| 完整执行轨迹 + 代码 | 50.0% | 56.7% |
这个发现直接指向了 Meta-Harness 的核心命题：
> Harness 优化不是 prompt 优化。它需要的是系统级诊断，不是文字反馈。
---
二、问题：为什么 OPRO、TextGrad 们在 Harness 上集体失效？
2.1 什么是 Harness？
Harness 是围绕 LLM 的代码——不是模型权重，不是训练数据，而是决定：
- 存储什么信息（what to store）
- 检索什么信息（what to retrieve）
- 如何呈现给模型（how to present）
- 何时做总结、何时做路由
2.2 传统文本优化器的三重缺陷
| 方法 | 每迭代上下文 | 反馈形式 | 核心问题 |
|---|---|---|---|
| OPRO | ~2K tokens | (solution, score) 对窗口 | 无记忆，仅标量 |
| TextGrad | ~15K tokens | 当前工件的文本反馈 | 无历史，仅局部 |
| GEPA | ~8K tokens | rollout 轨迹的反思摘要 | LLM 压缩丢失信号 |
| AlphaEvolve | ~22K tokens | 程序数据库 + 评估分数 | 聚合分数，无执行细节 |
| Meta-Harness | ~10M tokens | 所有日志、代码、轨迹 | 需要强编码 Agent |
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）
| 统计 | 数值 |
|---|---|
| 每迭代读取文件数（中位数） | 82 files |
| 范围 | 69–99 |
| 引用先前候选数 | >20 per step |
| 文件类型分布 | 源代码 41%, 执行轨迹 40%, 分数/摘要 6%, 其他 13% |
Proposer routinely 检查大部分可用历史，而非只 conditioning 在最近父节点上。它会在第 10 次迭代时引用第 2 次迭代的结果，因为"理解为什么失败往往比理解为什么成功更有指导意义"。
---
四、实验结果：三个 Benchmark 全面碾压
4.1 在线文本分类（Online Text Classification）
设置：GPT-OSS-120B，LawBench (215类)、Symptom2Disease (22类)、USPTO-50k (180类)
| Harness | Law ↑ | S2D ↑ | USPTO ↑ | 平均 ↑ | 上下文 (K) |
|---|---|---|---|---|---|
| Zero-Shot | 12.0 | 63.2 | 7.0 | 27.4 | 0 |
| Few-Shot (32) | 13.0 | 72.2 | 21.0 | 35.4 | 7.9 |
| MCE | 14.0 | 83.0 | 23.0 | 40.0 | 28.5 |
| ACE | 16.0 | 77.8 | 29.0 | 40.9 | 50.8 |
| Meta-Harness | 14.0 | 86.8 | 45.0 | 48.6 | 11.4 |
- 比 ACE +7.7 点
- 比 MCE +8.6 点
- 使用 4× 更少上下文 token（11.4K vs 50.8K）
收敛速度：Meta-Harness 在 4 次评估内达到 OpenEvolve 和 TTT-Discover 的最终准确率，最终超过 10 个百分点。
4.2 检索增强数学推理（Retrieval-Augmented Math Reasoning）
设置：检索语料 ≥500,000 已解决问题，搜索 40 迭代，测试 200 IMO 级别问题
发现的 Harness 结构：四路 BM25 路由——组合数学、几何、数论、默认（代数/其他），每路由不同检索策略。
| 方法 | GPT-5.4n | GPT-5.4m | Gem-3.1FL | Gem-3F | GPT-20B | 平均 |
|---|---|---|---|---|---|---|
| 无检索 | 23.0 | 28.8 | 28.6 | 42.6 | 47.6 | 34.1 |
| Dense (k=5) | 31.1 | 28.3 | 37.1 | 47.2 | 46.7 | 38.1 |
| BM25 | 30.2 | 29.2 | 32.8 | 46.6 | 48.9 | 37.5 |
| Meta-Harness | 31.7 | 30.4 | 34.9 | 46.3 | 50.6 | 38.8 |
- 相比无检索：+4.7 点平均
- 相比 BM25：+1.3 点
- 所有 5 个 held-out 模型上提升，避免了 Dense Retrieval 在某些模型上的回归
4.3 TerminalBench-2 Agentic Coding
Opus 4.6 结果：
| Harness | 自动优化 | 通过率 |
|---|---|---|
| Claude Code | × | 58.0% |
| Terminus 2 | × | 62.9% |
| Droid | × | 69.9% |
| TongAgents | × | 71.9% |
| Terminus-KIRA | × | 74.7% |
| Capy | × | 75.3% |
| Meta-Harness | ✓ | 76.4% |
| Harness | 通过率 |
|---|---|
| OpenHands | 13.9% |
| Claude Code | 27.5% |
| Terminus-KIRA | 33.7% |
| Goose | 35.5% |
| Meta-Harness | 37.6% |
- Opus 4.6：#2（所有报告 agent 中）
- Haiku 4.5：#1（所有报告 agent 中）
五、消融实验：为什么"完整轨迹"是唯一答案
在线文本分类上的消融（控制代码和分数不变，只改变反馈形式）：
| 条件 | 分数 | 代码 | 摘要 | 轨迹 | 中位数 | 最佳 | >Zero-Shot |
|---|---|---|---|---|---|---|---|
| 仅分数 | ✓ | ✓ | × | × | 34.6 | 41.3 | 26 |
| 分数 + 摘要 | ✓ | ✓ | ✓ | × | 34.9 | 38.7 | 23 |
| 完整轨迹 | ✓ | ✓ | - | ✓ | 50.0 | 56.7 | 39 |
1. 摘要有害：加上 LLM 生成的摘要后，最佳准确率从 41.3% 降到 38.7% 2. 轨迹是关键：完整执行轨迹是中位数提升 44%（34.6→50.0）的唯一变量 3. 非线性跳跃：不是渐进改善，而是"有轨迹 vs 无轨迹"的质变
> "访问原始执行轨迹是启用 harness 搜索的关键成分。"
---
六、案例：TerminalBench-2 上的搜索轨迹
附录 A.2 记录了 Meta-Harness 在 TerminalBench-2 上的真实搜索轨迹，非常有启发性：
| 迭代 | 行为 | 结果 |
|---|---|---|
| 1-2 | 结构修复 + 提示模板修改 | 两者都回归 |
| 3 | 识别混淆因素："提示模板修改导致 agent 在任务完成前删除了必要状态" | 仍回归 |
| 4-6 | 直接修复诊断出的失败模式 | 仍回归 |
| 7 | 转向纯加法修改：环境 bootstrap | 最佳候选 |
| 8 | 组合两个正交修复 | 进一步提升 |
| 10 | 跨运行迁移：引用早期搜索运行结果 | 持续改进 |
6.1 "evo env bootstrap" — 纯加法修改的力量
迭代 7 的最佳候选是一个纯加法修改：
# 概念性描述
在第一次 LLM 调用前，通过单个 shell 命令收集环境快照
（工作目录、文件清单、可用语言/工具、包管理器、内存）
将其附加到初始提示中
不改变其他方法
设计原理：
- 避免修改之前证明脆弱的完成机制
- 消除依赖重型任务上的 3-5 个浪费探索回合
- 对已通过的 task 无回归风险
6.2 正交修复的组合
迭代 8 的洞见：
> "组合两个正交修复——环境快照（节省早期探索回合）+ marker stripping with no-tool-call loop breaker——将产生 +1-3pp，因为它们解决了独立的失败模式，而不触碰提示或确认流程。"
这说明 Meta-Harness 不仅能找到单个修复，还能识别独立失败模式并做正交组合——这是人工调试很难做到的。
---
七、计算成本：贵，但值得
7.1 搜索效率
| 指标 | 数值 |
|---|---|
| 典型运行评估 harness 数 | ~60 over 20 iterations |
| 墙钟时间 | "a few hours" |
| 每迭代候选数 | 2 (文本分类), 可变 (其他) |
7.2 上下文成本
Meta-Harness 不是"更便宜"——它每次迭代消耗约 1000 万 tokens 的诊断信息。但它用这些信息换来了：
- 评估效率：达到最终准确率仅需 ~4 次评估，而 OpenEvolve/TTT-Discover 需要 ~40 次
- 上下文效率：发现的 harness 本身使用更少 token（文本分类上 4× 减少）
- 泛化能力：单个 harness 跨 5 个模型提升
7.3 成本权衡
| 维度 | 传统文本优化器 | Meta-Harness |
|---|---|---|
| 单次迭代成本 | 低（~10K tokens） | 高（~10M tokens） |
| 收敛所需迭代 | 多（~40 次） | 少（~4 次） |
| 最终 harness 运行成本 | 高（ACE 用 50.8K context） | 低（11.4K context） |
| 人工干预 | 需要（prompt 调优） | 几乎不需要 |
八、局限与未来方向
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
| 范式 | 优化对象 | 工具 | 复杂度 |
|---|---|---|---|
| Prompt Engineering | 提示字符串 | 手动调优、A/B 测试 | 低 |
| Prompt Optimization (OPRO/TextGrad) | 提示字符串 | 自动搜索、梯度反馈 | 中 |
| DSPy | 模块化 pipeline | 编译器优化 | 中 |
| Harness Engineering (Meta-Harness) | 完整 Python 程序 | Agent 搜索 + 系统级诊断 | 高 |
核心洞察的三层递进
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优化 #小凯
🌟 智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。
🎁 领取 2000万 Tokens