HarnessDev 分析

论文HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?2026年9月来自字节跳动种子基金 (ByteDance Seed)、新加坡科技设计大学、佐治亚理工学院M-A-P和TokenWave.AI。HarnessDev 是一个 benchmark评测框架不是提升 agent 能力的算法。它要回答的问题是LLM 能不能自己搭出 agent harness再自己把它改好这里的 harness 指模型权重之外的执行基础设施包括执行循环、工具、上下文、状态、恢复和验证。论文给的动机例子是同样用 GPT-5Terminal-Bench 2.1 在 Terminus 2 里得分 35.2%换到 Codex CLI 里是 49.6%。差距完全来自 harness。1. 核心形式化把造系统的模型和用系统的模型拆开L_C, D --〉H (H, L_E, x) --〉 y --〉{J} --〉scoreL_Ccreator 在开发环境 D 里写出 harness H。D 是 Claude CodeGPT-5.5 例外用的是 Codex。H 冻结之后交给 L_Eexecutor 去做下游任务 x再由评估器 J 打分。评测对象从一次任务的答案变成了可以跨任务复用的可运行基础设施。这是全文最核心的设计。2. 两个阶段Creation (RQ1)Evolution (RQ2)起点统一的弱种子 H_seedcreator 自己在 RQ1 产出的代码 harness H_0信号任务规格、设计教程、1–3 个开发样例固定反馈集的完整评测结果SWE-Pro 100 题 Terminal-Bench 89 题预算—10 次完整的成对评测每两次之间最多 2 次 5 题探针产出冻结的 H一串冻结版本加上 creator 自己声明的最终版 H_dec弱种子Weak Seed的设计很关键它能跑、可审计但不带任何策略。具体来说它负责解析输入和模型配置暴露被动的底层原语文件、搜索、进程、LLM 网关、产物 I/O并按要求写出 result/trajectory/log。它不包含以下任何东西agent loop、任务分解、工具策略、上下文管理、持久状态、verifier、重试、停止规则。原样运行时它在所有基准上都是 0 分。所以任何非零分数都只能来自 creator 自己加的控制逻辑。这样做避开了两个极端给空仓库会把harness 设计能力和CLI/文件格式杂活混在一起给成熟 agent又等于把规划和验证结构直接送给了 creator。creator 需要实现的六个控制模块 E执行循环、T工具策略、C上下文、S状态/记忆、L生命周期/恢复、V验证。3. 评测协议Self-EvalL_E L_C衡量creator 加上它自己的 harness这个整体。Unified-EvalL_E 固定为 Gemini 3.1 Pro让不同 creator 造出的 harness 可以直接横向比较也能隔离出harness 和执行模型的兼容性这个因素。两个评估维度 能力下游原生指标以及效率executor 消耗的 tokencreator 开发时花的 token 不计入。防作弊 计分路径和 harness 隔离。harness 自报的成功不算分。SWE-Pro 只看工作目录里实际留下的 diffTerminal-Bench 只看环境的最终状态。所有轨迹都保留下来做事后审计。论文报告的审计结果是没有发现违规。Evolution 的泛化测试 每个正式版本都会额外在 630 道从未给 creator 看过的 SWE-Pro 题上评测以此区分适应了反馈集和真正泛化。覆盖范围 4 个领域代码、数据/MLE、写作、搜索研究5 个基准共 2,207 个实例6 个 creator 模型每组 avg3。4. 主要发现Creation最好的是 Opus 4.8Self-Eval 均分 67.8。人工参考系统是 86.2。写作EQ-Bench3已经接近人工水平。MLE-bench 上反超人工参考32.9 对 24.0。搜索BrowseComp差距最大52 对 92。代码方向也明显落后。代码量不预测性能 Gemini 只加了约 1,000 行却拿到 Terminal-Bench 最高的 68.8。状态/记忆是普遍短板 26,679 条轨迹里一次 checkpoint 都没有出现过。大量死代码 写作领域 587 个特性里有 124 个从未执行。自测次数和最终分数几乎不相关ρ≈0.13–0.26。读失败、做定向修改、再验证这类修订调用次数才相关ρ0.57。对执行模型的共适应co-adaptation Opus 的 SWE-Pro harness 换成 Gemini 执行后从 69.3 跌到 33.0原因是硬编码了 120 步上限。它的搜索 harness 换执行模型后重复查询率从 10% 涨到 88%。反过来Qwen 和 DeepSeek 的 harness 换上 Gemini 后反而变好说明它们原来的瓶颈在执行模型本身。EvolutionSelf-runtime 下反馈集上全部有提升3 到 14。但到 held-out 上提升缩小到 1.4 到 4.4。固定 Gemini 执行时只有 Opus 在 held-out 上提升。另外三条谱系都退步了GPT-5.5 退了 −10.3。一共 64 次版本切换其中只有 2 次的提升明确超出了噪声带。同一个 commit 重复跑波动大约 ±4.75 分。反馈分数和 held-out 分数同向变化的比例只有 53%接近抛硬币。9 个声明的最终版里只有 2 个恰好是 held-out 上最优的版本。诊断环节最薄弱专门的轨迹查看接口一共只被调用了 2 次。最好的正面案例Opus 发现 99/100 次运行自报成功实际只过了 48 次由此定位到过早宣布完成的问题并加了一个完成检查completion gate。5. 评价优点问题重要切入角度新。 它把harness 工程变成可以测量的对象对应现实中 forward-deployed engineer 这类岗位的工作。creator/executor 解耦加上 Self/Unified 双视角。 这让harness 好和模型强可以分开看共适应这一发现也是靠这个设计才得到的。弱种子设计干净。 0 分基线加上不给任何策略归因很清楚。反过拟合设计严谨。 每个版本都在 held-out 集上评测计分路径和 harness 隔离还有事后审计。机制层面的分析有价值。 死代码、组件是否真的被触发、噪声带这些比只报最终分数更有信息量。局限和疑点Evolution 的统计力很弱。 每个 creator×runtime 组合只有 1 条轨迹作者自己也承认没法估计不确定性。再加上 ±4.75 的噪声大部分 held-out 提升1 到 4其实落在噪声范围内。人工参考不是成对对照。 人工参考是外部系统和外部模型的组合带 * 的数字没有重跑。所以超过人工或落后人工只能看作粗略的距离。Evolution 只覆盖代码领域。 held-out 也只有 SWE-Pro结论能否推广到其他领域还不清楚。开发环境 D 固定为 Claude Code 或 Codex。 creator 的表现可能混入了它对 D 的熟悉程度。例如 Opus 和 Claude Code 是同一家的产品可能存在主场优势。没有和盲搜基线对比。 比如随机修改、或者在相同预算下做简单搜索。所以无法判断 Evolution 的提升来自有依据的诊断还是带噪声的局部搜索。论文把这一点列为了未来工作。Unified-Eval 只用 Gemini 一个执行模型。 而 Gemini 本身也是 creator 之一它的 harness 在 Unified-Eval 下天然没有迁移成本。6. 总结HarnessDev 证明了当前前沿模型能从零搭出可用的 harness部分领域已经接近或超过人工系统。但它们很难稳定地自我进化用反馈优化容易对执行模型和反馈集过拟合而且普遍缺少状态/记忆和语义层面的验证。对做 agent 系统的人来说最直接的启示有两点一是别在 harness 里硬编码只适配某个执行模型的预算或步数二是完成检查和读失败后定向修改再验证这类机制比堆代码量更有效。附录的补充分析一、附录 B实验配置里几个值得注意的点1. 开发环境并不统一。 GPT-5.5 用的是 Codex 0.144.3另外五个模型都用 Claude Code 2.1.177。解码参数也各不相同Qwen 的温度是 0.6Seed 的 top-p 是 0.70Gemini 和 Qwen 的最大输出约 65K其他约 128K。所以creator 能力这个变量里其实混入了开发环境和采样配置的差异。2. 人工参考基线比正文看起来更弱。 表 9 显示了它们的来源SWE-Pro 80.0Claude Fable 5 配公开的 coding agentTerminal-Bench 88.8 和 BrowseComp 92.2都是 GPT-5.6 Sol三个带 * 的数字全部取自 OpenAI 的 GPT-5.6 发布报告论文没有重跑MLE-bench 24.0MLEvolve 配 Gemini 3.1EQ-Bench3 83.7Kimi Writer 配 Opus 4.8这意味着人工 harness 和 creator 生成的 harness 之间的差距同时混着更强的执行模型Fable 5、GPT-5.6 Sol 都比 creator 新一代。尤其是搜索方向 52 对 92.2 的差距不能全算在 harness 头上。反过来MLE-bench 上反超人工对比对象只是 MLEvolve 配 Gemini 的 24.0这个基线本身不算强。3. 资源预算。MLE-bench每题 1 张 A800、10 小时、500 步上限RQ2 代码任务每题 500 步、7200 秒4. 成本差异很大图 9。 在 MLE-bench 上GPT-5.5 用 29.3M token 拿到 19.1DeepSeek 用 208.4M token 拿到 19.6。效果几乎一样成本差了 7 倍。论文特意没有把成本和效果合成一个指标。二、附录 Charness 接口与种子骨架六模块接口规范这是可接受 harness的抽象契约模块关键方法executionrun(task)→Result、step(state, obs)→Actiontoolsregister(toolspec)、call(name, **params)→Observationcontextbuild(task, history, state)→Prompt、compress(messages)statesave(checkpoint)、load(id)、resume()lifecyclebeforeAction→Action|Abort、afterAction、onFailure→Recovery、onTimeout→Gracefulevaluationevaluate(result, criteria)→Score、recordTrajectory(step)不过系统提示词里明确写了不要求按这六个文件名去实现只要求系统在运行时真的承担了这些职责。所以这个表只是分析框架不是硬性约束。正文图 5 统计机制是否真的被触发用的就是这套框架。种子骨架C.1harness/entry module # python -m harnessseed runner # 解析输入可选做一次仅总结的 LLM 探针audit contract # result.json · trajectory.jsonl · ​Registered Protected by Markmonitor · 日志llm gateway # 只负责连通性不带策略primitives/ # paths / files / search / process / artifact_io全部是被动工具种子只执行一次不行动的遍历然后以 statuspartial 结束。这里有个关键设计各领域共享审计契约但真正被计分的产物是领域特定的。代码领域要真实的仓库 diff数据领域要可评分的 submission写作要最终正文搜索要带证据的答案。只把 JSON 和日志写出来就等于没完成任务所以种子在所有基准上都是 0 分。三、附录 E两份系统提示词协议的真实形态RQ1 创建契约里值得关注的约定术语分层很清楚 generated agent generated harness runtime LLMcreation agent metaharnessClaude Code/Codex creator。这正好对应正文中 L_C、D、L_E 三个角色的拆分。调用接口要兼容三种 CLI 形式和一批参数别名-p/--prompt、--workdir/--work-dir/--workspace 等保证 harness 能被不同评测器调用。模型调用必须走 provider-neutral 的路径。 禁止硬编码模型名、URL、采样参数禁止使用 Anthropic 等厂商的 SDK并建议只发最小的标准 chat-completions 请求。这是 Unified-Eval 能把 Gemini 直接换进去的前提。职责划分原则 语义决策交给 runtime LLMharness 负责让这些决策可执行、可观测、可恢复、可验证、可计分。反装饰条款 禁止留 TODO、NotImplementedError、pass 占位禁止写从不被调用的模块禁止退化成一次性 LLM 调用。同时明说 LOC、机制数量这些遥测指标不计分用来防止 creator 为了看起来完整去刷结构。可正文第 4 节仍然统计出大量死代码说明这条约束只靠提示词约束不住。RQ2 进化契约几乎是一个完整的实验控制器设计工作区是一个 git 仓库HEAD 就是当前候选版本。 只能通过 rq2b-tool 和控制器交互submit-pair冻结一个 commit在两个基准上做完整评测消耗 1/10 的预算submit-probe固定 5 题探针每轮最多 2 次不能累积read-feedback / wait-feedback读事件流 events.jsonlfinal-readiness、budgetdeclare-final结束实验的唯一方式而且不能声明 H0控制器完全不替 creator 做决定 不做 accept/reject不选最优版本不回滚不做失败归因不总结反馈。创作者也没有用户通道在文本里请求确认不会产生任何效果。所以 RQ2 测的是完全自主的工程决策能力。反馈分三层语义提示词里写得很明确score唯一的正确性信号adapter_status 等运行诊断即使是 success 也可能 0 分行为产物是否改了文件、patch 是否非空非空 patch 也可能完全是错的正文里 Opus 发现99 次自报成功实际只过了 48 次正好是读懂了第 1 层和第 2 层的差别。一些工程细节 评测提交后不能取消同一 commit 重复提交会去重12 小时没有动作会触发 idle 通知两次不回应就进入只能 declare 的模式评测账本 evals/ 是只读的篡改会被检测并回滚。建议工作法不强制、不计分先诊断再改在文件里维护外部台账因为对话会被压缩声明最终版之前对照台账而不是靠记忆先在本地验证再花预算可以参考成熟 harness 的模式planner/executor 分离、完成前的验证门、按失败类型驱动重试、有界探索、外部状态文件。另外还提供了 capability_notes.md 能力清单以及一个辅助 LLM 端点用来写轨迹分析脚本。这对解读结果很重要 提示词已经明确建议读 trajectory、维护台账但正文统计显示专门的轨迹接口只被调用了 2 次人工检查过的样例只覆盖了反馈任务的 0.5% 到 40%。也就是说不是模型不知道该诊断而是知道了也没去做。这比不会诊断更能说明当前模型在长程自主工程上的执行纪律不足。四、附录 F案例轨迹案例 1RQ1 代码GPT-5.5最终结果是从种子到成品改了 12 个路径1251/−4 行核心集中在单个 1,245 行的 agent.py。特点是单一控制面加上从轨迹倒推修 bug按时间顺序先读完构建契约、三种 CLI 形式、种子源码确认只有 harness/ 会被打包所以 agent loop 必须自包含。用 JSON-action 工具循环替换掉种子的一次性 runner。本地冒烟测试发现产物登记有 bug文件写出来了但没记进 changed_files。修好后再验证。从 SWE 诊断跑里依次发现三个问题模型一个回合里输出多个 JSON 动作解析器只认一个。修法是用 raw_decode 抽取多个对象合成一个 batch。shellTrue 默认调用 /bin/shsource 之类的命令失败。修法是改用 /bin/bash。模型输出 Codex 风格的 *** Begin Patch 格式。修法是加一个专用解析器再依次回退到 git apply 和 patch。5. 对重复动作做安全去重只去重读、搜索这类只读动作写入、patch、finish 永远不去重。最终记录是契约冒烟测试 1SWE 0Terminal 1。有一点做得很严谨模型多次区分了这个分数验证的是启动时的快照不包含后来热改的代码。启示 这些 bug 都是执行模型的输出格式偏离 harness 预期导致的。GPT-5.5 的 harness 实际上在适配自己这个执行模型的输出习惯。这从机制上解释了正文的共适应现象。案例 2RQ1 代码Opus 4.8特点是先划清模块边界再几乎一次性重写agent.py 负责执行和生命周期tools.py 和 schemas.py 定义结构化工具taskspec.py 和 prompts.py 负责任务分类和上下文runner.py 负责 diff、验证和产物一开始就写死了预算和诚实终止规则 max_steps120、6600 秒、150K token 的软上下文上限压缩上下文时保留最近 3 条观测如果连续多轮不调用工具或者仓库 diff 为空就降级为 partial不谎报成功。 这里正好对上正文的一个发现 正文说 Opus 的 SWE-Pro harness 换 Gemini 执行后从 69.3 跌到 33.0原因就是这里硬编码的 max_steps120。Opus 的执行模型效率高120 步够用Gemini 需要更多步就被截断了。这个上限是 creator 按自己的步数习惯设定的评测的步数上限其实是 500。RQ2 案例GPT-5.5 和 Opus这两个案例对应正文表 7 的总结Opus 主要做完成门、自审、进程恢复就是那个99 自报 vs 48 实过之后加的完成检查。GPT-5.5 主要做探针、分支回滚、最终状态审查。附录里还记录了版本之间的差值例如相对 T6SWE −6Terminal −4.49可以直接看到进化过程中的回退。五、总结人工差距要打更大的折扣。 参考系统用的是更新一代的执行模型比如 GPT-5.6 Sol 和 Fable 5三个关键数字都来自厂商发布报告。所以论文给出的差距里有相当一部分是模型差距不全是 harness 差距。共适应已经有了机制层面的证据。 案例显示 creator 会按自己的输出格式、步数习惯、工具协议来写 harness。比如 GPT 写的多 JSON 解析和 Codex patch 解析Opus 写死的 120 步。所以 Unified-Eval 的退化不是偶然而是在自己身上调试这种开发方式的必然结果。一个可行的改进是在开发阶段就混入不同的执行模型做测试。RQ2 的协议设计本身就是一个贡献。 成对预算、固定探针、只追加的事件流、只读台账、控制器不做任何决策这套设计可以直接复用来做 harness 自动优化的研究比单纯的榜单分数更有参考价值。提示词已经给了足够的方法论指导模型却没有照做。 所以瓶颈在执行纪律和长程自主性不在知识。这也意味着如果把诊断→台账→验证做成强制流程而不是建议可能会显著改变 RQ2 的结论。论文没有做这个消融实验。