VERSE: Verified Self-Evolving Optimizer for Agent Harnesses

论文阅读：VERSE: Verified Self-Evolving Optimizer for Agent Harnesses

论文标题：VERSE: Verified Self-Evolving Optimizer for Agent Harnesses
作者：Zekai Wang, Yingqiang Ge, Zekun Wang, Hai Wang, Yuhui Xu, Joshua Frandsen, Shancong Fu, Ashia C. Wilson, Chandan K. Reddy
作者机构：MIT（Zekai Wang、Ashia C. Wilson）；Amazon（其余作者）
通讯作者：Zekai Wang、Yingqiang Ge
发表位置：arXiv Preprint，尚未发现正式会议或期刊录用信息
arXiv 编号：2610.02616
提交时间：2026 年 10 月 2 日
原文链接：https://arxiv.org/abs/2610.02616
代码仓库：https://github.com/wzekai/VERSE
主题：Agent Harness Evolution、Self-Evolving Optimizer、Execution-based Verification
核心问题：在优化一个 Agent 的 Harness 时，能否同时让负责优化的 Optimizer 也不断改进自己的工具、Prompt 和执行流程，并通过真实执行验证来保证这种自进化确实有效？

1. 论文要解决什么问题？

1.1 什么是 Harness Evolution？

首先需要理解论文讨论的一个基本概念：Agent Harness。

一个 LLM Agent 并不只是一个语言模型，它通常还包含：

Prompt：指导模型如何执行任务。
Tools：模型可以调用的工具。
Memory：模型使用的记忆机制。
Workflow：模型的执行流程和控制逻辑。
Hooks：在特定执行阶段自动触发的程序逻辑。

这些部分共同构成了 Agent 的 Harness。

可以简单理解为：

Base Model 决定 Agent 具备什么基础能力，而 Harness 决定这些能力如何被组织和使用。

因此，即使不改变底层模型的参数，也可以通过修改 Prompt、Tools、Memory 和 Workflow 等组件，改善 Agent 的任务表现。

近年来出现了一类 Harness Evolution 方法，其基本流程如下：

使用一个 Optimizer 观察 Executor Agent 的执行轨迹。
分析 Executor 在任务中失败的原因。
根据失败原因修改 Executor 的 Harness。
使用修改后的 Harness 重新执行任务。
根据新的执行结果继续修改。

这里涉及两个不同的角色：

角色	职责
Optimizer	分析执行失败，并负责修改 Harness
Executor	使用当前 Harness 实际执行任务

传统方法主要关注如何优化 Executor，而 Optimizer 本身通常保持不变。

例如：

Optimizer 的 System Prompt 不变。
Optimizer 的工具集合不变。
Optimizer 的失败分析方式不变。
Optimizer 的工作流程不变。

这就产生了一个问题：

如果 Executor 的优化能力依赖 Optimizer，那么为什么不进一步优化 Optimizer 本身？

举个例子：

假设 Optimizer 经常错误判断 Executor 的失败原因。

它可能反复修改 Executor 的 Prompt，但实际上真正的问题是工具调用逻辑。

即使 Executor 的 Harness 可以不断被修改，如果 Optimizer 始终采用同一种错误的诊断方式，那么整个优化过程仍然会受到限制。

因此，作者提出了一个新的研究方向：

不仅要让 Optimizer 优化 Executor，还应该让 Optimizer 能够优化自己。

1.2 两种不同的优化对象

为了理解本文，需要区分两个 Harness。

Executor Harness：

负责让 Executor 更好地执行任务。

记为：

\[h \]

Optimizer Harness：

负责决定 Optimizer 如何分析失败、生成修改方案、使用工具以及进行验证。

记为：

\[g \]

因此，本文实际上存在两个优化目标：

优化对象	具体内容
\(h\)	Executor 的 Prompt、Tools、Workflow 等
\(g\)	Optimizer 自己的 Prompt、Skills、Tools、Hooks、Notes 等

这里有一个非常重要的细节：

本文并没有训练或更新 Optimizer 和 Executor 的模型参数。

两个模型的权重始终保持冻结。

发生变化的是两个 Agent 的 Harness：

Executor 的 Harness \(h\) 不断更新。
Optimizer 的 Harness \(g\) 也不断更新。

这就是本文所说的 Self-Evolving Optimizer。

【Figure 1，展示传统固定 Optimizer 与本文 Self-Evolving Optimizer 的区别】

2. 背景与动机：作者发现了什么？

在正式介绍 VERSE 之前，作者首先进行了两个实验，用于验证 Optimizer 自进化是否真的有效，以及 Optimizer 在自进化过程中究竟会产生什么变化。

2.1 Observation 1：没有执行验证，自进化反而可能降低性能

作者首先使用 Meta-Harness 作为基础框架，研究 Optimizer 是否能够通过修改自己的 Harness 提升优化效果。

实验比较了五种配置：

初始 Harness。
原始 Meta-Harness。
允许 Optimizer 自进化，但不提供执行验证。
提供简单执行验证，但 Optimizer 不自进化。
同时提供执行验证和 Optimizer 自进化。

这里的执行验证比较简单：

Optimizer 在正式提交修改之前，可以先使用修改后的 Executor Harness 执行一个训练任务，观察实际结果。

如果发现修改没有达到预期，就可以继续调整，而不是直接提交。

实验结果如下：

配置	Optimizer 自进化	执行验证	Test Accuracy (%)
初始 Harness	否	否	33.95
Meta-Harness	否	否	39.20
Self-Evolving Optimizer	是	否	31.79
Meta-Harness + Verification	否	是	39.81
Meta-Harness + Verification + Self-Evolution	是	是	41.05

可以看到一个很有意思的现象：

仅仅允许 Optimizer 修改自己的 Harness，并不能保证性能提升，甚至可能让性能下降。

为什么？

因为 Optimizer 在没有验证机制的情况下，只能根据历史执行轨迹和任务得分判断自己的修改是否有效。

例如：

Optimizer 认为：

我修改了某个诊断工具。
下一轮的任务表现有所变化。
因此，我的诊断工具可能有效。

但是，这种判断并不一定正确。

可能存在以下情况：

修改本身就是错误的。
任务结果存在随机性。
新一轮的性能变化并不是由这次修改造成的。
Optimizer 错误理解了失败原因。

如果 Optimizer 把这些未经验证的经验写入自己的 Prompt、Skills 或 Tools，就可能不断积累错误的优化策略。

而执行验证可以在提交修改之前提供更加直接的证据。

因此，作者得到第一个重要观察：

Optimizer 的自进化需要建立在可靠的执行验证之上，否则它可能不断强化错误的经验。

2.2 Observation 2：Optimizer 在自进化时会修改什么？

接下来，作者进一步研究：

如果允许 Optimizer 自己修改 Harness，它实际上会产生哪些变化？

作者使用五种不同的 Executor 模型进行实验，让 Optimizer 从空白工作空间开始，经过六轮优化，观察其最终生成的自进化产物。

五次实验一共生成了 51 个 Artifact。

这些 Artifact 分为五种类型：

类型	数量	作用
Prompt	10	修改 Optimizer 的系统指令和工作要求
Skills	13	增加可复用的操作知识和执行指导
Tools	7	创建新的可调用工具
Hooks	16	修改 Optimizer 执行过程中的自动触发逻辑
Notes	5	保存历史轮次的经验和结果
总计	51

作者进一步发现，这些 Artifact 主要承担四种功能。

1. Attribution：失败归因

创建用于分析和定位失败原因的工具或 Skill。

例如：

统计不同失败类型出现的频率。
对失败轨迹进行分类。
分析哪些执行步骤可能导致失败。

2. Verification：执行验证

创建用于验证修改是否有效的工具。

例如：

执行修改后的 Harness。
检查是否修复目标任务。
检查是否引入新的错误。

3. Training Audit：训练过程审计

记录不同轮次的优化结果。

例如：

哪些失败在之前的修改后得到解决？
哪些问题后来又重新出现？
哪些修改虽然解决了一个问题，却引入了其他问题？

4. Workflow：工作流程管理

修改 Optimizer 自己的执行逻辑。

例如：

如何分配有限的执行预算。
如何安排不同候选方案的工作。
在执行到特定轮次时应该完成什么操作。

这说明 Optimizer 的自进化并不只是修改自己的 Prompt。

它实际上可以逐步建立一套更完善的诊断、验证、审计和工作流程管理机制。

作者正是根据这两个观察，提出了 VERSE。

3. VERSE 方法

3.1 整体架构

VERSE 的全称是：

Verified Self-Evolving Optimizer for Agent Harnesses

它并不是完全从零构建一个新的 Harness Optimizer，而是可以添加到现有 Harness Evolution 框架之上。

作者将原有的优化框架称为 Host。

实验中使用了四种 Host：

Meta-Harness
AHE
Self-Harness
HarnessX

不同 Host 的主要区别在于如何分析 Executor 的失败轨迹，以及如何将分析结果提供给 Optimizer。

VERSE 保留原有 Host 的失败分析能力，并在其基础上增加四个组件：

Attribution
Verification
Training Audit
Optimizer Self-Evolution

下面分别介绍。

3.2 Attribution：失败归因与轨迹压缩

首先是失败归因。

Optimizer 需要知道 Executor 为什么失败，才能决定应该修改哪个部分。

但是，一个 Agent 的执行轨迹可能非常长。

例如，一次任务可能包含：

用户任务描述。
多轮 LLM 推理。
多次工具调用。
工具返回结果。
文件修改。
后续执行和测试。

如果最终任务失败，直接阅读整条轨迹并不容易准确定位真正的问题。

因此，VERSE 在原有失败归因方法的基础上，增加了一个重要机制：

Trace Minimization（轨迹最小化）。

它的基本思路是：

获取一条失败的执行轨迹。
从轨迹中选择一部分执行步骤。
重新执行这些步骤。
检查是否仍然能够复现原来的失败。
如果能够复现，就保留这些步骤。
如果不能复现，就继续调整选择的步骤。

最终得到一条更短的轨迹，但仍然能够复现原始失败。

例如：

原始失败轨迹：

Step 1
Step 2
Step 3
...
Step 129

经过最小化：

Step 12
Step 35
Step 48
...
Step 101

最终保留下来的步骤能够复现原来的错误。

论文中的 Replay Study 显示：

轨迹类型	原始轨迹中位数	最小化后中位数	中位数压缩倍数
Failed Trace	129	8	14.4×
Successful Trace	127	4	28.2×

注意，这里的压缩倍数是逐条轨迹压缩比例的中位数，而不是简单用两个中位数相除。

通过这一机制，Optimizer 可以把注意力集中在少量真正重要的执行步骤上。

3.3 Verification：执行验证机制

这是 VERSE 最重要的组成部分之一。

前面已经介绍，单纯阅读轨迹并不能可靠判断修改是否有效。

因此，VERSE 提供了三种验证工具。

3.3.1 Verification Tool：验证修改是否有效

这个工具主要回答：

修改后的 Executor Harness 是否真的修复了目标任务？

具体流程：

Optimizer 对 Executor Harness 生成一个 Draft Edit。
指定希望该修改解决的失败任务。
使用修改后的 Harness 重新执行这些任务。
检查任务测试结果。
将结果和代码执行错误返回给 Optimizer。

一次调用最多可以检查三个目标任务。

此外，作者还设置了一个比较严格的判断标准：

一个任务必须连续两次通过，才能被认为真正修复。

这是因为单次执行成功可能只是随机结果。

3.3.2 Replay Tool：验证失败是否可以复现

这个工具主要回答：

之前观察到的失败是否真实存在，能否重新复现？

例如，Optimizer 认为某个执行步骤导致了任务失败。

它可以重新执行记录的失败轨迹，检查是否仍然出现相同的结果。

如果原来的失败无法复现，那么之前的诊断可能就不可靠。

3.3.3 Perturbation Tool：验证某个步骤是否真的导致失败

这个工具主要回答：

如果修改或者移除某个可疑步骤，原来的失败是否会发生变化？

具体来说：

获取一条能够复现失败的执行轨迹。
选择一个可疑步骤。
删除该步骤，或者使用其他内容替换它。
重新执行剩余轨迹。
比较修改前后的结果。

例如：

原始轨迹：

Step A
Step B
Step C
Step D

假设 Optimizer 怀疑 Step C 是问题所在。

它可以尝试：

Step A
Step B
Step D

然后观察失败是否仍然存在。

如果移除 Step C 后，原来的失败消失，就说明 Step C 可能确实与失败存在因果关系。

当然，这种实验结果仍然需要结合具体环境和执行条件解释，不能简单认为一次成功就证明了唯一原因。

三种工具的区别如下：

工具	验证对象	核心问题
Verification	修改后的 Harness	修改是否真正修复任务？
Replay	原始失败轨迹	失败是否可以复现？
Perturbation	可疑执行步骤	失败是否依赖这个步骤？

其中，Verification 主要验证修改结果，Replay 和 Perturbation 主要验证失败诊断。

论文为这些工具设置了执行预算。

每个候选方案最多拥有 8 个 Verification Budget Units，同一轮中的三个候选方案共享总计 24 个单位的预算。

需要注意：

这些验证工具并不是强制性的提交门禁。

Optimizer 可以自主决定什么时候调用、调用哪种工具，以及是否继续修改或直接提交。

这意味着 VERSE 不只是简单地在每次修改后自动执行测试，而是让 Optimizer 自己决定应该进行什么验证实验。

3.4 Training Audit：跨轮次的优化审计

前面的组件主要负责分析当前失败和验证当前修改。

但是，还有一个问题：

如果某个问题在之前的轮次已经被解决，后面又重新出现，Optimizer 应该如何知道？

因此，VERSE 引入了 Training Audit。

它负责跨轮次追踪失败问题及其修复情况。

例如：

失败问题	Round 1	Round 2	Round 3
工具调用错误	失败	修复	修复
Patch 格式错误	失败	失败	修复
测试未执行	失败	修复	再次失败

这样，Optimizer 就可以知道：

哪些问题已经解决。
哪些问题仍然存在。
哪些修改引入了回归。
哪些问题在不同轮次反复出现。

这些记录会成为下一轮 Optimizer 自进化时的重要输入。

因此，Training Audit 并不是简单地保存历史日志，而是帮助 Optimizer 建立跨轮次的修改效果记录。

3.5 Optimizer Self-Evolution：优化器自身的自进化

这是 VERSE 的核心设计。

每完成一轮 Executor Harness 优化之后，Optimizer 都会进行一次自我更新。

作者允许 Optimizer 修改五种对象：

修改对象	具体含义
Prompts	修改自己的系统提示词
Skills	增加或修改自己的技能文件
Tools	创建或修改可调用工具
Hooks	修改自身执行过程中的自动触发逻辑
Notes	更新历史经验和优化记录

在每一轮结束时，Optimizer 最多可以使用 30 个 Turns 进行自我更新。

它会回顾本轮的信息，包括：

本轮的验证集准确率。
之前预测需要修复的任务是否真的修复。
哪些修改引入了新的失败。
自己调用了哪些验证工具。
工具调用过程中是否发生错误。

然后根据这些信息修改自己的 Harness。

例如：

假设 Optimizer 发现：

自己经常错误定位失败原因。
之前生成的修改很少真正修复目标任务。
自己没有检查修改是否破坏原本已经成功的任务。

那么，它可能在下一轮：

修改失败归因 Skill。
创建新的批量失败分析工具。
修改 Prompt，要求修改前先验证。
增加一个 Hook，在提交修改之前检查是否包含回归测试。
在 Notes 中记录哪些诊断方式有效。

这样，下一轮 Optimizer 就可以使用更新后的工作机制继续优化 Executor。

这里还有两个重要细节。

第一，基础验证工具本身保持固定。

VERSE 提供的 Verification、Replay 和 Perturbation 工具，其底层实现并不会被 Optimizer 直接修改。

但 Optimizer 可以修改自己的 Prompt、Hooks、Skills，并且能够在这些基础工具之上创建新的工具。

第二，自进化代码需要通过安全检查。

Optimizer 自己编写的代码，只有通过安全检查和测试运行之后，才会被加载。

如果新版本不能通过检查，就继续保留之前的版本。

【Figure 4，展示 VERSE 的完整架构，包括 Attribution、Verification、Training Audit、Self-Evolution 以及多轮迭代过程】

4. VERSE 的双层优化机制

前面分别介绍了 VERSE 的四个组件。

接下来从整体上理解它们是如何协同工作的。

4.1 两层循环

VERSE 实际上构成了一个 Bilevel Optimization（双层优化）过程。

两层循环分别对应两个优化对象。

内层循环：优化 Executor Harness。

Optimizer 使用当前的 Harness \(g_t\)，分析 Executor 的失败轨迹，并生成新的 Executor Harness 候选方案。

记为：

\[h_{t+1} \]

外层循环：优化 Optimizer Harness。

当这一轮 Executor Harness 优化结束后，Optimizer 根据本轮结果修改自己的 Harness：

\[g_t \rightarrow g_{t+1} \]

两层循环的目标可以表示为：

\begin{align} \text{Inner:}\quad h_{t+1}(g) &\in \arg\min_{h\in\mathcal{C}_t(g)} \widehat{L}_{\mathrm{train}}(h), \\ \text{Outer:}\quad \min_g\quad &\mathbb{E}\left[ \widehat{L}_{\mathrm{val}}(h_{t+1}(g)) \right]. \notag \end{align}

其中：

\(h\)：Executor Harness。
\(g\)：Optimizer Harness。
\(\mathcal{C}_t(g)\)：当前 Optimizer Harness 能够生成的候选 Executor Harness 集合。
\(\widehat{L}_{\mathrm{train}}\)：训练集上的损失。
\(\widehat{L}_{\mathrm{val}}\)：验证集上的损失。

内层优化的目标是：给定当前 Optimizer 的工作机制，找到表现更好的 Executor Harness。

外层优化的目标是：不断修改 Optimizer 自己的工作机制，使其下一轮能够生成和验证更好的 Executor Harness。

因此，外层优化并不是直接修改 Executor，而是改善未来产生 Executor 修改方案的能力。

4.2 一轮完整的执行流程

结合论文 Appendix B 的 Algorithm 1，可以将 VERSE 的执行流程整理为以下步骤。

Step 1：初始化

准备：

冻结的 Optimizer 模型权重 \(\omega\)。
冻结的 Executor 模型权重 \(\theta\)。
初始 Executor Harness \(h_0\)。
初始 Optimizer Harness \(g_0\)。
Training、Validation 和 Test 三个互不重叠的任务集合。

首先在 Validation Set 上评估初始 Executor Harness，并保存结果。

Step 2：开始内层优化

在当前轮次固定 Optimizer Harness \(g_t\)。

Optimizer 开始分析 Executor 的执行轨迹，并生成多个候选 Executor Harness。

每个候选方案都可以：

阅读失败轨迹。
查看之前的验证反馈。
使用 Attribution 结果。
调用 Verification 工具。
调用 Replay 和 Perturbation 工具。
根据执行结果继续修改 Executor Harness。

论文实验中，每轮生成三个候选方案。

需要注意，这些候选方案在当前轮次使用相同的 \(g_t\)，Optimizer 的自进化发生在轮次之间，而不是每个候选方案执行过程中都更新一次全局 Optimizer Harness。

Step 3：筛选 Executor Harness

候选方案生成完成后，在相同的训练任务子集上进行比较。

论文使用最多 12 个训练任务进行候选方案的比较。

选择训练表现最好的候选方案。

之后还需要进行 Smoke Check，确保修改后的 Harness 能够正常运行。

如果检查失败，Optimizer 最多可以尝试修复三次。

Step 4：验证集评估

使用选出的 Executor Harness 执行验证任务。

然后将验证结果整理成反馈信息。

反馈主要包括：

每轮的 Validation Accuracy。
哪些任务从失败变成成功。
哪些任务从成功变成失败。
这些变化在重新运行后是否能够复现。
Harness 代码执行过程中出现了多少错误。

一个非常重要的设计是：

Optimizer 不会获得 Validation Task 的具体内容、测试代码和执行轨迹。

它只能获得经过整理的结果摘要。

这样可以降低 Optimizer 直接针对验证任务进行过拟合的风险。

Step 5：外层自进化

Optimizer 根据本轮的 Training Audit 和 Validation Feedback，修改自己的 Harness：

\[g_t \rightarrow g_{t+1} \]

例如更新自己的工具、Skill、Prompt、Hook 和 Notes。

更新完成后进入下一轮。

Step 6：最终选择

六轮迭代结束后，作者不会简单地选择最后一轮的 Executor Harness。

而是：

将所有轮次的 Harness 及其验证结果保存。
选择验证集表现最好的两个 Harness。
对它们进行额外评估。
选择表现更好的一个。
最终在完全独立的 Test Set 上进行评估。

因此，最终使用的是验证集选出的最佳 Harness，而不一定是最后一轮生成的 Harness。

4.3 整个过程的核心信息流

总结一下，VERSE 的信息流可以概括为：

Executor 执行任务

↓

Optimizer 分析失败轨迹

↓

Attribution 定位潜在原因

↓

Optimizer 修改 Executor Harness

↓

Verification / Replay / Perturbation 提供执行证据

↓

Training Audit 记录修改效果

↓

Optimizer 根据执行结果修改自己的 Harness

↓

下一轮使用更新后的 Optimizer Harness

↓

继续优化 Executor

这就是 VERSE 的双层自进化机制。

需要特别强调：

整个过程中，两个模型的参数始终没有更新。

真正发生变化的是 Optimizer 和 Executor 的 Harness。

5. 理论分析

作者从理论上分析了为什么执行验证能够帮助 Optimizer 进行更可靠的修改，以及为什么 Optimizer 的自进化能够改善最终 Harness。

主要包含两个理论结果。

5.1 Theorem 1：执行验证能够降低错误修复的概率

作者将失败诊断抽象成一个假设检验问题。

假设 Executor 失败可能存在两种原因：

原因 \(W=1\)。
原因 \(W=2\)。

两种原因分别对应不同的修复方案：

\(h_1\)。
\(h_2\)。

Optimizer 并不知道真实原因，只能根据执行轨迹等已有信息选择一个修复方案。

这里存在一个问题：

如果两种原因对应的历史轨迹非常相似，那么 Optimizer 就很难仅仅通过阅读轨迹判断真正原因。

作者使用 Bhattacharyya Coefficient（巴氏系数）描述两种假设对应证据分布的重叠程度。

记：

\(\beta_0\)：执行验证之前已有证据的重叠程度。
\(\rho_j\)：第 \(j\) 次验证产生的反馈，在两种原因下的分布重叠程度。
\(\epsilon\)：Optimizer 的实际决策误差相对于最优决策规则的额外误差。

作者给出以下上界：

\[\Pr(\hat h\neq h_W) = p_n^*+\epsilon \le \frac{1}{2}\beta_0 \prod_{j=1}^{n}\rho_j +\epsilon \]

其中，\(p_n^*\) 表示利用已有证据和 \(n\) 次验证之后，理论上能够达到的最小错误修复概率。

直观理解：

如果某个验证实验能够产生明显不同的结果，那么它就能够帮助区分两种可能的失败原因。

例如：

如果移除 Step A 后失败消失，那么 Step A 可能与失败有关。
如果移除 Step A 后失败仍然存在，那么 Step A 可能不是主要原因。

这类真实执行结果可以提供仅靠阅读轨迹无法获得的信息。

反过来，如果所谓的验证只是重新阅读之前的轨迹，没有产生任何新的信息，那么它就无法真正降低最优诊断错误率。

作者进一步指出，当验证完全没有提供新的原因区分信息时，最小错误概率仍然存在下界：

\[p_n^* \ge \lambda(1-\lambda)\beta_0^2 \]

其中 \(\lambda\) 和 \(1-\lambda\) 是两种可能失败原因的先验概率。

这说明：

仅仅让 Optimizer 反复反思已有信息，并不能保证它最终找到正确的失败原因。执行验证的价值在于产生新的证据。

5.2 Theorem 2：自进化如何改善最终 Harness？

接下来，作者分析整个 Harness Evolution 过程。

找到正确的失败原因还不够，还需要同时解决两个问题：

Optimizer 是否选择了值得修复的失败？
Optimizer 是否提出了正确的修复方案？

作者将第 \(i\) 次修改成功找到一个优质 Harness 的概率拆分成两个因素：

\(r_i\)：Optimizer 选择到一个正确的失败目标，并且该目标的正确修复能够产生优质 Harness 的概率。
\(e_i\)：在选择了正确目标的前提下，Optimizer 最终提交错误修复的概率。

作者给出了以下性能上界：

\[\mathbb{E}[L_{\theta,D}(\hat h)] \le \ell_0 + (1-\ell_0) \prod_{i=1}^{K} [1-r_i(1-e_i)] + \epsilon_{\mathrm{sel}} \]

其中：

符号	含义
\(\ell_0\)	判断 Harness 是否足够优秀的目标损失阈值
\(r_i\)	第 \(i\) 次提案选择正确优化目标的概率
\(e_i\)	第 \(i\) 次提案产生错误修复的概率
\(K\)	总提案次数
\(\epsilon_{\mathrm{sel}}\)	最终 Harness 选择过程的误差

这个公式表达了三个重要因素：

第一，目标选择能力。

如果 Optimizer 总是选择不重要的失败进行修复，即使修复方案本身正确，也不一定能够显著改善整体性能。

因此，需要提高 \(r_i\)。

第二，修复正确率。

即使找到了正确的失败原因，如果修复方案本身存在问题，也可能无法改善任务表现。

因此，需要降低 \(e_i\)。

执行验证可以帮助 Optimizer 提前发现错误修改，降低这一误差。

第三，候选方案选择能力。

即使某一轮已经产生了优秀的 Executor Harness，如果最终选择机制不能正确识别它，也可能导致性能损失。

因此，还需要降低 \(\epsilon_{\mathrm{sel}}\)。

作者认为，Optimizer 自进化可以通过学习更好的诊断方式、工具使用方式和验证策略，提高 \(r_i\)，同时降低 \(e_i\)。

这也解释了为什么 VERSE 不只是简单增加几个验证工具，而是需要让 Optimizer 自己学习如何更好地使用这些工具。

6. 实验设置

6.1 数据集

论文主要使用 SWE-rebench。

它是一个持续更新的软件工程任务集合，任务形式与 SWE-bench 类似，主要是让 Agent 根据 GitHub Issue 修改代码仓库。

作者将任务划分为三个互不重叠的集合：

数据集	任务来源	数量	用途
Training	2025 年 1 月至 2026 年 2 月	110	优化 Harness
Validation	同一历史任务池	50	选择 Harness、提供反馈
ID Test	2026 年 3 月发布	108	最终测试
OOD Test	2026 年 7 月发布	107	跨时间、跨语言测试

其中：

Training 和 Validation 都是 Python 项目。
ID Test 也是 Python 项目。
OOD Test 包含五种编程语言。

OOD Test 的具体组成：

语言	任务数量
Go	21
Java	17
Python	20
Rust	25
TypeScript	24
总计	107

其中 87 个任务属于非 Python 语言。

因此，作者不仅希望验证 Harness 能否在训练任务所属领域内提升性能，也希望验证其优化结果能否迁移到新的编程语言。

6.2 模型配置

主要实验使用：

角色	模型	参数规模
Optimizer	Qwen3.8-Flash-Next	总参数 176B，激活参数 6B
Executor	Qwen3.8-27B	27B

两个模型的权重都保持冻结。

实验进行六轮迭代，每轮生成三个 Executor Harness 候选方案。

6.3 对比方法

作者选择了四种已有 Harness Optimizer 作为 Host：

方法	主要特点
Meta-Harness	通过读取原始执行轨迹进行优化
AHE	使用 LLM Debugger 对执行轨迹进行分析
Self-Harness	根据失败轨迹和失败模式生成修改方案
HarnessX	使用分阶段的 Harness Evolution 工作流程

作者将四种方法重新实现到统一实验协议中。

这样可以保证：

使用相同的 Executor。
使用相同的 Optimizer 模型。
使用相同的 Harness 修改空间。
使用相同的候选方案数量。
使用相同的提案轮次预算。

不同方法主要保留各自原有的失败证据分析接口。

此外，作者还比较了加入 VERSE 后的两种情况：

VERSE，但不允许 Optimizer 自进化。
VERSE，同时允许 Optimizer 自进化。

指标采用 avg@3 accuracy，即对每个 Harness 进行三次测试执行，计算解决任务的平均比例。

7. 主要实验结果

7.1 SWE-rebench 主实验

首先看主要实验结果。

下表展示 Validation-selected Harness 在 ID Test 和 OOD Test 上的准确率。

数值单位均为百分比，省略标准误差以方便比较。

Host	配置	ID Test	OOD Test
Meta-Harness	原始方法	39.20	28.66
Meta-Harness	+ VERSE，不自进化	34.57	28.35
Meta-Harness	+ VERSE，自进化	42.28	37.69
AHE	原始方法	33.95	26.17
AHE	+ VERSE，不自进化	37.96	35.51
AHE	+ VERSE，自进化	35.19	30.22
Self-Harness	原始方法	29.63	29.28
Self-Harness	+ VERSE，不自进化	40.12	31.78
Self-Harness	+ VERSE，自进化	34.88	30.22
HarnessX	原始方法	32.72	27.41
HarnessX	+ VERSE，不自进化	38.89	27.10
HarnessX	+ VERSE，自进化	35.80	37.69

从结果中可以观察到几个现象。

第一，VERSE 可以改善不同类型的 Harness Optimizer。

作者在四种 Host 上都观察到了性能提升。

这说明 VERSE 并不依赖某一种特定的失败分析方法。

无论原有 Host 使用原始轨迹、Debugger 报告、失败分组还是轨迹摘要，都可以接入 VERSE。

第二，执行验证与 Optimizer 自进化结合后，整体表现更加稳定。

论文统计了 16 组对比：

四种 Host × 两个测试集 × 两种 Harness 选择方式（Validation-selected 和 Last）。

加入 VERSE 并开启 Optimizer 自进化后，16 组对比全部优于对应的原始 Host。

提升幅度为 0.6～10.3 个百分点。

第三，Optimizer 自进化并不一定让每一个实验的分数都进一步提高。

这是一个值得注意的细节。

例如，AHE 和 Self-Harness 上，加入 VERSE 但不自进化的部分结果，反而高于开启自进化的结果。

但是，开启自进化的 VERSE 在所有 16 组对比中都高于对应的原始 Host。

因此，作者的结论并不是自进化必然能够提高所有配置的指标，而是自进化能够让整个 VERSE 框架在不同 Host 上更加稳定地获得收益。

第四，OOD 泛化结果比较明显。

原始方法在 OOD 测试集上的提升通常比较有限。

例如，Meta-Harness 在 ID Test 上达到 39.20%，但在 OOD Test 上只有 28.66%。

而加入 VERSE 并开启自进化之后，达到了 37.69%。

这说明在 Python 任务上学到的 Optimizer 工作机制，可以帮助 Executor 在 Go、Java、Rust 和 TypeScript 等不同语言的任务上获得提升。

7.2 Terminal-Bench 补充实验

除了 SWE-rebench，作者还在 Appendix F 中进行了 Terminal-Bench 实验。

该实验使用另一套模型配置，包括匿名的闭源模型家族，因此不能直接与前面的主实验数值混为一谈。

三次独立进化实验的平均结果如下：

方法	SWE-rebench	Terminal-Bench
Initial Harness	28.70	37.08
Meta-Harness	30.56	36.95
AHE	29.94	37.45
Self-Harness	29.32	37.83
HarnessX	28.39	36.96
VERSE	32.82	40.57

VERSE 在两个 Benchmark 上都取得了最高的三次运行平均成绩。

不过作者也指出，Terminal-Bench 在这一实验配置下对 Harness 的敏感度相对较低，大部分方法与初始 Harness 的差距不大。

7.3 跨领域和跨模型迁移

作者还研究了优化器自身的自进化成果能否迁移到其他环境。

主要有三个发现。

1. 跨编程语言迁移

在 Python 上进化得到的 Harness，可以迁移到其他编程语言。

在四种 Host 和五种语言构成的 20 组对比中，VERSE 在 16 组中提升了对应 Host 的表现。

2. 跨任务领域迁移

作者研究了 SWE-rebench 与 Terminal-Bench 之间的迁移。

结果显示：

Executor Harness 通常具有明显的任务领域特征。
Optimizer 的方法论、Skills、Notes 和诊断工具更容易跨领域迁移。

也就是说，跨领域迁移的主要对象并不是已经进化好的 Executor Harness，而是 Optimizer 自身积累的优化能力。

3. 跨 Executor 模型迁移

作者将已经进化好的 Harness 直接交给其他 Executor 模型。

结果发现：

针对某一个 Executor 模型优化得到的 Harness，在更换 Executor 模型之后，Zero-shot 迁移效果通常接近于零。

这说明 Executor Harness 仍然具有较强的模型依赖性。

8. 消融实验与进一步分析

8.1 各组件是否真的有用？

作者在 AHE Host 上进行了消融实验。

这里所有配置都关闭 Optimizer 自进化，主要用于研究 VERSE 各个组件的独立贡献。

配置	Validation-selected Accuracy (%)
AHE + 完整 VERSE	37.96
去掉执行验证	37.65
去掉 Attribution 和 Trace Minimization	35.80
只去掉 Training Audit	36.73
原始 AHE	33.95

从实验可以看到：

Attribution 和 Trace Minimization 很重要。

去掉失败归因和轨迹最小化之后，性能从 37.96% 降低到 35.80%。

这意味着仅仅提供执行验证还不够。

如果 Optimizer 不知道应该验证什么、哪些步骤可能导致失败，那么执行验证也难以发挥作用。

Training Audit 同样重要。

只去掉 Training Audit，性能降低到 36.73%。

如果只关注当前失败，而不追踪历史修改的效果，Optimizer 可能无法及时发现反复出现的失败和回归问题。

8.2 执行验证究竟发现了什么？

作者统计了 VERSE 在整个进化过程中的验证记录。

在 170 次 Draft Verification 中：

结果	数量
真正修复目标失败任务	17
只通过原本已经成功的回归测试	30
没有修复任何测试任务	112
无法判断	11
总计	170

也就是说，只有 17 次验证明确发现了目标任务被修复。

这看起来并不是一个很高的比例。

但这恰恰说明执行验证的重要性：

如果 Optimizer 不进行提前验证，那么大量无效修改就会直接进入下一轮。

此外，作者发现：

在后续训练执行中，Optimizer 声称应该被修复的 286 个失败任务中，有 258 个仍然失败，占约 90%。

这说明 Optimizer 对自己修改效果的预测并不可靠。

更值得注意的是，修改还可能引入回归。

在 18 次实验运行中，经过重新执行确认：

148 个验证任务从失败变成成功。
134 个验证任务从成功变成失败。

这说明一次修改即使修复了目标任务，也可能破坏其他已经成功的任务。

因此，VERSE 不仅要求检查目标任务，还鼓励 Optimizer 将原本已经成功的任务作为 Regression Test。

8.3 自进化是否改变了 Optimizer 的验证行为？

作者还比较了固定 Optimizer 和 Self-Evolving Optimizer 在验证过程中的行为。

结果如下：

行为	固定 Optimizer	Self-Evolving Optimizer
Draft Verification 中包含回归测试的次数	2/89	34/81
验证未修复任何目标后，修改 Draft 再提交的比例	57%	79%

可以看到，自进化不仅改变了 Optimizer 的工具和 Prompt，也改变了它实际使用工具的方式。

例如：

更主动地检查原本已经成功的任务。
在验证失败后重新修改 Draft。
更重视提交之前的执行证据。

这也是论文非常重要的一个发现：

Optimizer 自进化的价值不仅在于拥有更多工具，还在于它能够逐渐学会更合理地使用工具。

8.4 失败轨迹分析本身是否可靠？

作者在 Appendix I 中进行了专门的 Replay Study。

其中一个发现是：

LLM 即使能够大致判断失败类型，也不一定能够准确定位真正导致失败的步骤。

在具有已知注入错误的轨迹中：

98.7% 的情况下，模型能够将正确的失败类型列入候选原因。
62.0% 的情况下，模型的第一选择就是正确原因。
36.9% 的情况下，模型能够精确指出出错步骤。
57.3% 的情况下，模型指出的步骤距离真正出错的位置不超过一步。

这进一步说明：

仅仅阅读执行轨迹并不足以可靠地完成细粒度失败归因。

因此，论文使用 Trace Minimization 和 Perturbation 等执行实验辅助诊断。

在另一项失败修复测试中，作者发现：

只允许修改一个步骤时，50.3% 的失败轨迹可以被修复。
允许最多修改五个步骤时，修复比例提高到 67.1%。
实际平均修改步骤数为 1.65。

这些实验为论文中的执行验证设计提供了进一步的实证依据。

9. 局限性与适用范围

结合论文的实验和分析，可以归纳出以下几个边界。

9.1 仍然属于 Harness-Level Evolution

虽然论文使用了 Self-Evolving 和 Self-Improving 等概念，但这里的进化对象并不是模型参数。

Optimizer 和 Executor 的模型权重始终冻结。

发生变化的是：

Prompt
Skills
Tools
Hooks
Notes
Workflow

因此，它属于 Harness 层面的自进化，而不是模型权重层面的持续学习或强化学习训练。

9.2 自进化必须依赖可靠的验证反馈

Observation 1 已经证明，仅仅允许 Optimizer 修改自己的 Harness，并不能保证获得提升。

如果缺乏真实执行验证，Optimizer 可能把错误判断写入自己的工作机制。

因此，VERSE 的关键设计不是单纯开放自修改权限，而是将执行验证与自进化结合起来。

9.3 实验主要集中在软件工程任务

主要实验使用 SWE-rebench 和 Terminal-Bench。

虽然作者进行了跨语言、跨领域和跨模型迁移研究，但尚不能直接证明 VERSE 能够在所有类型的 Agent 任务中获得相同效果。

例如，知识检索、科研 Agent、复杂规划 Agent 等场景是否能够获得类似收益，论文没有给出实验结论。

9.4 额外执行成本不可忽略

VERSE 引入了额外的验证执行、轨迹重放以及 Optimizer 自更新过程。

虽然论文在候选方案数量和提案轮次等方面统一了实验协议，但不同方法的总执行次数、Token 消耗和运行时间并不完全相同。

因此，性能提升需要结合额外计算成本一起理解。

9.5 更换 Executor 模型后需要重新适配

实验显示，针对一个 Executor 优化的 Harness，在更换底层模型后，Zero-shot 迁移能力通常较弱。

因此，Optimizer 的自进化能力虽然能够跨一定任务领域迁移，但不代表 Executor Harness 可以在不同模型之间直接通用。

10. 总结

VERSE 研究的是一个非常明确的问题：

传统 Harness Evolution 主要优化 Executor，却通常固定负责优化的 Optimizer。

VERSE 则进一步允许 Optimizer 修改自己的 Harness，使其能够不断改善失败诊断、工具使用、验证策略和工作流程。

它的核心设计可以归纳为四个部分：

Attribution：分析失败原因，并通过 Trace Minimization 缩短失败轨迹。
Verification：通过实际执行、轨迹重放和步骤扰动验证修改及诊断结果。
Training Audit：跨轮次追踪修复效果和回归情况。
Self-Evolution：根据执行反馈修改 Optimizer 自己的 Prompt、Skills、Tools、Hooks 和 Notes。

这四个部分共同构成了双层优化机制：

内层不断优化 Executor Harness。
外层不断优化 Optimizer Harness。

其中最关键的设计思想是：

自进化不能仅仅依赖模型对历史经验的反思，还需要通过真实执行获得新的证据，并根据证据持续调整自身的优化机制。

论文的实验也表明，Optimizer 自进化与执行验证相结合，能够改善多种现有 Harness Optimizer，并在一定程度上将优化能力迁移到新的编程语言和任务领域。

参考

Wang et al., VERSE: Verified Self-Evolving Optimizer for Agent Harnesses, arXiv:2610.02616, 2026.
VERSE Official GitHub Repository

posted @ 2026-11-05 17:59 YourF4u1t 阅读(10) 评论(0) 收藏举报

刷新页面返回顶部

VERSE: Verified Self-Evolving Optimizer for Agent Harnesses

论文阅读：VERSE: Verified Self-Evolving Optimizer for Agent Harnesses

1. 论文要解决什么问题？

1.1 什么是 Harness Evolution？

1.2 两种不同的优化对象

2. 背景与动机：作者发现了什么？

2.1 Observation 1：没有执行验证，自进化反而可能降低性能

2.2 Observation 2：Optimizer 在自进化时会修改什么？

3. VERSE 方法

3.1 整体架构

3.2 Attribution：失败归因与轨迹压缩

3.3 Verification：执行验证机制

3.3.1 Verification Tool：验证修改是否有效

3.3.2 Replay Tool：验证失败是否可以复现

3.3.3 Perturbation Tool：验证某个步骤是否真的导致失败

3.4 Training Audit：跨轮次的优化审计

3.5 Optimizer Self-Evolution：优化器自身的自进化

4. VERSE 的双层优化机制

4.1 两层循环

4.2 一轮完整的执行流程

4.3 整个过程的核心信息流

5. 理论分析

5.1 Theorem 1：执行验证能够降低错误修复的概率

5.2 Theorem 2：自进化如何改善最终 Harness？

6. 实验设置

6.1 数据集

6.2 模型配置

6.3 对比方法

7. 主要实验结果

7.1 SWE-rebench 主实验

7.2 Terminal-Bench 补充实验

7.3 跨领域和跨模型迁移

8. 消融实验与进一步分析

8.1 各组件是否真的有用？

8.2 执行验证究竟发现了什么？

8.3 自进化是否改变了 Optimizer 的验证行为？

8.4 失败轨迹分析本身是否可靠？

9. 局限性与适用范围

9.1 仍然属于 Harness-Level Evolution

9.2 自进化必须依赖可靠的验证反馈

9.3 实验主要集中在软件工程任务

9.4 额外执行成本不可忽略

9.5 更换 Executor 模型后需要重新适配

10. 总结

参考

公告