Paper Reading
Agent systems · benchmark · technical report

HarnessDevCan LLMs Create and Evolve Their Own Agent Harness?

论文把评测对象从“一次任务的答案”移到“能够反复运行的执行基础设施”：让 LLM 从一个几乎没有策略的 seed 构建 harness，再让它依据下游反馈继续修改自己的 harness。

arXiv:2609.01437 · v1 提交：2026-09-01 arXiv 分类：cs.SE / cs.CL 19 位作者 · ByteDance Seed / SUTD / Georgia Tech / M-A-P / TokenWave.AI
arXiv record · 原始 PDF · 官方项目页
Paper Verified

先给结论

HarnessDev 的核心发现不是“LLM 已经能稳定地自我改进”，而是：模型可以从弱 seed 构建出能工作的 harness，也能根据可见反馈做出局部有用的修改；但这些修改在隐藏任务上不稳定，并且强烈依赖执行 harness 的 runtime model。

部分可以

Creation

六个 creator 都能把零分、无策略的 runnable seed 变成可执行系统；但 code 与 search/research 距离成熟人工系统仍大。

局部可以

Evolution

在可见的 100 个 SWE-Pro 与 89 个 Terminal-Bench 反馈上常能升分；跨到 630 个隐藏 SWE-Pro 任务后，收益明显收缩。

尚不稳定

Transfer

同一 harness 换一个 executor 可能升分，也可能崩溃；“能被另一个模型运行”不等于“能力可以迁移”。

一句 reviewer 版总结 论文成功建立了一个把 harness 当作一等可交付物的 benchmark，并用冻结版本、隐藏评测、跨 executor 与 token cost 拆开了多个混淆因素；但 Evolution 仍是单 lineage 的描述性实验，不能据此宣称 robust recursive self-improvement。

本文页面只把论文真正测量到的内容写成事实；有关 procedural material、context optimizer 或更强 evaluator 的内容会明确标为 Research Extension。

论文身份核准

标题、作者与研究定位

字段核准信息证据边界
准确标题HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?标题末尾有问号；用户原文中的 “Evolve” 不是标题拼写错误，准确标题如此。
作者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 ZhangarXiv record 列出 19 位作者；论文另标出 Wu、Zhang、Shi 为 core contributors。
机构ByteDance Seed；Singapore University of Technology and Design；Georgia Institute of Technology；M-A-P；TokenWave.AIPDF 首页给出 1–5 组机构；页面不擅自推断每位作者的逐人对应关系。
时间与版本arXiv v1，2026-09-01 15:45:33 UTC 提交；PDF 首页标注 2026-09-02这是动态的最新版本身份；当前 record 未显示 conference / journal 接收信息。
Venue 状态arXiv technical report，分类 cs.SE（Software Engineering）与 cs.CL（Computation and Language）不能写成已发表会议论文；论文正文与项目页均按 benchmark/report 介绍。

这篇论文位于三篇 Self-Developing Agents 工作的 “SYSTEM” 层：Aspire 追问 vague goal 能否变成可训练的 target，S3Gym 追问 experience 能否被 self-test / self-judge / self-improve，HarnessDev 则追问这些能力是否能落到一个可运行、可维护、可复用的 system harness。三者的关系是项目页的研究框架，不是 HarnessDev 单独完成的联合实验。

Research Motivation

为什么要把 harness 单独拿出来评测？

传统 benchmark 隐藏了最昂贵的一层工程

在 SWE-bench、GAIA、WebArena、τ-bench、AgentBench 等常见设置里，task、environment、scorer 与执行 scaffold 已经准备好，研究者只需在固定 harness 中比较模型。这样做适合控制变量，却把现实部署中决定“能否工作”的一整层排除在外：执行 loop、工具编排、context 管理、状态保存、失败恢复、生命周期与验证。

论文借用 forward-deployed engineer（FDE）的类比：部署到真实客户环境后，工程师要把模糊意图转成成功标准，补出可靠的反馈信号，并不断维护运行系统。HarnessDev 只聚焦其中第三层——模型能否建设并维护承载未来任务的 execution scaffold。

普通代码编辑

模型修改一个外部程序；目标行为通常已给定，局部测试可以验证修改是否有效。

失败多半是“这次程序没有按规格工作”。

自改 harness

模型修改的是未来每一次观察、计划、工具调用、恢复与停止的执行底座；一次错误修改可能改变所有后续任务。

难点是从 trace 识别结构瓶颈，并让修复成为可复用的 capability gain。

真正的 research gap

已有研究分别探索了 agent benchmark、自动 agent design、prompt/workflow/topology search、self-improving agent 与 harness optimization，但缺少一个统一协议同时测量：

  • 从弱起点创造一个真正 runnable、persistent 的 harness；
  • 让 creator 与 executor 分离，区分“模型适合自己”与“软件可迁移”；
  • 在反馈集上逐版本演化，同时对隐藏任务做 post-freeze generalization；
  • 审计机制是否真的在运行，而不是仅出现在代码或类名里；
  • 同时报告 task capability 与 executor token cost。
Our Interpretation 论文的隐含 hypothesis 是：如果 harness 真的是“系统智能”的一个承载体，那么在模型权重固定时，改变 harness 应该改变下游能力；如果模型拥有 harness engineering 能力，那么这种改变应当能跨任务、跨版本、最好还能跨 executor 保持。实验只验证了第一句的部分可行性，以及第二句的困难。
Problem Formulation

被评测的不是答案，而是冻结后的系统

令 \(L_C\) 为 creator LLM，\(D\) 为它工作的 development environment，\(H\) 为最终的 runnable harness，\(L_E\) 为只在冻结之后运行下游任务的 executor LLM，\(x\) 为下游 task，\(y\) 为 authoritative task artifact，\(J\) 为固定 evaluator。论文的核心计算图是：

\[(L_C,D)\rightarrow H,\qquad (H,L_E,x)\rightarrow y \xrightarrow{J} \mathrm{score}.\]

这里有一个决定性 freeze boundary：\(D\) 参与构建 \(H\)，\(L_E\) 只在 \(H\) 冻结之后执行任务。否则，评测分数可能混入 development environment 的能力，无法回答“harness 本身是否有效”。

Harness 的六元表示

\[H=\langle E,T,C,S,L,V\rangle.\]
符号职责下游可见行为
\(E\) · execution执行 loop、planning、调度、停止条件决定何时向 LLM 请求下一步、何时继续、何时结束。
\(T\) · tools工具接口、选择、输入输出约束、错误处理把模型输出转成读写文件、shell、search 或其它受限 action。
\(C\) · contexttask、代码、日志、history、约束的组织与压缩决定模型下一轮究竟看到哪些证据。
\(S\) · state目标、假设、进度、尝试、失败与 artifact 状态支持 resume、checkpoint 与跨操作的可追踪性。
\(L\) · lifecycleaction 前后 hook、timeout、failure recovery、finalization让运行可以恢复、优雅终止，并避免“假成功”。
\(V\) · verificationtests、checks、artifact validation、trajectory 记录将“模型说完成了”与真实可评分结果分开。

六元表示是研究抽象，不要求最终代码必须有六个同名文件；关键是这些责任必须在可执行路径上真正发生。\(H\) 不是模型权重，也不是一次 prompt，而是把模型输出变成可靠 action 的 model-external software system。

Creation 与 Evolution 的变量

记号含义它在实验中如何出现
\(H_{\mathrm{seed}}\)统一弱 seed有 CLI、配置、被动 primitive 与审计输出，但没有 task-solving policy。
\(H_0\)Evolution 的起始 harness由同一 creator 在 RQ1 Creation 中产出并冻结。
\(H_t\)第 \(t\) 个冻结候选每一个完整 feedback pair 评估后才进入 official trajectory。
\(H_{\mathrm{dec}}\)creator 声明的 final version只允许声明非 \(H_0\)、且完成两个 benchmark full evaluation 的 commit。
\(P_t\)Evolution 的 pair score等权平均 SWE-Pro-100 与 Terminal-Bench-89 的百分比分数。
\[\bar P_t=\frac{1}{2}\left(P^{\mathrm{SWE100}}_t+P^{\mathrm{Term89}}_t\right).\]

这条公式只用于 Evolution 的可见 feedback pair；post-freeze 的 hidden-630 是单独的 SWE-Pro 分数，不能与 pair score 当作同一个指标。论文还报告 executor tokens，但 creator 修改 harness 所用的 tokens 不计入 execution cost。

Our Interpretation · 隐含优化目标 论文没有把 creator 写成一个可微的训练目标；从 benchmark 语义看，可以把它理解为在 admissible harness 集合中寻找下游任务成功率与执行成本之间的可用点：
\[H^{\ast}\in\arg\max_{H\in\mathcal{H}_{\mathrm{admissible}}}\ \mathbb{E}_{x\sim\mathcal{D}_{\mathrm{down}}}\left[J\!\left((H,L_E,x)\right)\right]\quad\text{with}\quad\mathrm{cost}(H,L_E)\ \text{reported separately}.\]
这是帮助理解评测方向的研究者重写，不是论文声称的 optimizer 或训练算法；实际实验只在有限 feedback、hidden split 与 pair budget 下观察候选版本。
Benchmark Design

两个阶段、四个领域、五个下游 benchmark

Table 1–2 的结构化重排。Creation 与 Evolution 的可见信号不同。
阶段起点creator 可见信号输出 / 评测
Creation · RQ1\(H_{\mathrm{seed}}\)task-family specification、1–3 个 development cases、简短设计教程、工具/权限约束冻结 final harness \(H\)，在 held-out downstream tasks 上 Self-Eval 与 Unified-Eval。
Evolution · RQ2creator 自己的 RQ1 code harness \(H_0\)固定 100 个 SWE-Pro feedback tasks + 全部 89 个 Terminal-Bench 2.1 结果；最多 10 个 full pairs每个完整 commit 冻结并评估；最终由 creator 声明 \(H_{\mathrm{dec}}\)，再对 630 个隐藏 SWE-Pro tasks 复测。

Creation 的下游覆盖

领域Benchmark实例数主指标作用
CodeSWE-bench Pro public split731Task success真实 repo patch 是否通过评分。
CodeTerminal-Bench 2.189Task success终端环境最终状态是否正确。
Data / ML engineeringMLE-bench75Medal score / rate机器学习实验、提交文件与指标。
WritingEQ-Bench346Rubric scoreLLM judge 的 rubric / pairwise 评分。
Search / researchBrowseComp1,266Accuracy检索、证据组织与最终回答正确性。

五个 benchmark 合计 2,207 个 unique downstream instances。Evolution 使用的 100 个 SWE-Pro feedback tasks 与 630 个 held-out tasks 都来自 731 个 public-split instances，89 个 Terminal-Bench task 全部作为 feedback；因此 Evolution 的反馈集与 Creation 的总覆盖不是另加 189 个独立实例。

故意设置的弱 seed

Figure 2 · 结构化重绘（非原论文位图）

提供：稳定的 contract floor

统一 task / model-config / workspace / output contract CLI：python -m harness ... passive paths · files · search · process · LLM gateway result.json · trajectory.jsonl · response.md · logs

刻意不提供：控制层

没有 execution loop / task decomposition / tool policy 没有 context management / durable state / memory 没有 verifier / retry / recovery / stopping rule 未修改时只做一次 non-acting pass，五项 score 均为 0

这个边界避免了两个极端：空仓库会把 CLI 与文件格式工作混进 harness design；成熟 agent 又会直接赠送 planning 与 verification policy。任何非零 Creation 分数都必须来自 creator 添加的 execution logic，而不是 seed 自带策略。

Algorithm / Pipeline

从写 harness 到冻结、执行、再演化

\(L_C\) Creator分析 specification、读反馈、编辑 harness、决定何时提交候选。
\(D\) Development envClaude Code 或 Codex，提供读文件、编辑、测试、debug 的外层工作台。
\(L_E\) Executor只在 harness 冻结后运行下游 task；Self 与 Unified 的关键变量。
\(J\) Evaluator读取 domain-specific authoritative artifact；不接受 harness 自报 success。
Creation 从 policy-free seed 获得可复用系统
specification + 1–3 dev cases→ creator inspect / edit / run→ 公开 feedback→ 冻结 \(H\)→ Self-Eval / Unified-Eval→ hidden score
Evolution 从 \(H_0\) 的反馈驱动局部程序搜索
冻结 \(H_0\)→ 100 SWE + 89 Terminal full pair→ 读 score / traces / artifacts→ 编辑新 commit→ 最多 2 probes / round→ 最多 10 pairs→ 声明 \(H_{\mathrm{dec}}\)→ hidden-630 post-freeze

一次下游任务真正发生什么？

Task \(x\)prompt、workspace、model config 与权限
Context \(C\)选择代码、日志、history、constraints
LLM actionruntime model 选择下一步工具或 finish
Tools \(T\)读取、编辑、search、shell、patch
Lifecycle \(L\)retry、timeout、recovery、finalization
Verify \(V\)真实 repo / environment / artifact → score

图中的顺序不是说所有 harness 都实现同一个 planner，而是描述论文要求的责任闭环：runtime LLM 做 task-semantic decision，harness 负责让它可执行、可观察、可恢复、可验证、可评分。

Appendix C / E

接口、artifact 与不可绕过的约束

六个可审计模块的参考接口

模块接口责任为什么重要
execution.pyrun(task) → Result
step(state, observation) → Action		实现多轮 loop 与 action scheduling，而非 one-shot call。
tools.pyregister(toolspec)
call(name, **params) → Observation		将工具 schema、输入输出与错误处理纳入可控边界。
context.pybuild(task, history, state) → Prompt
compress(messages) → Messages		避免历史膨胀导致重要证据丢失。
state.pysave(checkpoint) · load(id) · resume()把目标、假设、失败与 artifact 从瞬时 context 变成持久状态。
lifecycle.pybeforeAction · afterAction · onFailure · onTimeout决定何时拦截、重试、优雅收尾或恢复。
evaluation.pyevaluate(result, criteria) → Score
recordTrajectory(step)		把验证与轨迹记录接入真实执行；不能只写装饰性模块。

CLI 与统一审计 envelope

至少支持三种入口

python -m harness run --task-json <task.json> --model-config <model.json> --output-dir <out>

python -m harness --task-json <task.json> --workdir <dir> --model-config <model.json> --output-dir <out>

python -m harness -p "<task>" --workdir <dir> --output-dir <out> --max-steps <n>

并接受 -p/--prompt、--workdir/--work-dir/--workspace、--max-steps/--max-turns、--output-dir/--output 别名。

每次运行至少留下

result.json（诚实 status、artifact paths、metrics、errors）

trajectory.jsonl（每行一个 action / observation / state / time / error event）

response.md、stdout.log、stderr.log 与 domain-specific final artifact。

Code 任务还需真实 patch / changed files；只生成 JSON 与 log 不算完成。

约束不是“请自觉”，而是被 scorer 路径隔离

creator-visible specification 禁止 hard-code task ID、答案、expected patch、file-name allowlist、private scorer、hidden tests / answers / patches、official evaluation feedback，也禁止换成自己的 provider-specific LLM access path。SWE-Pro 只根据 task workdir 中的真实 repository diff 给 credit；Terminal-Bench 只根据最终 environment state 给 credit。因此 harness 在 result.json 中自报 success 不会直接得分。

Paper Verified · audit outcome 作者审计了论文报告的每次运行的 harness source 与 execution artifacts，报告没有发现通过被禁止路径取分的 harness，也没有因此排除实验运行。这里的“无违规”是论文自己的审计结论，不应理解为通用 agent sandbox 已经安全。

伦理与安全边界：Creation 与下游任务在 container 中运行，但作者明确说该边界主要为 reproducibility 配置，不等同于 containment；复用生成 harness 时应将其视作 untrusted code 并采取更强隔离。

Experimental Protocol

怎样把“模型、harness、评测器”拆开？

Self-Eval 与 Unified-Eval

设置固定什么改变什么回答的问题
Self-Eval每个 creator 自己的 \(L_C\)、harness、scorer\(L_E=L_C\)，每个模型运行自己构建的 harness完整的 model–harness co-design 是否有用？
Unified-Eval所有生成 harness 共用 Gemini 3.1 Pro executor 与 evaluator只替换由不同 creator 产出的 \(H\)harness 是 transferable software asset，还是只适配原 creator？
Human reference公开系统的 harness–model pair不是同一 executor 的 paired control与选定成熟系统的距离；不是绝对人类上限。

因此 Self-Eval 的高分混合了 executor 能力、harness 设计与二者兼容性；Unified-Eval 减少了 executor 差异，却不能消除 harness–model interaction。论文没有把外部 human row 当作第三个统一 executor。

Creation：每个 creator–benchmark 三次独立构建

六个 creator 与四个 domain / 五个 benchmark 组合下，RQ1 为每个 creator–benchmark pair 独立创建并评估三个 harness，报告 avg@3。隐藏任务、答案与人工实现不提供给 creator。每个完成的 harness 冻结后才进入 downstream evaluation，execution token 只计 \(L_E\) 在评测期的用量，创建代码的 token 不计入。

Evolution：full pair、probe 与 hidden-630

  1. 每条 lineage 从自己的 RQ1 code harness \(H_0\) 开始；controller 先提交 H0 在 100 个 SWE-Pro 与 89 个 Terminal-Bench 上的 baseline pair。
  2. 一个 official post-H0 candidate 必须以同一 commit 完成两个 full evaluation；任一 leg 未完成的 probe、partial、stopped 或 invalid instance 不进入官方 trajectory。
  3. 总预算为 10 个 post-H0 pairs；每个 pair 先 freeze commit，再异步运行两个 benchmark。每轮最多 2 个 probe，probe 永远是每个 benchmark 固定的前 5 个任务，只提供方向性信号。
  4. creator 读到可见反馈后自行判断诊断、编辑、是否提交、是否回滚、何时停止与选择哪个版本；controller 不替它做 accept/reject、best-version selection、failure attribution 或 summary。
  5. 所有 official versions 完成后，另行在 630 个与 feedback disjoint 的 SWE-Pro tasks 上评估；这些分数从不返回 creator，也不能影响编辑、停止或 final selection。
\[\text{visible feedback}\ \longrightarrow\ \text{edit and select}\qquad\text{versus}\qquad\text{post-freeze hidden-630}\ \longrightarrow\ \text{generalization}.\]

论文还规定了 liveness guard：反馈全部到达、仍有预算但 12 小时没有新 commit 或 submission 时发 idle notice；两次未回应后进入 declare-only，之后再等待 24 小时会 archive。它是复现实验控制器语义的一部分，不是模型能力指标。

RQ1 · Paper Verified

Creation：模型能把弱 seed 变成什么？

实验设置

Creator LLM 为 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 0.144.3 外，其余使用 Claude Code 2.1.177 作为 development environment。官方 API 或 OpenRouter 提供模型调用；每个创建结果独立运行三次。

Opus 4.8 avg
67.8
Gemini 3.1 avg
55.6
GPT-5.5 avg
55.1
Human reference
86.2

柱状图仅可视化 Table 3 的 unweighted average：SWE-Pro、Terminal-Bench、EQ-Bench3、BrowseComp 四项的算术平均；MLE-bench 不并入该 Avg。

Table 3 · Self-Eval：creator 运行自己的 harness

分数为 benchmark native metric；token 为每个 harness 的平均 executor tokens（百万）；每个 creator–benchmark 为 avg@3。
CreatorSWE-Pro
score / M tokens		Terminal-2.1
score / M tokens		MLE-bench
medal / M tokens		EQ-Bench3
score / M tokens		BrowseComp
score / M tokens		Avg.
Opus 4.869.3 / 759.564.8 / 46.232.9 / 101.784.6 / 3.152.4 / 593.967.8
GPT-5.532.8 / 325.652.1 / 12.219.1 / 29.383.0 / 4.952.6 / 313.555.1
Gemini 3.1 Pro43.6 / 783.668.8 / 177.132.4 / 131.374.8 / 5.235.2 / 267.455.6
DeepSeek V4 Pro28.9 / 739.735.6 / 35.219.6 / 208.475.4 / 4.940.9 / 1,449.945.2
Qwen 3.7 Max33.5 / 421.941.3 / 19.33.1 / 42.968.7 / 4.332.3 / 130.944.0
Seed 2.0 Pro10.8 / 454.46.0 / 23.05.3 / 557.171.1 / 9.03.2 / 610.222.8
Human harness + paired model80.0* / —88.8* / —24.0 / —83.7 / 9.292.2* / —86.2

最强的自评 overall 是 Opus 4.8 的 67.8，仍低于选定 human-engineered system row 的 86.2。分领域看，Writing 接近 reference；MLE-bench 的 Opus 32.9 与 Gemini 32.4 高于外部 reference 24.0；EQ-Bench3 的 Opus 84.6 略高于 83.7；BrowseComp 的最佳 creator GPT-5.5 只有 52.6，对 92.2 的 gap 很大。

不能过度解读 human row 80.0、88.8、92.2 等带星值来自公开系统报告，human harness 与 paired executor 并非在本实验中用一个共同模型复跑。超过 100%（若按 Figure 4 的 reference-normalized 图）也只代表超过选定外部 reference，不代表超过“人类能力上限”。

Table 4 · Unified-Eval：统一由 Gemini 3.1 Pro 执行

同一生成 harness 换成固定 Gemini executor；‡ 表示对应 Code cell 含一个 collapsed R3 replica，论文另给 post-hoc clean sensitivity。
Creator harnessSWE-ProTerminal-2.1MLE-benchEQ-Bench3BrowseCompAvg.
Opus 4.833.0‡ / 782.952.4 / 94.316.9 / 46.374.2 / 2.153.6‡ / 505.853.3‡
GPT-5.527.8 / 383.949.4 / 24.316.0 / 80.546.5 / 4.955.4 / 177.844.8
Gemini 3.1 Pro43.6 / 783.668.8 / 177.132.4 / 131.374.8 / 5.235.2 / 267.455.6
DeepSeek V4 Pro29.2‡ / 492.438.2‡ / 26.89.8 / 125.572.9 / 5.054.8 / 362.848.8‡
Qwen 3.7 Max41.3 / 1,253.348.6 / 81.916.0 / 44.071.5 / 2.549.9 / 133.452.8
Seed 2.0 Pro15.6 / 786.813.1 / 79.013.3 / 1,717.573.1 / 44.917.3 / 398.429.8

换 executor 后排名明显移动：Qwen、Seed、DeepSeek 在若干 Data / Search 设置反而提升，而 Opus、GPT-5.5 更常在自己的 executor 下强。结论不是“Gemini 更好”，而是 harness 设计与 runtime model 存在兼容性。

实现形态与失败分布

  • 18 个 Code artifacts 合计新增净 17,111 LOC，但代码体量不预测分数；Gemini 只增加 1,006 行，却得到最高 Terminal-Bench 68.8。
  • 18/18 实现了显式 execution loop；tools、lifecycle control、verification 分别在 13/18、13/18、15/18 中完整。
  • 状态管理最弱：11/18 定义了 State class，但只有 1 个暴露 state-saving interface，只有 1 个做 periodic checkpointing；26,679 条轨迹中没有观察到 checkpoint event。
  • Data 任务中 2,325 次执行有 441 次产生 degenerate submission 且没有 harness 检出；验证“文件存在”远不等于验证“提交有意义”。77.8% 的失败 Data task 被归因于 harness defect。

Table 5 · RQ1 Code harness 的编辑规模

文件计数与净 LOC 汇总每个 creator 的三个独立 Code artifacts；median / range 按单个 artifact 统计，只覆盖 creator 负责的 harness/。
CreatorFiles add / change / deleteTotal net LOCMedian / range per replicaSWE-ProTerminal-2.1
Opus 4.819 / 7 / 162,470698 / 656–1,11669.364.8
GPT-5.53 / 10 / 03,5371,231 / 1,059–1,24732.852.1
Gemini 3.1 Pro4 / 4 / 01,006324 / 270–41243.668.8
DeepSeek V4 Pro14 / 4 / 13,242988 / 931–1,32328.935.6
Qwen 3.7 Max12 / 6 / 03,5621,339 / 551–1,67233.541.3
Seed 2.0 Pro14 / 6 / 03,2941,200 / 868–1,22610.86.0

Table 5 的对照正好支持作者的 caution：LOC 不是能力代理变量；Gemini 以最少净增量取得最高 Terminal-Bench，但这只是本实验的描述性结果。

Behavioral Analysis

机制真的被调用了吗？

HarnessDev 的一个重要贡献是把“代码中声明了什么”和“正式运行时发生了什么”分开统计。Figure 5 的 normalized evidence density 不是分数、显著性或因果效果，而是机制进入主路径或触发于真实运行的证据密度。

观测层级Code harness 统计应怎样读
component instances108 个；72 trigger，18 partial evidence，18 never observed没有被观察到的 18 个全部属于 state / memory；类名存在不是 runtime evidence。
其它 Creation domainWriting 有 587 个 features，其中 124 个 dead code；Data 有 36 个 dead mechanisms把机制写出来不等于它参与了执行，也不等于它有用。
self-test vs scoreself-test count 与 downstream score Spearman 仅 0.13–0.26，不显著测试数量本身不是有效质量指标。
revision calls vs scorerevision calls 相关达到 0.57，\(p\le 0.0005\)更有价值的是读懂失败、做 targeted change、再验证，而不是堆测试数量。

跨 executor 的兼容性证据

可迁移的正例

Qwen harness 换到 Gemini 后，BrowseComp 从 32.3 到 49.9（+17.6），MLE-bench 从 3.1 到 16.0（+12.9）。原来的 executor 可能才是瓶颈。

过拟合的反例

Opus Code harness 的 Self-Eval SWE-Pro 为 69.3，换 Gemini 后降至 33.0；Opus Search 中 duplicate-query rate 从 10.1% 升到 88.2%，说明 dedup、review、termination 规则适配了原模型。

这也是为什么论文把“generated agent”定义为 \(H+L_E\)，而不是把 harness 当作独立可排名的静态库：软件资产是否有用，取决于它与调用模型的 protocol、prompt、budget、tool schema 与 stopping rule 是否相容。

RQ2 · Paper Verified

Evolution：局部修复能否变成稳定收益？

Table 6 · 可见反馈上涨，不等于隐藏任务上涨

Feedback pair 是 SWE-Pro-100 与 Terminal-Bench-89 等权平均；held-out 只用事后隐藏的 SWE-Pro-630；final gap 为该 lineage 的最佳 hidden score 减 creator 声明版本的 hidden score。
Setting / creatorVisible pair \(H_0\rightarrow H_{\mathrm{dec}}\)Hidden-630 \(H_0\rightarrow H_{\mathrm{dec}}\)Final gap
Self · Gemini 3.1 Pro59.9 → 68.7 (+8.8)48.89 → 51.59 (+2.70)0.00
Self · Opus 4.871.1 → 74.1 (+3.0)63.02 → 67.46 (+4.44)1.59
Self · Qwen 3.7 Max41.8 → 55.7 (+13.9)42.22 → 43.65 (+1.43)3.17
Self · DeepSeek V4 Pro47.2 → 60.6 (+13.4)47.30 → 50.48 (+3.17)1.75
Self · GPT-5.559.2 → 65.1 (+5.9)48.25 → 52.06 (+3.81)0.00
Fixed Gemini · Opus 4.858.8 → 68.6 (+9.7)48.10 → 50.79 (+2.70)2.54
Fixed Gemini · Qwen 3.7 Max62.1 → 63.2 (+1.1)49.52 → 48.41 (−1.11)1.11
Fixed Gemini · DeepSeek V4 Pro47.3 → 53.8 (+6.5)43.02 → 40.63 (−2.38)3.02
Fixed Gemini · GPT-5.556.6 → 59.1 (+2.4)42.22 → 31.90 (−10.32)16.51

五条 Self-runtime lineage 全部在 hidden-630 上比 H0 有提升，范围 +1.43 到 +4.44，均值 +3.11；固定 Gemini 的四条对照中只有 Opus 提升，其余三条回退。可见 feedback 与 hidden score 在 64 个 adjacent version switches 中只有 34 次同向（53.1%），9 个 creator-declared final versions 只有 2 个是 hidden set 上的最优版本。

Evolution 的稳定性与可归因性

8

switches 在两个 benchmark 都回退

16

只在一个 benchmark 回退

27

表面 gain 仍在 repeated-run noise band 内

2

有超出噪声带的明确正证据

7

没有可测变化

1

没有 executable code change

同一个 commit 的 pair score 约可波动 ±4.75 points，因此小幅分数变化不能仅凭 score 归因于代码修改。169 个新增 function / class 中，113 个从 entry point 可达，31 个只从 dead code 可达，25 个没有 caller。

Table 7 · 改了什么，而不是改了多少行

Setting / creatorOfficial switchesH0 → Hdec cumulative diff主要编辑焦点
Self · Gemini 3.1 Pro811 files, +692 / −38tool output、editing、timeouts、patch cleanup
Self · Opus 4.838 files, +450 / −18completion gate、self-review、process recovery
Self · Qwen 3.7 Max89 files, +1101 / −106empty-response / parse recovery、auto-submit checkpoints
Self · DeepSeek V4 Pro109 files, +1730 / −58completion logic、tool extensions、workspace pre-analysis
Self · GPT-5.574 files, +496 / −49final-state review gate、artifact tracking
Fixed Gemini · Opus43 files, +227 / −21pre-completion verification、scratch-file cleanup
Fixed Gemini · Qwen54 files, +219 / −96context、message-sanitizer rewrite
Fixed Gemini · DeepSeek98 files, +476 / −12message-protocol recovery、workspace discovery
Fixed Gemini · GPT-5.5106 files, +297 / −34probes、branch rollback、final-state review

9 条 lineage 共产生 73 个 official versions、64 个 adjacent version switches。64 个 switches 中，58 个改 execution / control flow，37 个改 tools，17 个改 lifecycle recovery，16 个改 context，只有 4 个改 state，没有一个修改 standalone verifier。Evolution 更像围绕 runtime feedback 的 local program search：删除代码与回滚同样重要。

最清楚的成功案例与反例

Opus：从“99 次报告成功”追到“48 次真的通过”

Opus 发现 100 个运行中有 99 个自报 success，但真实通过只有 48 个；它把差距追溯到 premature completion，并添加 completion check。这个修改在端到端验证后才进入有效反馈。

Qwen：message sanitizer 破坏了有效协议

一个看起来合理的 context / message 清理重写，反而破坏 Gemini 的有效 tool-result sequence。它说明“更干净的 context”并不自动等于更强的执行系统。

诊断仍是最弱环节：专用 trajectory interface 只被调用两次；不同 lineage 明确检查的 feedback cases 只覆盖 0.5%–40.2% 的 189 个 feedback tasks。某个 GPT-5.5 candidate 通过了全部 5 个 Terminal probe，但 full set 只得到 0.584。

Figure / Table Guide

论文图表应该怎样读？

由于单文件页面不直接复制 PDF 位图，下面采用基于原图 caption 与正文的结构化重绘；所有数值表格尽量保留论文原始数字。图示标明“非原图”，避免把重绘误当作作者的视觉排版。

Figure 1 · 结构化重绘（非原图）

Existing agent evaluation

Fixed harness Model + tools + context + memory + loop One downstream task \(x\) Evaluated artifact: answer \(y\)

HarnessDev

Weak seed \(H_{\mathrm{seed}}\) Creator: analyze → edit → solve Frozen runnable \(H\) reused across tasks Evaluated artifact: persistent infrastructure
Figure 1：把单位从一次 task output 改成可冻结、可审计、可复用的 harness；Creation 与 Evolution 都围绕这个 artifact 展开。见 PDF p.2。
Figure 3 · 结构化重绘（非原图）
Creator \(L_C\)实现六类控制责任
Execution core\(E,T,C,S,L,V\)
Audit contractresult / trajectory / logs
Coderepo state + patch
Data / MLEsubmission + metrics
Writing / Searchprose / cited evidence
Figure 3：统一审计输出不强迫所有领域使用同一文件格式；最终 scorer 读取各 domain 的 authoritative artifact。见 PDF p.5。
Figure 5 · 机制证据的读法

Declared in code

类、函数、配置、transient state 出现，只能给 partial weight。

Observed at runtime

机制进入 main path 或在 formal run 触发，才得到 full weight；仍不等于它有效。

Figure 5：颜色表达 evidence density，不表达 score、显著性或因果效果。论文用它揭示“写了 state / memory”与“真的保存 checkpoint”之间的落差。
Figure 4 · reference-normalized bars
Code / SWE-Pro
69.3 / 80.0
Terminal
68.8 / 88.8
Writing
84.6 / 83.7
Research
52.6 / 92.2
Figure 4：将 Self-Eval 分数除以各 benchmark 的 selected human-engineered reference，并在柱旁保留 raw score。它展示“离选定成熟系统有多远”，不是统一 evaluator 下的人类上限；MLE-bench 另以 medal rate 表示。
Figure 6–10 · 组合阅读
Figure 6：Self-Eval 与 fixed Gemini 的 score 连接线，揭示 executor portability 与 co-adaptation。 Figure 7：9 条 Evolution feedback trajectory；H0、后续冻结版本与 creator-declared final。 Figure 8：把可见 SWE-Pro-100 曲线叠在事后 hidden-630 曲线上，直接看过拟合与 final selection gap。 Figure 9：score 对 executor token cost 的 log-scale trade-off；MLE-bench 质量相近时成本可近一个数量级。 Figure 10：每一个 frozen version 的执行 token 用量，且分开 self runtime、fixed Gemini 与 hidden-630。
Figure 7–10 的共同信息：版本曲线、隐藏集与成本必须同时看，不能把一次可见分数峰值直接写成“最优 harness”。

Related work 的边界

论文将自身放在 Harness-Bench、Meta-Agent Challenge、HarnessOpt-Bench、Evo-Bench 与自动 agent design / harness evolution 工作之间。最接近的差异是：HarnessDev 把 from-scratch Creation 接到 Evolution，区分 creator–executor，记录 execution cost，并将每个冻结版本都放到 disjoint hidden set 上；但作者也承认 matched-search evaluation 仍是 future work。

Reproducibility

复现边界：哪些已固定，哪些仍不可得？

这不是模型训练 benchmark

HarnessDev 不更新 creator 或 runtime LLM 的权重，也没有 optimizer、learning rate、batch size、epoch 或 fine-tuning loss。Creation / Evolution 的“学习”发生在 inference-time software development：\(L_C\) 通过 development environment 修改 harness source，commit 被 freeze，\(L_E\) 再在下游 task 上执行。可持久化的载体是 harness code、Git version、trajectory、feedback ledger 与最终 artifact，而不是新的 neural checkpoint。

所以论文中的 capability gain 应理解为 model-external learning / system engineering gain。作者明确不主张 heuristic harness learning 可以替代 parameter training；它测量的是模型能否建设与维护承载 future tasks 的 execution system。

Appendix B · Creator decoding 配置

CreatorDevelopment envTemp.Top-pTop-kMax output
Opus 4.8Claude Code 2.1.1771.0provider defaultdefault128,000
GPT-5.5Codex 0.144.3defaultdefault—128,000
Gemini 3.1 ProClaude Code 2.1.1771.00.956465,100
DeepSeek V4 ProClaude Code 2.1.1771.00.95—131,072
Qwen 3.7 MaxClaude Code 2.1.1770.60.952065,536
Seed 2.0 ProClaude Code 2.1.1771.00.70—131,072

所有 creator 使用 high reasoning effort 与 streaming，output length 设为 endpoint maximum；“default”表示 provider 未暴露或论文未覆盖该参数，不应自行补成某个数值。

下游资源与 human reference

项目论文给出的配置 / reference
MLE-bench runtime每 task 独立 container：1× NVIDIA A800-SXM4-80GB、14 vCPUs、227 GiB RAM；36,000 s wall-clock，其中 harness 34,200 s、grader reserve 1,800 s；500-step cap；数据下载/准备不计入 task clock。
RQ2 code runtime500-step cap，7,200 s per task；100 SWE-Pro + 89 Terminal-Bench full pair。
SWE-Pro referencePublic coding-agent setup + Claude Fable 5，80.0（外部公开结果，未在本实验重跑）。
Terminal-Bench referenceOpenAI agent setup + GPT-5.6 Sol，88.8（外部公开结果）。
MLE-bench referenceMLEvolve + Gemini 3.1，medal rate 24.0。
EQ-Bench3 referenceKimi Writer + Opus 4.8，rubric score 83.7。
BrowseComp referenceOpenAI browsing stack + GPT-5.6 Sol，92.2（外部公开结果）。

Representative system prompts

附录 E 给出了两套代表性 system prompt，但删去了 task-specific prompt 与 auxiliary workspace documents。RQ1 的共同 prompt 要求模型作为 agent harness engineer，交付 executable system code，而不是 architecture description、README、plan 或未被调用的 helper modules；随后定义 runtime LLM、generated harness、generated agent、creator、metaharness，并要求实现 \(E,T,C,S,L,V\) 的行为责任。RQ2 prompt 在此基础上改为持续改进已存在的 runnable code-agent harness，并明确 controller 不替 creator 做 best-version selection、rollback、failure attribution 或 feedback summarization。

页面不伪造未公开的完整 task prompt。论文明确说任务相关 prompt 与 auxiliary workspace 文档被 omitted；因此此处只整理原文公开的 system-level contract。

若要复现实验，最小的 honest-status 语义是什么？

success：有合理证据最终 artifact 完成任务；partial：有真实进展但验证不足、依赖受阻或结果不确定；failed：没有有效 artifact 且记录失败原因。不能把 plan、解释、模板、空 artifact 或模型自报状态写成 success。

官方代码仓库与 release 状态

截至当前 arXiv v1 的 record 与官方项目页，本页未发现作者在页面上链接一个可直接复现实验的公开 HarnessDev GitHub repository。附录 C.1 承诺 release reference seed implementation、audit script 与 held-out task splits；在它们实际公开前，不应声称本地已完成 benchmark reproduction。论文正文与附录本身是当前可核验的一手材料。

MathJax 3 browser-safe smoke test

页面统一使用 MathJax 3 的 \(I^{\ast}\)、\(z^{\ast}_{\mathrm{img}}\)、\(z^{\mathrm{img}}_{1:I}\)、\(z_{\lt t}\)、\(P_{\theta}(\mathbf{z}\mid\mathbf{x})\) 与 \(\beta_1=0.9,\ \beta_2=0.95\)。

\[P_{\theta}(\mathbf{z}\mid\mathbf{x})=\prod_{t=1}^{T}p_{\theta}(z_t\mid z_{\lt t},\mathbf{x})\]
\[d_t=\mathrm{LPIPS}(R_t,I^{\ast})\]

这些是项目页面规范要求的渲染验收表达式，与 HarnessDev 的原始公式分开，仅用于检查 HTML parser、MathJax delimiter 与 inline nowrap CSS。

Paper vs. Implementation 论文报告的是完整运行与审计后的 benchmark 结果；公开材料中能核验到的 implementation contract 是 CLI、六类职责、artifact envelope 与 controller protocol。缺少公开代码时，页面不把附录里的接口 skeleton 当成作者最终 harness 的 source code，也不把第三方博客中的推测当作实现事实。

把事实、作者主张与我们的解释分开

Paper Verified
  • 所有六个 creator 都能从弱 seed 产出 runnable harness，seed 本身在五项 Creation benchmark 均为 0。
  • Creation 在 writing 与 MLE-bench 更接近或超过选定 reference，在 code 与 search/research 明显落后。
  • Evolution 的 Self-runtime hidden-630 final gains 为 +1.43 至 +4.44，均值 +3.11；fixed Gemini 只有 Opus 提升。
  • 64 次 adjacent switches 中 feedback / hidden 同向 34 次（53.1%），只有 2/9 declared final 是 hidden-optimal。
  • state / memory 大量只存在于代码声明，未在 runtime 触发；executor 变化可导致显著崩溃或提升。
Author Claim
  • Harness 是继 model weights 之外，另一处可以积累、测试、复用并通过失败持续改进的 intelligence substrate。
  • Creation 与 Evolution 能让 agent development 成为可测量的 software-engineering object。
  • 可靠的 harness engineering 需要从 execution traces 诊断行为限制，而非只增加代码量或 self-test 数量。

这些是作者用实验动机与讨论支持的总体论断；并不等于已经证明了跨领域、跨模型、长期稳定的自我进化。

Our Interpretation
  • Self-Eval 主要测量 model–harness co-design；Unified-Eval 才较接近“软件资产可迁移性”，但仍受模型协议影响。
  • Evolution 的核心 bottleneck 不是“不会写新代码”，而是 feedback attribution、版本选择、噪声估计与回归保护。
  • 论文中最有价值的负结果是：结构名词（State、Memory、Verifier）必须用 runtime reachability 与真实 artifact 验证。
Research Extension
  • 为 harness 版本建立 provenance graph，把每次修改与 failure evidence、触发路径、成本和 held-out 回归绑定。
  • 用多任务、跨 executor 的 survival rule 替代“可见分数最高即 final”。
  • 把 verifier confidence、uncertainty 与 repeated-run variance 纳入选择器，而不把一次 noisy gain 当成 causal proof。
Reviewer Commentary

Reviewer 视角：一篇好的 benchmark，尚不是稳定 RSI 证明

Strengths

  • 评测单位选得准确。冻结 runnable harness、分离 creator 与 executor，把长期系统能力从一次答案质量中拆出来。
  • 边界与审计清楚。弱 seed 既可运行又不带 task-solving policy；score path 读取真实 repo / environment，避免 self-report gaming。
  • 覆盖维度完整。同时看 capability、execution-token efficiency、hidden generalization、cross-executor transfer、dead mechanisms 与 version trajectories。
  • 负结果具体。没有用“模型会 self-improve”收束，而是量化 53.1% 方向一致率、±4.75 noise、state/checkpoint 缺失与 441 个 degenerate Data submissions。
  • 可复现边界诚实。公开 decoding、hardware、CLI、artifact、controller budget 与 system-level prompts；对 human reference 的非 paired 性质做了标注。

Weaknesses / 需要谨慎的地方

  • Evolution 样本仍很薄。9 条 lineage、每个 creator–runtime cell 一条 trajectory，且有一个 unfinished main-runtime cell，不足以给出稳健的不确定性估计或 population-level claim。
  • Hidden generalization 只有 SWE-Pro。Creation 有四个领域，Evolution 的 post-freeze hidden set 却只覆盖 630 个 code tasks；无法证明 writing、data、research 的 evolution transfer。
  • Human baseline 不完全公平。不同 benchmark 的 reference 使用不同 harness–model pair、版本与公开 leaderboard 条件，不是共同 executor 下的 controlled upper bound。
  • Unified-Eval 仍不是纯 harness test。一个 harness 的 prompt、tool schema、budget、stop rule 与 Gemini 的 response style 可能不匹配；executor–harness compatibility 本身也会被测到。
  • 可见反馈的诊断质量有限。作者说 controller 不做 failure summarization，把诊断责任完全交给 creator，正是研究问题的一部分，但也使最终选择混入“读了多少 case、会不会 ledger”等额外能力。
  • 没有强 search baseline。作者承认 matched-search evaluation 是 future work；因此 Evolution gain 还不能与简单的保留 H0、随机 rollback、best-of-n 或人类规则选择器充分比较。
  • 安全边界不是 sandbox 证明。生成 harness 被审计无违规，但容器是 reproducibility boundary，不是可直接面向不受信代码的 containment 方案。

Potential Improvements

改进方向具体设计要排除的混淆
多 executor、多任务 survival每次 candidate 同时在多个 runtime model 与多个 unseen domain 上评估，按保守下界选择。不把单一 executor 的 co-adaptation 写成泛化。
噪声与因果归因每个版本 repeated runs、paired seeds、confidence interval；记录修改触发的具体 failure bucket。不把 ±4.75 的自然波动归因给一行代码。
强 baseline加入 H0 保留、随机 edit、best visible、best hidden oracle、简单 regression gate 等对照。分离“会改代码”与“会做正确版本选择”。
机制可达性验证静态 call graph + dynamic trace + artifact-level assertion；对 state / verifier 设最小触发标准。不把 dead code、decorative modules 或 self-report 当能力。
可组合 harness把 \(E,T,C,S,L,V\) 做成 versioned components，跨模型检验替换单一模块的影响。避免每次改动同时改变多个层，无法定位收益。
Research Extension

对 Agent / Context Optimization 研究的启发

以下不是 HarnessDev 的论文结果，而是从其问题定义和负结果推导出的研究接口。它们与程序化材质、renderer-in-the-loop agent 也有直接对应关系。

1. Context 不是“加更多历史”，而是可验证的选择器

论文中 \(C\) 的责任是把 task、代码、日志、history 与 constraints 送入 runtime context。Future harness 可以把 context selection 显式记录为 provenance：模型看到什么、为什么看到、压缩掉什么、压缩后是否改变 tool-message pairing。对 renderer agent，可把参考图像的多尺度 feature、graph diff、编译错误、渲染截图与预算状态作为 typed observations，而不是无结构长日志。

2. Verifier 应独立于模型自报

HarnessDev 的 code score 只读取真实 repo / environment，这个原则可以迁移到材质生成：不要只看 agent 写出的 success，而要让 Substance cook、render、graph validity、通道完整性与目标图像指标各自产生 evidence。指标可以写成一个未来工作的多目标 evaluator：

\[R=\lambda_{\mathrm{struct}}R_{\mathrm{struct}}+\lambda_{\mathrm{appearance}}R_{\mathrm{appearance}}+\lambda_{\mathrm{physical}}R_{\mathrm{physical}}+\lambda_{\mathrm{compile}}R_{\mathrm{compile}}-\lambda_{\mathrm{budget}}R_{\mathrm{budget}}.\]

这个公式是研究延伸，不是 HarnessDev 的原始公式。它强调 compile / artifact validity 是硬边界，不能被单一图像相似度或模型自评覆盖。

3. 双层演化：局部 action loop 与版本 survival loop

Context目标、约束、多尺度证据
Typed action调用工具、修改图或代码
Observation真实执行与 renderer 反馈
Failure ledger证据化归因，不只写分数
Candidate H′冻结、重复运行、跨 executor
Survival rule隐藏任务与回归门控

HarnessDev 已经说明“修改 execution、tools 很常见，而修改 state、verifier 很少”。后续研究的关键不是继续增加模块，而是证明每个机制可达、被调用、能改善下一个任务，且不会吞掉已有能力。

最小可发表的后续实验

因素ControlTreatment主要指标
Context原始 task + 全量 history带 provenance 的结构化 context selector / compressortoken cost、重要证据保留率、tool-pair integrity
Verification模型自报 finish独立 artifact / execution / renderer verifierfalse-positive、real success、回归率
Evolutionvisible best 或独立 retryfailure-bucket + repeated-run + hidden survival ruleheld-out gain、direction agreement、best-version gap
Transfer单一 runtime model多 executor、多预算、多任务 family跨模型迁移、成本–能力 Pareto front

References

  1. Wu, Y. et al. HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? arXiv:2609.01437v1, 2026. 论文 record、作者、提交时间与 abstract。
  2. Wu, Y. et al. HarnessDev 原始 PDF. 2026-09-02 标注版本；本文的公式、表格、附录接口与实验数字均以此一手资料为准。
  3. HarnessDev authors. Self-Developing Agents project page. Aspire、S3Gym、HarnessDev 的三问框架与跨研究结果。
  4. SWE-bench team. SWE-bench / SWE-bench Pro. HarnessDev 使用 public split 的 731 个实例，Evolution 取 100 feedback + 630 held-out。
  5. The Terminal-Bench team. Terminal-Bench 2.1. HarnessDev 使用全部 89 个任务作为 Evolution feedback benchmark。
  6. Chan, J. S. et al. MLE-bench. Evaluating machine learning agents on machine learning engineering, 2024。
  7. Paech, S. J. EQ-Bench3. Emotional intelligence benchmark，论文引用版本含 46 scenarios。
  8. OpenAI. BrowseComp. HarnessDev 的 search / research downstream benchmark。
  9. Lu, X. et al. The Meta-Agent Challenge: Are Current Agents Capable of Autonomous Agent Development? 相关的 agent artifact development benchmark。
  10. Ursekar, V. et al. HarnessOpt-Bench: Evaluating LLMs at Harness Optimization. HarnessDev 在 Related Work 中讨论的 concurrent benchmark。
  11. Wu, Y. et al. 本页中的版本号、模型名、execution cost、hidden split、audit 与 controller 语义均直接回链上述 arXiv PDF 的 Sections 3–6 与 Appendices A–E；第三方解读只用于发现线索，未作为关键事实来源。
阅读提示 这是一篇 2026-09-01 提交的 arXiv v1 technical report，不是已确认的 conference paper；页面没有把后续可能出现的 revision、代码 release 或 venue 变化提前写成事实。