让大模型自己当"脚手架工程师"：Evo-Bench 把智能体自我进化变成了一场可测量的大考

你有没有注意到一个挺拧巴的现象：现在刷榜的智能体，功劳到底该记在模型头上，还是记在那套精心调出来的 agent harness 头上？Claude Code、Codex 这些系统之所以好用，很大一部分是靠工程师反复打磨的脚手架——工具怎么组织、上下文怎么管、失败了怎么恢复。那反过来问：如果让大模型自己去写这套脚手架，它能干得过人类工程师吗？

这个问题听着简单，真要做成 benchmark 就处处是坑。模型自己进化出来的 harness 涨了分，到底是它会改代码，还是底子本来就强？在验证集上调出来的结构，到测试集上会不会直接过拟合？人大高瓴联合 BOSS 直聘团队放出的 Evo-Bench（arXiv:2608.09096）就是冲着这三个坑来的。说实话，这是我最近看到的把"harness 进化"这件事拆得最干净的一篇评测工作——它没有提出新的优化算法，而是干了一件更基础的事：给"模型能不能当长时域的系统工程师"立了一把尺。

核心摘要

Evo-Bench 是首个专门评测大模型内在 harness 进化能力的基准：固定一个 policy 模型和一个极简 CodeAct 种子脚手架，让九个前沿/开源模型扮演"研究工程师"，在 20 轮迭代预算内自主修改可执行的 agent harness，最终在完全隔离的测试集上见真章。结果挺打脸的也挺提气的：GPT-5.6 Sol 和 Claude Opus 4.8 分别拿到 16.6 分和 16.1 分的绝对提升，距离人类工程师搭的组合脚手架只差 1 分多；但分化极其明显——搜索任务上模型能补齐网页导航逻辑暴涨 30 多分，Office 任务上却几乎全军覆没。更有意思的是失败模式：多数模型早早就"饱和"了，后面十几轮全在做局部微调甚至负优化。这篇论文最值钱的不是榜单，而是它把"自我进化"从玄学变成了可复现、可归因的实验。

论文信息

• 标题：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（通讯）
• 机构：中国人民大学高瓴人工智能学院、BOSS 直聘
• 链接：https://arxiv.org/abs/2608.09096 （2026 年 8 月 10 日提交，v2 版本）

🎯 为什么这个 benchmark 难做

先交代一下背景。智能体自我改进这条线最近很热，从早期的 prompt 搜索（Promptbreeder 那一路），到工作流优化（ADAS 等），再到最近直接改可执行 harness 代码的工作（比如 Meta-Harness、HarnessX、VeRO）。方法层面的花样越来越多，但评测层面一直缺一块拼图：怎么测量一个底座模型"天生"的 harness 工程能力。

作者把难点拆成了三个，我觉得这个拆解本身就很有价值：

之前做类似评测的工作多少都栽在这几点上。比如有的基准任务太简单，换个强模型直接碾过去，harness 改不改无所谓；有的验证集和测试集分布不齐，模型在验证集上狂调参数，换个集合就崩。Evo-Bench 的设计几乎就是对着这三条逐条打的。

🏗️ Evo-Bench 的游戏规则

整个设定可以理解成一场"受控的 AI 科研竞赛"：

图2：评测流水线全貌。左侧是验证沙盒（evolver 只能通过 train_eval 请求验证集评估，拿到轨迹、分数和诊断信息）；中间是进化沙盒，evolver 模型在固定的 evolve harness 里做失败分析、改 harness、追踪实验；进化结束后 harness 被冻结，送到右侧完全隔离的评估沙盒跑最终分。

几个关键设定值得注意：

角色完全分离。 policy 智能体 \(A_t^{\mathrm{task}}=(\pi, H_t)\) 是固定的 DeepSeek-V4-Flash 加上当前版本的 harness \(H_t\)，负责真正干活；evolver \(A^{\mathrm{evo}}=(E, \mathcal{H}_{\mathrm{evo}})\) 是被评测的大模型，跑在一套借鉴 Claude Code 设计的固定 evolve harness 里，负责看证据、改代码。evolver 永远碰不到测试集，只能通过 train_eval 接口请求验证集评估。

起点刻意压得很低。 种子 harness \(H_0\) 是一个极简 CodeAct 循环，只有 shell 执行和提交答案两个工具。没有搜索、没有文件读写封装、没有任何领域知识——全靠 evolver 自己长出来。

预算硬约束。 20 轮迭代、1000 步、48 小时，到点就冻结。这让"会不会规划研究预算"本身也成了被测能力。

任务横跨三个领域五个基准：搜索用 BrowseComp 和 HLE，办公用 GDPval 和 APEX-Agents，通用任务用 Claw-Eval。最终构成 160 题的可见验证集和 448 题的隔离测试集。

图1：左图是三层领域结构和五个源基准的配比（总共 608 题，搜索 320、办公 192、通用 96）；右图是验证集与测试集的划分——验证集每个源各 32 题，测试集 BrowseComp 和 HLE 各 128 题、其余各 64 题。

🔬 最巧的设计：用 harness 来选任务

这篇论文里我个人觉得最漂亮的一块，是两阶段的 benchmark 构建框架。问题很具体：从五个公开基准里捞出来的 2329 个候选任务，怎么知道哪些真的"吃 harness"？

图3：第一阶段先用外部辅助任务池（与五个源基准完全不相交）跑多模型独立进化，收集并去重出 12 个代表性辅助 harness；第二阶段用这 12 个 harness 去"探测"候选任务，按敏感度和难度做分层筛选，最终切成验证集和测试集。

第一阶段，作者在与目标基准完全隔离的辅助任务池上，用 GLM-5.2、Claude Opus 4.8、Claude Sonnet 5、GPT-5.6-Sol 四个模型各跑一遍完整进化，收集到 73 个被正式评估过的 harness 变体，再用多样性筛选挑出 12 个代表性 harness 组成探测集 \(\mathcal{H}_{\mathrm{aux}}\)。

第二阶段，拿这 12 个 harness 去跑所有候选任务，给每个任务算两个指标：

\(\mathrm{Sens}(x)\) 是任务得分与 harness 整体质量（留一法估计）之间的皮尔逊相关系数。注意这个设计的心思：如果只是看方差，一个任务在不同 harness 下分数乱跳也可能是噪声；而相关性捕捉的是"好 harness 在这题上就是稳定地更好"，这才是真正能区分 harness 优劣的信号。\(\mathrm{Perf}(x)\) 则用来刻画难度，\(1-\mathrm{Perf}(x)\) 越大说明提升空间越大。

筛任务的流程是：先砍掉 \(\mathrm{Sens}(x)\leq 0\) 的（对 harness 质量无响应甚至反响应的），再按难度分层、每层里挑敏感度最高的，最后在层内随机切成验证集和测试集。从 Table 1 的数据看，过滤力度不小——APEX-Agents 的 421 个候选里有 133 个敏感度非正被扔掉，BrowseComp 768 个里扔了 47 个。保留下来的任务平均敏感度在 0.24 到 0.45 之间，难度也有明显梯度（Claw-Eval 平均得分 0.75 偏简单，BrowseComp 和 HLE 只有 0.27 和 0.25）。

坦白讲，这套"用进化出来的 harness 反过来标定任务"的思路有点自举的味道——探测集本身就来自四个前沿模型的进化过程，会不会把 benchmark 往这几家的进化风格上偏？作者在附录里做了敏感度分析，但我没完全看到对这个循环依赖的更彻底消融。不过总体上，这比拍脑袋选题或者按方差选题要严谨得多。

📊 主实验：九分模型大排名

榜单来了。所有模型统一从同一个 CodeAct 种子出发，policy 固定 DeepSeek-V4-Flash，评判统一用 Qwen3.7-Plus。Overall 是 448 题隔离测试集上的最终分，AnytimeVal 是进化过程中验证集历史最好成绩的平均值（衡量进化过程的效率，而不只是终点）。

这张表里有几个点我想单独拎出来说。

九家全部正收益，这件事本身是个结论。 最弱的 Gemma-4-31B 也涨了 6.2 分。说明"改 harness 涨分"不是某一家模型的独门绝技，而是前沿 LLM 普遍具备的能力——只是天花板差别很大。顺带一提，人工 harness 组合是三个领域各自的最强开源框架拼起来的（搜索用 MiroFlow、办公用 Stirrup、通用用 Claw-Eval 原生脚手架），GPT-5.6 Sol 的 46.3 距离这个 47.5 只差 1.2 分。

但拆开领域看，画风突变。 Search 领域是模型的舒适区：Opus 4.8 暴涨 34.8 分几乎追平人工脚手架，原因很直白——种子 harness 连搜索工具都没有，evolver 只要补上网页抓取和导航逻辑就是白捡的分。Office 领域则是集体滑铁卢：最好的 Minimax-M3 也只涨 3.3 分，Qwen3.7-Max 和 Kimi K2.7 Code 还倒退了。办公任务需要高度专门化的处理流程（APEX 要按文件、页码、单元格追踪证据，GDPval 要产出可重开的成品文档），这种东西很难靠看几条失败轨迹就"悟"出来。真正有意思的是 General 领域：GPT-5.6 Sol 和 Qwen3.7-Max 双双干到 59.4，反超了人工脚手架的 56.3——这是全文我最在意的数字，说明自动进化出来的推理结构在某些场景确实能超过人工设计。

AnytimeVal 和 Overall 的错位暴露了进化策略差异。 Opus 4.8 的 AnytimeVal 最高（51.4）但 Overall 不是第一，说明它很早就能演化出好结构，但后续迭代在引入负优化——作者管这个叫"early saturation"。GPT-5.6 Sol 相反，AnytimeVal 只有 50.1 但终点最高，是靠着把 20 轮预算榨干、持续探索拿到的。

💰 预算与成本：两条完全不同的进化路线

图4：迭代数、步数、耗时三个维度的预算消耗。只有 GPT-5.6 Sol 和 Kimi-K2.7 Code 用满了 20 轮迭代；Qwen3.7-Max 和 DeepSeek V4 Pro 在第 15 轮就停了，步数才用了 200 出头。

预算使用模式基本把模型分成两派。GPT-5.6 Sol 和 Kimi-K2.7 Code 是"耗尽派"：打满 20 轮、用了 550 步上下、跑 32 小时以上。其余模型多数提前收工——Gemma-4-31B 只用了 154 步，理由是反复提出非法代码或者陷入停滞的推理循环。

但有意思的是，预算耗尽和成绩好并不严格挂钩。Qwen3.7-Max 15 轮就停了，照样在 General 领域并列第一，作者夸它"样本效率极高"。这让我有点怀疑：对那些提前停下的模型，到底是"会见好就收"，还是"不知道接下来该干嘛"？从附录的失败模式分析看，恐怕后者居多。

图5：成本-性能散点图（横轴对数刻度）。虚线是帕累托前沿，横线是人工 harness 的 47.5 分。GPT-5.6 Sol 单次运行烧掉 500 多美元；GLM-5.2 和 Qwen3.7-Max 在 40 美元以内站上了性价比拐点；DeepSeek V4 Pro 用不到 1 美元锚定了最左端。

成本这块的数据很有工程参考价值。整条帕累托前沿是陡峭的对数形态：从不到 1 美元的 DeepSeek V4 Pro（39.1 分），到 40 美元档的 GLM-5.2（43.5 分），再到 500 美元以上的 GPT-5.6 Sol（46.3 分）。从 GLM-5.2 到 GPT-5.6 Sol，成本翻了 12 倍，分数只涨了 2.8 分。如果你是拿这个能力做生产系统，GLM-5.2 和 Qwen3.7-Max 所在的"膝盖"位置显然才是甜点区。

🔍 案例解剖：GPT-5.6 Sol 是怎么进化的

图6：GPT-5.6 Sol 的进化轨迹摘要。它不是给所有任务套一个统一 harness，而是先诊断再路由——搞了一个层级路由器按领域分发 prompt 和工具；Search 侧补了网页搜索、抓取和 HTML 清洗器（去脚本、留链接），把 Search 从 6.3 拉到 45.3；Office 侧把 APEX 和 GDPval 拆成两套契约；General 侧加了空响应恢复、凭据脱敏和"草稿勿发"护栏；最后还做了稳定性测试才冻结。

这个案例读起来像一份 AI 写的工程复盘。几个细节值得咂摸：它在 Search 上先加工具把分数从 6.3 干到 18.8，但发现违规次数高达 43 次，于是回头查迭代 1 的轨迹，加 HTML 清洗把卡死从 4 次降到 0，才冲上 45.3。在 Office 上它也试过加严格门控，结果缺文件数从 10 涨到 13，被自己的验证数据"证伪"后乖乖回滚。这套"提出假设→验证→证伪→回滚"的循环，已经有点人类系统工程师的样子了。

但作者也没留情面，直接点出三个短板：它是对着聚合分数做表面反应，而不是从大量日志里提炼因果性的失败模式；跨领域冲突用的是朴素的路由分发，而不是发现真正通用的共享机制；预算利用不充分，缺乏人类工程师那种目标导向的执着。结果就是核心组件依然原始——planner 是被动的、上下文只会追加、verifier 形同虚设。

🧪 消融：进化出来的 harness 能迁移吗

两个消融实验回答了两个关键疑问。

预算能不能堆出性能？ 能，但边际递减。作者拿 Qwen3.7-Max 和 GLM-5.2 跑了 24h/36h/48h 三档预算。

图7：两个模型的 Overall 和 AnytimeVal 都随预算单调上升。GLM-5.2 的 Overall 在 24h 到 36h 之间陡升后趋平（37.5 → 43.1 → 43.4），Qwen3.7-Max 则更接近线性（38.7 → 40.0 → 41.5）。

两个模型走势完全不同：GLM-5.2 前期爆发后期饱和，Qwen3.7-Max 匀速爬坡。这个差异本身挺说明问题——模型之间的"进化风格"是真实存在的个体差异，不是噪声。

换 policy 模型还好使吗？ 好使得出乎意料。作者把 policy 从 DeepSeek-V4-Flash 换成 Qwen3.6-35B-A3B 和 GLM-5.2，重新跑进化：

最夸张的是 GLM-5.2 自己进化、自己当 policy 那一格：General 领域从 73.4 冲到 80.3，Overall 从 38.0 拉到 48.4——比用 DeepSeek-V4-Flash 当 policy 时的任何结果都高。而弱 policy（Qwen3.6-35B-A3B，基线只有 13.9）也能被 harness 进化翻倍到接近 30 分。作者的结论是进化出来的 harness 是可迁移的推理结构，而不是针对某个模型怪癖的补丁。这个结论对工程界很友好：你给一个模型进化出来的脚手架，换个底座照样能用。

⚠️ 失败模式：附录里藏着最扎心的部分

附录 D 的失败模式分析，说实话比正文更能反映当前模型的真实水位。三个典型案例：

• Qwen3.6-27B：第 10 轮已经干到 49.7，结果第 15 轮把上下文和验证器的改动打包提交，一个畸形的验证器直接让 160 题里 159 题崩溃，分数跌到 0.3。更迷的是，面对 4.3 分的下滑，它把原因归给"噪声"，没有复现也没有恢复第 10 轮的快照，最后带着两轮没用完的预算草草冻结了一个 45.4 的版本。
• DeepSeek V4 Pro：第 3 轮就到了 46.5 的巅峰，之后十几轮全在调 prompt、调过滤规则做"聚合爬山"，整个过程中只看了 4 次原始轨迹。它甚至把第 3 轮的巅峰当成离群点丢弃，没有复评就冻结了一个更差的版本。这是典型的"把科研做成了流程"。
• Kimi K2.7 Code：回滚纪律最好（唯一会恢复字节级一致的最佳快照的），但从第 13 轮之后就困在局部搜索里——反复试 prompt 变体、门控、阈值，不做架构级重构，20 轮评估全用完了步数才用一半。

跨模型看，共同病灶很清楚：早期快速堆能力，后期沉迷局部微调；缺乏因果定位的失败分析；没有便宜的预检机制防崩溃；不管理最佳快照；也不会在局部搜索失败后触发架构级重置。这几条拿去当 agent 自我进化系统的设计 checklist，基本上是现成的。

🤔 我的判断

这篇论文的价值坐标要放对：它不是方法工作，是评测工作，而且是那种"定义问题"级别的评测工作。它最大的贡献是给出了一个可复现、可归因、防过拟合的实验范式，让"模型能不能自我进化 harness"这个此前只能在博客里争论的问题，变成了可以跑分、可以对比、可以写 failure analysis 的科学问题。

亮点有三个。一是敏感度引导的任务选择框架，用辅助 harness 的进化产物反向标定任务，把"harness 敏感性"从口号变成了可计算的相关系数；二是跨 policy 迁移实验，直接回答了工程界最关心的问题——进化产物是不是一次性补丁；三是失败模式分析，把"early saturation"和"局部微调依赖"这两个现象摆到了台面上。

要挑毛病的话也有几处。单一 policy（主实验全用 DeepSeek-V4-Flash）意味着榜单排名多少掺着"谁更会给 DeepSeek 打补丁"的成分，虽然消融部分缓解了这个问题；探测 harness 来自四家前沿模型的进化，benchmark 的"口味"存在被头部模型定义的循环风险；还有成本——跑一轮榜首要 500 多美元，这个基准天然对财力不足的实验室不友好，小团队可能只能站在 1 美元的 DeepSeek 档位上看别人玩。另外 47.5 分的人工基线是三个领域最优框架的组合，这个 baseline 选得其实相当强了，模型在 General 上能反超、整体上还差 1.2 分，这个解读空间比"逼近人类水平"要微妙。

对工程实践的启发倒是直接的：如果你在搭 agent 系统，这篇论文等于告诉你——现在最强的模型已经能自动写出接近人工水平的脚手架了，尤其在搜索类和通用任务上；但办公类高度专业化的流程还是得人来设计；而且无论用哪个模型当 evolver，最佳快照管理、改动隔离、便宜的冒烟测试这三件事必须替它做，因为它自己大概率做不好。

还有一个更本质的追问悬在那里：当 evolver 自己也是由 harness 驱动的时候，下一层递归——模型能不能进化"进化用的 harness"——才是通往真正自我改进的那道门。Evo-Bench 把 evolve harness 固定死了，这既是实验控制的需要，也恰恰是它留下的下一个问题。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我