EADST

最近读了论文 HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?。这篇工作的关注点很有意思：它不再问“模型能不能完成某个任务”，而是把评测对象向外移动了一层——模型能不能构建并持续改进承载自己的 Agent Harness。

• 论文：HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?
• PDF：arXiv PDF
• 项目主页：Self-Developing Agents

这里的 Harness 不是一段 System Prompt，而是完整的模型外部执行系统，包括 Agent Loop、工具调用、上下文管理、状态记录、故障恢复、停止条件和结果验证。论文最终给出的答案比较克制：

当前 LLM 已经可以从弱空壳开始写出可运行的 Harness，但距离成熟的人工系统仍有差距；它也能根据反馈改进 Harness，只是这种改进不稳定，而且很容易绑定特定模型或过拟合开发集。

图 1：HarnessDev 将 Harness 开发拆成 Creation 和 Evolution 两个阶段。图源：原论文 Figure 1。

Harness 本身也是 Agent 能力的一部分

通常讨论 Agent 能力时，我们很容易把结果归因于底层模型。但相同模型放进不同 Harness，表现可能相差很大。

论文举了一个很直观的例子：在模型权重不变的情况下，GPT-5 在 Terminus 2 中的 Terminal-Bench 2.1 成功率为 35.2%，放到 Codex CLI 中则达到 49.6%。模型没有变，变化的是执行循环、工具协议、上下文组织和验证机制。

因此，一次 Agent 运行更接近下面这个过程：

• Creator LLM 在开发环境中构建 Harness；
• Harness 冻结后，由 Executor LLM 在其中执行任务；
• Evaluator 根据实际产物评分，而不是相信 Agent 自己报告的“任务成功”。

这一区分很重要。一个 Harness 可能代码结构完整，却没有真正调用状态模块；也可能在创建者模型上工作良好，换一个模型就因为工具格式、步数预算或停止规则不同而崩溃。只看最终任务分数，很难判断问题究竟出在模型、Harness，还是两者的适配关系上。

HarnessDev 怎么评测

HarnessDev 把开发过程分成两个阶段。

Creation：从弱 Seed 构建完整 Agent

模型拿到一个可以运行、但完全不会做任务的 Seed Harness。它只负责解析输入、暴露文件和进程等底层工具，以及写出日志和结果文件，不包含：

• Agent 执行循环；
• 任务分解和工具策略；
• 上下文与持久状态管理；
• 验证、重试和故障恢复；
• 停止条件。

Creator LLM 需要根据任务说明和 1～3 个开发样例补齐这些能力。完成后，Harness 会被冻结并用于隐藏任务评测。

Creation 覆盖 6 个 Creator LLM、4 类任务和 5 个 Benchmark：

• Code：SWE-bench Pro、Terminal-Bench 2.1；
• Data / ML：MLE-bench；
• Writing：EQ-Bench3；
• Search / Research：BrowseComp。

总计包含 2,207 个不同的下游任务。评测同时关注两件事：任务完成质量和Executor 消耗的 Token 数量。

Evolution：让模型继续改进自己的 Harness

Evolution 阶段从 Creator 自己生成的 Code Harness 开始。模型可以读取 SWE-Pro 和 Terminal-Bench 反馈，分析失败、修改 Harness、重新评测，再从多个版本中选择一个最终版本。

为了检查模型是在真正改进通用能力，还是只记住了可见反馈，作者又准备了 630 个不会返回给 Creator 的 SWE-Pro held-out 任务。最终可以分别观察：

• 可见反馈集是否提升；
• 未见任务是否同步提升；
• 换成另一个 Executor 后改进是否仍然成立。

这个设计很像真实的软件迭代：修复一次失败并不难，难的是不引入回归，并确保修复可以迁移到更多任务和运行环境。

实验里最值得注意的几个结果

1. LLM 可以造出 Harness，但不同领域差异很大

在 Self-Eval，也就是 Creator 使用自己构建的 Harness 执行任务时，Opus 4.8 的综合得分最高，为 67.8；论文选择的人工系统参考为 86.2。

分领域看更有意思：

• SWE-Pro：69.3，对应人工参考 80.0；
• Terminal-Bench：64.8，对应人工参考 88.8；
• EQ-Bench3 写作：84.6，对应人工参考 83.7；
• BrowseComp 搜索研究：52.4，对应人工参考 92.2；
• MLE-bench：Opus 达到 32.9，人工参考为 24.0。

也就是说，模型生成的 Harness 在短文本写作和机器学习实验上已经可以接近甚至超过所选参考，但在长流程代码任务和搜索研究上仍有明显差距。

图 2：不同领域中的 Self-Eval 结果相对人工系统参考的比例。图源：原论文 Figure 4。

这里需要注意，人工结果来自不同的 Harness–Model 组合，并不是同一个 Executor 下的严格对照。因此“超过参考”不能理解成超过了人类能力，只能说明超过了论文选取的那个公开系统结果。

2. Harness 会过拟合创建它的模型

论文设置了 Unified-Eval：让所有生成的 Harness 都使用固定的 Gemini 3.1 Pro 作为 Executor。结果显示，换模型之后排名和性能会发生很大变化。

最明显的是 Opus 构建的 Code Harness：

• SWE-Pro 从 Self-Eval 的 69.3 降到 33.0；
• Writing 从 84.6 降到 74.2；
• 一个 Code Harness 因为围绕原 Executor 写死了 120 步限制，换成 Gemini 后几乎失效；
• Search Harness 的重复查询率从 10.1% 上升到 88.2%。

这说明 Harness 虽然是外部程序，却可能和特定模型共同适配。Prompt 写法、工具调用格式、上下文预算和停止条件，都可能隐式依赖创建它的模型。

图 3：实心点为 Self-Eval，空心点为固定 Gemini Executor 后的结果。图源：原论文 Figure 6。

对实际开发来说，这意味着“支持多个模型”不能只验证 API 接口兼容。一个 Harness 能跑起来，不代表它能保留原来的能力。

3. 写得更多、调用得更多，不一定更强

18 个 Code Harness 总共新增了 17,111 行代码，但代码规模与下游性能没有明显关系。Gemini 创建的 Harness 新增代码最少，却取得了最好的 Terminal-Bench 结果之一。

Token 成本也类似。在 MLE-bench 上，不同 Harness 的消耗相差约 19 倍，但更高的 Token 消耗并不稳定地带来更高分数。

另一个有意思的发现是“看起来存在”和“真正执行”之间的差距。论文分析的 108 个 Code 组件实例中：

• 72 个在实际运行中触发；
• 18 个只有部分证据；
• 18 个完全没有被观察到。

这些未触发的组件全部与状态和记忆有关。也就是说，模型很会写出一个结构上完整的 Agent 项目，但其中不少模块只是摆设或死路径。

Self-test 数量与最终得分的相关性也只有 0.13～0.26。相比之下，根据失败结果进行修改的 revision call，与性能的相关性达到 0.57。关键不是“测了多少次”，而是有没有：

1. 读懂失败；
2. 定位具体原因；
3. 做针对性修改；
4. 重新完成端到端验证。

Evolution 有效，但还远称不上“自我进化”

在可见反馈集上，所有 Self-runtime Creator 都能让最终版本获得提升；但换到 held-out 任务后，提升明显缩小，只剩下约 +1.43～+4.44 个百分点。

更大的问题是改进并不稳定：

• 64 次正式版本切换中，反馈集和 held-out 同方向变化的比例只有 53.1%，接近抛硬币；
• 最终声明的 9 个版本中，只有 2 个是 held-out 最优版本；
• 同一个版本重复运行，Pair Score 可能波动约 ±4.75 分；
• 固定 Gemini 作为 Executor 后，只有 Opus 的最终版本在 held-out 上提升，Qwen、DeepSeek 和 GPT-5.5 都出现回退。

图 4：Creator 根据 SWE-Pro-100 的可见反馈选版本，但其变化不一定迁移到 held-out-630。图源：原论文 Figure 8。

这更像是一个带噪声的局部程序搜索过程，而不是稳定的能力进化。模型确实可以发现一些有效问题，例如“Agent 在证据不足时过早宣布成功”，然后加入完成前验证。但继续扩展同一机制，反而可能影响其他任务；在小规模 Probe 上有效的修改，也可能在完整评测中回退。

我的看法

我觉得这篇论文最大的价值不是提出了一个新的 Agent 架构，而是明确提出：Harness 应该成为独立的研究和评测对象。

以前比较 Agent 时，我们经常把模型、Prompt、工具、Context 管理和执行框架打包成一个系统，然后只报告最终分数。HarnessDev 则把其中几个角色拆开：

• 谁开发 Harness；
• 谁运行 Harness；
• Harness 本身包含什么；
• 修改是否真正进入主执行路径；
• 性能提升能否迁移到未见任务和不同 Executor。

这个视角对 Agent 工程很实用。模型权重是能力积累的一部分，Harness 也是另一部分，而且它更显式、可检查、可测试，也可以通过真实失败不断修改。

不过，目前的结果距离“Agent 可以稳定改进自己”还很远。论文的 Evolution 每个 Creator–Runtime 配置基本只有一条轨迹，held-out 也只覆盖 SWE-Pro；人工参考并非统一 Executor 下的严格对照，运行噪声还不小。因此更准确的结论应该是：

LLM 已经能参与 Harness 工程，并偶尔找到有效的结构性改进；但它还不擅长可靠地诊断失败、控制回归、选择最佳版本，以及把改进迁移到其他模型和未见任务。

换句话说，自动写 Agent 框架已经开始变得可行，但真正困难的部分仍然是软件工程里最朴素的那些问题：理解失败、做小而准确的修改、验证因果关系，以及知道什么时候应该停止。