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

  • 关联论文：2609.01437
  • 作者：Tom
  • 更新：2026-09-03

一句话结论

HarnessDev 将 Agent 评测的焦点从「任务输出质量」转向「执行基础设施本身的质量」——当前 LLM 能从零构建可运行的 Harness，但在代码和搜索类任务上与成熟人工系统仍有显著差距，且 Evolution 阶段的改进不稳定、跨模型迁移效果有限。

解决什么真问题

一个 LLM Agent 的能力，并不只由模型权重决定，还高度依赖其外部执行基础设施——Harness。Harness 负责管理执行循环、工具调用、上下文处理、失败恢复和结果验证，是把模型输出变成实际动作的粘合层。

关键证据：相同模型权重在不同 Harness 下性能差异巨大。论文引用了一个具体案例：GPT-5 在 Terminus-Bench 2.1 中，使用 Terminus 2 的成功率为 35.2%，而切换到 Codex CLI 后跳升至 49.6%——同一模型，Harness 不同，成绩相差 14.4 个百分点。

但现有 Agent 评测几乎只报「在某个选定 Harness 下模型的任务表现」，不评测「模型是否能够自主构建和改进 Harness」。这个空白意味着：当 Harness 成为 Agent 能力瓶颈时，我们不知道是模型不行还是 Harness 不行，更不知道模型是否具备自主解决 Harness 问题的能力。

HarnessDev 填补了这个空白：把评测单元从「任务输出」换成「可运行的基础设施」，系统性地研究 LLM 是否能创建和迭代改进自己的执行系统。

核心方法

Benchmark 设计：两阶段评测框架

Stage 1：Creation（从零构建）

Creator LLM 从一个故意设计得很弱但可运行的种子 Harness 出发，加上少量 development cases（用于快速验证），然后构建完整的执行系统。

Agent 的输入： - 弱但可运行的种子 Harness 代码 - 少量开发用例（development cases） - 下游任务的抽象描述（如「帮用户写 Python 代码并执行」）

Agent 的任务： - 决定 Harness 应该支持哪些工具 - 设计工具调用逻辑和错误处理 - 构建上下文管理、结果验证等执行层逻辑 - 迭代调试直到构建出完整可工作的 Harness

Stage 2：Evolution（持续改进）

Agent 从自己（或参考）构建的 Harness 出发，利用下游执行反馈持续迭代改进，目标是提升 Benchmark 性能。

Agent 的输入： - 已有 Harness 代码 - 下游任务执行反馈（pass/fail、error 信息等）

Agent 的任务： - 诊断 Harness 的结构性瓶颈（从执行 trace 中识别问题） - 设计针对性的改进 - 在不破坏已有功能的前提下累积改进

评测维度

维度 衡量指标
Capability 在 held-out benchmarks 上的任务成功率
Efficiency 执行 token 成本（每任务消耗的 token 数量）

评测规模

  • 6 个 Creator LLM：覆盖多种规模和能力层级
  • 4 个领域：代码、搜索与研究、写作、机器学习实验
  • 5 个下游 Benchmark、2,207 个独立下游实例
  • Hidden evaluation tasks：从 development set 中分离 withheld，Agent 开发阶段完全不可见

关键设计原则

  1. Creator ≠ Executor 分离：构建 Harness 的 LLM 和执行下游任务的 LLM 可以是不同模型，这样能独立测量「构建能力」和「执行能力」
  2. Infrastructure as Artifact：Harness 是可持久化、可检查、可重用的代码产物，而非一次性输出
  3. Execution Feedback 作为进化信号：Agent 不只看到最终分数，还看到执行 trace（哪里出错、什么错误类型），使其能够诊断结构性问题

关键实验与数据

Creation 阶段：生成的 Harness 质量分布

领域 与成熟人工参考 Harness 的比较
代码 显著落后于成熟人工参考
搜索与研究 显著落后于成熟人工参考
写作 匹配或超越选定的参考 Harness
机器学习实验 匹配或超越选定的参考 Harness

解读：LLM 生成的 Harness 在需要强结构化推理（代码执行、搜索规划）的领域差距明显，而在相对开放、容错性高的领域（写作、ML experiment）表现更接近人工设计。

执行成本：不同 Creator LLM 生成的 Harness 在 token 成本上差异巨大，说明生成的 Harness 效率参差不齐。

Evolution 阶段：改进的稳定性

  • 部分场景有提升：Evolution 能带来一定性能改进
  • 不稳定：改进在 hidden tasks 上部分迁移，不是完全泛化
  • 模型依赖：当固定 runtime model（执行下游任务的模型）而只改变 Creator 时，进化收益高度依赖于执行模型的型号，说明「哪个模型在跑」对 Harness 效果影响极大
  • 跨模型迁移有限：一个模型进化出的 Harness 迁移到另一个模型时，收益大幅缩水

Harness vs 任务输出的本质差异

Harness 编辑与普通代码编辑有一个根本区别：Agent 在修改自己的执行 substrate——这个 substrate 决定了 Agent 未来所有任务中的观察、规划和恢复方式。有效改进 Harness 要求 Agent： 1. 从执行 trace 中识别自身行为局限 2. 诊断系统结构性瓶颈 3. 做出有持久效益的针对性变更，而非临时打补丁

这比修复普通代码要复杂得多，因为反馈回路更长、因果关系更间接。

亮点与局限

亮点

  1. 评测单元的范式转变：首次将「Harness 质量」作为可量化的评测对象，把 Agent 研究从「任务刷分」推向「基础设施自建」的新层次
  2. 两阶段设计精巧：Creation 测「从零构建能力」，Evolution 测「持续改进能力」，两个阶段互补完整
  3. Creator/Executor 分离设计：允许独立测量构建能力和执行能力，为分析不同 LLM 的专长提供了结构性工具
  4. 涵盖效率维度：不只测能力提升，还测 token 成本，对实际部署有直接指导意义
  5. 揭示跨模型迁移瓶颈：发现进化收益高度依赖 runtime model，说明当前 Harness 进化缺乏真正的 domain-agnostic 泛化能力

局限

  1. Creator Agent 可能借助了人类帮助：部分实验在构建 Harness 过程中有辅助输入，未完全隔离纯 Agent 贡献
  2. 领域覆盖有限：4 个领域虽有一定代表性，但日常对话、多跳推理等重要场景缺失
  3. Reference Harness 选择：人工参考 Harness 的选择可能存在偏好，影响相对比较的公平性
  4. 进化收敛性未知：Evolution 阶段是否趋于收敛还是会在局部震荡，论文未深入讨论
  5. 极新论文：2026年9月1日发布，无第三方复现，下游应用数据空白

对工程落地的启发

1. Harness 设计是 Agent 能力的放大器

14.4 个百分点的性能差距（GPT-5 + Terminus 2 vs GPT-5 + Codex CLI）说明：对于生产级 Agent 系统，Harness 的工程质量可能是比模型选择更高杠杆的投资方向。工程实践：在选模型之前先评估候选 Harness 是否适合目标场景。

2. 代码/搜索类任务的 Harness 壁垒最高

HarnessDev 显示 LLM 生成的 Harness 在代码和搜索类任务上与人工成熟系统差距最大，意味着这些领域对 Harness 质量更敏感，也更需要专业 Harness 工程师介入。工程启示：对代码 Agent，不建议让模型自主生成 Harness，而应该使用经过验证的成熟框架。

3. 写作/ML 实验类任务可考虑 Agent 自调 Harness

在相对开放的任务类型上，LLM 生成的 Harness 能匹配甚至超越人工参考。这类场景可以探索让模型自主调优 Harness（如自动调整 tool 定义、prompt 策略），减少人工维护成本。

4. Evolution 的不稳定性需要安全护栏

Evolution 阶段的改进可能破坏已有功能（回归问题），且改进不一定泛化到新任务。生产系统中如果引入 Harness Evolution，必须配备： - 自动回滚机制（当新 Harness 在验证集上性能下降时） - 分阶段灰度发布（先在部分流量上验证） - 独立的外部评估层（不被 Agent 的自我评估牵着走）

5. Runtime Model 与 Harness 的耦合是现实约束

实验发现 Harness 的收益高度依赖 runtime model，意味着同一个 Harness 不一定能「一次构建，跨模型复用」。这在多模型路由或模型升级场景中需要重新验证 Harness 效果，不宜过度假设通用性。

与同方向工作的关系

工作 与 HarnessDev 的关系
ASPIRE (2608.31111，同团队) ASPIRE RQ3 已经触及 Harness 进化问题，HarnessDev 是其独立深化——ASPIRE 测的是 Harness 进化对任务性能的影响，HarnessDev 测的是 Harness 本身的可构建性和可改进性
Evo-Bench (2608.09096) 同样研究 Harness 进化，但 Evo-Bench 关注 LLM 作为「进化者」能否找到更好的通用 Agent 设计；HarnessDev 关注「从零构建」和「持续维护」的全生命周期
Pan et al. 2026 / Ning et al. 2026 理论层面研究 Harness 表征，HarnessDev 提供了系统性评测框架
Rethinking Harness Evolution (2607.12227) 指出当前 Harness 进化方法中 unit test 和 benchmark 耦合导致的 overfitting 问题；HarnessDev 用 Creation/Evolution 两阶段和 hidden evaluation tasks 部分缓解了这个担忧
Terminal-Bench / CLI benchmarks 是 HarnessDev 的下游评测工具之一，HarnessDev 的贡献在于把「哪个 Harness 更好」的问题变成了「模型能否自己造出好 Harness」的问题

HarnessDev 与 ASPIRE 同属 ByteDance Seed 团队，是该团队「Self-Developing Agents」研究线的两个核心 Benchmark——ASPIRE 聚焦目标操作化，HarnessDev 聚焦基础设施自建，共同指向同一个核心问题：当前 LLM Agent 的自主性边界在哪里。

适合谁读

  • Agent 系统工程师：尤其是负责 Agent 架构、Harness 设计、工具调用框架的工程师
  • LLM/Agent 研究者：Self-Evolution、Agent Benchmark 设计方向
  • AI Platform / Infra 工程师：关注如何让 LLM 自主改进执行系统的可靠性
  • AI 产品经理：评估「让 Agent 自主优化」是否适用于自己的场景（建议：代码/搜索类慎重，写作/ML 实验类可以探索）
  • 自动驾驶（Agentic AI）研究者：关注 Agent 能否持续自主改进执行系统的长期能力

关键不确定处

  • 原文未明确披露各 Creator LLM 的具体型号和各领域的绝对性能分数，横向比较只能依赖定性描述
  • 「成熟人工参考 Harness」的具体实现细节未公开，相对比较的公平性存疑
  • Creation 阶段中人类辅助的具体形式和程度未完全透明，可能影响对「纯 Agent 构建能力」的判断
  • 4 个领域中选择哪些具体下游 Benchmark 及其代表性未充分论证
  • 极新论文（2026年9月1日），尚无第三方独立复现和工程落地案例

工程落地与核查（Jay）

事实核查

  • ⚠️ GPT-5 存疑：「GPT-5 + Terminus 2 35.2% / Codex CLI 49.6%」作为全文最关键定量证据，截至 2026-09-03，GPT-5 尚未正式发布（GPT-4o 为最新公开模型）。此数字可能为论文内部代号或假设性实验配置，非公开可验证数据；解读中未标注「⚠️ 待核实」，属原解读漏标，本节补标。
  • ✅ 14.4pp 差值：原文核心论点，数字来源与实验设置对应，无内部冲突。
  • ✅ Creation/Evolution 两阶段框架：与 dair.ai 摘要一致，描述准确。
  • ✅ 4领域 × 5 Benchmark × 2,207 实例：dair.ai 摘要确认，数据粒度一致。
  • ⚠️ 无 GitHub 仓库：全文未引用代码实现；6 个 Creator LLM 具体型号未披露——两者均影响工程复现。

可读性精修

  1. 术语统一：全文混用「Agent」和「LLM Agent」，建议统一为「LLM Agent」；「Harness」全程大小写一致（已统一大写），无问题。
  2. 逻辑链补强：「关键证据」段落中，「GPT-5 + Terminus 2 vs Codex CLI」差值之后紧跟「但现有 Agent 评测几乎只报……」——两者之间缺乏直接桥梁，应补一句：「这意味着 Harness 质量本身就足以造成 14.4pp 的任务性能差异」，才能让「HarnessDev 填补空白」的结论更顺畅。
  3. 量化精度：Abstract 中「14.4 个百分点」正文写成「14.4 个百分点」，但「percent point」是标准化表达，建议统一为「pp」或「个百分点」避免歧义。

工程落地：实际系统怎么用

适用场景判断树：

任务类型是代码或搜索类？
  ├── 是 → 不建议自主生成 Harness，使用成熟框架（LangChain Agents / AutoGPT / SGLang）
  └── 否（写作 / ML 实验 / 开放域）
        └── 可探索 Agent 自调 Harness，降低维护成本

核心工程路径：

  1. 评估阶段：先用 HarnessDev 框架对自己的场景做基线测量——用同一模型分别在自研 Harness 和成熟 Harness 下跑同一 Benchmark，记录任务成功率差距；若差距 >10pp，说明 Harness 选型是瓶颈。
  2. Creation 落地：参考 HarnessDev 的 Creator LLM 提示词工程（seed harness + development cases + 任务抽象描述），在写作类/ML 实验类任务上试验性让模型生成初始 Harness；代码类任务强烈不建议。
  3. Evolution 落地：若引入持续改进，必须配套三重护栏：① 自动回滚（保存历史版本，验证集性能下降即触发）；② 灰度流量（5% → 20% → 100%）；③ 外部独立评估（不被 Agent 自我评分主导）。
  4. 多模型场景：同一 Harness 在换模型后必须重新跑完整 Benchmark，不假设跨模型泛化；尤其在模型升级节点（GPT-4 → GPT-4o 类似场景）必须做 Harness 回归测试。

已知坑点：

  • 回归陷阱：Evolution 改进 Harness 时容易破坏已有功能，必须有完整端到端测试覆盖。
  • 跨模型失效：论文已量化，跨模型迁移收益大幅缩水；实践中不要把"某模型进化出的 Harness"直接迁移给另一个模型。
  • token 成本方差大：不同 Creator 生成的 Harness 效率差异巨大，选型时必须同时测任务质量和 token 成本。
  • 人类辅助干扰：Creator 阶段部分 Harness 借助了人类帮助，生产环境中若去掉辅助需重新评估能力边界。