不调模型调"脚手架"：斯坦福 Meta-Harness 让AI自动优化LLM外围代码，效果炸裂

---

你有没有想过，同一个模型，换一套外围代码就能涨好几个点？

我说的不是微调，不是RLHF，而是你写的那些 prompt 模板、检索逻辑、上下文拼接代码——这些东西在学术圈叫 harness（脚手架），在工程上就是你天天在调的"胶水代码"。

坦率的讲，做过 LLM 应用开发的人都有体会：模型能力是一回事，怎么喂数据给它、怎么组织上下文、怎么后处理输出，这些代码层面的东西对最终效果的影响，有时候比换一个更大的模型还大。但问题是，这些代码全靠人手调——试错成本高，而且很多时候你都不知道最优解长什么样。

斯坦福和MIT的一个团队最近丢出来一篇论文，核心想法直接且大胆：让 coding agent 自动搜索最优的 harness 代码。 不是优化一句 prompt，而是优化整个 Python 文件——包括检索策略、上下文管理、多轮调用逻辑、后处理流程，全部自动搜索。

效果？在线文本分类任务上比 ACE 涨了 7.7 个点，同时上下文 token 用量砍到四分之一。在 TerminalBench-2 编程基准上，Claude Haiku 4.5 配上搜索出来的 harness 直接登顶第一。

这篇论文叫 Meta-Harness，我觉得它提出的问题比给出的答案更重要——它在说：别光盯着模型本身了，模型外面那层代码同样值得系统性优化。

---

论文信息

• 标题： Meta-Harness: End-to-End Optimization of Model Harnesses
• 作者： Yoonho Lee, Roshen Nair, Qizheng Zhang, Kangwook Lee, Omar Khattab, Chelsea Finn
• 机构： Stanford University, KRAFTON, MIT
• 日期： 2026年3月30日
• 链接： https://arxiv.org/abs/2603.28052

作者阵容挺豪华——Chelsea Finn 是斯坦福机器人学习方向的明星教授，Omar Khattab 则是 DSPy 框架的作者。这两个人凑到一起搞 harness 优化，说明这个方向确实在变热。

---

问题动机：Harness 到底有多重要？

先说清楚一个概念：harness 在这篇论文里指的是什么？

它不是模型权重，不是训练数据，而是围绕模型的那层调用代码——决定了模型看到什么输入、以什么格式看到、用多少上下文、怎么做检索、怎么处理输出。举几个具体例子：

• 文本分类时：给模型看哪些 few-shot 样本？按什么顺序排？要不要加对比样本？
• 数学推理时：检索哪些相关题目作为参考？用什么检索策略？怎么路由到不同的检索模式？
• 代码生成时：agent 的系统提示怎么写？工具调用的顺序怎么编排？环境初始化脚本怎么配？

这些东西，现在全靠人工试错。而且有个很尴尬的现实——同一个模型，不同人写的 harness，效果差别可以非常大。

之前的工作，比如 DSPy、TextGrad、OPRO 这些 prompt 优化方法，归根到底还是在优化文本片段（prompt 字符串）。Meta-Harness 的野心更大：它要优化的是整个 Python 程序。

---

核心方法：让 Agent 在文件系统里"挖矿"

Meta-Harness 的架构其实就是一个搜索循环，但它的信息获取方式很不一样。

图1：Meta-Harness 的三步搜索循环。一个 coding agent（用的是 Claude Code + Opus 4.6）从文件系统中读取历史候选的代码、分数和执行轨迹，提出新的 harness 代码，评估后把所有信息写回文件系统。

整个流程三步走：

第一步：Agent 提议新的 harness 代码。 Agent 可以自由浏览文件系统里的所有历史记录——之前试过哪些 harness、每个的源码长什么样、跑出来什么分数、哪些 case 过了哪些没过、执行轨迹（reasoning traces）全在。Agent 用 grep、cat 这些命令自己去翻文件，不是被动接收一个压缩过的摘要。

第二步：评估。 新 harness 在任务上跑一遍，拿到分数。

第三步：存档。 把新 harness 的源码、分数、执行轨迹全部写入文件系统。

然后重复，大约 20 轮迭代。

这里最关键的设计决策是什么？

是信息的保真度。

传统的 prompt 优化器（OPRO、TextGrad 等）每轮迭代给优化器看的信息量大概是 0.002-0.026 MTok（百万 token）。为什么？因为它们会压缩——把历史信息总结成分数或者文字摘要，然后塞进一个 prompt 里。

Meta-Harness 每轮迭代的可访问信息量是 10 MTok。差了三个数量级。

它不压缩，不总结，所有原始数据都在文件系统里，Agent 自己决定看什么。论文报告说 Agent 每轮迭代平均读 82 个文件——包括之前候选的源码、执行日志、错误输出等等。

这个设计选择很有意思。它等于是在说：信用分配（credit assignment）这件事，交给 Agent 自己来做，别替它总结。 Agent 可以自己去翻某个失败 case 的执行轨迹，定位到是检索阶段出了问题还是 prompt 格式有问题，然后针对性地改。

---

实验一：在线文本分类——用四分之一的 token 涨 7.7 个点

这组实验是在三个数据集（USPTO 专利分类、Symptom2Disease 症状诊断、LawBench 法律）上做的在线文本分类任务。

先看主实验结果：

方法	USPTO	S2D	Law	平均准确率	上下文长度(K)
Zero-Shot	12.0	63.2	7.0	27.4	0
Few-Shot (8)	14.0	67.9	21.0	34.3	2.0
Few-Shot (32)	13.0	72.2	21.0	35.4	7.9
Few-Shot (all)	15.0	78.3	29.0	40.8	12.3
MCE	14.0	83.0	23.0	40.0	28.5
ACE	16.0	77.8	29.0	40.9	50.8
Meta-Harness	14.0	86.8	45.0	48.6	11.4

几个值得注意的点：

LawBench 上从 29.0 涨到 45.0，这个提升幅度相当惊人。Symptom2Disease 上也从 77.8 到 86.8。但 USPTO 上基本没涨（14.0 vs 16.0 甚至略低于 ACE），这说明搜索出来的 harness 不是所有场景都能赢。

最让我在意的是上下文长度那一列：Meta-Harness 只用了 11.4K 上下文，ACE 用了 50.8K。 效果更好的同时 token 用量砍了四倍多——这在生产环境里很有实际意义，直接影响延迟和成本。

图2：测试准确率 vs 附加上下文长度。红色星标是 Meta-Harness 发现的帕累托最优 harness。可以看到在几乎所有上下文预算下，Meta-Harness 都在帕累托前沿上方——也就是说，不管你愿意花多少 token，它都能找到一个比人工方案更好的选择。注意右侧的 MCE 和 ACE 用了 115K 和 200K 的上下文，效果反而不如 Meta-Harness 用 50K 时的方案。

---

搜索效率：搜索曲线才是真正有意思的地方

图3：搜索进度对比。横轴是 harness 评估次数，纵轴是历史最佳性能。Meta-Harness（红线）大约在第 7-8 次评估时就跃升到 55%，之后逐步攀升到 57%。而 TTT-Discover、OpenEvolve 等方法在 40 次评估后才慢慢收敛到 45% 左右。

看这张图，Meta-Harness 对比其他方法的表格也很说明问题：

方法	中位数准确率	最佳准确率
GEPA	32.6	40.2
Best-of-N	34.0	44.2
OpenEvolve	39.1	43.3
TTT-Discover	34.1	45.6
Meta-Harness	50.0	56.7

中位数 50.0 vs 其他方法最好的 39.1——这个差距不小。但我想指出一个公平性的问题：Meta-Harness 每轮迭代消耗的 token 远高于其他方法（10 MTok vs 0.002-0.026 MTok），虽然评估次数更少，但总 token 消耗其实不一定更低。论文在这方面的讨论不太充分。

---

消融实验：执行轨迹是关键

这组消融直接验证了"信息保真度"这个核心假设：

Agent 可访问的信息	中位数准确率	最佳准确率	超过Zero-Shot的方案数
仅分数	34.6	41.3	26
分数 + 文字摘要	34.9	38.7	23
完整信息（Meta-Harness）	50.0	56.7	39

看到那个"分数 + 摘要"的结果了吗？34.9，甚至比只看分数的 34.6 没好多少。

这说明什么？压缩过的摘要信息几乎没用。 Agent 需要看原始的执行轨迹——具体哪些 case 错了、错在哪里、模型的推理过程是什么——才能做出有效的改进决策。这跟我们做 debug 的经验是一致的：看一个"失败率 30%"的数字，和看 10 个具体的失败 case，能做出的改进完全不一样。

---

实验二：数学推理——跨模型迁移的 Harness

这个实验设计更有意思：在一组模型上搜索最优的检索 harness，然后直接迁移到五个从未见过的模型上。

方法	GPT-5.4n	GPT-5.4m	Gem-3.1FL	Gem-3F	GPT-20B	平均
无检索	23.0	28.8	28.6	42.6	47.6	34.1
Dense检索(k=1)	27.1	24.5	31.3	42.3	46.9	34.4
Dense检索(k=5)	31.1	28.3	37.1	47.2	46.7	38.1
BM25检索	30.2	29.2	32.8	46.6	48.9	37.5
Meta-Harness	31.7	30.4	34.9	46.3	50.6	38.8

平均从 34.1 到 38.8，涨了 4.7 个点。在 GPT-OSS-20B 上效果最好（50.6 vs 47.6），但在 Gemini-3-Flash 上反而比 Dense 检索(k=5) 差了一点（46.3 vs 47.2）。

搜索出来的 harness 是什么样的？论文描述了一个四路 BM25 检索系统——根据题目的数学分支（组合、几何、数论、代数）走不同的检索路径。这个策略本身不算新颖，但关键在于这种分支逻辑是 Agent 自己探索出来的，不是人预设的。

说实话，4.7 个点的提升在 IMO 级别的数学题上算是有意义的，但不算特别大。而且 Meta-Harness 和 BM25 的差距只有 1.3 个点（38.8 vs 37.5），这让我对检索 harness 优化的上限有点存疑——也许在这个任务上，检索策略的天花板就在这附近了。

---

实验三：TerminalBench-2 编程基准——小模型逆袭

这组实验的结果可能是最抓眼球的。

图4：TerminalBench-2 编程基准上 Claude Haiku 4.5 各 agent 的通过率对比。Meta-Harness（37.6%）排名第一，超过了 Goose（35.5%）和 Terminus-KIRA（33.7%）。注意原版 Claude Code 只有 27.5%——配上优化后的 harness 涨了 10 个点。

具体数据：

Claude Opus 4.6 上：
Meta-Harness 76.4%，排在 ForgeCode（81.8%）之后，位列第二。

Claude Haiku 4.5 上：
Meta-Harness 37.6%，排名第一。原版 Claude Code 只有 27.5%。

这里有个很有意思的现象：Haiku 是个小模型，但配上搜索出来的 harness，直接超过了用更大模型但 harness 没优化的 agent。涨了 10 个点——从 27.5% 到 37.6%。

搜索出来的 harness 做了什么？论文说是环境引导（environment bootstrapping）——在 agent 开始执行任务之前，先注入一个操作系统快照，让 agent 对当前环境有更完整的认知。这个策略很实用，但其实不少工程团队早就在手动做类似的事了。Meta-Harness 的贡献在于它自动发现了这个策略。

---

搜索过程的质性分析：Agent 真的在做因果推理吗？

论文里有一段对 TerminalBench-2 搜索轨迹的质性分析，我觉得挺有价值的。

Agent 在搜索过程中遇到了一个问题：一次修改同时改了 harness 结构和 prompt 内容，结果效果变差了。但到底是哪个改动导致的？Agent 注意到了这种混淆因素（confounded edits），主动将修改拆开，分别测试。之后它转向了"纯加法修改"策略——只在之前的最优基础上叠加新功能，不做结构性改动。

这种行为——识别混淆变量、做变量控制、调整搜索策略——看起来像是在做因果推理。但我对此持保留态度：这也可能是 Claude Opus 4.6 这个基础模型本身的能力，在 coding agent 场景下的自然表现。论文没有做足够的对照实验来区分"这是 Meta-Harness 的框架贡献"还是"这是基础模型足够聪明"。

---

OOD 泛化：搜索出来的 Harness 能迁移吗？

论文还测了 9 个分布外（out-of-distribution）数据集：

方法	SciCite	FiNER	Amz5	FPB	GoEmo	Bank77	AGNews	SciTail	TwHate	平均
Zero-shot	32.7	56.0	52.7	90.0	42.0	80.7	84.7	89.3	75.3	67.0
ACE	40.7	74.0	48.0	96.7	44.0	83.3	86.0	90.7	68.7	70.2
Meta-Harness	53.3	67.0	60.0	94.0	46.0	82.7	86.7	91.3	77.3	73.1

平均 73.1 vs ACE 的 70.2，涨了 2.9 个点。SciCite 上涨幅最大（53.3 vs 40.7），但 FiNER 上反而比 ACE 差了不少（67.0 vs 74.0），FPB 上也略低（94.0 vs 96.7）。

图5：验证集 vs 测试集准确率。粉色点是 Meta-Harness 搜索出的各候选 harness。大部分点分布在对角线附近或上方，说明搜索过程没有严重过拟合验证集。但 USPTO（右图）上点的分布比较散乱，泛化效果不太稳定。

泛化性总体还行，但不是所有数据集都稳赢。这也合理——搜索出来的 harness 策略（比如"先确认再质疑"的两阶段分类）本身有适用范围，不是万能的。

---

我的判断：这篇论文到底怎么样？

亮点很明确：

1. 问题定义有价值。 把"harness 优化"作为一个独立的优化问题提出来，这个 framing 我觉得是对的。之前大家要么在调 prompt（文本级别），要么在调模型（权重级别），中间那层代码级别的优化一直是手工活。

2. 信息保真度的设计选择很有说服力。 消融实验清楚地表明，压缩信息几乎没用，Agent 需要原始执行轨迹。这对整个"LLM 优化 LLM"这个方向都有启发意义。

3. 跨模型迁移。 数学推理实验表明搜索出来的 harness 可以直接迁移到新模型上——这意味着 harness 优化的成本可以被摊分。

我觉得有问题的地方：

1. 计算成本不太透明。 论文说每轮迭代 Agent 读 10 MTok 信息、读 82 个文件。20 轮迭代就是 200 MTok 的读取量，加上 Agent 自身的推理消耗，总成本不低。跟其他方法比"评估次数更少"，但 per-iteration 成本高很多，总成本对比缺失。

2. 基础模型依赖。 搜索用的是 Claude Code + Opus 4.6——目前最强的 coding agent 之一。换一个弱一点的 Agent 做 proposer，效果会怎样？论文没有做这个消融。如果 Meta-Harness 的效果高度依赖基础模型的能力，那它的可复现性和普及性就要打个问号。

3. 搜索出来的策略本身不算新。 两阶段确认-质疑分类、BM25 分支路由、环境引导注入——这些都是有经验的工程师可能会想到的策略。Meta-Harness 的贡献在于"自动发现"，但如果终点就是人工也能到达的地方，那更像是自动化工程而不是方法论突破。

4. 任务选择偏窄。 三个实验涵盖了分类、检索和编程，看起来挺全面的。但文本分类上那 7.7 个点的提升主要来自 LawBench（45 vs 29），USPTO 上几乎没有提升。数学推理上和 BM25 的差距只有 1.3 个点。TerminalBench-2 的结果最亮眼，但只在 Haiku 上排第一——在 Opus 上排第二。

工程启发：

如果你在做 LLM 应用，这篇论文给出了一个很清晰的信号：系统性地优化 harness 代码是有价值的。 即使你不用 Meta-Harness 这套自动化框架，至少应该：

• 记录每次 harness 修改的效果变化（别光存最终版本）
• 保存失败 case 的完整执行轨迹，不只看分数
• 把 harness 当作可搜索的代码空间，而不是一次性写好的固定代码

说到底，这篇论文最有价值的地方可能不是 Meta-Harness 这个系统本身，而是它提出的这个观察：在 LLM 应用开发中，模型之外的代码层同样需要被当作一等公民来优化。 这个观察，对于当前越来越多的 Agent 框架、RAG 系统、工具调用链来说，都很有现实意义。

---

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我