VERSE: 面向 Agent 框架的验证式自演进优化器

1. 问题与价值

这篇论文解决的核心问题是：在“harness evolution”中，优化器（optimizer）本身的工作方式是否也应该被优化。所谓 harness，是指把一个大语言模型包装成可执行 agent 所需的提示词、工具、记忆和控制流。已有工作让一个固定流程的优化器去改进执行器（executor）的 harness，但优化器自己的诊断方式、编辑方式、测试方式始终保持不变。

这个问题重要，是因为优化器在阅读失败轨迹时经常产生错误判断：它可能报告从未发生过的失败，也可能在训练任务上有效、在新任务上失效。如果优化器不能验证自己的编辑，它会把错误经验写进自己的 harness，导致后续轮次越来越差。

受益者是使用 LLM agent 做软件工程任务的团队。如果优化器能自我改进，他们可以用更少的进化轮次得到在新任务上更稳的 harness，而不是在训练任务上过拟合。论文给出的直接收益是：在 SWE-rebench 留出测试集上，最佳验证选择 harness 达到 42.3%，而最强基线是 39.2%；在更新的五语言 OOD 任务上达到 37.7%，最强基线是 29.3%。

2. 已有工作的不足

在本文之前，最好的做法是让一个 LLM 优化器读取失败轨迹和分数，然后编辑执行器 harness，多轮迭代。代表方法包括 Meta-Harness、AHE、Self-Harness、HarnessX。这些方法的主要区别在于优化器如何消化失败证据：Meta-Harness 直接读原始轨迹，AHE 用 LLM 调试器蒸馏根因报告，Self-Harness 对失败轨迹做确定性聚类，HarnessX 按需生成轨迹摘要。

具体不足有三点。

第一，优化器自己的 harness 是固定的。它不会根据前几轮的经验修改自己的提示词、技能、工具、钩子或笔记。这意味着优化器可能反复犯同样的诊断错误。

第二，优化器在提交编辑前没有执行级验证。它只能从下一轮的训练结果中看到编辑效果，而单次运行噪声很大。论文报告，在验证集上，一半的结果变化在重跑后不能复现。没有验证时，优化器无法区分“编辑无效”和“运行噪声”。

第三，已有工作经常在同一个基准上搜索和报告结果，这类似于 test-time scaling，收益可能来自对特定任务模式的过拟合，而不是更好的 harness 设计。Wang et al. 2026b 已经指出这一点。

3. 重建作者的思考路径

从旧方法出发，最自然的想法是：既然优化器能改进执行器 harness，为什么不让它也改进自己的 harness？这是直接的自指扩展。但论文的 Observation 1 显示，简单允许自我进化反而更差：没有验证时，优化器把未经验证的教训写进自己的 harness，验证集上没有任何轮次超过第 0 轮，最终验证选择回到初始 harness。

撞上的矛盾是：优化器只能从轨迹和分数中学习，而轨迹会误导。它看到编辑后的分数变化，但无法区分是编辑造成的还是噪声造成的。于是它可能把噪声当成有效经验，写进自己的提示词和笔记，污染后续轮次。

一个自然的修补是：让优化器在提交前先跑一次编辑后的 harness。这就是论文中的 simple verification。它让优化器在一个训练任务上试运行草稿，看到测试是否通过，再决定提交还是修改。这个改动让自我进化从最差变成最好。

但 simple verification 仍然不够。它只回答“这个草稿在某个任务上是否通过”，不回答“失败是否可复现”和“哪一步导致失败”。优化器可能在一个任务上通过，但不知道这是否只是运气，也不知道草稿是否破坏了其他已经通过的任务。

进一步的想法是：给优化器提供更结构化的验证工具。一个工具检查草稿是否修复了目标任务，一个工具重放记录的失败看它是否复现，一个工具扰动单个步骤看失败是否依赖该步骤。同时，把失败轨迹压缩到少数关键步骤，让优化器更容易定位原因。这就是 trace minimization 和三个验证工具的来源。

但这里还有一个新问题：即使有这些工具，固定优化器也不一定会好好用。论文的消融显示，没有自我进化时，优化器在 AHE 主机上前九次验证调用全部驳回了自己的草稿，之后就不再调用。工具需要优化器自己学会何时调用、如何解读结果。于是需要让优化器在轮次之间修改自己的提示词、技能、工具、钩子和笔记，把验证经验沉淀下来。

与论文实际路径的差异：我猜的路径是先做自我进化、发现失败、再加验证，这与论文 Observation 1 的顺序一致。但论文的实际设计更强调“从第一轮就提供验证工具”，而不是让优化器自己慢慢造出来。Observation 2 先审计了优化器在五个执行器上自发构建了什么，发现它倾向于造归因、验证、训练审计和工作流四类工具，然后 VERSE 直接把这些工具作为固定组件提供。我猜的路径没有明确区分“固定验证工具”和“优化器自建工具”的层次，而论文的关键设计是：验证工具固定，但优化器可以决定何时调用它们，并可以在其上构建新工具。

4. 核心 intuition

可以把优化器想象成一个修车学徒。旧方法是：学徒读维修记录，然后直接改车，改完等下一轮测试才知道结果。问题是维修记录可能写错，测试结果也可能因为天气、油品等偶然因素波动。学徒可能把一次偶然的成功当成有效经验，写进自己的维修手册，结果越修越坏。

VERSE 的做法是给学徒一个试车场。他改完车后，可以立刻开出去试，看故障是否消失；可以重放故障录像，看故障是否稳定复现；可以拆掉一个零件再试，看故障是否真的由这个零件引起。更重要的是，学徒会把这些试车经验写进自己的维修手册，下次知道该先试什么、怎么判断结果。

这个类比对应机制：试车场对应执行级验证工具，它提供的是“干预后的结果”，而不是“阅读后的推断”。故障录像重放对应 replay 工具，它区分“真实故障”和“记录错误”。拆零件对应 perturbation 工具，它检验因果归因。维修手册对应优化器自己的 harness，它把验证经验跨轮次沉淀下来。机制上有效的原因是：执行结果比文本推断更接近真实因果结构，而自我进化让优化器学会利用这种信号。

5. 方法 pipeline 举例

假设输入是一个 SWE-rebench 训练任务，任务 ID 为 task_42，执行器是 Qwen3.8-27B，优化器是 Qwen3.8-Flash-Next，主机是 Meta-Harness。

第一步，初始 harness h0 在训练任务上运行，task_42 失败。失败轨迹有 129 步，测试报错是 ModuleNotFoundError: pytest。

第二步，归因组件做 trace minimization。它从 129 步中选出若干子集重放，最终找到一个 8 步子集，重放后仍然产生同样的 ModuleNotFoundError。这 8 步中包括一步 python -m pytest tests/test_core.py，而执行环境的基础 Python 没有安装 pytest。

第三步，优化器读取归因报告，提出一个编辑：在执行器 harness 的 hook 中，把 python -m pytest 改写为使用仓库自带虚拟环境中的 Python。这个草稿记为 h_draft。

第四步，优化器调用 verification 工具。它选择 task_42 作为目标任务，另外选了一个当前 harness 已经通过的任务 task_17 作为回归检查。verification 工具在 task_42 上运行 h_draft，测试通过；再跑一次确认，仍然通过。在 task_17 上运行 h_draft，也通过。工具报告：目标任务修复确认，回归任务未破坏。

第五步，优化器提交 h_draft 作为本轮候选。候选在训练比较子集上评估，训练损失下降，被选为本轮 harness h1。

第六步，验证集上 h1 修复了 3 个任务，但破坏了 2 个之前通过的任务。验证反馈返回给优化器，只包含任务 ID 和结果变化，不包含任务内容。

第七步，优化器进入自我更新阶段。它回顾本轮结果，发现自己验证时只测了预期修复的任务，没有测足够多的回归任务。它修改自己的提示词，加入规则：“每次验证必须包含至少一个当前 harness 已通过的任务作为回归金丝雀”。它还把失败模式分类脚本写成一个可调用工具 corpus_triage，下次可以一次调用完成分类。

第八步，下一轮开始时，优化器使用更新后的自己。它先调用 corpus_triage 分类所有失败，然后针对最大的失败类提出编辑，并在验证时包含回归任务。

6. 核心数学推导

论文的核心理论是 Theorem 1，它分析验证如何帮助选择正确的修复。假设读者只有本科线性代数和概率论。

先解释符号。设 W 是真实故障原因，取值 1 或 2，先验概率分别是 λ 和 1 - λ。设 h1 和 h2 是分别针对原因 1 和原因 2 的正确修复。优化器不知道 W，它根据证据选择一个修复 ĥ。错误概率是 P(ĥ ≠ h_W)。

证据的重叠程度用 Bhattacharyya 系数衡量。对于两个概率分布 P1 和 P2，Bhattacharyya 系数定义为 Aff(P1, P2) = Σ_y sqrt(P1(y) P2(y))。它取值在 0 到 1 之间。如果两个分布完全相同，系数是 1，表示证据完全无法区分两个原因；如果两个分布支撑集不交，系数是 0，表示证据完美区分两个原因。

设 β0 是检查前所有证据的重叠系数。设 ρj 是第 j 次检查的重叠系数上界。Theorem 1 给出：

P(ĥ ≠ h_W) = p*_n + ε ≤ (1/2) β0 ∏_{j=1}^{n} ρj + ε

其中 p*_n 是任何决策规则在 n 次检查后能达到的最小错误概率，ε ≥ 0 是优化器相对于最优规则的超额误差。

推导分两步。第一步，Lemma C.1.2 证明每次检查最多把重叠系数乘以 ρj。设 I_j 是第 j 次检查后的完整历史。在给定历史 I 和查询 q 的条件下，反馈 Y 的分布是 κ_w(· | I, q)。第 j 次检查的重叠系数是：

ρj = sup_I Σ_q Π_j(q | I) Aff(κ1(· | I, q), κ2(· | I, q))

其中 Π_j 是优化器选择查询的策略。因为 Π_j 在两个原因下相同，所以历史分布的重叠系数满足 βj ≤ ρj β_{j-1}。迭代得到 βn ≤ β0 ∏ ρj。

第二步，Lemma C.1.1 给出 Bayes 错误概率与 Bhattacharyya 系数的关系。对于证据分布 P1 和 P2，最小错误概率 p* 满足：

λ(1-λ) β² ≤ p* ≤ sqrt(λ(1-λ)) β ≤ (1/2) β

上界来自 min(a, b) ≤ sqrt(ab)，其中 a = λ P1(I)，b = (1-λ) P2(I)。下界来自 Cauchy-Schwarz 不等式。把 βn ≤ β0 ∏ ρj 代入上界，就得到 Theorem 1 的不等式。

这个公式在计算：执行级检查能把错误修复概率的上界从 (1/2) β0 压缩到 (1/2) β0 ∏ ρj。如果检查只是重新分析已有证据，那么 κ1 = κ2，ρj = 1，上界不下降。只有检查的反馈依赖于真实原因，才能降低 ρj 从而降低错误概率。

7. 实验设计

数据集是 SWE-rebench。训练集 110 个任务，验证集 50 个任务，都来自 2025 年 1 月到 2026 年 2 月的月度发布池。分布内测试集是 2026 年 3 月发布的 108 个可评分任务，全部是 Python。OOD 测试集是 2026 年 7 月发布的 107 个可评分任务，覆盖 Go、Java、Python、Rust、TypeScript，其中只有 20 个 Python。

基线是四个重新实现的 harness 优化器：Meta-Harness、AHE、Self-Harness、HarnessX。所有方法在统一协议下运行：同一个执行器 Qwen3.8-27B，同一个优化器 Qwen3.8-Flash-Next，六轮进化，每轮三个候选，相同的提案轮数限制。指标是 avg@3 accuracy，即三次测试评估的平均通过率，报告标准误。

消融实验在 AHE 主机上进行，去掉验证、去掉归因和最小化、去掉训练审计，分别看验证选择 harness 的准确率变化。另外还有探针预算消融，从每候选 1 到 8 个单位变化。

实验能支撑核心结论：VERSE 在四个主机上都改善了基线，且 OOD 上也有增益。但有几个缺口。第一，每个配置只跑一次进化，表 2 中标准误只反映测试评估的方差，不反映进化运行的方差。附录 F 的三运行研究部分弥补了这一点，但主表没有。第二，总计算量在不同方法间不同，VERSE 的墙钟时间是基线的 1.3 到 2.5 倍，论文没有完全排除“更多计算带来更好结果”的解释。第三，验证集反馈可能造成选择偏差，论文在附录 C.3.2 用自适应数据分析的框架给出了界，但没有实证估计这个偏差的大小。

8. take-aways

1. 在 SWE-rebench 上，没有执行验证的优化器自我进化会让验证选择回到第 0 轮，测试准确率 31.79%，低于 Meta-Harness 基线的 39.20%；加上 simple verification 后达到 41.05%，是表 1 中最高。

1. 在 18 个进化运行的日志中，提交的编辑预期修复的训练任务只有约 10% 在下一轮真的通过；verification 工具在 170 次草稿评估中只有 17 次确认草稿修复了失败目标。

1. 验证集上约一半的结果变化在重跑后不能复现，所以 verification 工具要求任务通过两次才算修复。

1. 自我进化优化器在 81 次草稿评估中有 34 次包含回归检查，而固定优化器在 89 次中只有 2 次；当验证显示草稿没有修复任何目标时，自我进化优化器在 38 例中有 30 例修改草稿后再提交，固定优化器在 74 例中只有 42 例。

1. 在 OOD 五语言测试集上，VERSE 带自我进化在 Meta-Harness 主机上达到 37.69%，而 Meta-Harness 基线只有 28.66%；在非 Python 的 87 个任务上，VERSE 带自我进化达到 35.6%，blank 是 25.3%。

9. 最脆弱的假设

最脆弱的假设是：训练任务上的执行级验证结果能推广到验证集和测试集。整个方法的价值依赖于“在训练任务上跑草稿能预测草稿在未见任务上的效果”。如果训练任务和测试任务的失败模式差异很大，验证工具给出的信号就会系统性地误导优化器。

论文自己给出的证据是 OOD 实验结果：在 Python 训练任务上演化的 harness 在 Go、Java、Rust、TypeScript 上也有增益，说明验证信号至少部分跨语言迁移。但附录 G.2 的跨域实验显示，从 SWE-rebench 移植到 Terminal-Bench 时，执行器 harness 零样本会低于目标域 blank，说明执行器 harness 本身是域特定的。跨域迁移的收益主要来自继承的优化器 harness，而不是执行器 harness。这意味着验证信号的价值可能依赖于任务域的相似性。如果任务域差异更大，比如从软件工程到完全不同的 agent 任务，这个假设可能不成立。

另一个相关假设是：验证工具的执行结果比文本推断更可靠。论文的 replay study 支持这一点：LLM 阅读轨迹时，精确指出注入故障步骤的比例只有 36.9%，而执行重放可以确认故障是否复现。但如果执行环境本身有噪声，比如测试有随机性、依赖外部状态，那么执行验证的可靠性也会下降。论文通过要求两次通过来缓解，但没有完全消除这个风险。

10. 一周最小复现

目标：复现 Observation 1 的核心结论，即“自我进化加验证优于自我进化无验证”。

硬件约束：一张 24GB 消费级显卡。Qwen3.8-27B 和 Qwen3.8-Flash-Next 无法直接跑，需要替换为更小的模型。建议执行器用 Qwen2.5-Coder-7B-Instruct 或类似规模，优化器用同一个模型或稍大的 14B 模型，用 4-bit 量化。

步骤：

1. 准备数据。从 SWE-bench 官方仓库取 20 个训练任务、10 个验证任务、20 个测试任务。不要用 SWE-rebench 的完整规模，时间不够。

1. 实现一个最小 harness evolution 循环。初始 harness 包含基础提示词和一个 bash 工具。优化器读取失败轨迹，提出 harness 编辑，提交后重新运行训练任务。

1. 实现 simple verification。给优化器一个工具，让它在一个训练任务上运行草稿编辑，返回测试结果和轨迹。

1. 跑三个配置：固定优化器无验证、自我进化无验证、自我进化加验证。每个配置 3 轮，每轮 1 个候选。自我进化让优化器在每轮结束后修改自己的提示词和笔记。

1. 指标：验证集准确率，以及测试集准确率。预期结果：自我进化无验证的验证选择准确率不高于固定优化器，自我进化加验证的准确率最高。论文表 1 中三者的测试准确率分别是 39.20%、31.79%、41.05%，但小规模复现的绝对数值会低很多，关键是相对顺序。

1. 记录优化器在无验证时写进自己 harness 的错误教训，以及在有验证时是否学会加入回归检查。这是论文 Section 4.4 的核心观察。

预期时间分配：数据准备 1 天，实现循环和验证工具 2 天，跑三个配置 2 天，分析日志 1 天，留 1 天缓冲。

11. 反例设计

设计一个实验，如果成功就能推翻本文的核心主张“执行级验证加自我进化优于固定优化器”。

实验设计：构造一个训练集，其中失败轨迹的文本特征与真实失败原因系统性无关。具体做法：在训练任务中，注入一种“幽灵失败”——轨迹文本中反复出现某个看似相关的错误模式，比如 KeyError: 'config'，但真实失败原因是环境变量未设置。同时，让验证工具的执行结果也受到同样的文本特征干扰，比如验证工具运行时，如果草稿中包含某个关键词，就自动返回通过。

判据：如果在这种对抗性训练集上，VERSE 带自我进化的验证选择准确率不高于固定优化器基线，甚至低于 blank，那么本文的核心主张就被推翻。因为这说明执行验证的价值依赖于“执行结果与真实因果结构一致”这一前提，而这个前提在对抗性环境下不成立。

更强的版本：让验证工具的执行结果在训练任务上系统性地与测试任务相反。比如训练任务中，某个修复总是通过验证但在测试集上总是失败。如果优化器学会信任验证工具，它会在测试集上表现更差。这个实验直接检验 Theorem 1 中 ρj 是否真的小于 1。如果验证反馈的分布不依赖于真实原因，ρj = 1，验证就不应该有帮助。如果实验显示验证仍然有帮助，说明论文的理论框架有漏洞。

12. 落地判断

可以用于“抢占式 GPU 自托管 27B 模型做多智能体脚手架”，但需要适配。

怎么用：把 VERSE 的验证工具和训练审计集成到多智能体脚手架的进化循环中。执行器是 27B 模型，运行在抢占式 GPU 上。优化器可以用同一个 27B 模型或更小的模型。关键适配点有三个。第一，抢占式 GPU 意味着运行可能随时中断，所以验证工具的结果必须持久化，不能依赖单次连续运行。第二，多智能体脚手架的状态空间比单 agent harness 更大，trace minimization 的压缩比可能更低，需要调整归因策略。第三，27B 模型在单张 24GB 卡上需要量化，量化可能引入额外的执行噪声，验证工具要求两次通过会更重要。

成本量级：论文表 4 显示，VERSE 带自我进化的 agent runs 是 1453，而 Meta-Harness 基线是 1326，增加约 10%。但墙钟时间从 21.6 小时增加到 38.0 小时，增加约 76%。在抢占式 GPU 上，墙钟时间的增加意味着更高的抢占风险和更高的实际成本。如果每轮进化需要 6 小时以上，抢占式环境下的重启成本会显著放大。

最大的坑：验证工具本身消耗执行预算，而抢占式 GPU 的不可靠性会让验证结果更难解读。如果一次验证运行因为抢占而中断，优化器可能把中断误读为测试失败，从而错误地驳回有效草稿。需要在验证工具中区分“测试失败”和“运行中断”，并把中断作为 inconclusive 结果返回，不计入通过或失败。论文的验证工具已经有 inconclusive 类别，但在抢占式环境下这个类别的频率会高得多，优化器需要学会处理它。