HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?

作者Yuhao Wu, Jingyuan Zhang, Jiajun Shi, Xinping Lei 等 19 人

机构ByteDance Seed · SUTD · Georgia Tech · M-A-P · TokenWave.AI

时间2026-09-01

把"写 agent scaffold 的代码"本身变成一个 benchmark 任务：给定一个只有 input parsing、跑任何 benchmark 得零分的 weak seed，测 LLM 能不能补全出可以跑任务的完整 harness（Creation），再测它能不能用自己的真实执行 feedback 迭代改进这个 harness（Evolution）。本质是翻转现有评估逻辑——固定 harness 测 agent 能力 → 固定任务测 harness 质量。

Figure 1：Creation（从 weak seed 构建可用 harness）和 Evolution（用真实执行 feedback 迭代改进）两个阶段。

术语速查

术语	在本文中的具体含义
Creator LLM	写 harness 代码的模型（如 Opus 4.8、GPT-5.5）
Executor LLM	用那段 harness 实际跑下游任务的模型，可以与 Creator 相同（Self-Eval）或不同（Unified-Eval）
Harness H	一段 Python 代码，包含 E/T/C/S/L/V 六个控制模块，决定 agent 如何循环、调工具、管 context、存 state、恢复失败、验证结果
Weak seed Hseed	只有 input parsing + passive audit log 的最小 harness；未经修改对所有 benchmark 得零分
Creation	Creator LLM 修改 Hseed → 得到可跑任务的 H₀
Evolution	Creator LLM 用 H₀ 的真实执行 feedback → 迭代改出 Hdec，在未见过的 held-out 任务上测泛化
Self-Eval	Creator = Executor，即模型自己写的 harness 自己跑
Unified-Eval	Executor 固定为 Gemini 3.1 Pro，隔离 harness 质量与 executor 能力

研究动机

问题难在哪：同一个 GPT-5.5，在 Terminus 2 harness 里解决 Terminal-Bench 的 35.2%，在 Codex CLI 里解决 49.6%——差 14.4 个百分点，只因为 harness 不同、权重相同。现有 benchmark 把 harness 当固定配置，测出来的是"model × harness"的联合能力，无法分辨是模型弱还是 harness 弱。
现有方法的问题：(1) harness 由人工专家设计，无法自动适应新模型或新任务；(2) "固定 harness 测 agent"循环默认 harness 已经最优；(3) 没有系统性评估 LLM 能否构建和改进 harness 本身的基准。
核心 insight：把 harness 从固定基础设施变成被评估对象——如果 LLM 能创建和演化自己的 harness，就意味着 agent 能力的瓶颈不再是固定的，AI R&D 自动化就包含了改进执行框架本身这一层。

核心方法

1. Weak Seed——刻意设计的零分起点

所有 Creator 从同一个 Hseed 出发：解析输入、可选一次连通探测、写审计记录。没有执行循环、任务分解、工具策略、上下文管理、持久状态、验证器、重试、停止规则。未修改时对所有 benchmark 得零分。

Figure 2：Weak Seed 结构与开发环境。Seed 只固定 input/output 接口；Creator 在公开开发环境中迭代修改 H；评估集始终隔离不可见。

直观理解：Hseed 相当于一个只有 main 函数骨架、所有逻辑全是 TODO 的 Python 文件——Creator 必须从这里填出整个 agent runtime。

2. 六个 Harness 组件（E/T/C/S/L/V）

Figure 3：Creator 必须实现的六个控制模块及最终交付 scorer 的格式化输出。

组件	代号	职责
Execution Loop	E	主控循环，决定何时调工具、何时停止
Tool Policy	T	工具选择、调用顺序、权限管理
Context Management	C	上下文压缩、历史裁剪、token budget
State & Memory	S	跨步骤持久状态、任务进度、恢复点
Lifecycle & Recovery	L	失败重试、中断恢复、超时处理
Result Verification	V	输出合规检查、验收标准判断

3. 评估协议——Creator vs Executor 分离

flowchart LR
  D["Dev Env"] --> LC["Creator LLM"]
  LC -->|"build H"| H["Frozen Harness H"]
  H -->|"run task"| LE["Executor LLM"]
  LE --> y["output y"]
  y --> J["Evaluator J"]
  J --> score["score"]
  style H fill:#F2E5DA,stroke:#B39A8F

drag to pan · scroll to zoom

评估流程：Creator 在开发环境中构建 H；H 冻结后，Executor 用 H 跑下游任务；Evaluator 对输出打分。Self-Eval = Creator = Executor；Unified-Eval = Executor 固定为 Gemini 3.1 Pro，隔离 executor 差异。

4. Evolution——用真实 feedback 改进 H

从 RQ1 的 H₀ 出发，用 100 个 SWE-Pro feedback 任务 + 89 个 Terminal-Bench 任务的执行结果迭代改进，budget = 10 次完整双 benchmark 评估对。泛化测试对象：630 个 Creator 从未见过的 SWE-Pro 实例（held-out set）。

直观理解：这是一个 creator 自己跑自己写的代码、看失败日志、改代码、再跑的迭代过程——区别在于改的不是解题代码而是 agent runtime 本身。

最关键的一句话

当模型修改自己的 harness，它在编辑的是自己在所有未来任务中的感知、规划和恢复方式——这与修改一个独立程序根本不同。

主要实验结果

RQ1 Creation：Self-Eval 结果

六个 Creator 在五个 Benchmark 上的 Self-Eval 分数，与人工参考对比。Opus 4.8 整体最强（均分 67.8），但仍低于人工参考（86.2）。EQ-Bench3（Writing）最接近参考；BrowseComp（Search）差距最大。

详细数字（点击展开）

Creator ↕	SWE-Pro ↕	Terminal-Bench ↕	MLE ↕	EQ-B3 ↕	BrowseComp ↕	均分 ↕
Human ref	80.0	88.8	24.0	83.7	92.2	86.2
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

Human ref 部分为外部结果。avg@3 均值。

关键量化发现

代码量 ≠ 性能：18 个 Code harness 合计加了 17,111 LOC，但 edit size 与分数无相关。Revision 调用次数与分数 Spearman 0.57（p≤.0005）；self-test 数量仅 0.13–0.26（不显著）——看懂失败定向修改，比写更多测试更重要。
Gemini 最省代码最强 Terminal-Bench：只加 1,006 net LOC（最少），但 Terminal-Bench 68.8（最高）——focused 改动 > 代码量。
State/Memory 是系统性盲点：18 个 Code harness 中只有 1 个保存 state，1 个实现 checkpointing。18 个 S 模块实例在真实运行中从未被观察到触发。
MLE-bench token 用量极差 19×：成本与性能完全去耦合；Seed 2.0 Pro 花最多 token（557K/任务）但 medal rate 仅 5.3%。

六组件实现率（Code harness）

Figure 5：跨域和阶段的 harness 架构证据热图。State & Memory（第四列）在所有域中最弱。

Executor 可移植性——关键反例

Figure 6：固定 Gemini executor 下的 harness 可移植性。Opus SWE-Pro 从 69.3 跌至 33.0（−36 点）；Qwen BrowseComp 反而升 +17.6——说明可移植性高度依赖 harness 是否对原 executor 过度定制。

Opus harness 硬编码了针对 Opus executor 的 120 步限制；换 Gemini 后限制触发错误，SWE-Pro 暴跌 36 点。
Opus Search harness 换 Gemini 后，重复查询率从 10.1% 升至 88.2%——去重/终止规则针对原 executor 行为调参。
结论：可运行 ≠ 可迁移，harness 与 executor 存在隐式耦合。

RQ2 Evolution：有改进但不稳定

Creator	Feedback 集提升	Held-out-630 提升
Gemini 3.1 Pro (Self)	+8.8	+2.70
Opus 4.8 (Self)	+3.0	+4.44（最大）
其余（Fixed Gemini executor）	仅 Opus 保持 held-out 正增益，其余三个退化

5 个 self-runtime 轨迹，73 个 official version，64 次版本切换。所有 creator 在 visible feedback 上都有提升，但换 executor 后只有 Opus 泛化成功。

局限与展望

批判性定位

怀疑论者：这不就是"让 LLM 写一个 coding agent"，本质是代码生成 benchmark，输出碰巧是 scaffolding 代码而不是解法？OpenHands、SWE-agent 的 harness 也是 LLM 辅助设计的。
真正新的东西：(1) 明确分离 Creator/Executor 角色并系统性评估两者独立贡献；(2) Evolution 阶段有真实 feedback 迭代 + held-out 泛化测试，不是一次性代码生成；(3) Executor 可移植性实验揭示了 harness 与 executor 之间的隐式耦合这一具体可测量问题；(4) 发现 State/Memory 在所有 LLM 生成的 harness 中几乎一致缺失——这是一个可复现的系统性盲点。

已知局限

Evolution 过拟合 feedback：Gemini self feedback 集提升 +8.8，held-out 只有 +2.70——改进高度依赖反馈样本分布，泛化有限
Executor 耦合：harness 隐式对原 executor 行为过度定制（步数限制、去重策略、停止规则），换 executor 即退化
State/Memory 盲点：26,679 条轨迹无一次 checkpoint 事件；77.8% MLE-bench 失败归因于 harness 缺陷而非 executor 能力
Cost-performance 去耦合：token 用量 19× 极差，高成本不可靠预测高性能

研究趋势

HarnessDev 处于"harness 本身是 AI R&D 自动化目标之一"这一方向的实证前沿——与 Anthropic/OpenAI 2026 年 R&D 自动化报告、Prime Agent 的 continual harness self-modification 方向对齐。下一步关键：(1) 解决 State/Memory 缺失问题（harness 级的持久状态和 checkpointing）；(2) 开发 executor-agnostic 的 harness 设计规范，降低可移植性风险；(3) 把 Evolution 的 held-out 泛化作为主优化目标而非 feedback 集得分，防止过拟合反馈环境；(4) 把"harness 改进量"作为独立的 AI 能力度量维度，而不仅仅是下游任务分数。