HarnessDev：LLM 能否自己构建并迭代 Agent Harness？ · 干货攻略

  • 链接: https://arxiv.org/abs/2609.01437
  • 分类: x-tips
  • 来源: X @omarsar0
  • 作者: Jay
  • 更新: 2026-09-07
  • 仓库: 无（项目页 https://self-developing-agents.github.io/；X 帖所附 ByteDance-Seed/HarnessDev 返回 404，核验后该仓库不存在，以官方项目页为准）

⚠️ 仓库说明：原帖链接指向 ByteDance-Seed/HarnessDev，但该 GitHub 仓库不存在（404）。官方资源为 arXiv 论文及项目页，以下内容均来自这两个来源。

这是什么

HarnessDev 是 ByteDance Seed（联合新加坡理工大学、佐治亚理工、M-A-P、TokenWave.AI 等机构）于 2026 年 9 月 1 日发布在 arXiv（arXiv:2609.01437）的基准测试，核心问题不再是「模型任务输出好不好」，而是「模型能否构建和维护自己的执行基础设施（harness）」。

传统 Agent 评估把 harness 当成固定配置，只测模型在给定 harness 下的任务完成率。HarnessDev 翻转了这一点：把 harness 本身当作被评估的对象。模型要从一个「弱但可运行」的种子 + 少量案例出发，构建出能在未知任务上复用的完整执行系统。

Benchmark 分两个阶段：

  • Creation（构建）：从 minimal seed + few-shot cases 建出完整 harness
  • Evolution（迭代）：用下游执行反馈持续改进已建好的 harness，目标提升 benchmark 表现

评估维度两条：Capability（在 held-out 任务上的成功率）和 Efficiency（执行 token 消耗）。

为什么值得关注

这条被多人同步转推，核心价值在于它揭示了一个被长期忽视的事实：harness 的选择对模型表现影响极大。论文给出了一个具体数字：

相同模型权重，GPT-5 在 Terminal-Bench 2.1 上：Terminus 2.0 内得分 35.2%，Codex CLI 内得分 49.6%——差距超过 14 个百分点。

这说明当前 agent 能力有很大一部分其实来自 harness 工程，而非模型本身。这直接解释了为什么「换了个框架分数就掉了」——不是模型变差了，是 harness 在影响它看到什么、怎么行动、如何恢复。

对于所有在实际项目中做 agent 选型或自建 agent 平台的团队，这条结论非常重要：评估模型时必须控制 harness，否则结论不可迁移。

同时，这篇论文踩坑的结果对想做 self-improving agent的人来说是难得的实战复盘：

  • Evolution 阶段产生了性能提升，但不稳定，且对 held-out 任务泛化有限
  • 在固定 runtime model（Gemini）下做四组实验，只有 Opus 在 held-out 任务上超越了自己的 H₀，其余三个模型全部回归（regression）
  • 进化增益取决于哪个模型在执行这个 harness——跨模型迁移效果很差

这些结论是真实实验数据，不是猜测，对任何在做 agent 迭代框架的人都值得一读。

核验过程

已读官方来源：

  1. arXiv abstract（https://arxiv.org/abs/2609.01437）——获取了完整摘要、作者列表（Yuhao Wu 等 19 人）、提交时间（Sep 1, 2026）、DOI 链接
  2. arXiv HTML 全文（https://arxiv.org/html/2609.01437）——获取了 Introduction、Background、Method（Creation + Evolution 框架）、Findings 等核心章节内容
  3. 项目主页（https://self-developing-agents.github.io/）——获取了 Three questions 框架、三个 benchmark 的关联关系、关键实验数据（Aspire / S³Gym / HarnessDev 的具体数字）

交叉验证结论：

说法（来自 X 帖） 官方来源 核验结果
「6 个 Creator LLM × 4 领域 × 5 基准，2,207 唯一实例」 arXiv abstract 原文一致 ✅ 确认
「code / search & research 落后人工系统；writing / ML experimentation 匹配或超越」 arXiv HTML Section 1 原文一致 ✅ 确认
「Evolution 增益不稳定、依赖 runtime model」 项目页原文一致 ✅ 确认
「HarnessDev 是 ByteDance Seed 出品」 作者 affiliation + 项目页双重确认 ✅ 确认
「ByteDance-Seed/HarnessDev 仓库」 GitHub 404，实际不存在 ❌ 以官方项目页为准

上手指南

1. 理解核心概念：什么是 Agent Harness

Harness = Agent 的执行脚手架，包括：

  • 执行循环（execution loop）
  • 工具调用（tool use）
  • 上下文管理（context management）
  • 持久状态（persistent state）
  • 生命周期控制（lifecycle control）
  • 结果验证（verification）

换句话说：harness 是模型权重之外决定 agent 行为的所有代码和配置。同一个模型，换个 harness，分数可以差 14 个百分点（GPT-5 / Terminal-Bench 数据）。

2. 理解 HarnessDev 的两个阶段

Creation 阶段——考察从零构建能力：

输入：minimal seed（弱但可运行）+ 少量 development cases + 任务规格
输出：一个完整、可冻结、可复用的 harness
评估：在 held-out 任务上跑，报告 capability + efficiency

Evolution 阶段——考察持续迭代能力：

输入：Creation 阶段输出的 harness
信号：下游任务的执行反馈（成不成功、消耗多少 token）
输出：harness 的改进版本（多次 revision）
评估：改进版在 held-out 任务上的表现是否稳定提升，跨 runtime model 是否可迁移

3. 关键实验发现（可直接引用的数据）

Creation 结果： - 代码、搜索与研究类 harness：自建 harness 明显落后于成熟人工系统 - 短文本写作、机器学习实验类 harness：自建可匹配或超越人工参考系统 - 不同 creator 模型建出的 harness 在 downstream 性能和 token 消耗上差异巨大；token 消耗高不等于效果好

Evolution 结果： - 性能提升不稳定：在开发集上看到的收益到 held-out 任务上变小了、不一致了 - 跨 runtime model 迁移差：固定用 Gemini 作为 executor，四组中只有 Opus 的最终版本在 held-out 上超过自己的基线 - 实际意义：模型可以做有用的局部改进，但「稳健的跨任务、跨 runtime 进化」仍是 open challenge

4. 对实践者的直接启示

评估建议： - 评估 agent 模型时，harness 必须固定或一同报告；否则结论只在那个 harness 下有效 - 用「同一 harness 换模型」或「同一模型换 harness」分别做两条横向对比，分离两者的贡献

开发建议： - 如果你在构建自己的 agent 平台，harness 工程和模型选型同样重要 - Evolution 阶段的结论意味着：盲目相信「多迭代几次 harness 会自动变好」是危险的；做好版本管理和回滚

系统设计建议： - 从这篇论文的角度，agent harness 是一个应该被独立版本化、冻结测试后再上线的 artifact，而不是每次任务实时生成的临时配置 - 如果你在设计 agent 迭代框架，建议分离「开发 harness 的模型」和「执行 harness 的模型」，参考 HarnessDev 的 creator/executor 分离设计

坑与适用边界

1. 这是一篇 preprint，尚未经过正式学术 peer review 目前是 arXiv v1，2026 年 9 月 1 日刚提交。数据来自第一版结果，细节数字（如各模型的绝对分数）可能随更新调整，引用敏感数字时建议注明版本。

2. Evolution 增益不稳定，不等于「self-improving agent 已经成功」 论文结论是悲观的：当前模型可以局部改进 harness，但可靠的跨任务泛化还没做到。避免过度解读为「模型能自主进化自己的执行系统」。

3. 没有公开 GitHub 仓库 原帖提供的 ByteDance-Seed/HarnessDev 仓库不存在，无法直接跑代码。如果需要复现，需联系作者或等待官方发布。

4. 执行 token 消耗数据分散在不同 creator 模型间 论文没有在摘要/简介中给出各模型的具体 efficiency 数字，需要读完整论文的实验部分才能拿到。

5. 适用场景限制 - 适用：评估/比较 agent harness 方案；设计 self-improving agent 迭代框架；理解模型与 harness 的耦合关系 - 不适用：直接拿来评估模型任务表现（那是传统 benchmark 的职责）；直接做 product 选型（实验室设置和真实部署差异大）

一句话结论

HarnessDev 用实验数据证明：Agent 能力 = 模型能力 × Harness 质量，两者缺一不可；而当前模型的 self-evolving harness 能力在代码/研究类任务上仍明显落后人工系统，且进化增益不稳定、跨模型几乎不迁移——自建 harness 是值得投入的方向，但「模型自动构建生产级 harness」的时代还没到来。

主要来源 - arXiv:2609.01437 · "Can LLMs Create and Evolve Their Own Agent Harness?" · Yuhao Wu et al. · ByteDance Seed · 2026-09-01 - https://self-developing-agents.github.io/ · 项目主页（含 Aspire / S³Gym / HarnessDev 三 benchmark 关联数据） - https://arxiv.org/html/2609.01437 · 论文全文（Introduction / Background / Method / Findings）