调 Agent 的脚手架，模型自己行不行？HarnessOpt-Bench 给了一次正面测量
你有没有过这种体验：同一个模型，换一套 Agent 框架——提示词、工具定义、循环控制、记忆管理全换一遍——跑出来的效果判若两人。行业里管这套包裹模型的代码叫 harness（脚手架）。大家都承认 harness 很重要，也都在手工调，但一个更扎心的问题一直没人系统回答过：让 LLM 自己来调 harness，它到底行不行？
Scale AI 这篇 HarnessOpt-Bench（arXiv:2608.06301）就是冲着这个问题去的。看完我的感受是：这活儿模型确实能干，但干得很不均匀——最强的配置能吃下某任务三分之二的提升空间，最弱的在有些任务上跟没优化一样。而且这个能力跟模型的 coding 跑分并不是一回事。
核心摘要
HarnessOpt-Bench 把"用 AI 优化 AI 智能体的脚手架"变成一个可复现的 benchmark：优化器（一个 LLM 套一个 coding harness）拿到目标 Agent 的种子 harness、带分数的评估反馈和固定的评估预算，自己改代码、自己提名最终版本，最后在全程不可见的 held-out 测试集上算归一化增益。5 个前沿模型（claude-opus-5、claude-sonnet-5、gpt-5.6-sol、gpt-5.6-terra、kimi-k3）、4 个下游任务、111 次打分的运行跑下来，结论挺反直觉：换模型带来的差异（0.142）比换 coding harness（0.079）大 1.8 倍；各家"原生" harness 并没有稳定优势；而且有个很耐人寻味的发现——广撒网式地到处改跟收益正相关，埋头读失败 trace 反而跟收益负相关。这不是又一篇"我们的方法效果最好"的论文，而是一套测量协议，价值在于把一个一直被各家自说自话的能力变成了可以横向对比的数字。
论文信息
- 标题：HarnessOpt-Bench: Evaluating LLMs at Harness Optimization
- 作者：Varun Ursekar, Apaar Shanker, Yash Maurya, Shehab Yasser, Vijay S. Kalmath, Veronica Chatrath, Yuan (Emily) Xue
- 机构：Scale AI
- 链接：https://arxiv.org/abs/2608.06301 （2026 年 8 月 6 日提交）
🎯 为什么这件事值得一个 benchmark
先交代一下背景。这两年"自我改进"方向很热：DSPy 调提示词、GEPA 用反思反馈做进化、ShinkaEvolve 和 AlphaEvolve 把 LLM 当变异算子塞进进化框架、ADAS 和 AFlow 直接搜索 Agent 结构。但这里有个角色上的分野——ShinkaEvolve、GEPA 这类是把 LLM 当作大搜索流程里的一个零件，而 VeRO、MetaHarness 这类是让 coding agent 端到端地把 harness 当成代码库来改。
哪种角色更难？取决于一次可靠评估有多贵。改完代码跑个单测，便宜；但 harness 改动的效果，得让 Agent 在一堆 case 上真跑，结果是随机的，一次评估又贵又噪。在这种"评估昂贵且带噪"的 regime 里，靠堆候选数量做选择就不灵了，从不完整证据里推理本身成了核心能力。
问题来了：现在各家报 harness 优化的结果，用的目标 Agent、种子、预算、披露策略、打分协议全都不一样。你看到"我们的优化器提升了 X 个点"，根本没法回答到底是模型强、还是它借的 coding harness 强、还是协议占便宜。
这篇论文的答案是把三样东西钉死：目标模型/环境/验证器固定；最终评估全程 held out，防止过拟合到可见分数；加一个可信执行边界，强制执行预算、隔离 held-out 状态、把每个候选版本存档备查。
图1：整个协议的安全边界。优化器沙箱里只能写目标 Agent 的 harness 代码，能读评估结果和任务数据；评估服务器把 dev（可见 trace）、val（只给聚合分）、test（啥都不给）三个分区隔开；所有模型调用都过网关，按作用域执行 allow-list 和 token 预算。关键设计在于：这些限制是执行环境的属性，而不是"要求优化器自觉遵守的指令"——作弊在架构上就不成立。
🏗️ 任务定义：一个带预算约束的随机程序优化问题
形式化其实不复杂。候选 harness \(H\) 就是个可执行代码库，提示词、工具、记忆、控制流之间不设语义边界，随便改。任务固定不变量 \(\theta = (\mathcal{M}, E, V)\)：可用模型、每个 case 的环境、以及把轨迹映射到 \([0,1]\) 分数的验证器。优化器能改 \(H\)，不能碰 \(\theta\)。
打分用归一化增益，直接衡量"吃下了多少种子基线上方的提升空间"：
负值就是提名的候选比种子还差。预算这块设计得挺实在：每个分区 100 次评估调用、dev 和 val 各 4 次完整 case 遍历，外加目标模型 token 上限。优化器自己的推理只计量不设限——论文明说这是在估计"当优化器的推理不是稀缺资源时，能达到什么水平"。
种子 harness 故意写得 naive。比如 OfficeQA 的种子是个约 130 行、基于 OpenAI API 的小 Agent，三个工具、24 轮循环、一个泛泛的系统提示。GAIA 的种子更极端——一个跑不起来的 stub，基线实测为零，所以在 GAIA 上增益就是原始 held-out 分数，考的是"从零搭一个能用的 Agent"，跟其他三个任务考"改进一个能跑但平庸的 Agent"完全两种 regime。
套件四个任务的设计常量：
| 任务 | 目标模型 | 数据划分 dev/val/test | 种子基线 | 分辨率带宽 |
|---|---|---|---|---|
| OfficeQA | deepseek-v4-flash | 49/98/99 | 0.341 | ±0.045 |
| BrowseComp-Plus | deepseek-v4-flash | 33/66/66 | 0.462 | ±0.066 |
| Terminal-Bench | grok-build | 17/36/36 | 0.241 | ±0.054 |
| GAIA | gpt-5.4-mini | 33/66/66 | 0.000（stub） | ±0.035 |
"分辨率带宽"这个概念我喜欢：同一个候选打两次分会有噪声差异，把这个噪声中位数换算到增益尺度上就是带宽——小于带宽的差异不被当作差异。这等于公开承认了 Agent 评估的噪声量级，而不是假装小数点后两位都有意义。附录里还有个很能说明问题的对照：同样的 held-out 分区，直接把现成的开源 harness（opencode、goose、openhands-sdk、mini-swe-agent、terminus-2）换上去，分数普遍碾压种子（OfficeQA 种子 0.341，mini-swe-agent 直接 0.734）。这说明种子确实留足了 headroom，优化空间是真实存在的。
🧪 主实验：模型差异比 harness 差异大 1.8 倍
核心网格是 5 个优化器模型 × 2 种 coding harness——共享的 opencode（所有模型同用）加各家原生 harness（Claude 配 claude-code、GPT 配 codex、Kimi 配 kimi-cli），共 10 个配置，跨 4 个任务。另外 GAIA 上多跑了 goose 和 mini-swe-agent 两个 harness。
主结果表（归一化增益，每列加粗为该任务最佳）：
| 模型 | 优化器 harness | OfficeQA | BrowseComp-Plus | Terminal-Bench | GAIA |
|---|---|---|---|---|---|
| claude-opus-5 | claude-code | 0.59 | 0.41 | 0.18 | 0.42 |
| claude-opus-5 | opencode | 0.63 | 0.48 | 0.29 | 0.47 |
| claude-sonnet-5 | claude-code | 0.53 | 0.07 | 0.10 | 0.33 |
| claude-sonnet-5 | opencode | 0.51 | 0.15 | 0.15 | 0.25 |
| gpt-5.6-sol | codex | 0.49 | 0.03 | 0.12 | 0.49 |
| gpt-5.6-sol | opencode | 0.29 | 0.09 | 0.13 | 0.31 |
| gpt-5.6-terra | codex | 0.07 | −0.03 | 0.01 | 0.30 |
| gpt-5.6-terra | opencode | 0.14 | 0.02 | 0.04 | 0.17 |
| kimi-k3 | kimi-cli | 0.59 | 0.23 | 0.16 | 0.31 |
| kimi-k3 | opencode | 0.41 | 0.16 | 0.12 | 0.28 |
说实话我第一反应是去找"原生 harness 主场优势"，结果数据不太给面子：20 个模型-任务对上，共享 harness 赢 11 个、原生赢 9 个，零平局。基本对半开。
更值得看的量级对比。固定任务和 harness 换模型，增益平均移动 0.142；固定任务和模型换 harness，只移动 0.079。前者是后者的 1.8 倍，而且 harness 对比只是勉强超过分辨率带宽。你想想看，这说明什么：花大价钱给模型配"最合适"的 Agent 框架，不如直接换个更强的模型。
图2：左图是受控双 harness 设计下每一次运行的归一化增益散点（marker 形状区分 harness），右图是 LSS-λ 模型效应。opus-5 一骑绝尘（+0.228），中间三个挤在同一档，5.6-terra 垫底（−0.174）。
右图的 LSS-λ 是论文定义的模型综合分：把增益对任务和模型做加性分解 \(\bar{g}_{mt} = \mu + \tau_t + \lambda_m + \varepsilon_{mt}\)，取模型项 \(\lambda_m\)——"换这个优化器模型值多少，扣除任务难度之后"。只在共享 harness 的均衡网格上估计（GAIA 因零基线被排除），结果分三档：
| 模型 | LSS-λ（增益单位） | 档位 |
|---|---|---|
| claude-opus-5 | +0.228 | 1 |
| claude-sonnet-5 | +0.029 | 2 |
| kimi-k3 | −0.014 | 2 |
| gpt-5.6-sol | −0.069 | 2 |
| gpt-5.6-terra | −0.174 | 3 |
估计器自身的分辨率是 ±0.058，同档内的排名不可分辨。作者还跑了另外两种估计器（任务内标准化、组内平均秩），排序完全一致（pairwise rank concordance ≥ 1.00），所以这个排序不依赖加性假设。方法上挺严谨。
但我要泼点冷水：极端值分得开，中间挤成一团。最强配置吃下 OfficeQA 约三分之二、BrowseComp-Plus 约一半的 headroom，最弱的在 BrowseComp-Plus 和 Terminal-Bench 上跟零无法分辨。中间档三个模型的差距经常小于轮次间的波动——所以这个 benchmark 目前支持的是"分档"而不是"精确排名"。作者自己也承认了这点，用的是 tier 而不是 rank，态度诚实。
📈 能追踪模型代际进步吗？
一个 benchmark 如果连模型换代都分辨不出来，那就没什么用。作者用 OfficeQA 上两条发布序列做了检验。
图3：GPT 系（橙）从 5.1 到 5.6-sol 五代单调爬升，增益从 +0.03 涨到 +0.49，四步里有三步超过分辨率带宽；Claude Opus 系（蓝）从 4.5 到 5，范围 +0.37 到 +0.59，非单调（4.7 之后还回落了一次），但首尾跨度超过带宽。阴影区是 OfficeQA 的 ±0.045 带宽。
这个结果其实信息量很大。GPT 系早期版本在这个任务上几乎不会优化 harness（5.1 只有 +0.03），到 5.6-sol 涨到 +0.49——这种能力是随模型代际真实增长的，而不是一个平稳的常量。Opus 系起点就高（4.5 发布时就有 +0.37），但进步放缓且抖动。如果你信这个测量，那"harness 优化能力"可以作为追踪模型能力演进的一个新维度，跟 MMLU 那种 saturated 的榜单不一样，headroom 还很大。
🔬 最有趣的部分：优化器们到底是怎么搜的
主表之外的轨迹分析，才是我觉得这篇论文最值钱的地方。作者给搜索过程装了探针，挖出四个发现。
发现一：动的地方越多，收益越高。 作者在 OfficeQA 上预注册了八个 harness 杠杆：提示词、上下文管理、步数上限、重试与超时策略、工具 schema、答案抽取、检索策略、推理强度。搜索期间触碰过的杠杆比例跟增益在全部四个任务上都正相关，Spearman ρ 从 +0.34 到 +0.88。
图4：四个任务分面，横轴是搜索期间触碰的预注册杠杆比例，纵轴是归一化增益。OfficeQA 和 BrowseComp-Plus 上 ρ 都到了 +0.88，GAIA 最弱（+0.34）但方向一致。
等等，先别急着下"广撒网就是王道"的结论。作者自己拆台拆得很及时：有个配置碰了四分之三的杠杆、做了七处编辑，最后提交的是原封不动的种子。探索广度和总修改量本来就相关，数据分不开"广度"和"努力程度"。所以这是个相关性观察，不是因果结论。
发现二：读 trace 跟收益负相关。 这个真的反直觉。优化器花在读评估输出上的动作占比，跟增益的相关系数是 −0.31 到 −0.64。111 个运行单元里只有 7 个请求过详细 trace，总共 16 次。大家基本只看 per-case 的分数摘要。
我的第一反应是"这说明诊断不重要"，但作者的解释更谨慎：可能这些任务里 per-case 摘要已经足够定位失败，读完整 trace 的上下文成本不划算。也可能是另一种更丧的解释——当前的优化器根本不会有效利用 trace，读了也白读。论文没区分这两种情况，这块我觉得是留给后续工作的钩子。
发现三：卡脖子的是 case 遍历次数，不是评估调用数。 中位优化器只用了 8 次评估调用（额度的 4%），却用掉了 82% 的 case 配额；100 个单元里有 55 个把至少一个分区的 case 预算跑光了。设计预算的人得注意：调用次数看着是瓶颈，实际约束藏在 case-pass 里。
发现四：可见的验证分数普遍偏乐观。
图13：横轴是搜索中观察到的最佳验证分，纵轴是提交候选的 held-out 测试分，虚线是相等线。大部分点落在对角线下方——你搜索时看到的最好成绩，提交后基本都要打折。
这图对工程实践是个直接警告：只看 validation 分数选模型/选 harness，你大概率在高估。到底是选择导致的过拟合还是 val/test 分布失配，论文说这图分不出来，但结论方向是明确的——held-out 评估不可省。
🔧 GAIA 上的 harness 大乱斗
最后单独说说 GAIA，因为它是唯一一个 harness 变量超过两个水平的任务（opencode、goose、mini-swe-agent 加各自原生，四档）。
图5：(a) 每个模型在三个共享 harness 上的连线互相交叉——没有任何 harness 能跨模型保持排名。(b) 原生 harness 相对该模型最佳共享 harness 的差值：两个 GPT 模型在 codex 下好出 4-5 个分辨率带宽（+0.179、+0.131），sonnet-5 在 claude-code 下 +0.056，而 kimi-k3 和 opus-5 用原生反而是负的。
这个交叉图挺打脸的。如果只看共享 harness，你会得出"模型越强对 harness 越敏感"的假规律；把原生 harness 加进来，这个规律就碎了。原生优势的分布是集中的而不是普遍的——基本就是 GPT+codex 这一对在大口吃红利。合理的猜测是 codex 和 GPT 模型的协同是联合训练/联合调优的产物，但这种协同没有迁移到别家。对做 Agent 产品的人，这说明"用谁家模型就用谁家框架"这条经验法则并不可靠，得实测。
🤔 我的判断
这篇论文的真实定位：不是方法突破，是测量基础设施，而且是做得相当讲究的那种。可信执行边界、分辨率带宽、分层披露（dev 给 trace、val 只给聚合分、test 全程封锁）、候选版本存档——这些设计细节说明作者是真被"Agent benchmark 被刷"这件事搞怕了的（伦理部分还引用了 benchjack 那篇讲评估器劫持的工作）。
亮点我列三个：一是把 harness 优化从"各家自报自夸的 demo"变成了可横向对比的协议，这个领域正缺这个；二是 LSS-λ 加 tier 的分档报告方式，对 Agent 评估的噪声很诚实；三是轨迹分析挖出的几个反直觉发现（广度正相关、trace 阅读负相关、case-pass 才是真瓶颈），每一个都能直接指导实践。
问题也有。每个配置只跑两轮，作者自己说"两轮估计不了离散度"，所以 Table 2 里那些范围看看就好。目标模型每任务只钉了一个，种子复杂度没系统化变化，LSS-λ 的排序换个任务分布可能就动。还有个大实话：GPT 系、Opus 系、kimi-k3 同时出现在一个 benchmark 里本身就很微妙——Scale AI 作为数据/评估厂商做这件事，中立性会比纯学术机构更受审视，好在协议和种子都开源释放了。
对工程的启发倒是立竿见影：如果你在调自己的 Agent，别只盯着一个杠杆死磕（数据说广度重要），别迷信 trace 精读（先确认 per-case 摘要够不够用），预算设计盯 case-pass 而不是 API 调用次数，以及——选 harness 前先在 held-out 上测，validation 分数会骗你。
最后一句话总结这篇论文的野心，作者自己说得挺好："下一个前沿不只是更好的 Agent，而是能可靠地把 Agent 变得更好的模型。"这个 benchmark 就是给这句话准备的尺子。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我