Meta-Harness:模型驾驭的端到端优化
2026年3月来自斯坦福、韩国公司krafton和MIT的论文“Meta-Harness: End-to-End Optimization of Model Harnesses”。
大语言模型 (LLM) 系统的性能不仅取决于模型权重,还取决于其驾驭(harness):即决定存储、检索和呈现给模型信息的代码。然而,驾驭(harness)的设计仍然主要依赖人工,现有的文本优化器由于过度压缩反馈而难以适应这种环境:它们缺乏记忆性,仅基于标量分数,或将反馈限制为简短的模板或摘要。本文的 Meta-Harness,是一个外循环系统,用于搜索驾驭代码(harness code)中的 LLM 应用。它使用一个智能提议器,通过文件系统访问所有先前候选模型的源代码、分数和执行轨迹。在在线文本分类任务中,Meta-Harness 比最先进的上下文管理系统提高了 7.7 分,同时使用的上下文token数量减少了 4 倍。在检索增强的数学推理任务中,单个驾驭在 200 个 IMO 级别问题上,在五个预留模型中平均提高了 4.7 分的准确率。在智体编码方面,已发现的驾驭(harness)在 TerminalBench-2 上超越最佳的手工编码基线。这些结果共同表明,更丰富地获取先前经验可以实现自动化驾驭工程(harness engineering)。
围绕固定的大语言模型 (LLM) 更改驾驭(harness),在同一基准测试中可导致 6 倍的性能差距 [47]。驾驭(harness)——决定存储、检索和向模型展示哪些内容的代码——通常与模型本身同等重要。这种敏感性促使人们对驾驭工程越来越感兴趣,驾驭工程是指通过改进 LLM 周围的代码来提升系统整体性能的实践 [36; 21; 10; 9]。但尽管驾驭工程非常重要,它仍然主要依赖人工操作:实践者检查故障、调整启发式算法,并迭代少量设计方案。本文探讨这一过程本身是否可以自动化。
一个自然的切入点是近期关于文本优化的研究,因为驾驭工程也涉及利用先前尝试的反馈来迭代改进文本和代码工件 [38; 39; 35; 26; 1]。然而,这些方法与驾驭工程并不匹配,因为它们通常使用短期或高度压缩的反馈:某些条件仅针对当前候选方案 [31; 51; 53],其他方法主要依赖于标量分数[35; 12],还有一些方法将反馈限制在简短的模板或LLM生成的摘要中[1; 26]。这是一种务实的可扩展性选择,并非表明长程依赖关系无用。驾驭的作用范围很广:关于存储什么、何时检索或如何呈现的单个选择,可能会影响后续多个推理步骤的行为。压缩反馈通常会移除将下游故障追溯到早期工具决策所需的信息。在几个代表性文本优化器研究的任务中,每个优化步骤可用的上下文范围仅为100到30,000个tokens(表1所示),远低于工具搜索的诊断范围。更广泛地说,关于检索和记忆增强语言模型的研究表明,有用的上下文通常应该自适应地访问,而不是整体地打包到单个提示中[28; 48; 37; 56]。
本文利用 Meta-Harness 解决这一局限性。Meta-Harness 是一种基于智体的驾驭,它通过端到端搜索来优化驾驭(如图 2 所示)。其提出者是一个编码智体,即一个基于语言模型的系统,可以调用开发工具并修改代码。选择编码智体(而非原始语言模型)至关重要,因为经验量会迅速超出上下文限制,因此提出者必须决定检查哪些内容,并通过与代码库的直接交互来验证修改。其关键设计选择是通过文件系统公开完整的历史记录,从而能够选择性地诊断原始代码和执行轨迹,而不是从候选驾驭压缩的摘要中进行优化。对于每个先前的候选驾驭,文件系统都会存储源代码、评估分数和执行轨迹,提出者通过 grep 和 cat 等标准操作来检索这些信息,而不是将它们作为单个提示符导入。
在实践中,在要求最高的场景下,提出者每次迭代平均读取 82 个文件,每一步引用超过 20 个先前的候选驾驭(candidate harness)。在本文研究的设置中,一次评估可以产生多达 10,000,000 个诊断信息tokens,比先前文本优化设置中使用的最大反馈预算高出大约三个数量级(如上表 1)。
Meta-Harness 是用于搜索特定任务驾驭的外循环过程。Meta-Harness 的理念是,驾驭优化受益于允许提议者通过文件系统访问选择性地检查先前的代码和执行轨迹,而不是从有损的摘要或额外手工设计的搜索结构中进行优化。从宏观层面来说,它会反复地提出、评估和记录新的驾驭。
Meta-Harness 本身在广义上也是一个驾驭(因此得名),因为它决定了提议者模型在搜索期间可以看到哪些信息。本文使用“驾驭(harness)”来指代正在优化的特定任务程序。
目标。驾驭是一个有状态的程序,它封装一个语言模型,并决定了模型在每个步骤中看到的上下文。目标很简单:找到使底层模型在目标任务分布上性能最佳的驾驭。形式上,令 M 表示一个固定的语言模型,X 表示一个任务分布。对于驾驭 H 和任务实例 x ∼ X,执行一个展开轨迹 τ ∼ p_M(H, x)。该驾驭为模型 M 构建提示,模型做出响应,驾驭在每次交互后更新自身状态。任务特定的奖励函数 r(τ, x) 对轨迹进行评分。装置优化的目标是找到能够最大化预期最终奖励的驾驭(harness)。
当多个目标相关时(例如,准确性和上下文成本),根据帕累托支配原则评估候选,并报告由此产生的边界。在实践中,这种搜索传统上是由工程师和研究人员手动执行的,他们迭代地手动改进提示、上下文管理规则和工具使用逻辑。
Meta-Harness 搜索循环。Meta-Harness 使用一个可访问不断增长的文件系统 D 的编码智体提议器,该文件系统用作其反馈通道。这里,编码智体是一个基于语言模型的系统,可以调用开发人员工具并修改代码。与以往将改进逻辑外化到手工设计的搜索循环中系统不同,Meta-Harness 将诊断和提议委托给编码智体本身:它决定要检查哪些先前的工件、要解决哪些故障模式,以及是进行局部编辑还是进行更实质性的重写。同样地,提议器不是一个基于外部循环组装固定提示的原始下一个token模型;它是一个智体,负责检索信息、浏览先前的工件并编辑代码,这些都是搜索过程的一部分。每个被评估的测试驾驭(harness)都会贡献一个目录,其中包含其源代码、评分和执行轨迹(例如提示、工具调用、模型输出和状态更新)。文件系统通常远大于提议者的上下文窗口,因此提议者会通过 grep 和 cat 等终端工具进行查询,而不是将其作为单个提示接收。在每次迭代中,提议者首先检查先前的代码、评分和执行轨迹,然后推断可能的故障模式,最后生成新的测试驾驭。
Meta-Harness 维护一个群 H 和一个基于已评估测试驾驭的帕累托前沿,但不强制执行父代选择规则:提议者在提出新测试驾驭时可以自由地检查任何先前的测试驾驭及其执行轨迹。运行固定次数的迭代,并在帕累托前沿上执行最终的测试集评估。这种简洁性是刻意为之:通过将诊断和编辑决策交给提议者,而不是硬编码搜索启发式算法,Meta-Harness 可以随着编码智体能力的提升而自动改进。提议者无需查看测试集结果;其唯一的反馈来自搜索集(用于在搜索过程中评估候选驾驭并生成改进反馈信号的任务实例子集)以及在这些搜索运行期间记录的执行轨迹。
代码空间搜索的优势。驾驭优化发生在代码空间中,在代码空间中,对检索、记忆或提示构建逻辑的微小更改都可能影响后续多个步骤的行为,这使得局部搜索启发式算法与问题匹配度较低。通过检查执行轨迹,提议者通常可以推断出驾驭失败的原因以及哪些早期设计选择可能导致了失败,而不仅仅是知道它失败了。由此可见,提议者会广泛阅读先前的代码和日志,然后利用这些痕迹来识别混淆的编辑,隔离可能的因果变化,并在反复出现回归问题后转向更安全的修改。因此,提议者可以在算法结构层面修改驾驭,从更改检索、内存或提示构建逻辑到完全重写程序,而不是填充模板或应用预定义的变异算子。实际上,它通常从一个强大的先前驾驭开始,但这是一种涌现策略,而非硬编码规则。尽管搜索空间很大,但将驾驭表示为程序提供一种自然的正则化偏差:编码模型倾向于提出连贯的算法,而不是脆弱的、硬编码的解决方案,这使得搜索倾向于可重用的上下文管理程序。这个行动空间与前沿编码助手所训练的读-写-执行工作流程紧密相关。
实际应用。在实验中,每个测试驾驭都是一个单文件 Python 程序,用于修改特定任务的提示、检索、记忆和编排逻辑。在实验中,提议者 P 是 Claude Code [4],使用 Opus-4.6 版本。提议者遵循一个最小的域特定技能,该技能描述在哪里编写新的测试驾驭、如何检查之前的测试驾驭及其执行轨迹,以及它可以修改和不能修改哪些文件。基础模型 M 因领域而异,并且始终保持不变。在实验中,一次典型的运行会在 20 次迭代中评估大约 60 个测试驾驭。
如下所示Meta-Harness 的算法总结伪代码:
本文提到两个具有代表性的端点:Meta-Harness(草稿验证),即上下文最少的边界点;以及 Meta-Harness(标签引导查询),即正文中使用的最高精度边界点。
概述。这两个驾驭(harness)都会维护一个不断增长的已标注示例记忆,并在推理时基于该记忆构建提示。区别在于用于查询记忆的控制流程。Meta-Harness(草稿验证, Draft Verification)使用两次短调用,并显式地将驾驭的初始猜测与检索到的反例进行比较;而 Meta-Harness(标签-引导查询,Label-primed query)则花费更大的单次调用预算来明确标签空间和局部决策边界。图 5 和图 6 总结了这两个驾驭。

Meta-Harness(草稿验证)。对应的发现文件是 draft-verification.py。这个轻量级变体将预测过程简化为两次调用。它首先检索 5 个最相似的已标注示例,并进行草稿预测。然后,它会根据草稿标签重新查询同一记忆,检索出 5 个具有相同标签的验证样本和 5 个具有不同标签的挑战样本,并询问模型是否维持或修改其初始答案。关键发现是,第二次检索依赖于查询和草稿预测,因此该驾驭可以找到针对模型当前猜测的反例,而不仅仅是通用的邻近样本。如果积累的标记样本太少,程序会回退到标准的单次调用少样本提示。
第一阶段:草稿。检索 5 个最接近的标记样本并请求初始预测。
第二阶段:验证。根据草稿标签进行检索,然后在做出最终预测之前显示支持样本和挑战样本。
冷启动。如果可用的标记样本少于 5 个,则跳过两阶段过程,并使用标准的单次调用少样本提示。
为什么它成本低。两种调用都使用简短的检索上下文,因此即使调用两次模型,整体上下文成本也保持在前沿的低端附近。
Meta-Harness(标签-引导查询)。相应的发现文件是 label prime d query anchored.py。这个最强的变体使用一个由三个部分组成的大型调用。它首先是一个标签-引导部分,列出有效的输出标签;然后构建一个覆盖率部分,每个标签对应一个与查询相关的示例;最后添加查询锚定对比对,将具有不同标签的高度相似示例并排放置。覆盖率模块暴露完整的标签空间,而对比模块则强化当前查询周围的局部决策边界。在代码中,该驾驭通过对过去标记的样本进行 TF-IDF 检索以及一个查询锚定配对规则来实现这一点,该规则从同一局部邻域中选择对比示例。
标签-引导部分。在显示任何示例之前列出有效的输出标签,以便模型能够预先看到完整的答案空间。
覆盖率模块。对于每个已知标签,检索与查询最相关的已标注示例,并为每个类别包含一个代表性示例。
对比模块。构建标签不同的高度相似示例对,以便提示能够揭示当前查询周围的局部决策边界。
检索规则。使用 TF-IDF 相似度和基于查询的匹配选择,而不是与标签无关的最近邻匹配。
Meta-Harness 为数学推理发现一种检索驾驭(retrieval harness)。最终的驾驭是一个紧凑的四-路径 BM25 程序,其结构是通过搜索生成的,而非事后手动指定。以下所有设计选择——路由谓词、重排序词、去重阈值和每条路径的示例计数——均由外层循环经过 40 次迭代演化后确定。
概述。在推理阶段,该框架会将每个问题分配到以下四个路径之一:组合数学、几何、数论,或用于代数和其他问题的默认路径。这些逻辑门以轻量级词法谓词的形式实现,作用于问题陈述之上,包括关键词集和少量用于几何表示的正则表达式特征。该框架不会聚合不同路径的输出:一旦选定一条路径,就只有该路径会检索最终提示的示例。所有路径都使用 BM25 作为底层检索机制,检索对象为上述过滤后的语料库。BM25 索引使用数学感知token化器,将 LaTeX token(例如,\frac, ˆ{2})保留为原子单元。所选驾驭是两个成功搜索谱系的合并,由提出者在搜索过程中自主组合:一个谱系基于原始 BM25 贡献一条更强的几何路径,而另一个谱系基于去重和难度重排序贡献一条更强的组合数学路径。如图 8 给出最终程序的简洁流程图。
组合数学:获取 20 个 BM25 候选,去重至 8 个,按词法得分和难度重新排序,然后返回前 3 个。这是该算法在多样性和难题匹配之间进行权衡的主要途径。
几何学:返回 1 个 NuminaMath 难题参考以及 2 个原始 BM25 邻居。搜索始终优先选择原始结构匹配,而不是难度重新排序。
数论:获取 12 个 BM25 候选,并使用词法得分、难度以及对早期阐明解法的少量加分进行重新排序。这有利于证明策略明确的题目。
默认:获取 10 个 BM25 候选,按词法得分和难度重新排序,并根据检索得分最高的集中程度自适应地选择题目数量。
TerminalBench-2 评测驾驭(harness)基于 Terminus-KIRA [25] 构建,并继承其原生的工具调用机制(取代Terminus 2 中基于 ICL 的 JSON 解析方式)、30KB 的输出上限,以及多视角完成度检查清单。Meta-Harness 识别出的主要修改在于“环境引导”(environment bootstrapping):在智体(agent)循环开始之前,该驾驭会执行一条复合 Shell 命令,以收集沙盒环境的快照,并将其注入到初始提示词中。提案者提出的假设(直接逐字记录自搜索日志)如下:
该快照包含:当前工作目录、/app 目录的文件列表(若目录较大,则截断至前 20 条目)、可用的编程语言及其版本(Python、GCC、G++、Node、Java、Rust、Go)、已安装的包管理器(pip、apt-get),以及可用记忆。这一机制省去了智体通常需要花费 2 到 4 个交互回合(turns)来探索可用工具和文件的时间,从而使模型能够立即投入到实质性的工作中。该环境引导命令设有 15 秒的超时保护;若执行失败,系统将静默处理(即不报错),从而确保在非典型环境中不会导致智体崩溃。完整的实现代码在 Terminus-KIRA 的基础上仅增加约 80 行。如图 9 概述了该评测框架的整体结构结构。
逐任务分析:与 Terminus-KIRA 相比,所发现的评测驾驭在 89 项任务中有 7 项取得了性能提升,其中在“蛋白质组装”(protein-assembly)和“路径追踪”(path-tracing)任务上的提升尤为显著。这些取得提升的任务具有一个共同特征:它们均依赖于特定的域专用工具,且这些工具在环境中是否可用无法预先假定(例如生物信息学库、渲染管线、国际象棋引擎、密码学实用工具以及 CoreWars 模拟器等)。若缺乏环境引导机制,智能体通常会在前 2 到 4 个回合中耗费时间去探测环境;对于那些具有严格回合数限制的任务,或者那些因早期错误假设而引发连锁反应的任务而言,这些被浪费的回合往往正是决定任务成败的关键所在。这表明,当所处的环境状态并非显而易见,且任务要求智体根据环境中实际已安装的工具来调整其策略时,环境引导机制所能发挥的价值将达到最大化。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐


所有评论(0)