智能体的"轮子"，能不能让模型自己造？HarnessDev 给出了一个不太乐观但很诚实的答案
你有没有发现一个很拧巴的现象：同一个模型，套进不同的 agent 框架里，跑出来的分数能差出一大截。论文里给了一组让我愣了一下的数字——同样是 GPT-5，权重一模一样，放在 Terminus 2 这个执行框架里只能解决 35.2% 的 Terminal-Bench 2.1 任务，换到 Codex CLI 里就能解决 49.6%。
模型没变，变的只是外面那层"壳"，分数差了 14 个点。
这层壳有个正式名字，叫 agent harness——模型权重之外的所有执行基础设施：执行循环、工具调用策略、上下文管理、故障恢复、结果验证，全都算。现在的问题来了：既然 harness 这么重要，而它又只是代码和配置，那模型能不能自己把 harness 造出来，甚至自己把它越改越好？
这就是 HarnessDev 要回答的问题。
核心摘要
HarnessDev（arXiv:2609.01437）把 agent 评估的单位从"任务输出"换成了"可运行的基础设施"：给模型一个弱得几乎不能用的种子框架加 1-3 个开发样例，让它从零搭出一套完整的执行系统（Creation 阶段），再让它基于下游执行反馈迭代改进这套系统（Evolution 阶段）。六个顶尖模型在四个领域、五个 benchmark、2207 个下游实例上的结果挺扎心：最强的 Opus 4.8 总分 67.8，离人类工程参考的 86.2 还差一大截，尤其在代码和搜索研究类任务上差距明显；写作和机器学习实验倒是追平甚至反超了人类参考。Evolution 阶段能涨分，但增益在 held-out 任务上缩水且不稳定，而且严重依赖执行模型本身——换个 executor，很多"改进"就失效了。我的判断：这不是一篇秀肌肉的工作，而是一篇诚实地给"自进化 agent"泼冷水的 benchmark 论文，它最值钱的地方在于把"模型造基础设施"这件事变成了可测量、可审计的对象。
论文信息
- 标题：HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?
- 作者：Yuhao Wu, Jingyuan Zhang, Jiajun Shi, Xinping Lei, Qingshui Gu, Yuxuan Zhang, Zexuan Wang, Chen He, Chen Huang, Maojia Song, Zhiyuan Zeng, Shaowen Wang, Jinkai Liu, Yunfeng Shi, Jiaheng Liu, Shen Yan, Wenhao Huang, Ge Zhang, Wenxuan Zhang
- 提交日期：2026 年 9 月 1 日
- 链接：https://arxiv.org/abs/2609.01437
- 项目主页：https://self-developing-agents.github.io/
📖 为什么这件事值得单独做个 benchmark
先交代下背景。最近一年"自进化 agent"（self-evolving agents）这个词特别热。按照 A Taxonomy of Self-Evolving Agents 的分法，自进化大致分三层：改产出物的（Artifacts，比如 AI 编程工具反复修 bug）、改脚手架的（Harness，改 prompt、memory、工具策略）、改模型权重的（Model，比如 self-training、自对弈）。Harness 这一层被认为是最现实的突破口——改起来便宜、可逆、不用重新训练。翁荔在《Harness Engineering for Self-Improvement》里也判断，RSI 大概率先在 harness 层爆发，理由是几轮 harness 迭代就能把推理成本打下来不少，而且生产环境里部署最多的中间档模型恰恰是从 harness 改进中获益最大的那批。
工业界确实已经动起来了：MiniMax 开源 M2.7 时提到模型在内部 harness 里自主跑了一百多轮"分析失败→改代码→跑评测"的循环，把内部评估集性能提了三成；Karpathy 的 autoresearch 实验让 agent 整夜自己改训练配置。
但热闹归热闹，有个根本问题没人系统回答过：现有的 agent benchmark 全都是"给定 harness 测模型"，没有任何一个把 harness 本身当成被开发、被评估的产物。 模型写代码的能力我们测了很多，但"写一套自己以后要住在里面的房子"这个能力，性质完全不同——你改的不是别人的代码，是你自己用来观察世界、规划行动、从失败中恢复的那套基座。改错了，影响的是未来所有任务。
HarnessDev 就是冲着这个空白来的。
🏗️ 怎么测：两阶段设计
形式化地说，流程是这样的：创造者模型 \(L_C\) 在开发环境 \(D\) 里产出一个可运行的 harness \(H\)；\(H\) 被冻结之后，执行器模型 \(L_E\) 拿着它去跑下游任务 \(x\)，评估器 \(J\) 打分：
关键原则就一条：\(D\) 只用来造 \(H\)，\(L_E\) 只在 \(H\) 冻结后使用。 评估的对象是持久、可检查、可复用的基础设施，不是一次性输出。
Creation 阶段：从一个"弱种子"开始
创造者拿到的起点是一个精心设计过的弱种子 \(H_{seed}\)：它能解析任务配置、暴露几个被动工具、按规定格式写日志，但没有 agent loop、没有任务分解、没有上下文管理、没有验证器、没有重试逻辑，最多发一次连通性探测。未修改的种子在所有下游 benchmark 上得分是零——所以任何非零分数都必须来自创造者自己加进去的执行逻辑。
这个设计挺讲究的。给空仓库吧，测出来的全是搭命令行、写文件格式的杂活；给成熟框架吧，等于把被测的规划结构直接泄露了。弱种子正好卡在中间。
Evolution 阶段：带着预算去迭代
起点是创造者自己造出来的代码 harness \(H_0\)，反馈集是固定的 100 个 SWE-Pro 任务加全部 89 个 Terminal-Bench 任务。预算协议很严格：总共只有 10 次完整评估对的机会（每次要同时跑完 100 个 SWE-Pro 和 89 个 Terminal-Bench 才算数），两次正式评估之间最多用 2 个小探针（各 5 个任务）做诊断。
最狠的是 held-out 设置：每个正式版本事后还要在与反馈集不相交的 630 个 SWE-Pro 实例上再测一遍，而这些分数从不给创造者看。这就把"针对反馈集过拟合"和"真的变强了"分开了。说实话，这个设计是我觉得整篇论文最值钱的地方之一——太多自进化工作的"提升"经不起 held-out 检验。
四个领域、五个 benchmark
| 领域 | Benchmark | 任务数 | 主要指标 |
|---|---|---|---|
| 代码 | SWE-bench Pro public split（SWE-Pro） | 731 | 任务成功率 |
| 代码 | Terminal-Bench 2.1 | 89 | 任务成功率 |
| 数据分析 | MLE-bench | 75 | Medal 分数 |
| 写作 | EQ-Bench3 | 46 | Rubric 分数 |
| 研究检索 | BrowseComp | 1266 | 准确率 |
合计 2207 个独立下游实例。评估看两个轴：capability（冻结 harness 的任务成功率）和 efficiency（解题消耗的 executor token 数，创造者建 harness 花的 token 不算在内）。合规审计也做了——禁止硬编码实例级解法、禁止偷看隐藏测试，论文报告所有运行经审计无一违规。
🔬 主实验：六个模型造出来的 harness 差距有多大
六个创造者：Opus 4.8、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4 Pro、Qwen 3.7 Max、Seed 2.0 Pro。除 GPT-5.5 用 Codex 外，其余都在 Claude Code 里开发，全部开 high reasoning effort，每个组合跑 3 个副本取均值。
Self-Eval 结果（创造者即执行者，avg@3）：
| 创造者 | SWE-Pro | Term.-2.1 | MLE-bench | EQ-Bench3 | BrowseComp | 平均 |
|---|---|---|---|---|---|---|
| Opus 4.8 | 69.3 | 64.8 | 32.9 | 84.6 | 52.4 | 67.8 |
| Gemini 3.1 Pro | 43.6 | 68.8 | 32.4 | 74.8 | 35.2 | 55.6 |
| GPT-5.5 | 32.8 | 52.1 | 19.1 | 83.0 | 52.6 | 55.1 |
| DeepSeek V4 Pro | 28.9 | 35.6 | 19.6 | 75.4 | 40.9 | 45.2 |
| Qwen 3.7 Max | 33.5 | 41.3 | 3.1 | 68.7 | 32.3 | 44.0 |
| Seed 2.0 Pro | 10.8 | 6.0 | 5.3 | 71.1 | 3.2 | 22.8 |
| 人类 harness 参考 | 80.0 | 88.8 | 24.0 | 83.7 | 92.2 | 86.2 |
几个值得停一秒的观察。
第一，Opus 4.8 造 harness 的能力明显高一档。 67.8 对 55.6，领先第二名 12 个点。我之前在做类似工程时就有体感，这类"设计执行系统"的活特别吃模型的长程规划和对模糊意图的拆解能力，这个榜单算是给了数据佐证。
第二，领域间的差距模式很说明问题。 写作（84.6 对人类 83.7）追平了，机器学习实验（32.9 对人类参考的 24.0）反超了，但代码和搜索研究差得远——BrowseComp 最好的 52.6 对人类参考的 92.2，腰斩。为什么？写作任务的反馈循环短、单次输出就能评分；而搜索研究需要长程的信息搜寻、去重、判断何时停止，代码需要跨多轮协调仓库检查、编辑、验证——这些恰恰是 harness 工程里最难的部分。模型擅长造"短循环"的 harness，不擅长造"长循环"的。
第三，钱花得多不代表活干得好。 MLE-bench 上 token 消耗差了约 19 倍，但 GPT-5.5 花 29.3M token 拿 19.1 分，DeepSeek V4 Pro 花 208.4M token 才拿 19.6 分。执行成本和性能之间没有稳定关系。这个数据对那些"堆推理算力就能解决 agent 问题"的论调是个不错的反例。
第四，harness 本身确实是瓶颈。 数据分析任务里 77.8% 的失败归因于 harness 缺陷而不是执行器能力。这反过来证明了这篇论文的前提是对的：harness 值得被当成一等公民来研究。
🧬 Evolution：能涨分，但别高兴太早
Evolution 阶段共 9 条谱系、73 个官方版本、64 次相邻版本切换。结果一句话概括：反馈集上的增益是真的，但一到 held-out 就缩水，而且很不稳定。
| 创造者（self-runtime） | 反馈集增益 | Held-out-630 增益 |
|---|---|---|
| Opus 4.8 | +3.0 | +4.44 |
| GPT-5.5 | +5.9 | +3.81 |
| DeepSeek V4 Pro | +13.4 | +3.17 |
| Qwen 3.7 Max | +13.9 | +1.43 |
| Gemini 3.1 Pro | +8.8 | +2.70 |
注意 Qwen 和 DeepSeek 这两行：反馈集涨了 13-14 个点，held-out 只涨了 1.4-3.2 个点。这个剪刀差就是教科书级的过拟合信号。更扎心的数字是：64 次版本切换中，反馈分与 held-out 分同向变动的只有 34 次（53.1%）——基本上跟抛硬币差不多；9 个最终声明版本里只有 2 个是 held-out 最优。
还有个细节我很喜欢：同一 commit 重复跑的分数波动就有 ±4.75 分，而 64 次切换里只有 2 次的增益明确超出了噪声带。换句话说，Evolution 过程中大部分"进步"其实是在噪声里游泳。说实话，看到这里我第一反应是回头审视了一下我们自己内部跑的那些"自迭代提升 xx 个点"的实验——有多少经得起 ±4.75 的噪声带检验？这篇论文没点名谁，但这盆冷水泼得很有必要。
当然也有正面案例。Opus 发现 100 次运行里 99 次自报成功但实际只有 48 次通过，定位为"过早完成"问题并加了完成检查——这是真正的"从执行轨迹中诊断结构性瓶颈"。9 条谱系里 8 条完成了至少一个完整的"读结果→编辑→重评估→选版本"循环。但失败诊断是最弱的一环：专门的轨迹检查接口只被调用了 2 次，显式检查的失败案例只覆盖反馈任务的 0.5%-40.2%。
模型会改代码，但还不太会"看病"。
🔀 换个执行模型，改进就失效了
这是另一个让我皱眉的发现。Unified-Eval 把所有 harness 统一用 Gemini 3.1 Pro 执行，结果排名大洗牌：
- Qwen 的 harness 换到 Gemini 下 BrowseComp 涨 17.6 分、MLE-bench 涨 12.9 分——说明它原来的执行器才是瓶颈，harness 造得其实不差。
- Opus 正好相反：Self-Eval 里 69.3 的 SWE-Pro 跌到 33.0，写作从 84.6 跌到 74.2。它的搜索 harness 换执行器后重复查询率从 10.1% 飙到 88.2%——去重、审查、终止规则全是跟原模型"共适应"出来的，换个模型就崩。还有个 Opus 的代码 harness 硬编码了 120 步上限，在 Gemini 下直接瘫痪。
Evolution 层面更明显：固定 Gemini 执行器后，四条谱系里只有 Opus 在 held-out 上保住了 +2.70 的提升，Qwen 退 1.11，DeepSeek 退 2.38，GPT-5.5 直接退 10.32（final gap 高达 16.51）。
结论有点残酷：当前模型造出来的 harness 不是通用基础设施，而是"为自己量身定制"的共生体。 你以为模型在造工具，其实它在给自己织茧。这对"让 AI 给别的 AI 造基础设施"的愿景是个实质性的障碍。
📊 架构覆盖热力图：所有模型都忘了做"记忆"
图1：HarnessDev 将 harness 拆成六个功能模块（E/T/C/S/L/V），统计每个模型生成的 harness 在各模块上的实现证据密度。一眼就能看到的规律：S 列（状态与记忆）几乎全白——六个模型无一例外地在这个模块上交了白卷，而其他五列至少都有中等以上的覆盖。
这张图配合文字数据更有说服力：18 个代码 harness 全部实现了显式执行循环，验证模块 15/18 完整；但 11/18 虽然定义了 State 类，却只有 1 个暴露了状态保存接口、1 个实现了周期性 checkpoint——26,679 条任务轨迹里没有出现过任何一次 checkpoint 事件。验证也大多停留在语法层面：2,325 个执行的数据任务里有 441 个产生了退化提交，没有一个 harness 检测到。
死代码问题同样普遍：代码 harness 的 108 个组件实例中 18 个从未在真实运行中被触发（全是状态/记忆类）；写作 harness 的 587 个特性里 124 个确认是死代码。
还有一组反直觉的数据：六个模型的实现策略差异巨大，Opus 喜欢重写整个执行栈，Gemini 只做就地小改，但编辑规模完全不预测性能——Gemini 只加了 1006 行代码却拿了 Terminal-Bench 最高分 68.8，而加了 3000 多行的 GPT-5.5、Qwen、Seed 都在中下游。18 个代码工件净增 17,111 行，行数和分数基本无关。测试数量也是弱信号（与下游分数的 Spearman 相关只有 0.13-0.26，不显著），但"读取失败→定向修改→重新验证"的 revision 调用相关系数达 0.57（p≤0.0005）。
写得多不如改得准。 这个道理人类工程师懂，模型好像还不太懂。
🤔 我的判断
亮点在哪。 一是评估范式的转移足够彻底：把 harness 从"实验配置"升格为"被评估的产物"，配上冻结、审计、held-out 三重防作弊机制，这个 benchmark 本身的设计水平很高，弱种子、预算协议、630 实例的隐藏泛化集，处处能看出作者被"自进化论文里的水分"折磨过。二是结论诚实：没有包装成"LLM 已经能自己造 harness 了"，而是明确说"代码和搜索还差得远，Evolution 增益不稳定且跨模型迁移差"。三是有几个发现是真正的增量知识：共适应问题（harness 跟 executor 长在一起）、状态记忆的集体缺失、编辑规模与性能脱钩、±4.75 的噪声带——这些都是做 agent 工程的人该知道的硬事实。
问题在哪。 Evolution 每个 creator-runtime 单元只有一条轨迹，作者自己也承认无法做不确定性估计——以 ±4.75 的噪声带看，+1.43 到 +4.44 的 held-out 增益其实相当脆弱。人类参考线也不均衡（各 benchmark 配的是不同的人类系统和不同模型，有的还是未重跑的外部结果），86.2 这个总分参考意义有限。另外固定 Gemini 做 Unified-Eval 本身也引入了 Gemini 偏好的交互模式，排名洗牌部分反映的可能是"谁的 harness 更讨 Gemini 喜欢"而非纯粹的 harness 质量。
跟同期工作比。 这半年 harness 自进化方向其实挺拥挤的——有做失败驱动修复的（Terminal-Bench-2 上把 held-out 通过率从 40.5% 拉到 61.9%），有做 harness 端到端优化的（Meta-Harness），还有拆"harness-updating 能力"和"harness-benefit 能力"两条轴的（结论是从 32B 到旗舰模型，提改动建议的能力几乎一样平）。HarnessDev 的定位不是方法而是标尺：它不提供让 harness 变得更好的技术，它提供的是"以后谁再说自己的 agent 会自进化，先过这套 held-out 检验再说"的基准。从这个角度看，它和那些方法类工作是互补的，而且它给出的悲观基线（反馈分与 held-out 同向率 53.1%）应该会成为后续工作必须面对的参考点。
对工程的启发。 如果你在做 agent 产品，三条直接可搬的经验：一，给自迭代循环配 held-out 评估，反馈集上的增益打个三折再信；二，检查你的 harness 里状态持久化和 checkpoint 是不是真的被用起来了——模型生成的基础设施大概率缺这一块，人工补；三，换执行模型之前，先查 harness 里有没有硬编码的步数上限、跟特定模型共适应的停止规则——这类隐性耦合换模型时会集中爆炸。
📝 收尾
论文结尾有句话我很喜欢："如果模型权重是智能积累的一处所在，harness 则是另一处：显式、可检查、可测试、可复用，并能通过失败、反馈与真实工程压力持续改进。"
HarnessDev 的价值不在于证明了 LLM 已经能接管 harness 工程师的岗位——它证明的恰恰是还不能，差得还不近。但它把"不能"变成了可测量的东西：差多少、差在哪、哪种改进是真改进、哪种是噪声。在自进化 agent 这个概念被过度营销的当下，这样一把诚实的尺子，比又一个宣称"性能提升 30%"的系统更有长期价值。
还有一个更本质的问题论文留给了未来：演化后的 harness 能不能自己成为下一轮演化的开发环境？如果能，那才是真正的递归自我改进的起点。现在，我们才刚走到"让模型学会给自己造工具"的第一步——而且造出来的工具，只有它自己用得顺手。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我