模型外面的那层运行框架Harness 的优化至关重要但与现有各种文本优化的方法不同Harness 是一个复杂的带状态的外层程序最近虽然涌现了一些“文本优化器”如 OPRO, TextGrad, GEPA 等试图利用 LLM 来迭代改进 Prompt 或代码但它们在 Harness 优化上面临严重的 水土不服主要原因在于反馈信息的过度压缩无记忆性或极短上下文许多现有方法在每次迭代时仅向优化器提供非常有限的上下文例如 100 到 30,000 个 Token且通常只包含标量分数或简短的 LLM 生成摘要丢失因果归因Causal Attribution能力Harness 的决策具有长程依赖性。比如第一步决定存储某个变量可能会导致第十步的推理失败。如果仅仅告诉优化器 任务失败了 或者给一个简短摘要优化器根本无法追踪到下游失败与早期 Harness 决策之间的因果关系。为了解决上述问题研究者提出了Meta-Harness。这是一个在代码空间中运行的外层循环系统Outer-loop system专门用于搜索和优化 LLM 应用的 Harness 代码方法该框架的思路如下先提出一个新的 harness → 跑评测 → 把这次的代码、分数、执行轨迹全部存下来 → 下一轮继续看这些历史再提出一个新的候选Meta-Harness 允许通过文件系统访问有选择的检查之前的代码和执行轨迹而不是从有损摘要和额外手工设计的搜索结构中进行优化每一轮优化不是只看 summary而是可以去翻全部历史Meta-Harness 的三大核心组件智能体提案者ProposerMeta-Harness 使用 Claude Code基于Opus-4.6模型作为一个具备编程能力的智能体来生成新的Harness。它不仅能生成文本还能调用开发者工具如终端命令直接修改和查阅代码完整的文件系统访问在每次迭代中对于每一个被评估过的历史候选Harness系统都会在文件系统中创建一个目录里面完整保存了源代码Source code、评估分数Evaluation scores以及详细的执行轨迹Execution traces包括 prompt、工具调用、模型输出等。 Proposer 不会把这些海量日志一次性塞进上下文窗口而是像人类程序员一样使用标准终端命令如 grep 和 cat在文件系统中选择性地检索、阅读和诊断。在最复杂的设定中单次评估可能产生高达 10,000,000 个 Token 的诊断信息比传统的文本优化器高出几个数量级代码空间搜索通过阅读执行轨迹Proposer 可以推断出 Harness失败的根本原因。然后它可以在代码的算法结构层面修改 Harness例如改变检索逻辑、重写提示词构建方式或修改状态更新机制并输出一个完整的Python程序而不是仅仅填补模板中的空缺作者统计过在最复杂的设置里proposer 每轮中位数会读82 个文件而且会参考20 多个过去候选实验研究者在三个高难度的数据集上进行了评估预测刑事指控的LawBench、预测疾病的 Symptom2Disease (S2D) 以及预测化学反应物前体的 USPTO-50k发现Meta-Harness 并非只发现了一种策略而是探索出了一个精度与上下文成本权衡的帕累托前沿。这里选择了两个代表性端点Draft Verification最低上下文边界点和Label-Primed Query最高准确度边界点帕累托前沿是一种解决多目标优化问题的方法在多目标优化中找到平衡的方案这个方案无法被改进找到在一个目标上的改进并且其它目标不劣于其他解的解Draft Verification草稿验证策略它首先检索5个最相似的历史样本让模型给出一个初始草稿标签。然后它根据这个草稿标签专门检索 5 个支持该标签的例子和 5 个反对该标签的例子要求模型重新思考并给出最终答案Label-Primed Query标签引导检索策略它构建了一个非常复杂且庞大的单次 Prompt。首先列出所有合法的输出标签然后为每个已知标签提取一个最具代表性的样本以提供全局覆盖最后通过 TF-IDF 相似度将高度相似但标签不同的样本配对展示从而在查询点附近建立极其敏锐的局部决策边界