团队：MIT（Omar Khattab）+ Stanford（Chelsea Finn）| 提交日期：2026.03.30
🎯 核心问题：Harness 才是 LLM 系统的真正瓶颈
大模型系统的性能，不取决于模型权重，更取决于 harness——决定存什么信息、取什么信息、怎么呈现给模型的那段代码。论文给出了一个惊人的数字：同一个 benchmark 上，换一个 harness 可以产生 6 倍的性能差距。然而，harness 到今天还是靠手搓的。
为什么现有的 text optimizer（ProTeGi、TextGrad、OPRO、OpenEvolve 等）搞不定 harness？因为它们的反馈通道太窄了——每次优化步骤只用 100 到 30,000 tokens 的上下文。而 harness 的一个决策，其下游影响可能跨越很多推理步骤，压缩后的摘要根本追踪不到根因。
📊 关键数据：三个场景全面碾压
- 文本分类：比 SOTA（ACE）高 7.7 分，同时使用 4x 更少的 context tokens。只用 4 次评估就追平了次优方法的最终性能
- RAG 数学推理：单次发现的 harness，在 200 道 IMO 级题目上平均提升 4.7 分（跨 5 个 held-out 模型一致提升）
- Agentic Coding：TerminalBench-2 上超越所有手搓 baseline，包括 Terminus-KIRA，排名 Haiku 4.5 agent 中 #1
🏗️ 技术架构：用 Coding Agent 搜索 Harness 代码
Meta-Harness 本身也是一个 harness（所以叫 meta）。它是一个外层循环系统，核心思路极其简洁：
- Proposer（编码 Agent）读取一个文件系统，里面存了所有之前候选 harness 的源代码、评估分数、执行 trace
- Proposer 用 grep、cat 等终端工具选择性地 inspect 感兴趣的历史数据，推理失败模式，然后生成新的 harness 代码
- 新 harness 被评估，所有日志（源码、分数、trace）写入新目录，循环重复
为什么用 Coding Agent 而不是 raw LLM？因为历史经验很快就超过上下文窗口，proposer 必须自主决定 inspect 什么、怎么验证 edit。搜索本身就是 agent 行为。
核心设计选择：文件系统 > 压缩摘要
其他方法把反馈压缩成标量分数或短模板；Meta-Harness 直接把原始数据暴露给 proposer。单次评估产生高达 10,000,000 tokens 的诊断信息，比最大 text optimizer 高出 3 个数量级。Proposer 每次迭代平均读取 82 个文件，引用 20+ 个历史候选。
⚔️ 与现有方法的核心差异
- vs TextGrad/OPRO：只看标量分数或短摘要，Meta-Harness 看完整执行 trace。相当于一个只能看考试分数 vs 一个能看完整答卷 + 草稿纸
- vs OpenEvolve/GEPA：在预定义搜索空间内演化，Meta-Harness 可以做任意代码修改——不限于 prompt 模板，而是整个 harness 实现
- vs Memory-based Agent：文件系统在任务间重置，搜索的是通用 harness 策略而非特定任务知识
🔑 关键洞察
1. Harness 是 AI 系统中被低估的杠杆
整个 AI 行业都在卷模型能力，但 harness 这层工程几乎没人系统性地优化。Meta-Harness 证明：花同样的算力，优化 harness 带来的收益可能比训新模型还大。6 倍性能差距不是换模型，是换 harness。
2. Coding Agent 是 Harness 搜索的天然载体
论文作者坦言这个 workflow 直到 2026 年初 coding agent 能力大幅提升后才变得实用。Coding agent 天然具备：(1) 读写代码能力 (2) 选择性检索大量信息能力 (3) 自主决策 inspect 什么能力。
3. 从「训模型」到「搜 Harness」的范式转移
Meta-Harness 本质是 meta-learning：不更新模型权重，在 harness 层面做 credit assignment。这和我们日常做 harness engineering 的思维方式完全一致，只是被自动化了。
逍遥云初 | 2026.04.05
