HarnessDev：AI 能自己写出驱动自己的 harness 吗？

同一个模型，只换掉外面的执行系统，分数差了 14 个百分点——agent 的能力到底藏在哪？

想象你花重金请来一位顶尖棋手，结果他只是换了副眼镜、换了张棋盘，胜率就掉了十几个百分点。听着荒谬，但 agent 世界每天都在发生。HarnessDev 论文开头就摆出一个锚点数字：同一个模型、同一批 Terminal-Bench 2.1 任务，套上 Terminus 2 时通过率 35.2%，换成 Codex CLI 变成 49.6%，模型权重一个字节都没动，分数差出 14.4 个百分点。

变的是模型外面那圈代码。论文把这圈代码称为 agent harness（执行骨架）：工具怎么暴露给模型、调用循环怎么跑、出错怎么重试、上下文怎么取舍、结果怎么验证。它不决定模型"想"什么，但决定模型"能做成什么"。HarnessDev 要检验的正是这件事本身：模型能否自造这个决定表现的 harness？检验值不值得做，取决于 harness 对表现的控制有多深。论文为此沿三层递进摆出证据：成本、失败指纹、从业现状。

第一层是成本。The Scaffold Effect 用 3 套开源 harness、2 个模型、50 个任务做了 300 次配对实验：同一个模型的通过率在不同 harness 下只差 0 到 8 个百分点，可"每解决一个任务消耗的 token"差了约 40 倍，最省的 Goose 每解一题花 2.8 万 token，最费的 OpenCode 要 115 万。Scaffold Effect 同一批任务、几乎相同的通过率，账单一头是零头、一头是天文数字。通过率还没分出高下，成本先被 harness 甩开两个数量级，harness 直接握着表现的经济账，这是检验的第一层理由。

图注：横轴是每个已解决任务消耗的 token（对数刻度），纵轴是通过率；三套 harness 各两个数据点。Goose 落在低成本前沿，OpenCode 被挤到最右端，通过率带却很窄（38% 到 50%），成本横跨约两个数量级。Scaffold Effect

第二层看行为本身。Goose 卡住就停，老老实实承认做不了；OpenHands-SDK 会反复较真验证，直到撞上轮数上限；OpenCode 则陷入空转的空循环，把时间耗在重读已经读过的文件上。这三种失败指纹在换模型之后原样复现。连"怎么死"都由 harness 决定，不是由模型决定，模型的成败和壳已经分不开了，这是检验的第二层理由。

第三层落到人身上。论文点出一个词：forward-deployed engineer（驻场工程师）。这个岗位的日常工作，就是把通用模型放进客户的数据、合规约束和工作流里，修修补补成一套能落地的执行系统。换句话说，造 harness 这门手艺一直是人在干，只是从没人把它当成"模型的一种能力"来评测。现存 benchmark 永远只报任务分数，从不问一句：这套骨架本身，造得好不好？模型自己，能不能把它造出来？HarnessDev 这门手艺存在已久，针对它的考卷却从未发过，这是最直接的一层理由。

三层证据一层比一层贴近结论：harness 决定花多少钱解一题，决定以什么方式失败，而造它的手艺又是人类一直占着的工种。判断凑齐了，HarnessDev 的答案随之落定：它把评测对象从"一次任务输出"换成"一套能跑、能冻结、能复用的执行系统"，然后分两个阶段来考：Creation，从零把骨架造出来；Evolution，拿执行反馈把自己的骨架改好。

图注：左半 Creation 里，creator 模型拿弱种子和少量开发用例搭出可运行的 harness；右半 Evolution 里，creator 用下游执行反馈反复迭代自己的骨架。两阶段评测的都是跨任务持久存在的执行系统，不是一次性任务输出。HarnessDev

把「能跑的骨架」本身当考题：Creation 与 Evolution 怎么设计才不算作弊？

把"写 harness"当考题，第一道坎就是防作弊。模型最擅长对着题目提示词硬编答案，而一套 harness 的价值恰恰在它没见过的那批任务上。所以 HarnessDev 的第一道防线是 hidden evaluation：开发时只见开发用例，评测时用从未见过的任务，creator 不许碰隐藏测试、答案和评分器。

上一张图里的左半 Creation，协议就是这样走的。每个 creator 拿到同一个弱种子，一份任务族规格说明，外加 1 到 3 个开发用例。它要在这基础上搭出一套完整 harness，冻结之后跑隐藏评测；每个（模型，基准）组合独立做 3 套，报告平均分。

弱种子是整套设计的命门，值得拆开看。它不是一个空仓库，而是一个"政策空白的可运行容器"：能解析输入输出、暴露原始工具、写结果和轨迹日志，但不带 agent 循环、不带任务分解策略、不带工具选择策略、不带状态管理，也不带任何结果验证。未修改时，它在所有下游基准上都是 0 分。

为什么要这么"裸"？为了 attribution。如果起点是一套已经被调到接近基准最优的种子，那之后每次改动的功劳都说不清：是模型改得好，还是种子本来就好？只有从政策空白出发，拿到的每一分才都能记到模型的账上。这有点像装修行业的毛坯房验收：交付时只有水电管线和承重墙，能通水通电但不能住人；装修公司不能改图纸，业主只看最终成果。对应关系是，毛坯房的可运行管线就是弱种子的输入输出解析和原始工具接口，装修就是模型在外围写的执行逻辑，hidden 基准就是验收。拿精装房当起点验收，谁都说不清功劳归谁。

图注：弱种子只保留"能跑"的三件套：输入输出解析、原始工具、结果与轨迹日志；agent 循环、任务分解、工具策略、状态、lifecycle、verifier 全部刻意排除，未修改时在所有基准上得 0 分。

Evolution 阶段把镜头转向自我改进：模型从自己造的 RQ1 harness 出发，拿着下游执行反馈迭代自己的壳。为了不让自我改进变成自我欺骗，协议规定候选版本必须把 100 个 SWE-Pro 任务和 89 个 Terminal-Bench 任务完整跑完，才算正式版本；诊断用的 probe 不计分。一套 630 实例的 held-out 集被彻底留到所有版本冻结之后才跑，全程不回喂给模型。

分数也要拆开报。Capability 指隐藏任务上的原生指标，Efficiency 指执行模型跑下游任务消耗的 token，构建阶段花的钱不算账。两个口径容易互相拆台，论文也不装它们能兼得。还有一个精巧的视角拆分：Self-Eval 里 creator 同时当 executor，测的是"模型加它自己的壳"这套组合；Unified-Eval 则把所有 harness 都交到一个固定执行器（Gemini 3.1 Pro）手里跑，把执行者差异剥掉，只比壳本身的可移植性。一个看组合实力，一个看壳的兼容性。HarnessDev

公平协议是这个赛道的共同焦虑。同期的 HarnessOpt-Bench 用 trusted execution 把测试集锁在沙箱外面，只有 optimizer 提名最终候选后才放行，思路殊途同归：考"造 harness"的评测，首先得让分数不可作弊。HarnessOpt-Bench

六个模型自己搭骨架：哪些领域逼近或超过所选工程参考，哪些领域一败涂地？

考题搭好了，谁来考？HarnessDev 请了六个前沿模型当 creator：Opus 4.8、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4 Pro、Qwen 3.7 Max、Seed 2.0 Pro，横跨四块领域：代码（SWE-Bench Pro 与 Terminal-Bench）、ML 实验（MLE-bench）、写作（EQ-Bench）、搜索研究（BrowseComp），五个下游基准合计 2,207 个独立实例。每个模型要为这些领域分别搭骨架。

先看整体，再看分域。Opus 4.8 的 Self-Eval 总分 67.8，人类工程化参考是 86.2，差距不小。但只要把分数拆到每个基准，故事立刻分裂。

图注：六组条形对应 Code、Terminal、MLE、EQ-Bench、Browse 与汇总，每组六条是六个 creator 的 Self-Eval 分数相对人类工程化参考的百分比，100% 虚线是所选成熟系统的参考线，条形旁标注原始分数。写作与 ML 实验的条形贴近甚至越过虚线，搜索与代码明显偏低。HarnessDev

图里那条 100% 虚线必须解释清楚：它代表论文选定的成熟系统（比如 Claude Code、OpenHands 这类人工工程产物），不是人类能力的天花板。条形越过虚线，只说明"超过了这份参考"，不等于"超过了人类"。

写作是第一个惊喜。Opus 的写作 harness 拿到 84.6，贴着参考线走。ML 实验更夸张，模型的骨架直接越过了参考线。搜索是重灾区：BrowseComp 上 Opus 的 harness 只有 52.4，参考是 92.2，差了将近 40 分。代码同样没到火候，表现最好的 Opus 在 SWE-Pro 上也只有 69.3，而参考线在八成上下，论文还特意标注这条参考取自外部公开结果，没有在本文重跑。

代码域为什么这么难？这要回到基准本身。HarnessDev 在代码域选用 SWE-Bench Pro，一个刻意做成"长视程"的软件工程基准：1,865 个问题、41 个仓库，补丁往往跨多文件、含数百行实质修改，专业工程师也要花数小时到数天。在这样拖长战线的任务上，骨架的好坏藏不住：工具暴露得全不全、上下文会不会撑爆、验证做得到不到位，全都直接写进分数里。SWE-Bench Pro

更扎眼的是能力与效率的撕裂。MLE-bench 上，GPT-5.5 的 harness 花 29.3M token 拿到 19.1 的奖牌率；DeepSeek V4 的 harness 花 208.4M token 才拿到 19.6。钱多花了七倍，成绩几乎没动。骨架好不好，不只是"能不能解"，还是"花多少钱解"。

最反直觉的发现出现在"换执行器"实验里。同一份 harness 换个执行模型，分数排序可以整个重排：Qwen 的 BrowseComp 壳从自己的执行器换到 Gemini，反而涨了 17.6 分，说明卡住它的不是壳，而是原来的执行器。Opus 反着来，SWE-Pro 的壳从 69.3 跌到 33.0，写作壳从 84.6 跌到 74.2。更夸张的是，Opus 的搜索壳换到 Gemini 下，重复查询率从 10.1% 飙到 88.2%，它去重、审查、收尾的规则，全都长在原来那个执行器的脾气上。HarnessDev

一句话总结：在这些迁移实验中，harness 的表现强烈依赖原执行器。可运行的骨架不等于可移植的骨架。既然壳和主人绑得这么紧，下一关的问题就顺理成章：让模型自己改自己的壳，能改好吗？

让 AI 反复改自己的骨架，73 个版本下来，真的越改越强吗？

Evolution 的实验像一场长跑马拉松。九条演化线以各自的 RQ1 harness 为起点，反复"跑任务、看反馈、改代码、重跑"，一共产出 73 个正式版本、64 次相邻版本切换。每一次正式评估都必须把反馈集完整跑一遍：100 个 SWE-Pro 加 89 个 Terminal-Bench 任务。

先看最乐观的一面。在 self runtime 下，五条演化线在反馈集和 held-out 集上全部拿到正收益；held-out-630 上平均 +3.11 分，其中 Opus 4.8 最大 +4.44。看起来"越改越强"似乎成立。

图注：2×2 网格。上排是 self runtime，下排是固定 Gemini 执行器；左列 SWE-Pro-100，右列 Terminal-Bench-89。每条折线从起点 harness 走到后续正式版本，星标是 creator 自己声明的版本。上排折线基本向上，下排多条折线掉头向下。HarnessDev

但把执行器固定成 Gemini 再跑一遍，结论立刻翻脸。四条演化线里只有 Opus 还保持正收益（+2.70），Qwen 掉了 1.11 分，DeepSeek 掉 2.38 分，GPT-5.5 暴跌 10.32 分。为某个执行器优化的壳，换一个执行器就变成伤害。这张图正是故事的视觉版：上排的轨迹几乎都在爬升，下排的折线开始往下走。

更戳破幻象的是稳定性统计。64 次版本切换里，反馈集和 held-out 分数同向移动（方向一致）的只有 34 次（53.1%），跟抛硬币差不多。九个 creator 自己"声明"的最终版本里，只有 2 个真的在 held-out 上最优。同一个版本重复跑，分数波动就有 ±4.75 分。feedback 分数不能当最终版选择依据，这句话论文说得非常克制。HarnessDev

为什么有的改壳有效、有的帮倒忙？一个正面案例能说明该怎么做。Opus 发现反馈集里 100 个任务有 99 个自报成功、却只有 48 个真正通过验收，定位到"提前收工"这个毛病后，给 harness 加了一道完成度闸门，成绩随之改善。这是教科书式的"读失败、改骨架、重新验证"。反例也有：Qwen 加了一个消息过滤器，把 Gemini 给合法工具结果组装的序列搞断，一顿操作反而添乱。

这种不稳定性不是 HarnessDev 独有。Rethinking the Evaluation of Harness Evolution 在统一预算下做了严格对照：harness evolution 的平均分（67.4）反而低于朴素的并行采样（72.3），质疑自动进化带来的增益很可能只是"多试了几次"的副产品，同基准自评还容易过拟合。HarnessDev 把反馈集和 held-out 严格分离、再补一个固定执行器的消融实验，正是对这类批评的协议级回应：增益是真的还是虚的，必须分开报。Rethinking

改壳这件事，同样会过拟合。那么问题就落到评测本身：如果你的 agent 分数时高时低，你分得清是模型变笨了，还是壳变差了吗？

一张考「写 harness」的考卷，为什么值得整个 agent 生态关注？

HarnessDev 的意义不在它的分数，而在它把"造 harness"从工程师的工单搬进了评测实验室。从这篇论文起，"模型能不能自己搭执行系统"成为一件可测量、可对比、甚至可以训练的事。

2026 年一整年，这条线上已经站满了人。Agentic Harness Engineering（AHE）最早把"改 harness"做成无人值守闭环的系统化方法之一：一个在 GPT-5.4 上进化出来的工作区，移植到五个没参与进化的模型上全部拿到正收益，+2.3 到 +10.1 个百分点。AHE

Self-Harness 用 propose-evaluate-accept 三阶段循环，让模型在固定权重下改自己的壳，9 个模型与基准的组合全部同时提升 held-in 和 held-out。Self-Harness

Evo-Bench 把进化成果摆上跨域评测台，最强进化者的综合分 46.3，逼近人工组合的 47.5。Evo-Bench

JIT-Agent 走得更远：它把 harness 形式化成 memory、planning、action、capability 四个模块，训练一个专门模型为每个任务即时合成骨架，18 对骨干模型与基准的组合全部拿到正收益。到这一步，harness 已经不是等待评测的对象，而是一个可以训练出来的能力维度。JIT-Agent

图注：给定一个任务，生成器按 memory、planning、action、capability 四个模块实例化一份任务专属 harness；右侧是深度研究、产品生成、自主研究三个任务实例，不同的任务结构长出不同的执行协议。JIT-Agent

这些工作共享同一个判断：agent 能力的另一半藏在模型外面的执行系统里，而这一半不是给定的，是可以被造出来、被改好、被学出来的。

那 HarnessDev 的边界在哪？论文自己划得很清楚。成本与能力经常不可兼得，19 倍的 token 差距就摆在那里；harness 的收益跨执行器几乎不迁移，Evolution 不稳定、容易过拟合；人类参考本身来自五花八门的系统组合，不是一个受控对照；开发环境在两阶段都是固定的，骨架能不能自己进化出更好的开发环境，仍是开放问题。论文还特别声明，harness 工程不替代参数训练，它度量的是权重之外的学习。此外，论文承诺随发布开源骨架、审计产物和基准固定版本，截至项目页上线时还没有可下载的入口，论文与项目页按现有公开材料也未披露 Evolution 的算力总账单，这两笔账值得后续盯着看。HarnessDev 项目页

回到开头的问题。agent 的表现由什么决定？模型决定它"想"什么，harness 决定它能"做成"什么，两者纠缠在一起，谁也离不开谁。从 HarnessDev 开始，报 agent 分数必须同时报"谁在执行"。下一次你的 agent 分数忽高忽低，先别急着怪模型，去查查壳。

想深入可以读原文：HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? — arXiv:2609.01437

参考文献

• HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?（主轴论文）— arXiv:2609.01437
• HarnessDev 官方研究视角页（Self-Developing Agents，ByteDance Seed + TokenWave）— self-developing-agents.github.io
• Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses — arXiv:2604.25850
• Evo-Bench: Can Language Models Improve Agent Harness? — arXiv:2608.09096
• HarnessOpt-Bench: Evaluating LLMs at Harness Optimization — arXiv:2608.06301
• Rethinking the Evaluation of Harness Evolution for Agents — arXiv:2607.12227
• Self-Harness: Harnesses That Improve Themselves — arXiv:2606.09498
• JIT-Agent: Scaling Harness Intelligence via Just-in-Time Harness Evolution — arXiv:2608.25593
• The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable — arXiv:2607.22585
• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? — arXiv:2509.16941