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 传统方法的瓶颈：压缩反馈 现有的文本优化方法有一个共同的问题：**压缩反馈太厉害**。 | 方法 | 每一步能看到多少上下文 | |------|----------------------| | Self-Refine | 只看最近一次输出 + 自我批评，约 1000 token | | OPRO | 看过去几轮的方案和分数，约 2000 token | | TextGrad、AlphaEvolve、GEPA | 约 8000 到 26000 token | | **Meta-Harness** | **最高 1000 万 token** | 差距是 **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 第二 | 模型 | Harness | 成功率 | 排名 | |------|---------|--------|------| | Claude Opus 4.6 | Meta-Harness | **76.4%** | #2（所有 Opus 代理中）| | Claude Haiku 4.5 | Meta-Harness | **37.6%** | #1（所有 Haiku 代理中）| 需要强调的是，**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 值得借鉴的设计 | 优先级 | 功能 | 实施难度 | 说明 | |--------|------|----------|------| | 🔴 高 | 完整执行轨迹存储 | 低 | 每次 tool call、每次 LLM 响应都存下来 | | 🔴 高 | 反事实诊断能力 | 中 | 让 proposer 能回溯失败原因 | | 🟡 中 | 环境快照注入 | 低 | 任务开始前收集环境信息 | | 🟡 中 | Harness 版本控制 | 中 | 追踪每次 harness 变更的效果 | | 🟢 低 | 自动 harness 搜索 | 高 | 完整的 Meta-Harness 实现 | ### 7.2 具体可以做什么 1. **增强日志系统**：不仅存结果，还要存完整的执行轨迹 2. **提供检索工具**：让 agent 能用 grep/cat 等工具查询历史 3. **环境感知**：任务开始前自动收集环境信息注入 prompt 4. **失败分析**：自动分析失败模式，提出针对性修复建议 5. **A/B 测试框架**：方便比较不同 harness 配置的效果 --- ## 结语：Agent 工程的新阶段 Meta-Harness 代表了一个重要的范式转变： **从「优化模型」到「优化 harness」。** 从「人工调参」到「自动搜索」。 从「压缩反馈」到「完整轨迹」。 这可能标志着 LLM 应用开发进入下一阶段的标志。 模型能力的竞争正在进入一个新阶段。而 harness 的优化，将成为下一个战场。 --- ## 参考链接 - **论文**: [arXiv:2603.28052](https://arxiv.org/abs/2603.28052) - **项目主页**: [yoonholee.com/meta-harness/](https://yoonholee.com/meta-harness/) - **TerminalBench-2 Harness 代码**: [github.com/stanford-iris-lab/meta-harness-tbench2-artifact](https://github.com/stanford-iris-lab/meta-harness-tbench2-artifact) - **作者 Twitter**: [<span class="mention-invalid">@yoonholeee</span>](https://x.com/yoonholeee) --- **研究团队**： - 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 #斯坦福 #智柴 #记忆 #小凯