Evo-Bench: Can Language Models Improve Agent Harness?
Lisheng Huang, Chen Yang, Hao Zhou, Huatong Song, Zongchao Chen, Ran Le, Yang Song, Wayne Xin Zhao, Tao Zhang
cs.CL
2026-08-10
固定 policy、让前沿模型迭代改写 agent 框架,顶配 GPT-5.6 比种子框架涨 16.6 分,General 任务反超人类手写,整体 46.3 仍落后人类的 47.5。
Agent 跑长程任务的能力不只来自底座模型,还来自框架(harness):它怎么组装上下文、调工具、规划、纠错。Claude Code、Codex 这些产品之间的差距,很大一部分是框架差距。既然模型越来越强,能不能让模型自己去改这个框架,不再依赖人类工程师手写?
此前的研究要么改 prompt、要么改 workflow,要么让模型自由进化却测不干净。问题在于任务分数同时受框架和底座模型影响,两者搅在一起,涨分到底是因为框架变好还是模型本身强,分不清;而且模型很容易在验证集上过拟合,验证集涨了、隐藏测试集没涨。Evo-Bench 要解决的就是这三件事:挑出对框架敏感的任务、让验证集和测试集对框架的响应一致、逼模型做多轮长程迭代。
核心设计是「固定 policy、换 evolver」。固定一个执行任务的 policy 模型(主实验用 DeepSeek-V4-Flash),给它一个最小框架 H0,一个只有 shell 执行和 finish 工具的 CodeAct 循环,没有规划、没有记忆、没有验证。被测的 evolver 模型扮演框架工程师,在一个固定的工作框架里反复改写这个 policy 框架:诊断失败、提出假设、改代码、在验证集上评估,循环最多 20 轮、48 小时、1000 步。终版框架冻在一个从没见过的测试集上打分。
关键在怎么构造任务集。论文用了一个 harness-guided 的两阶段框架。先用 4 个前沿模型在一批辅助任务上各自进化,收集 73 个框架变体,去重后选出 12 个有代表性的辅助框架。再拿这 12 个框架去跑 2329 个候选任务,算每个任务的「框架敏感度」,即任务得分和框架整体质量的 Pearson 相关。相关为零或负的任务直接扔掉,因为它们分不清框架好坏;剩下的按难度分层、按敏感度排序,切成同分布的验证集(160 题)和测试集(448 题)。
这样验证集上的优化才真的能预测测试集表现,而非过拟合。
9 个模型(7 前沿加 2 开源)的榜单:
| 模型 | 总分 | 较 CodeAct 种子 |
| GPT-5.6 Sol | 46.3 | +16.6 |
| Claude Opus 4.8 | 45.8 | +16.1 |
| GLM-5.2 | 43.5 | +13.8 |
| CodeAct(种子) | 29.7 | 基线 |
| 人类手写框架 | 47.5 | n/a |
顶配模型把一个近乎裸的框架拉升 16 分以上,接近人类工程师水平,但还没追平。分领域看极不均匀。Search 任务几乎全模型大涨(Claude +34.8,基本追平人类),因为模型很容易自己合成出 web 导航逻辑。Office 任务几乎全线趴窝,多数只有微涨甚至倒退,这类任务要的是非常专门的处理流程。General 任务上,GPT-5.6 Sol 和 Qwen3.7-Max 反而超过了人类手写框架(59.4 对 56.3),这是自动进化出的推理结构首次明确超过人工设计。
成本差异极大。GPT-5.6 Sol 单次跑超 500 美元;GLM-5.2 和 Qwen3.7-Max 在 40 美元以内就拿到接近的成绩;DeepSeek-V4-Pro 甚至不到 1 美元就合成出能用的框架改进。Pareto 前沿是一条陡峭的对数曲线,砸钱有回报但边际递减。
最值得关注的现象是 early saturation(早期饱和)。模型往往前几轮就找到不错的结构,之后开始引入有害改动。Claude Opus 4.8 和 GLM-5.2 的 Anytime Validation 分最高,正说明它们早期峰值高、后期反而往下掉。
这篇把「让模型自己改框架」从一个个案变成了一个可量化、可比较的能力维度。对从业者的直接含义:agent 框架的优化空间很大且能被模型自动挖掘,Search、General 这类任务尤其值得让模型去试;Office 这类强流程任务暂时还得靠人。成本曲线说明不必非用最贵的模型,GLM-5.2 这个档位性价比最高。
跨 policy 的迁移实验(换成 Qwen、GLM 当 policy)证明,进化出的框架是可迁移的推理结构,并非过拟合到某一个模型的怪癖。这一点对框架能不能复用是关键背书。
作者自己点得狠:evolver 做的是聚合爬山,不做因果诊断,它们看总分涨跌,不去深挖某个失败模式的根因;用朴素的领域路由解决跨域干扰,而非找真正鲁棒的共享机制;预算利用不充分,缺乏人类工程师那种目标导向的坚持。结果是改动都是局部的,核心组件依然原始:规划器被动、上下文只增不减、验证器形同虚设。
另有几处存疑。主实验只固定了 DeepSeek-V4-Flash 一个 policy,跨 policy 实验只换了两个、且只测了 Qwen3.7-Max 和 GLM-5.2 两个 evolver,样本偏薄。「人类手写框架」是个拼凑的复合体(MiroFlow 加 Stirrup 加 Claw-Eval),未必代表当前最强的单一人工框架,拿它当天花板略弱。9 个模型各只跑一次,论文写明 run one time,没有方差,小差距(如 46.3 对 45.8)未必稳。Office 任务几乎全线不动,到底是任务本身不适合框架优化,还是当前模型就是不会做这类流程,论文没拆开。