Meta-Harness让Haiku性能狂飙，甚至追平Opus！

新智元报道

编辑：倾倾

【新智元导读】如果未来的某天，AI智能体可以给自己调参数，修bug，会发生什么？

就在这两天，斯坦福IRIS Lab的博士生Yoonho Lee联合MIT、威斯康星大学的研究者放出一篇新论文，把AI智能体优化的逻辑翻了个个儿。

作者阵容十分豪华。导师是机器人学习明星学者Chelsea Finn，合作者里还有DSPy框架作者Omar Khattab。

曾经，大家卷模型本身的参数量、训练数据、RLHF。但Meta-Harness另辟蹊径：支撑模型运行的那层「脚手架」同样决定生死。

这些东西以前全靠人工调。现在，Meta-Harness让AI自己来干这活。

结果十分完美：Claude Haiku 4.5的成功率达到37.6%，登顶所有Haiku智能体榜首；Claude Opus 4.6更是达到76.4%，仅次于榜一ForgeCode。

模型是商品，Harness决定成败

harness指的是一整套基础设施：系统提示词、工具定义、重试逻辑、上下文管理、子代理协调、生命周期钩子。

模型本身只是个大脑，harness才是让这个大脑能干活的身体。

这个概念在2026年突然爆火，业界终于意识到，同一个模型，换个harness，性能差距可以大到离谱。

2月，工程师Can Bölük做了个实验。

他只改编辑格式，不动模型，15个LLM的编码性能提升了5到14个百分点，输出token还减少了约20%。

更夸张的是，GPT-4 Turbo仅仅换了一种编辑格式，准确率就从26%飙升到59%。

同样的模型，性能差了一倍多，唯一变量是harness。

Agent = Model + Harness，成了最热门的趋势

模型提供智能，harness让智能变得有用。

Claude Code、Codex在做同一件事：精心设计harness来弥补模型的短板。

那么问题来了，harness工程目前高度依赖人工。

工程师得手动写提示词、调工具接口、设计重试策略，然后跑测试、看日志、猜哪里出了问题、改代码、再跑测试。

这个循环费时费力，而且很多失败模式根本不是人能轻易诊断的。

Meta-Harness想做的，就是把这个循环自动化。

400倍信息量：AI自己「复盘+迭代」

Meta-Harness尝试着给优化器看更多东西。听起来简单，但这恰恰是过去所有方法的瓶颈。

论文这张对比表，列出了主流文本每一步能看到多少上下文：

Meta-Harness 与主流优化方法的上下文观察量对比。

Self-Refine只看最近一次输出加自我批评，大约1000 token；

OPRO看过去几轮的方案和分数，大约2000 token；

TextGrad、AlphaEvolve、GEPA这些更先进的方法，也就在8000到26000 token之间。

Meta-Harness呢？最高1000万token，差距是400倍。

为什么需要这么多？因为harness工程产生的失败模式，往往藏在执行轨迹的细节里。

一个任务跑失败了，原因可能是十步之前的某个工具调用返回了截断的输出，导致后续推理全歪。

如果优化器只能看到一个「失败」的标量分数，或者一段压缩过的摘要，它根本没法定位问题。

Meta-Harness的做法，是给proposer一个完整的文件系统。

这个文件系统里装着所有历史候选harness的源代码、每一轮的执行轨迹、命令日志、错误信息、超时行为、评分结果。

Proposer可以用grep、cat这些标准工具自己去翻，想看哪个文件就看哪个，想搜哪个关键词就搜哪个。

优化器不再是在固定prompt上做推理，而是一个会检索信息、浏览历史、编辑代码的代理。

proposer用的是Claude Code，它不需要被喂压缩过的信息，它有能力自己决定看什么、怎么看。

整个搜索循环很直白：

1. Proposer读取文件系统里的历史记录

2. 分析哪些任务失败了、失败原因是什么

3. 针对性地重写harness代码

4. 新harness跑测试，结果写回文件系统

5. 循环继续

Meta-Harness 核心优化闭环示意图。Proposer 从“包含全部历史经验”的文件系统读取完整轨迹（①），提出新的 Harness 代码 → 结合 LLM 执行任务并评估（②）→ 将 Proposed Code、Reasoning Traces、Eval Score 等全部日志存回文件系统（③），实现自我迭代。

论文展示了一个19任务子集上的搜索过程。

从Terminus-KIRA基线的28.5%起步，到第7轮迭代就涨到了46.5%。

Meta-Harness 在 19 任务子集上的迭代优化过程。从 Terminus-KIRA 基线 28.5% 的成功率起步，第 7 轮迭代达到 46.5%，展示了通过完整执行轨迹诊断实现的高效 harness 优化。

每一轮都基于具体的执行轨迹做「反事实诊断」——如果我当时这样处理，结果会不会不一样？

举个例子，第7轮的改进是在第一次LLM调用之前先跑一条shell命令，把环境依赖信息注入到初始prompt里。

加一条命令，省掉无谓的试错。 这种程度的诊断精度，靠压缩摘要是做不到的。

89个任务，小模型登顶

Meta-Harness分了三个场景做了测试：文本分类、数学推理、代码代理。

代码代理用的基准是TerminalBench-2，它包含89个Docker化任务，覆盖代码翻译、分布式机器学习配置、系统编程、生物信息学、密码分析等领域。

每个任务都是二元评分，跑5次取平均，难度相当高。

因为它们需要长程自主执行、处理复杂依赖、应对截断的终端输出，还得有相当的领域知识。

这个基准被几乎所有主流前沿实验室用来衡量代码代理的实际能力，是继SWE-bench之后又一个被广泛认可的「真实工作」测试集。

Meta-Harness的做法是优化完整的编码harness，包括系统提示词、工具定义、完成检测逻辑、上下文管理，全部都在优化范围内。

Proposer会读取每个任务的执行轨迹，诊断失败模式，然后提出针对性修复。

结果，Claude Haiku 4.5的成功率达到37.6%，在所有Haiku 4.5代理中排名第一，超过第二名Goose的35.5%

Claude Opus 4.6的成功率高达76.4%，在所有Opus 4.6代理中排名第二，仅次于ForgeCode的81.8%

需要强调的是，Haiku是Claude系列里最轻量的版本，参数量远小于Opus。

传统思路下，小模型就是不如大模型，性能天花板是硬伤。

但Meta-Harness证明，通过优化harness，小模型的天花板可以被显著抬高。

Meta-Harness 端到端优化结果总结。（左）在文本分类任务上，Meta-Harness 以极少的评估次数就超越了 ACE、OpenEvolve 等先前方法；（右）在 TerminalBench-2 基准上，Meta-Harness 优化的 Claude Haiku 4.5 harness 达到 37.6% 通过率，超越所有已报道的 Haiku 4.5 harness（包括 Goose 35.5% 和 Terminus-KIRA 33.7%），实现小模型登顶。

不止代码：文本分类和数学推理同样有效

Meta-Harness不只在代码任务上管用。

在文本分类场景下，研究者用了三个数据集：LawBench（215个类别）、Symptom2Disease（22个类别）、USPTO-50k（180个类别），模型是GPT-OSS-120B。

跑了20轮进化迭代，每轮2个候选，总共产出40个候选harness。

最佳发现的harness在测试集上达到48.6%准确率，比之前的SOTA方法ACE高出7.7个百分点。

甚至它的成本更低——Meta-Harness只用了45.5K上下文token，而ACE用了203K。

Meta-Harness 在文本分类任务上的表现。

研究者还做了直接对比实验，把Meta-Harness和两个代表性的程序搜索方法放在一起，给同样的proposer和评估预算。

结果是，Meta-Harness用十分之一的评估次数就追平了它们的最终准确率，而最终准确率还比它们高出10个百分点以上。

Harness Optimizer 搜索进度对比。Meta-Harness（红色曲线）在极少的 Harness Evaluations 下快速达到最高性能，显著优于 OpenEvolve、TTTDiscover、ACE 等方法，展现了完整执行轨迹带来的效率优势。

原因就是OpenEvolve和PUCT都把历史压缩成固定的prompt格式，丢掉了执行轨迹。Meta-Harness保留了一切。

在数学推理场景下，Meta-Harness搜索的是检索增强的推理策略。

语料库里有超过50万道题，来自8个开源数据集。

研究者在250道题的搜索集上进化出一个检索harness，然后在200道IMO级别的题目上测试，还额外用了5个搜索时从未见过的模型。

单一发现的检索harness在5个新模型上平均提升了4.7个百分点（从34.1%到38.8%），而且是在模型不变的情况下。

Meta-Harness 检索策略的跨模型迁移能力。

这说明Meta-Harness发现的策略是可迁移的，不是只对特定模型有效的过拟合技巧。

模型能力的竞争正在进入一个新阶段。

过去几年，前沿实验室比的是谁的模型更强、参数更多、训练数据更大、benchmark分数更高。

但现在，GPT-5、Claude 4、Gemini 3在很多任务上已经拉不开太大差距。

真正的差距在哪里？在harness。

同一个模型，配上不同的harness，性能可以差一倍。

而harness工程目前还高度依赖人工经验，没有系统化的方法论，也没有自动化的工具。

模型是智能的来源，harness是智能的放大器，而现在，优化harness本身也可以交给AI来做。

这可能是LLM应用开发进入下一阶段的标志。

参考资料：

https://x.com/yoonholeee/status/2038640635482456118