Meta-Harness：让 LLM 自己搜索最优 harness，模型不动，性能白涨

插播：之前写的《动手学 AutoML》终于出版了，从 NAS 到超参优化都有覆盖，适合想系统入门 AutoML 的同学。好了广告结束，现在进入正题。

动手学AutoML书籍封面

Meta-Harness：让 LLM 自己搜索最优 harness，模型不动，性能白涨

原文：Meta-Harness: End-to-End Optimization of Model Harnesses

1. Motivation：为什么要优化 harness？

你有没有这种体验：同一个 LLM，换个 system prompt、改下 context 管理策略、调调 tool 调用逻辑，效果就突然起飞了？

这不是玄学，而是一个越来越被业界认可的事实：对于当前能力已经足够强的 LLM，性能瓶颈往往不在模型权重本身，而在"包裹"模型的那一套代码——harness。

所谓 harness，说人话就是：决定给模型看什么信息（context 管理）、怎么检索（retrieval）、怎么组织 prompt、怎么编排多步推理的那套外围代码。同一个模型，换一套 harness，可以在同一个 benchmark 上产生 6× 的性能差距。

问题是：这套 harness 到目前为止几乎全靠手工设计。研究员和工程师们凭直觉和经验去调 prompt、改 context 策略、设计 tool 接口。这个过程费时费力，而且效果高度依赖设计者的 domain expertise。

论文的核心问题就是：能不能让 LLM 自己搜索最优的 harness？

2. Challenge：现有的文本优化器为什么搞不定

你可能会问：这不就是 prompt optimization / text optimization 嘛？DSPy、OpenEvolve、TextGrad 不都在做类似的事？

确实相关，但论文指出了一个关键的匹配问题：现有的 text optimizer 对反馈信息压缩得太狠，丢失了 harness 搜索真正需要的诊断细节。

具体来说：

方法 历史信息 日志内容 每次迭代 token 开销
OPRO Window past (solutions, scores) 0.002 MToken
TextGrad Last textual feedback on current 0.015
AlphaEvolve Window program database + eval scores 0.022
GEPA Summary reflective feedback from n-best 0.038
Feedback Descent Summary comparison + textual feedback 0.012
TTT-Discover Window prev. solution fragment 0.026
Meta-Harness Full all logs and scores 1.00

现有方法对比

看到了吗？现有方法每次迭代只用 0.002~0.038 MToken 的上下文，而 Meta-Harness 用 1 MToken——差了两个数量级。

为什么需要这么多？因为 harness 优化和 prompt 优化本质上不一样：

  • Prompt 优化：搜索空间是一段文本，改几个词就能有效果，反馈信号（"好/坏"）直接
  • Harness 优化：搜索空间是一整套代码逻辑（检索策略、context 管理、prompt 构建、编排流程），需要看到完整的执行轨迹（哪个 example 失败了？失败时 context 里有什么？模型推理了什么？）才能做有效的归因

把一个完整 harness 的失败原因压缩成一句"accuracy too low"是没用的。你需要看到：哪些 case 错了、错的时候 context 长什么样、是检索没找到对的东西还是 prompt 格式有问题。这些诊断信息就是那 1M token 的来源。

3. 方法：Meta-Harness 怎么做

3.1 核心设计

Meta-Harness 的结构非常直觉——本质上是一个 outer-loop search，用一个 coding agent 作为 proposer，在 harness 代码空间里做搜索：

Meta-Harness 搜索循环

三步循环：

  1. Proposer 读取文件系统：一个 coding agent 拥有对完整文件系统的访问权限。这个文件系统里存放着所有历史 candidate harness 的源代码、执行轨迹、评估分数。Proposer 通过 grep、cat 等命令自由检索历史信息。

  2. 生成并评估新 harness：Proposer 生成新的 harness 代码，系统在验证集上评估它。

  3. 存储所有日志到文件系统：新 harness 的代码、推理轨迹、分数全部写回文件系统，供下一轮迭代使用。

3.2 关键设计选择

为什么是 filesystem 而不是 prompt？

这是论文最核心的设计决策。传统做法是把历史信息压缩成 summary 塞进 prompt——但 harness 级别的优化，一次评估就可能产生 1000 万 token 的诊断信息（100 个测试样本 × 每个样本完整推理轨迹）。这根本塞不进一个 prompt。

Meta-Harness 的方案是：不压缩，全存文件系统，让 proposer 自己决定看什么。 Proposer 是一个 coding agent，它可以自由地 grep 搜索失败 case、cat 某个具体轨迹、按分数排序历史 candidate——本质上把"该看什么历史信息"这个决策也交给了模型自己。

为什么 proposer 是 coding agent 而不是 text optimizer？

因为 harness 本身就是代码。Proposer 需要理解代码结构、做局部修改（而不是从头重写），这天然适合 coding agent。论文用的是 Claude Code [4] with Opus 4.6。

3.3 搜索策略

  • 维护一个 Pareto frontier（多目标：accuracy + context cost）
  • 每次迭代 proposer 生成 k 个 candidate
  • 通过验证集筛选后加入 frontier
  • 不做 population-based evolution——就是纯粹的 propose-evaluate 循环

实际跑的时候，一个典型的搜索过程是 20 轮迭代，每轮 proposer 读取中位数 82 个文件，引用超过 20 个历史 candidate。

4. 实验结果

论文在三个领域评估：在线文本分类、数学推理、agentic coding。

4.1 在线文本分类

文本分类结果：Pareto frontier

核心结论：

  • Meta-Harness 比当前 SOTA context 管理系统 ACE（Zhang et al. [59]）高 7.7 个点
  • 同时只用了 4× 更少的 context token
  • 仅 4 次评估就匹配了 next-best method 的最终 accuracy
  • 比所有现有 text optimizer（OpenEvolve、TTT-Discover）都强，且收敛更快（10× fewer evaluations）

各优化器对比

4.2 数学推理（IMO 级别）

这个实验设计很有意思：在 200 道 IMO 级别数学题上搜索 retrieval-augmented harness。

数学推理结果

  • 发现的 harness 在 5 个 held-out 模型上平均提升 4.7 个点——注意是 held-out 模型，说明发现的 harness 策略有跨模型迁移能力
  • 相比 no retriever、dense retrieval、BM25 retrieval 都有显著提升
  • 最终 harness 操作的是代码空间里的 retrieval stack（在 BM25 基础上做局部修改），而不是传统的 prompt rewrite

4.3 Agentic Coding（TerminalBench-2）

TerminalBench 结果

在 TerminalBench-2（89 道需要长 horizon 自主执行的 coding 任务）上：

  • Meta-Harness 自动发现的 harness 超过了所有手工设计的 baseline
  • 在 Opus 4.6 上达到 74.7% pass rate，超过手工调优的 Terminus-KIRA（72.5%）
  • 在 Haiku 4.5 上排名 #1（所有 Haiku 4.5 agents 中）
  • 发现的 harness 甚至超过了手工设计者在公开 leaderboard 上的提交

5. 讨论和思考

5.1 这本质上是 AutoML 在 LLM 时代的回归

作为做 NAS/AutoML 出身的人，看到这篇论文第一反应是：这不就是 harness 版的 neural architecture search 嘛。

NAS 的 insight 是：与其人工设计网络结构，不如定义搜索空间让算法去找。Meta-Harness 的 insight 完全对称：与其人工设计 harness 代码，不如定义评估协议让 agent 去搜索。

甚至连技术路线都有映射关系：

  • NAS 的 controller/proposer → Meta-Harness 的 coding agent proposer
  • NAS 的 search space (cells, ops) → 这里的 code space (harness 代码)
  • NAS 的 evaluation (train & val) → 这里的 task evaluation
  • NAS 的 Pareto frontier (accuracy vs FLOPs) → 这里的 Pareto frontier (accuracy vs context tokens)

5.2 "不压缩反馈"是最有意思的 insight

现有 text optimizer 的核心假设是：反馈信号可以被有效压缩成短 summary，然后塞进 prompt。这个假设在 prompt optimization 上基本成立——因为 prompt 本身就短，改动也小，一句"这个 prompt 在 X 类问题上容易出错"就够了。

但 harness 优化完全不一样。一个 harness 可能有几百行代码，失败原因可能藏在某个微妙的 edge case 里——比如"当检索结果超过 5 条时，context 格式化逻辑里有个 off-by-one bug"。这种诊断信息不可能被压缩成一个 scalar score 或一段 summary。

论文的 ablation 也证实了这一点：只给 scores（不给 traces）时 median accuracy 34.6；给 scores + summary 时 34.9；给完整 traces 时 50.0。traces 是真正的 game changer。

5.3 几个值得追问的问题

搜索成本有多大？ 论文没有特别强调这一点，但从设计看：每轮迭代 proposer 需要读 82 个文件、消耗 1M token，跑 20 轮就是 20M token 纯 proposer 开销，加上 evaluation 开销。对于一次性的 harness 设计来说可以接受（搜一次用很久），但对于需要频繁适配新任务的场景，成本积累不小。

泛化能力的边界在哪？ 数学推理实验里发现的 harness 能迁移到 5 个 held-out 模型，这很impressive。但 TerminalBench 的 harness 是"specialized to the TerminalBench-2 regime"——论文自己说了。所以迁移能力可能高度依赖任务类型：工具/格式层面的优化可能通用，但领域特定的 context 管理策略可能不行。

这对 harness engineering 的从业者意味着什么？ 短期看，Meta-Harness 是一个强大的辅助工具——你不再需要从零手工调 harness，而是可以让它做初始搜索，你再在搜索结果上做微调。长期看，随着 coding agent 能力提升，harness 设计可能真的会变成一个完全自动化的流程。

5.4 一个有点 meta 的观察

论文最后提到一个很有趣的点：Meta-Harness 自己也是一个 harness（包裹 proposer 模型的那套代码）。那问题来了——能不能用 Meta-Harness 来优化 Meta-Harness 自身？

这不是开玩笑。论文的 proposer 是 Claude Code with Opus 4.6——它的 system prompt、filesystem 结构、搜索策略本身也是一套 harness。如果这套"meta-meta-harness"的设计也能被自动化，那就真的有点 recursive self-improvement 的味道了。当然，目前还远没到那一步，但方向值得关注。

总体来说，这篇工作的 contribution 很清晰：不是做了一个更好的 prompt optimizer，而是把问题定义提升到了 harness 层面，并且用"不压缩反馈 + filesystem 作为 memory + coding agent 作为 proposer"这套组合拳解决了 scale 的问题。 实验结果也足够硬——在三个不同领域都超过了手工设计和现有自动优化方法。

作为一个做 AutoML 的人，看到这个方向和 NAS 的深层联系，还是挺兴奋的。可能 LLM 时代的 AutoML 不是在搜网络结构了，而是在搜 harness 代码。搜索空间变了，但那个"let the machine find the design"的 spirit 没变。

欢迎评论区交流，尤其想听听有在做 agent harness 工程的同学的看法。

posted @ 2026-07-23 16:38  marsggbo  阅读(1)  评论(0)    收藏  举报