Meta-Harness：给大模型「换马鞍」的自动化引擎

想象这个场景：你买了一匹千里马，配的却是漏水的马鞍。骑上去跑十里，马还好好的，你摔了三回。没人会怪马。马鞍的问题。

大语言模型也一样。模型权重是那匹良驹，真正决定它能不能跑出成绩的，是绕在模型外面的那层代码壳——论文叫它 harness（挽具/马具）。同一套模型，换一套 harness，性能能差到 6 倍（原论文引用 [47] 的数据）。也就是说，磨好提示词编排、检索策略、验证流程、记忆管理这些「马具」，往往比换大模型划算得多。

问题是——今天这套打磨活，基本全靠人肉。工程师盯失败 case，手调启发式规则，来回改几版，一下午没了。Stanford 和 MIT 的一帮研究者就问了个再自然不过的事：这活儿，能不能也自动化？

答案就是 Meta-Harness。一套用外循环搜索自动优化 harness 代码的系统。作者 Yoonho Lee（Stanford）、Omar Khattab（MIT）、Chelsea Finn（Stanford）等六人，arXiv 2603.28052。

1. 现有文本优化器，为什么搞不定 harness？

乍一想，这活儿不该难。文本优化（text optimization）这两年正热，OPRO、TextGrad、AlphaEvolve、GEPA、TTT-Discover 都是干这事的：给你一段文本——提示词也好，程序、配置也罢——拿反馈信号迭代往下改。那搬过来优化 harness 不就行了？

不行。原因在反馈的压缩太狠了。

看 Table 1：OPRO 每步上下文只有 0.002M token——就塞几对「方案-分数」。TextGrad 0.015M，就当前产物的一条文本反馈。AlphaEvolve 0.022M，程序数据库+纯标量分数。反馈最「丰富」的 GEPA，0.008M，摘要级反思。TTT-Discover 多那么一点，0.026M，但也只是上一版解法的一个片段。说白了，个个都跟失忆症患者似的——每轮迭代只记得最近的一小截。

Meta-Harness 呢？每步 10.0M token，全日志。 差了三个数量级。

为什么非要这么长的上下文？harness 的决策是长程依赖的。文本分类里你决定「检索 5 个还是 10 个」「做不做两阶段验证」「用什么相似度」，这几个选择会一路影响到几百个样本的推理表现。只给压缩反馈，就好比看考试总分、看不到每道题的答题过程——你知道考砸了，但哪道题砸的、为什么、怎么改？不知道。

费曼那话怎么说的来着——你要是解释不了一个设计选择为什么在某些样本上灵、换一种就死，那你不是在优化，你是在扔飞镖。

2. 三段式：文件系统 + Agent + 评估

Meta-Harness 的架构简单到有点反直觉。三个组件，一个循环：

① 文件系统，当记忆使。 所有历史候选方案的源码、执行轨迹、分数、推理日志，全扔磁盘上，按目录排好。每个候选者一个子目录：c0000/（基线）、c0001/、c0002/......一路排下去。不是什么 fancy 的向量数据库，也不是摘要系统——就是文件夹+JSON。正因为它够原始，cat / grep / diff 就能翻，Agent 真能像人一样「翻看代码仓库」。

我读到这儿的时候想起 Unix 那句老话：文本流胜过二进制，简单胜过复杂。整个搜索历史摊在文件系统里，审计优化过程不需要任何特殊工具。干净。

② Agentic Proposer——让 agent 来提方案。 一个能读文件、能写代码、能做推理的 coding agent。每轮拿到一份 skill 描述（自然语言写的任务定义）、整个文件系统的访问权、外加一份明确的「什么不能碰」清单。它自己决定看哪些历史记录、比哪些候选者、提什么新 harness。有个细节我很喜欢：要求 proposer 先写 hypothesis，再动手改。逼它解释「为什么改」，不光是「改了什么」。

③ 评估循环。 proposer 写完代码后，一个独立的外部评估器跑验证和打分。验证挂→直接扔。验证过→打分→写入文件系统。以当前最优候选者为 parent，进下一轮。

评估完全跑在 proposer 外面——proposer 不能给自己打分。这个设计防的就是「自欺欺人」。Meta-Harness 的信条说白了就一句：AI 出方案，客观指标当裁判。

整体看，和「爬山算法+帕累托前沿选择」挺像的，但多了一个要命的特征：proposer 看得见全部历史，不是只盯上一轮的 feedback。路径依赖被干掉了——它能从 20 轮前的一个老思路里挖出灵感，不会被最近的几次失败带沟里去。

3. 文本分类：机器自己搜出了人类没想过的检索策略

第一个战场：在线文本分类。样本一个个来，模型预测标签，然后立刻看到正确答案（在线学习设定）。harness 的活儿是管一个不断膨胀的标注记忆库，每次预测时从里面捞相关样本喂给模型。

9 个 OOD 分类基准（SciCite、FiNER-139、Banking77、GoEmotions 等）上，Meta-Harness 自动搜出来的最优 harness——Label-Primed Query——比当前最强的手工系统 ACE 高出 7.7 个点，同时上下文 token 只用了 1/4。

好玩的是，搜出来的策略是多目标的。论文 Figure 10 给出 8 个帕累托最优候选，从「准确率-上下文成本」前沿上能看到各种折中。最省 token 的叫 Draft Verification——两轮短调用，第二轮用第一轮的反例做验证。准确率最高的则是 Label-Primed Query——先亮标签空间，再填覆盖样例和对比对。

Label-Primed Query 的工作方式拆开看：

1. 先甩一个标签 primer——列出所有合法输出标签，模型一眼看清完整答案空间
2. 再铺 coverage 块——每个类别挑一个跟当前查询最相关的样例
3. 最后塞 contrastive 块——从同一近邻里挖出标签不同但内容高度相似的配对

第 3 步那个 query-anchored pairing（查询锚定对比对）是搜索过程自己长出来的——把人丢进搜索空间手动试，大概率想不到把对比学习那套思想嵌进提示词构造里。这才是 Meta-Harness 真正的价值：它不替代人，它试人没空试的东西。

一个人类工程师都没设计过这个方案。

4. 数学推理：一套检索策略，吃遍五个模型

第二个实验：检索增强的数学推理。535K 道数学题的数据库，从 IMO 级 200 道题的结果来看，Meta-Harness 找到了一套四路由 BM25 检索 harness。

结构漂亮——

• 组合数学：BM25 取 20→去重到 8→按难度+词法相关性重排→留前 3 题。20→8→3，这几个数字不是人调的，是搜索自己收敛出来的。
• 几何：1 道固定 NuminaMath 参考题+2 道 BM25 近邻。不做难度重排——搜索发现在几何题上纯结构匹配更好使。
• 数论：BM25 取 12→词法分数+难度+「证明策略前置」加分→留 3 题。
• 默认：BM25 取 10，自适应决定保留几个。

最要命的测试是泛化性：这个 harness 只在搜索阶段用了 88 道题做评估，最后搬去 5 个完全不搭边的 held-out 模型上测，平均提了 4.7 个点。搜出来的不是对某个模型的死记硬背——真找到了更好的检索策略。

5. Agent 编码：一条环境快照，省掉 2-4 轮盲探

第三个实验跑在 TerminalBench-2 上——让 coding agent 在 shell 环境里解复杂任务。

Meta-Harness 从 Terminus-KIRA（当时最好的手工 harness）起手，发现了一个改动——简单到你会怀疑这也能算发现：环境启动快照。在 agent 循环开跑前，一条复合 shell 命令抓取环境快照（工作目录、已装语言、包管理器版本、可用内存），灌进初始 prompt。

就这点改动，省了 agent 通常要花的 2-4 轮试探。89 道任务中 7 道有实质提升，涨分的全是同一种任务：需要特定领域工具链的那种——生物信息库、渲染管线、象棋引擎。agent 不能假设这些预装，所以前几轮全耗在环境探测上。

proposer 在搜索日志里写的 hypothesis，原文引用值得看一眼：

"Injecting an environment snapshot before the first LLM turn will reduce wasted exploration episodes by 3–5 turns on dependency-heavy tasks."

不是拍脑袋——是 agent 翻完失败 case 的执行轨迹之后自己下的判断、自己验证的结论。

6. 文件系统，不是向量数据库

Meta-Harness 最让我琢磨的一个选择：坚持用普通文件系统存全部历史。不是向量数据库，不是记忆管理系统，就是文件夹。

这其实是个挺深的工程判断。大多数文本优化系统用摘要或模板压反馈——不是因为他们觉得长程信息没用，是当年技术条件不允许：API 上下文窗口不够大。但现在 context window 和 coding agent 的能力在狂涨，这个约束松了。

Meta-Harness 赌的是：你把完整文件系统丢给 coding agent，它自己会挑着读——什么时候该翻什么、什么时候该跳过、哪些要对比。这种「选择性访问」比「预压缩摘要」管用。压缩的时候丢掉的细碎信息，往往就是关键线索。

类比一下：给你一份问题册的全部答案和解题过程，让你自己去翻、去总结错因；对比一下，只给你一行「本次平均分 72，主要扣在第 3-5 题」。前者让你真懂，后者就够写篇表面报告。

7. 实操心得——来自论文 Appendix D

作者在附录 D 掏了六条在三个实验域都管用的经验。这些比正文还有嚼头：

① Skill 文本是排第一的杠杆。 proposer 的行为主要靠 skill 描述来引。skill 该约束的是「什么不能做、产出啥、优化啥」，不该约束「怎么诊断」。作者的体感：跑够轮数后，累积的历史记录对 proposer 的塑造力会超过 skill 本身。正式跑之前，先来 3-5 轮短演化专门调 skill——这事儿值。

② 基线别太强。 基线快饱和了，搜索就没空间了。拿基线搞不定的样本当搜索集，50-100 个就够。快准狠的评估，比大而无当的数据集有用得多。

③ 日志别搞花活。 JSON 存机器可读数据，目录结构和文件名保持一致，让 grep/regex 就能高效翻。简单工具够用就别上复杂的。

④ 写个迷你 CLI。 历史目录攒到几十条之后，光靠文件系统翻着费劲。一个短小的 CLI——列帕累托前沿、展示 top-k、比两个 run 的 diff——能帮 proposer 省掉大把导航 token。

⑤ 大评估之前先做轻校验。 proposer 写的 harness 先过一道简单测试——import + 实例化 + 小样本调用。格式错、跑不起来的方案直接拦住。失败代价趋近于零。

⑥ 评估永远在 proposer 外面跑。 裁判和运动员不能是同一个人。就这么简单。

8. 跟 DSPy 比呢？

好多人会拿 Meta-Harness 对标 DSPy。都号称「自动优化 prompt/程序」，看着像。但目标层级差了一档。

DSPy 给你声明式接口——定义「输入→输出」的模块图，然后自动编译优化 prompt。它动的东西是prompt 模板和 few-shot 样例，跑在 DSPy 的框架里头。

Meta-Harness 动的是任意可执行代码——包括 DSPy 程序本身。它不绑任何框架，proposer 想读写啥就读写啥。说白了：DSPy 是特定域编译器，在已知空间里高效；Meta-Harness 是通用搜索系统，在未知空间里探索。不是一个维度的东西。

9. 让我停下来的三个点

翻完这论文，有三个地方让我想了很久。

第一，「记忆」是优化系统的第一性。 不是更大的模型，不是更好的算法——是更多、更完整的上下文。AI 系统的瓶颈，常常不在算力，在信息流。这话越琢磨越对。

第二，简单方案有时候就是对的。 文件系统+JSON+自然语言 skill——这技术栈朴素到让人起疑。但作者赌的是 coding agent 的能力和 context window 的增长这两条线。赌赢了。

第三，自动化 harness 工程，可能比 finetune 重要。 对大多数团队来说，改模型权重是重武器——贵、吃数据、容易搞坏其他能力。改 harness 是日常。harness 优化做不好，LLM 的大规模落地就做不好。

当然，Meta-Harness 的边界也清楚：搜索成本不低（每轮评估要跑真实任务），依赖 coding agent 质量，目前只在三个域验过。但作为方向性工作，它扎到了一个真实存在、而且被严重低估的痛点。

论文信息

#CrushAI #FeynmanLearning #MetaHarness #HarnessEngineering #智柴系统实验室🎙️