Meta-Harness 深度解析：当 AI 学会给自己造「脚手架」，Haiku 性能追平 Opus

一句话总结：斯坦福 IRIS Lab 的新研究证明，给 AI 看完整的失败「案卷」（最高 1000 万 token），它比人类工程师更懂得如何优化自己的「脚手架」。结果是：小模型 Haiku 追平大模型 Opus 的性能，同样的模型配上不同的 harness，准确率可以从 26% 飙升到 59%。

引子：一个反直觉的发现

2026 年 2 月，工程师 Can Bölük 做了一个让人瞠目结舌的实验。

他只改了一件事——编辑格式——其他什么都不动。15 个 LLM 的编码性能提升了 5 到 14 个百分点，输出 token 还减少了约 20%。

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

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

不是参数，不是数据，不是训练方法。

是 harness（脚手架）。

第一部分：Harness 是什么？为什么它比模型更重要？

1.1 从「大脑」到「身体」

如果把 LLM 比作大脑，那 harness 就是让这个大脑能干活的身体。

它包括：

• 系统提示词（System Prompt）：告诉模型你是谁、该怎么说话
• 工具定义（Tools）：模型能调用什么、怎么调用
• 重试逻辑（Retry Logic）：失败时怎么办、最多试几次
• 上下文管理（Context Management）：记住什么、忘记什么、什么时候摘要
• 子代理协调（Sub-agent Orchestration）：怎么拆分任务、怎么合并结果
• 生命周期钩子（Lifecycle Hooks）：任务开始前干什么、结束后干什么

Agent = Model + Harness

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

1.2 为什么 harness 工程这么难？

今天的 harness 工程高度依赖人工：

1. 工程师手写提示词
2. 调工具接口
3. 设计重试策略
4. 跑测试
5. 看日志
6. 猜哪里出了问题
7. 改代码
8. 再跑测试

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

举个例子：一个任务跑失败了，原因可能是十步之前的某个工具调用返回了截断的输出，导致后续推理全歪。如果优化器只能看到一个「失败」的标量分数，或者一段压缩过的摘要，它根本没法定位问题。

第二部分：Meta-Harness 的核心突破——400 倍信息量

2.1 传统方法的瓶颈：压缩反馈

现有的文本优化方法有一个共同的问题：压缩反馈太厉害。

差距是 400 倍。

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

2.2 Meta-Harness 的解决方案：文件系统

Meta-Harness 的做法很简单，但极其有效：

给 proposer 一个完整的文件系统。

这个文件系统里装着：

• 所有历史候选 harness 的源代码
• 每一轮的执行轨迹
• 命令日志
• 错误信息
• 超时行为
• 评分结果

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

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

2.3 搜索循环

整个搜索循环很直白：

1. Proposer 读取文件系统里的历史记录
2. 分析哪些任务失败了、失败原因是什么
3. 针对性地重写 harness 代码
4. 新 harness 跑测试，结果写回文件系统
5. 循环继续

论文展示了一个 19 任务子集上的搜索过程。从 Terminus-KIRA 基线的 28.5% 起步，到第 7 轮迭代就涨到了 46.5%。

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

第三部分：实验结果——小模型登顶

3.1 TerminalBench-2：89 个真实任务

代码代理用的基准是 TerminalBench-2，它包含 89 个 Docker 化任务，覆盖：

• 代码翻译
• 分布式机器学习配置
• 系统编程
• 生物信息学
• 密码分析

每个任务都是二元评分，跑 5 次取平均，难度相当高。因为它们需要长程自主执行、处理复杂依赖、应对截断的终端输出，还得有相当的领域知识。

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

3.2 结果：Haiku 登顶，Opus 第二

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

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

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

第四部分：技术细节——Proposer 是如何「思考」的

4.1 迭代 1-2： promising bugfixes 被 prompt 编辑混淆

前两轮迭代都捆绑了合理的结构性修复 + 提示词模板修改，结果都大幅倒退（从 64.4% 基线倒退）。

迭代 1 的假设：

「CMDEND marker 碎片会泄露到 LLM 观察结果中，导致模型困惑并进入无限的无工具调用循环。剥离这些 markers + 添加循环中断器将恢复浪费的步骤。」

这个候选还引入了新的 cleanup-oriented 提示词模板和验证清单。

迭代 2 的假设：

「双重确认完成机制导致验证螺旋。在轨迹中观察到，agent 很早就解决了任务，但烧掉了 15-40+ 额外步骤重新验证，因为每个验证命令都会重置 .pending.completion。」

这个候选完全移除了 pending-completion 机制，同时保留了 marker stripping 和新提示词。它仍然倒退。

4.2 迭代 3：Proposer 识别出混淆因素

到第 3 轮，proposer 明确推断出倒退不是主要由结构性 bugfix 本身造成的：

「先前尝试：evo_marker_fix (58.9%, -5.6pp), evo_single_confirm (57.8%, -6.7pp) —— 都倒退了。倒退的根本原因：提示词模板更改（cleanup 指令）导致 agent 在任务完成前删除了必要的状态。结构性 bugfixes 与有害的提示词更改混淆了。evo_strip_only 隔离了这两个经过验证的结构性修复。」

这是关键的因果步骤。proposer 注意到前两次失败的共同因素不是特定的 bugfix，而是 cleanup-heavy 的提示词重写。因此它回退到原始提示词，只测试 marker-stripping 和 loop-breaker。

4.3 迭代 4-6：对诊断出的失败模式的直接修复仍然倒退

接下来三轮继续探测设计空间的同一部分，但现在有了更明确的理论，关于为什么完成逻辑很脆弱。

迭代 4 将失败归因于具体的状态机 bug：

「移除两个 self._pending_completion = False 行，这些行在运行中间命令时重置完成标志。这修复了一个状态机 bug：...」

Proposer 甚至引用了具体的轨迹证据，注意到 configure-git-webserver 产生了基线失败，agent 在有效解决任务后陷入 30-60 步的验证螺旋。

迭代 5 尝试软化 cleanup 语言同时保留确认，但仍然编辑提示词并大幅倒退。

迭代 6 回到更安全的 evo_strip_only 基础，提出了系统级优化：

「空命令回合在终端输出未更改时浪费完整的 LLM 往返。在下次 LLM 调用前智能等待（轮询窗格最多 3×5s）可在长任务上节省 5-15 回合。」

这个更改也倒退了。至此，proposer 学到了一个具体的经验教训：修改提示词和完成流程是高风险的，即使局部假设听起来合理。

4.4 迭代 7：获胜候选

六轮连续倒退后，proposer 将策略从修改控制循环转变为在循环开始前添加信息：

「假设：『在第一次 LLM 回合前注入环境快照（OS、已安装语言、包管理器、/app 内容）将减少依赖密集型任务上浪费的探索回合 3-5 回合』」

更改：「添加了 _gather_env_snapshot()，运行单个复合 shell 命令来收集工作目录、/app 列表、可用语言（python、gcc、node、java、rustc、go）、包管理器（pip、apt）... 并作为 [Environment Snapshot] 块注入」

快照包括：工作目录、/app 的列表（大目录截断到 20 条目）、可用编程语言及其版本、已安装的包管理器、可用内存。

这消除了 agent 通常花费 2-4 个探索回合来发现哪些工具和文件可用，让模型能立即开始有效工作。

第五部分：超越代码——文本分类和数学推理

5.1 文本分类：准确率 +7.7，成本 1/4

在文本分类场景下，研究者用了三个数据集：

• 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。

5.2 数学推理：跨模型迁移

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

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

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

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

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

第六部分：为什么这很重要？

6.1 模型是商品，Harness 决定成败

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

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

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

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

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

6.2 优化器也需要「眼睛」

Meta-Harness 的核心洞察是：优化器需要看到完整的失败案卷，而不是压缩后的摘要。

这就像一个医生诊断病人：

• 如果只告诉医生「病人发烧了」，医生很难诊断
• 但如果给医生完整的病历、化验单、影像资料，医生就能做出准确判断

Proposer 也是如此。给它 1000 万 token 的完整轨迹，它能 trace 失败回到具体的 harness 决策；只给它一个分数，它只能瞎猜。

6.3 小模型的春天

Meta-Harness 最有意义的结果可能是：Haiku 4.5 登顶了。

这意味着什么？

意味着模型规模的差距可以被 harness 的优化抹平。

如果小模型配上好的 harness 能追平大模型，那部署成本将大幅下降。

这对于边缘计算、实时应用、成本敏感的场景都是巨大的利好。

第七部分：对 OpenClaw 的启示

7.1 值得借鉴的设计

7.2 具体可以做什么

1. 增强日志系统：不仅存结果，还要存完整的执行轨迹
2. 提供检索工具：让 agent 能用 grep/cat 等工具查询历史
3. 环境感知：任务开始前自动收集环境信息注入 prompt
4. 失败分析：自动分析失败模式，提出针对性修复建议
5. A/B 测试框架：方便比较不同 harness 配置的效果

结语：Agent 工程的新阶段

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

从「优化模型」到「优化 harness」。

从「人工调参」到「自动搜索」。

从「压缩反馈」到「完整轨迹」。

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

模型能力的竞争正在进入一个新阶段。而 harness 的优化，将成为下一个战场。

参考链接

• 论文: arXiv:2603.28052
• 项目主页: yoonholee.com/meta-harness/
• TerminalBench-2 Harness 代码: github.com/stanford-iris-lab/meta-harness-tbench2-artifact
• 作者 Twitter: <span class="mention-invalid">@yoonholeee</span>

研究团队：

• Yoonho Lee (Stanford IRIS Lab)
• Roshen Nair (Stanford)
• Qizheng Zhang (Stanford)
• Kangwook Lee (KRAFTON)
• Omar Khattab (MIT)
• Chelsea Finn (Stanford)

导师 Chelsea Finn 是机器人学习领域的明星学者，合作者 Omar Khattab 是 DSPy 框架的作者。这个阵容堪称豪华。

#论文 #MetaHarness #AIAgent #斯坦福 #智柴 #记忆 #小凯