HarnessOpt-Bench：AI如何自己优化AI？模型底座影响是脚手架的1.8倍
HarnessOpt-Bench: Evaluating LLMs at Harness Optimization
当业界谈论大语言模型（LLM）驱动的智能体（Agent）时，大家往往下意识将注意力集中在模型权重上。但在实际工程落地中，决定一个智能体表现上限的，不仅是模型本身的智能水平，更在于包裹在模型外层的脚手架（Harness）——包括系统提示词（Prompt）、工具定义、执行流控制、上下文与内存管理，以及各种重试容错代码。面对同一个底座模型，一套精心调优的 Harness 往往能爆发出截然不同的性能表现。
ArXiv URL：https://arxiv.org/abs/2608.06301v1
这就引出了一个极具吸引力却又充满工程挑战的问题：我们能否用一个高阶 AI 编程智能体作为“优化器”，去自主诊断、修改并持续提升另一个目标智能体的 Harness 代码？
由 Scale AI 团队主导的最新研究提出了 HarnessOpt-Bench，这是业内首个针对“端到端自动化 Harness 优化”建立的标准化评测基准。这项研究跳出了过去各家系统在自选题目、自定规则下的“自嗨式优化”，搭建了一套具备严格隔离防护与预算控制的可信评测协议。通过横跨 4 个代表性下游任务、涉及 5 大主流前沿模型的 111 次完整优化评测，该研究给出了一个颠覆不少人工程直觉的结论：在自动化优化 Harness 的过程中，优化器底层模型本身的能力差异，平均是其所采用编码脚手架差异的 1.8 倍；官方原生脚手架并不具备普适优势，而优化器之所以能拉开差距，关键在于能否大胆探索更多的系统杠杆，而非埋头硬啃冗长的执行日志。
从“写代码”到“修系统”：为什么 Harness 优化极其困难？
让 AI 优化 AI 的想法并不新鲜。此前在学术界，无论是利用演化算法迭代 Prompt 的 DSPy，还是通过文本梯度反向传播的 TextGrad，抑或是将模型自身作为变异算子的程序搜索，都已经有过初步探索。然而，现有的自动优化体系大多建立在假设极度理想化的沙盒中：要么只能调整提示词这一个狭窄维度，要么面对的是单步运行成本极低、结果确定性极强的单元测试。
传统的代码生成基准（如 SWE-bench 或 HumanEval）本质上是在做廉价且确定性的逻辑排错：写出一行补丁，运行测试套件，毫秒级内就能得到一个非黑即白的布尔值反馈。
但真实的 Harness 优化完全是另一套物理法则。它是一个典型的高成本、强随机性的黑盒程序优化问题：
-
反馈带有强随机性与延迟：修改了一段工具调用逻辑或上下文剪枝策略，目标智能体在面对复杂任务时是否变强，无法靠单一测试断言来验证，必须在多批次样本上跑完完整的交互轨迹（Rollout），才能得到具有统计意义的期望得分。
-
评估代价极其高昂：跑完一次全量验证，动辄消耗数百万甚至数千万 Token，耗时数十分钟。优化器不能肆无忌惮地暴力枚举或执行大规模遗传搜索，它必须在非常严苛的评估预算内，像一位资深系统架构师一样，依靠极少的样本反馈推断出瓶颈根因，并决定下一步往哪里改。
-
极易陷入过拟合泥潭：如果优化器直接看着测试集调整，甚至只是频繁观察验证集的具体得分，它极易写出针对当前样本的“作弊式”特异补丁，最终在未见过的真实场景下一溃千里。
此前许多宣称实现了“自我演化”或“元智能体优化”的研究，之所以难以令人信服，核心原因就在于评测协议严重混淆了优化器模型、优化器自身脚手架、目标任务特征以及预算限制。没有受控的评测边界，任何关于“AI 具备自主改进智能体能力”的断言，在方法论上都是站不住脚的。
HarnessOpt-Bench：给 AI 优化器戴上“防作弊镣铐”
为了将 Harness 优化真正变成一项可度量、可复现的严谨科学实验，HarnessOpt-Bench 确立了一套兼具控制力与现实工程约束的评测标准。
在形式化定义中，一个被优化的候选 Harness 被视作一个完整的可执行代码库 $H$。基准不再人为切分哪些是 Prompt、哪些是控制流或工具定义，优化器拥有在该代码库内自由修改、增删文件的完全权限。
为了确保评估的公正性，系统锁定了任务不变量 $\theta=(\mathcal{M}, E, V)$，即目标智能体可调用的底座模型集合 $\mathcal{M}$、交互运行环境 $E$、以及用于最终判分的自动验证器 $V$。优化器只能修改 Harness 代码本身，绝对无法篡改评估逻辑或环境规则。
更为核心的设计在于分级信息披露（Graded Disclosure）与严格的 held-out 评估边界：
-
开发集（Development Partition）：优化器在此运行候选版本时，能够看到详细的用例输入、单例执行结果以及全量的交互轨迹（Traces），以支撑深度的错误诊断。
-
验证集（Validation Partition）：优化器在此只能拿到一个聚合后的统计平均分，无法查看个案细节，仅用于辅助模型在多个候选版本间进行横向选择。
-
测试集（Held-out Test Partition）：在整个搜索优化过程中，优化器对测试集完全不可见。只有当优化器耗尽预算或主动宣布优化终结、正式提名一个最终候选者 $H^{+}$ 时，独立受信任的服务端才会在测试集上跑盲测。
最终衡量优化器能力的核心指标，不是绝对得分，而是测试集归一化增益（Normalized Gain） $g$：
\[g = \frac{\mathcal{E}_{\theta}(H^{+}) - \mathcal{E}_{\theta}(H_{0})}{1 - \mathcal{E}_{\theta}(H_{0})}\]其中 $H_{0}$ 是每个任务预设的初始种子代码。这个指标衡量的是优化器究竟吃掉了初始版本与理论满分之间多少比例的“剩余提升空间”。如果提名的最终版本改坏了代码、导致性能跌破初始水平，$g$ 就会直接变成负数。
为了防止大模型在搜索过程中“耍赖”，HarnessOpt-Bench 借鉴了 VeRO 等框架的思想，搭建了一套基于可信执行环境（Trusted Execution Environment）的评测网关（如图 1 所示）。在这个体系中，受信任的评估服务端与优化器运行的沙盒完全物理隔离。测试集数据、API 访问凭据均存放在网关之后；所有针对目标智能体发起的模型调用均受配额监控，严格限制开发集与验证集各自最多只能调用 100 次、遍历 4 次全量用例。通过将防作弊机制沉淀为底层基础设施的物理约束，基准杜绝了以往智能体评测中屡见不鲜的 Prompt 注入、篡改打分器或偷窥测试集的作弊手段。
初始种子与下游任务阵列
任何优化基准的有效性，都取决于其任务设置是否真实反映了技术瓶颈。HarnessOpt-Bench 选取的 4 个下游任务，刻意覆盖了长程推理、文档问答、复杂工具链与终端环境操作：
-
OfficeQA：针对企业复杂长文档的多跳事实问答，预设种子是一个约 130 行 Python 代码的极简 Agent，仅包含 3 个基础工具和一个简单的 24 轮交互循环，留下了极大的优化空间。
-
BrowseComp-Plus：涉及深层网络浏览与多源信息检索整合，极度考验搜索策略与上下文抗干扰能力。
-
Terminal-Bench：真实 Bash 终端操作与系统排错，需要智能体精准理解命令行报错并做出反馈。
-
GAIA：多模态、跨工具的高难度通用智能体基准，在此任务上，作者故意放置了一个完全不可运行的骨架代码（Non-functional stub），用来检验优化器能否从零排错并建立起一套合格的执行流。
在测试阵列中，评估团队选取了来自当前三大头部 AI 厂商的 5 款前沿模型作为优化器底座：claude-opus-5、claude-sonnet-5、gpt-5.6-sol、gpt-5.6-terra 以及 kimi-k3。为了解耦“模型本身能力”与“包装优化器的外部工程框架”，每款模型均接受双重测试：一律挂载在开源通用的共享编码脚手架 opencode 下运行；同时挂载至各家官方专门调优的原生脚手架（Claude 对应 claude-code，GPT 对应 codex，Kimi 对应 kimi-cli）下进行成对对比。
核心发现一：底座模型的代差，远比脚手架工具更具决定性
长期以来，开发者社群中存在一种声音：只要外层的 Prompt 编排得当、工具脚手架（Scaffold）设计得足够精妙，中等水平的模型也能逆袭顶级模型；甚至有人认为原生配套工具的调优才是 Agent 表现的核心。
HarnessOpt-Bench 的实验给这一观点泼了一盆冷水。
通过严格控制变量方差分析，研究团队发现：在保持下游任务和编码脚手架完全一致的前提下，仅仅更换优化器的底层大模型，带来的归一化增益变动平均达到 0.142；而如果保持任务和底层模型固定，仅仅在共享脚手架与原生定制脚手架之间切换，带来的增益变动平均仅有 0.079。
模型带来的性能方差，足足是外层工程脚手架的 1.8 倍。这清晰地表明：面对端到端 Harness 优化这种需要长时间反思、从模糊反馈中提取有效因果、并进行高复杂度代码重构的顶层任务时，大模型本体的深度推理能力才是真正的制高点，外层的辅助 Agent 框架根本无法弥合底座模型的认知代差。
更值得注意的是，官方原生脚手架并不存在天然优势。在全部 20 组模型-任务成对比较中，通用的共享脚手架 opencode 赢下了 11 场，官方原生脚手架仅赢下 9 场，双方几乎平分秋色。唯一的例外出现在高度依赖特定终端交互模式的 GAIA 任务上：两款 GPT 模型在搭配自家 codex 时展现出了显著优势，但对 Claude 系列与 Kimi 而言，原生工具相比通用开源框架并没有拉开显著差距。这说明，如果仅仅依赖官方工具评测模型在自动化研发场景中的实力，往往会引入强烈的系统偏差。
核心发现二：成功者的共同特质是“广泛试探”，而非“咬住日志不放”
借助可信沙盒留存的完整优化轨迹，研究者对 AI 优化器在搜索过程中的具体行为模式进行了微观剖析，结果揭示了几个极其耐人寻味的现象。
1. 探索杠杆的广度，与最终测试集收益高度正相关
作者在实验前将一个 Harness 的优化维度抽象为八大核心控制杠杆（Levers）：
-
提示词调优（Prompting）
-
上下文与记忆管理（Context Management）
-
最大单步上限与轮次控制（Step Cap）
-
错误重试与超时回退策略（Retry & Timeout Policy）
-
外部工具结构与参数规范（Tool Schema）
-
最终答案抽取与结构化解析（Answer Extraction）
-
检索与上下文召回逻辑（Retrieval Policy）
-
思考计算量预算（Reasoning Effort）
统计显示，优化器在搜索过程中触碰、尝试过的杠杆种类比例，与最终在盲测测试集上获得的归一化增益呈现强烈的正相关，在所有四个任务上的 Spearman 相关系数 $\rho$ 介于 $+0.34$ 到 $+0.88$ 之间。
这是整项研究中，唯一一个在所有任务上都稳定保持正向作用的过程指标。需要说明的是，这种“广度”指的是在优化过程中的试探性探索，并不要求所有改动都必须保留到最终代码中。那些表现最强劲的优化器，往往像一位经验丰富的高级工程师，在初期会大刀阔斧地改动工具 Schema、重新设计抽取模块、调整重试边界，进行大范围的系统性重构；而表现平庸的模型，往往只会局限在微调 Prompt 的遣词造句上，无法撼动系统的结构性瓶颈。
2. “死磕执行日志”不仅没用，反而往往意味着陷入困境
这或许是全篇论文中最反直觉的发现：优化器花在阅读单例错误日志（Trace Reading）上的动作比例，与最终的测试集增益呈现显著的负相关（相关系数在 $-0.31$ 到 $-0.64$ 之间）。
在实际运行中，极其详尽的单例 Trace 在 111 次优化运行中仅被主动请求了 16 次。进一步的轨迹复盘显示，当前前沿模型在面对庞杂、动辄上万字的多轮 Agent 交互原始日志时，往往缺乏极强的信息过滤能力。通读完整 Trace 不仅迅速吃空了上下文窗口，还极易让模型被某个具体用例的偶然错误带偏，导致其做出头痛医头、脚痛医脚的局部补丁。相反，高效的优化器更倾向于依赖分用例的聚合错误标签与结构化摘要（Summary），以此快速完成问题定位，将宝贵的推理资源留给宏观架构的设计与调整。
3. 验证集得分普遍具有“虚假繁荣”
数据显示，绝大多数优化器在搜索过程中观察到的历史最佳验证集得分，都显著高于最终在盲测测试集上的实际得分。由于智能体优化本身伴随着环境和模型采样的随机波动，优化器在数十次迭代中，极易将某一次偶然出现的验证高分误判为真正的系统级飞跃，并基于这个“高光假象”提名最终方案。这再次雄辩地证明，如果在评测自动优化系统时不保留严格隔离的 held-out 测试集，得到的任何指标都将充斥着严重的过拟合水分。
模型能力的代际爬升：从“改不动代码”到“吃透红利”
HarnessOpt-Bench 的另一个重要价值，在于它成功提供了一把能够敏感区分模型迭代进展的标尺。过去，当常规基准（如 GSM8k、MMLU）全面饱和后，工业界很难直观衡量新旧一代模型在系统工程综合推理上的真实差距。
以 OfficeQA 任务为例，研究人员回溯了两个模型家族连续多代产品的表现：
-
GPT 家族演进：随着版本迭代，其归一化增益从最初几乎毫无优化能力的 $+0.03$，一路线性单调爬升至最新版本的 $+0.49$。早期版本面对复杂的 Harness 甚至无法正确处理依赖环境和控制流闭环，而最新模型已经能够稳健地将初始脚手架推向一个高度可用的状态。
-
Claude Opus 家族演进：增益区间覆盖了 $+0.37$ 到 $+0.59$。尽管在中间代次存在一定的波动，但最新代次相比初期的净提升幅度依然大幅超越了评测基准的分辨率置信区间（$\pm 0.045$）。
在最强梯队的配置下，顶级模型已经能够吃掉 OfficeQA 任务中近三分之二的潜在优化空间，以及 BrowseComp-Plus 中一半的性能余量。但与此同时，面对 Terminal-Bench 这种需要与 Linux 底层内核交互的高抗阻环境，弱势模型的优化增益在统计学上依然与零无法区分。这说明当前的 Harness 自动优化绝非已解决的问题，模型之间的能力断层依然深不见底。
迈向“能够改进智能体的智能体”
HarnessOpt-Bench 确立的不仅仅是一个新的跑分排行榜，而是为大模型研究界定了一个全新的能力维度：模型自主诊断、重构并提升另一个智能体系统的元能力（Meta-Capability）。
这项研究给整个智能体研发社区带来了几点深刻的启示：
首先，在搭建 AI 研发助手（AI for Agent Engineering）时，不应过度迷信外部 Scaffold 的花哨设计。如果底座模型本身的推理视野不够广、无法从宏观层面权衡多种系统杠杆，再精巧的提示词工程和工作流包裹也是徒劳。
其次，自动优化工具必须建立对抗过拟合的机制。由于 Agent 执行的随机性，如何防止优化器被偶然的评测高分欺骗，如何设计更高信噪比的聚合反馈而非直接倾倒冗长 Trace，是下一代优化框架必须解决的核心课题。
正如论文在结语中所指出的：人工智能的下一个前沿，不仅仅是打造更强的 Agent，而是打造能够稳定、可靠地让其他 Agent 变得更强的模型。当代码脚手架的调优权被逐步移交给模型本身，一套具备防作弊能力、受控且贴近工业实战的度量衡，正是这场自我进化之旅不可或缺的安全底座。