一句话总结

来自字节跳动 Seed、新加坡科技设计大学、佐治亚理工学院及其合作者的研究人员提出了 HarnessDev，这是一个将大语言模型评估从任务输出转向模型创建和演化自身 agent 执行 harness 能力的基准，结果表明，尽管生成的 harness 在写作和机器学习实验任务上达到或超过人工设计的参考水平，但在代码和搜索方面仍显落后，且演化增益不稳定，跨模型迁移能力有限。

核心贡献

• HarnessDev 是一个基准，用于评估语言模型 agent 通过从最小种子进行 Creation 以及通过下游反馈进行 Evolution 来构建和改进可运行执行基础设施的能力，涵盖四个领域的 2,207 个实例和五个隐藏评估基准。
• 在 Creation 实验中，六个前沿语言模型生成的 harness 在写作和机器学习任务上达到或超过人工设计的参考水平，但在代码和搜索方面落后，且执行成本差异很大。
• Evolution 结果显示性能增益有限且不稳定，仅部分迁移到留出任务上，并且强烈依赖于执行模型，表明跨模型泛化能力较弱。

引言

随着基于 LLM 的 agent 进入实际部署，其周围的执行基础设施（即 agent harness）极大地影响着其有效性；即使模型权重相同，不同的 harness 也可能导致下游性能显著不同。大多数 agent 评估将 harness 视为固定的实验配置，而非需要开发的人工产物，这导致在衡量模型构建和迭代改进自身可运行执行系统的能力方面存在空白。作者提出了 HarnessDev，这是一个将评估从任务输出转向 harness 本身的基准，通过评估模型是否既能从弱种子创建 harness，又能利用反馈持续演化它，同时衡量能力、效率和跨运行时模型的迁移性。

数据集

HarnessDev 基准是一组下游任务实例，用于评估模型构建和改进执行 harness 的能力，而非用于训练模型本身。数据集的组成和使用方式如下：

• 总体规模与来源：该基准包含 2,207 个唯一的下游实例，来自四个领域的五个基准（详见论文表 2）。作者重点关注 Evolution 阶段的两个代码领域基准：SWE-Pro 和 Terminal-Bench。这些是成熟的开源任务套件；论文固定了它们的版本和许可证。

• SWE-Pro 子集：

  • 在 Creation 阶段使用公开划分的 731 个实例，模型从未见过完整集合，仅接收每个任务族 1-3 个开发案例。
  • 从该公开划分中，指定一个固定的 100 个任务子集作为 Evolution 阶段的反馈集。其余 630 个实例构成留出划分，仅用于衡量 harness 开发后的泛化能力，且从未展示给创建者。

• Terminal-Bench 子集：

  • 所有 89 个任务在 Evolution 阶段用作反馈集。未提及单独的留出划分；这些任务作为该阶段的开发信号。

• 数据使用方式：

  • Creation (RQ1)：模型接收任务族规范、弱种子 harness 和 1-3 个开发案例。它必须构建一个能泛化到未见任务的 harness。该 harness 被冻结，并在完整的下游基准（包括 SWE-Pro 公开划分和其他领域任务）上进行评估。
  • Evolution (RQ2)：从自身冻结的 Creation harness 开始，模型接收 100 个任务的 SWE-Pro 反馈集和所有 89 个 Terminal-Bench 任务的执行结果。它利用这些结果改进 harness。每次改进后，harness 被冻结，并在两个反馈集上（用于在线适应得分）以及至关重要的 630 个留出 SWE-Pro 实例上（用于泛化得分，从未展示给模型）进行评估。允许十次完整评估对的预算，其间可进行有限的诊断探测。

• 处理与元数据：不进行裁剪或数据增强。harness 必须产生结构化产物（轨迹、日志、结果），由预定义的评估器 J 评分。开发环境提供可变的 workspace，种子 harness 仅提供兼容层（解析、工具访问、产物写入），不包含 agent 逻辑，确保任何非零得分均来自创建者的添加。

方法

作者提出了 HarnessDev，这是一个旨在评估模型开发的执行系统而非其为单个任务产生的答案的基准。核心流水线涉及创建者 LLM $L_C$LC​ 在开发环境 $D$D 中工作，以产生可运行的 harness $H$H。一旦 $H$H 被冻结，执行者 LLM $L_E$LE​ 在其中对下游任务 $x$x 运行，评估器 $J$J 对结果输出 $y$y 进行评分。该过程形式化为：

$$(L_C, D) \to H, \qquad (H, L_E, x) \to y \xrightarrow{J} \text{score}.$$(LC​,D)→H,(H,LE​,x)→yJ​score.

为了衡量模型能否从头设计执行系统，作者为每个创建者提供了一个弱种子 harness $H_{seed}$Hseed​。该种子充当可运行的兼容层，而非任务求解 agent。它解析任务和模型配置，暴露允许的低级工具，并写入所需的结果、轨迹、日志和任务产物。关键是，种子缺少 agent 循环、任务分解、工具策略、上下文管理、持久任务状态、验证器、重试或恢复逻辑以及停止规则。未经修改时，它产生空或部分产物，并在下游基准上得分为零。

如上框架图所示，弱种子提供了统一的输入契约和公开的开发循环。创建者 agent 可以利用来自公开任务的可见反馈修改 harness，而隐藏的评估任务、答案和官方得分保持不可访问。种子暴露了被动原语，如路径、文件、搜索、进程、LLM 网关和产物 I/O，但这些是可用的但未被编排。

为了将弱种子转变为功能系统，创建者必须实现一个全面的控制层。

如下图所示，创建的可运行 harness $H$H 集成了由创建者实现的控制平面。该控制平面由六个关键模块组成：循环（E）、工具（T）、上下文（C）、状态（S）、生命周期（L）和验证（V）。这六个机制共同治理 harness 执行核心内的下游任务执行。完成的 harness 通过统一的审计契约进行报告，生成诸如 result.json、trajectory.json、response.md 和运行时日志等产物。领域终结器随后将运行映射为领域权威评分器可读的产物，该产物因领域而异（例如，代码仓库状态、数据或 MLE 提交、写作散文或带有引用证据的搜索答案）。

该基准研究了 harness 开发的两个阶段。在 Creation 阶段，创建者接收弱种子 $H_{seed}$Hseed​、任务族规范、工具和权限约束、设计教程以及一到三个开发案例。它利用这些案例的反馈修改 harness，以构建能泛化到未见任务的基础设施。生成的 harness $H$H 在评估前被冻结。在 Evolution 阶段，创建者从自身冻结的 Creation harness $H_0$H0​ 开始。在开发过程中，它接收来自固定反馈集的结果。控制器在基准上评估 $H_0$H0​，每个 $H_0$H0​ 之后的官方候选被冻结并作为一对评估提交。创建者获得 $H_0$H0​ 之后完整评估对的预算，并可在计费对之间使用固定子集探针进行诊断。泛化能力在冻结后，在开发循环中从未展示给创建者的留出实例上单独衡量。

实验

HarnessDev 基准评估 LLM 从最小种子构建并迭代改进执行 harness 的能力，将 harness 设计与单任务求解隔离开来。Creation 实验表明模型能够构建功能性 harness，但性能因领域而异，存在诸如死代码和执行器特定过拟合等常见陷阱。基于下游反馈的 Evolution 仅产生适度的、通常过拟合的增益，且 harness 改进很少能跨执行器或留出任务泛化，凸显了开发稳健、可复用基础设施的难度。

Harness 开发在两个阶段进行评估：Creation，模型从最小种子构建执行系统；Evolution，模型利用下游任务的反馈改进该系统。Creation 性能因领域而异，而 Evolution 是非单调且嘈杂的，可见反馈通常无法预测留出质量。Creation 从仅提供兼容层的弱种子开始，因此任何非零得分完全来自创建者添加的执行逻辑。Evolution 使用指定反馈集的结果，但改进经常被后续更改抹除，且更多更新并不能保证更好的最终 harness。可见反馈得分与留出性能仅在约一半的情况下同向变动，创建者声明的最佳版本很少与实际留出最优版本相符。在自我评估下，模型在写作和机器学习实验方面达到或超过人类性能，但在搜索、研究和代码方面仍远远落后。在 Evolution 过程中仅更换执行器就可能大幅改变基线，并改变哪些 harness 修改被证明有用。

Creation 基准涵盖四个领域，共 2,207 个任务，分布在五个下游评估中。重点是通过 SWE-bench Pro 和 Terminal-Bench 的代码领域，但也涵盖数据分析、写作和研究。性能因领域而异，模型仅在写作和机器学习实验方面达到或超过人类参考水平，而在其他方面落后。Creation 包含 2,207 个唯一实例，分布在代码（731 个 SWE-bench Pro，89 个 Terminal-Bench）、数据分析（75 个 MLE-bench）、写作（46 个 EQ-Bench3）和研究（1,266 个 BrowseComp）中。代码任务在套件中占主导地位，以任务成功作为主要指标，而其他领域使用准确率、评分量规得分或奖牌得分。在自我评估下，模型在写作方面与人类参考持平，在机器学习实验方面超越人类，但在搜索、研究和代码方面仍远远落后。

在自我评估下，harness 质量因领域而异，Opus 4.8 取得了最高的平均分（67.8），但仍落后于人工设计的系统（86.2）。写作 harness 接近参考水平，而搜索和代码任务差距最大，超过四分之三的失败数据任务归因于 harness 缺陷而非执行器限制。实现风格和编辑量并不决定成功：Gemini 3.1 Pro 以最少的添加行数取得了最佳的 Terminal-Bench 得分（68.8），表明聚焦的、经过验证的更改比代码量更重要。Opus 4.8 在自我评估的创建中领先，平均得分为 67.8，但仍远低于人类系统级得分 86.2。生成的写作 harness 几乎与人类性能持平，而搜索和代码 harness 远远落后，77.8% 的数据任务失败源于 harness 缺陷。Gemini 3.1 Pro 仅添加了 1,006 行，却取得了最高的 Terminal-Bench 准确率（68.8），表明紧凑、经过验证的编辑可以胜过更大的重写。

在固定的 Gemini 执行器下，harness 创建性能因领域和创建者而异。Gemini 自身的 harness 取得了最高的平均成功率，而其他创建者表现出领域特定的优势，部分 harness 包含损害性能的产物，如折叠的副本。Harness 缺陷是主要瓶颈，小而经过验证的编辑可以胜过更大的代码添加。Gemini 的 harness 在固定执行器评估下取得了最高的平均成功率（55.6），其次是 Opus（53.3）和 Qwen（52.8）。移除 Opus 的 SWE-Pro harness 中的折叠副本，其得分将从 33.0 提升至 49.1；对于 DeepSeek，SWE-Pro 从 29.2 提升至 43.8，Terminal-Bench 从 38.2 提升至 57.3。GPT-5.5 的 EQ-Bench3 均值在排除一个零值初始 harness 后从 46.5 跃升至 69.7，显示出对单个糟糕生成的高度敏感性。Harness 缺陷导致了 77.8% 的失败数据任务，使 harness 设计成为比执行器能力更关键的瓶颈。一个在 Self-Eval 下表现良好的 Opus Code harness，在固定的 Gemini 执行器下几乎崩溃，原因是硬编码的 120 步限制，这说明了跨执行器的脆弱性。Gemini 在所有创建者中添加的代码行数最少，却在 Terminal-Bench 中领先，表明聚焦的、经过验证的更改可能比大量代码添加更有效。

代码 harness 产物在净添加行数上表现出很大差异，但编辑规模并不能预测下游性能。Gemini 3.1 Pro 编写的代码最少，却取得了最高的 Terminal-Bench 得分，而 Seed 2.0 Pro 编写的代码多得多，却在两个基准上得分最低。Gemini 3.1 Pro 在其三个代码产物中仅添加了 1,006 净行，Terminal-Bench 得分达到 68.8，而 Seed 2.0 Pro 添加的行数是其三倍多（3,294），得分仅为 6.0。在净代码行数相近（约 3,200–3,500）的高行数创建者中，SWE-Pro 得分从 10.8 到 33.5 不等，证实代码更改量并不决定 harness 质量。

该评估将 harness 开发分为 Creation 阶段（模型从最小种子构建执行系统）和 Evolution 阶段（模型利用任务反馈迭代改进它）。自我评估的创建性能因领域而异，模型仅在写作和机器学习实验方面达到或超过人类参考水平，而在搜索、研究和代码方面仍远远落后，且 harness 缺陷是主要的失败来源。代码编辑量并不能预测下游质量，因为紧凑、经过验证的更改可以胜过更大的重写，并且 harness 表现出跨执行器的脆弱性，可能在不同运行时条件下导致性能崩溃。