前文的 RRSI 留下一个具体问题。RRSI 把 harness 编辑器约束在一组固定的演化任务上，用成本规则和正则化阻止它把这组题目的特征写死；它同时也承认，真正要回答的是未见的部署任务。当任务在测试时才第一次出现，演化集给出的分数就不存在了。此时「改进」依靠什么信号？反馈若有系统性偏差，重复改进也可能重复放大偏差。

Google 参与的两篇 2026 年 10 月新工作正面处理这件事，但走的是两条不同的路。Harness²（arXiv:2610.14224v1，2026-10-09 提交）说：没有真值验证器，就用同一任务上两个候选 harness 的行为差异作为证据，并把这套改进过程本身也变成可被改进的对象。DuoDiscover（arXiv:2610.17184v1，2026-10-12 提交）说：当一次真实评估要几十分钟到 28 小时，搜索的首要任务是先造出便宜的排序器，而造出来的排序器必须持续被真实评估复核。

按 PDF 首页核对，Harness² 由 Northwestern University 与 Google Cloud AI Research 的研究者合作完成；Ruiyao Xu 标注 Northwestern，并注明工作期间在 Google 实习。DuoDiscover 的署名单位包括 Google、UC Berkeley 和 Stanford。两篇均在 2026 年 10 月提交 arXiv，本文核对 v1，截止日为 2026-10-27。Harness² 原文、DuoDiscover 原文

RRSI 的固定演化集，与它留下的缺口

RRSI 的组织方式是把「产生候选的过程」当作评价对象：版本化候选、记录假设、成本准入、冻结后再测。这套做法有一个隐含前提，训练用的演化任务集可以反复读。它的消融表之所以有意义，正是因为存在一个没有被搜索污染的留出集可以对照。

Harness² 研究的部署任务序列不给改进回路提供真值标签。研究者仍可以在回路之外使用基准评价最终输出；这与让在线编辑器看见评分是两回事。于是「改进」只剩三种可能的反馈源：外部真值（不存在）、模型自我判断（不可靠且与自身偏置相关）、以及执行行为本身的差异（存在，但只说明行为变了，不说明变对了）。Harness² 的整个设计就是尽量利用第三种反馈源，同时明确承认它的上限。DuoDiscover 面对的是另一类缺口：真值存在、可执行、但太贵，贵到一次搜索只付得起十几次。两篇合起来正好覆盖「没有反馈」与「反馈太贵」两种情形。

Harness²：把行为对比做成可复用的证据

固定权重，八个可编辑组件

Harness² 的对象写得很清楚：Agent = Model + Harness，模型参数冻结，harness 由 K=8 个可编辑组件构成——系统提示、护栏、记忆、技能、工具指引、脚本、子代理、中间件插件，每个组件在运行时以文件形式挂载。这套分解沿用 AHE 的文件级划分并加了一个组件。任务以流的形式到达，q₁…q_N，没有真值答案，也没有带标注的验证反馈；每个任务都从同一个公共初始 harness H₀ 出发，允许在有界预算内重跑当前任务，但不允许重放已完成的任务。

Propose–Probe–Compose 三步

一次对比式改进步记为

(H′, e′, ξ) = Φ(q_t, H, E; R_t)

其中 e = (τ, y) 是一条执行记录（轨迹 τ 与交付物 y），E 是任务本地的执行与改进历史，ξ 记录参考执行、候选 harness、探测结果、组合决策与后继执行。模型与环境被省略，因为它们在整步中不变；改进 harness R_t 在任务级递归期间同样固定。

三个步骤各自使用不同的证据：

Propose。 先取一条参考执行 e⁰ ~ A(q_t; M, H)。论文特意强调，参考执行揭示的是 harness 的行为，不是交付物是否正确。然后基于任务、当前 harness、参考执行、历史与库，提出两个候选：一个「不变式候选」针对跨领域会复发的代理缺陷（规划、工具使用、上下文管理、委派），一个「领域候选」针对当前领域的知识、流程与约束。两个候选都是通过编辑组件文件得到的可执行 harness。

Probe。 两个候选在相同任务、相同模型、相同环境配置下执行。把候选的轨迹与交付物同参考执行比较，得到「行为对比」：编辑是否缓解了目标缺陷、是否没有改变相关行为、是否引入退化。论文在这里给出了它最重要的一句限定：这些对比用于指导后续组合，而不是验证任务正确性，因为执行随机性与模型共有偏置限制了证据的可靠性。

Compose。 读取参考执行、候选 harness、候选相对当前 harness 的 diff、以及全部任务本地执行证据，形成后继 H′。组合是选择性的：可以合并被支持的改动、修改冲突的编辑、采纳其中一个候选，或者保留当前 harness。每个决策绑定一个具体观察，而不是假定的分数增益。组合后的 harness 再执行一次得到 e′。

两种任务级递归与最后的采纳

并行递归借用 RSA 的聚合思路，但作用对象是可执行 harness 及其行为后果，而不是推理输出：先收集 k 条参考执行，再独立提出 k 个不变式候选与 k 个领域候选，形成候选池 P；随后 k 个独立的组合会话各自拿到完整候选池，各自产出 H′_j 并执行。论文明确说明实现只做一次种群更新，k 控制的是宽度而不是深度。顺序递归则是把 k 个对比步串起来，第 r 步的条件是第 r−1 步的 harness 与累积历史。

k>1 时还有一个最终选择器：它在不知道候选来自哪个 harness 的前提下，把匿名化的交付物同任务要求和源材料比较，只能返回已有输出，不能合成新内容。采纳的 harness 记为 H_t★，星号表示被采纳而非被验证为最优。

harnessing-level 递归：改进器也是被改进对象

任务交付之后，流水线回顾完整改进记录 D_t，提取「哪些改动解决了观察到的缺陷、在什么条件下、带来什么后果」的经验。这里有一条严格的准入规则：只有被执行对比支持的经验才会被保留；仅仅被选中一个输出，不足以确立可迁移性。库的更新写成

R_{t+1} = Update(R_t, H_t★, D_t)

每个库条目包含一个可执行 harness 和一份 EXPERIENCE.md，记录适用情形、教训与支持证据；有索引供后续会话按需查看。下一个任务仍然从公共 harness H₀ 出发，但改进过程由 R_{t+1} 引导，早期组件是通过 Propose 被选择性复用或改写，而不是自动继承。模型权重、各阶段指令、决策规则全部不变，变的只有库。

一个构造的教学例子

下面这个例子是我为说明机制构造的，不是论文中的实验。

设任务 q 是「把四份月度报表里的三个字段汇总成一份备忘，并标出差异」。参考执行 e⁰ 的轨迹显示失败模式不是知识不足：它从未打开第二、第三份文件做交叉核对，写出结果后也从未重新打开文件检查。

  • 不变式候选：加一条流程护栏——强制先列出全部输入文件清单、把每个数字追溯到具体来源、写出后用一个校验脚本重新打开产出并核对。这会增加校验动作，是否值得还需结合整体成本判断。
  • 领域候选：加一个技能，说明该领域报表的字段映射与数字格式（千分位、负数括号、币种），并给出换算规则。

Probe 在相同模型下重跑。对比显示：不变式候选出现了 3 次「重开校验」，并抓到 1 处数字错位；领域候选格式全对，但仍漏掉一份文件。两次探测都没有告诉我们哪一份备忘是「正确」的——它们只显示行为是否发生了变化、变化是否指向被诊断的缺陷。

Compose 因此不是二选一：它把护栏与字段技能合并，保留全部四处编辑。这里的改进依据是轨迹中的具体变化；即使研究者事后给交付物评分，这个分数也不应被倒灌进没有真值反馈的教学设定。

用伪代码把这个流程写清楚：

Φ(q, H, E; R):
    e0 ← run(A(q; M, H))                 # 参考执行：看行为，不判对错
    c_inv ← edit(H, E, e0, scope=通用缺陷)
    c_dom ← edit(H, E, e0, scope=本领域)
    for c in (c_inv, c_dom):
        e_c ← run(A(q; M, c))            # 同模型、同环境
        Δ_c ← contrast(e0, e_c)          # 行为差，非正确性
    H′ ← compose(q, H, {(c, Δ_c)}, E; R) # 合并/改写/采纳一个/保持不变
    e′ ← run(A(q; M, H′))
    return (H′, e′, ξ)                   # ξ 记录证据与决策

上述机制依据 Harness² §2，其中行为对比指导修改，不充当正确性证明。

Harness² 的读数：条件必须跟着数字走

主表口径：模型是冻结执行器（Gemini 3.5 Flash、GLM-5），初始 harness 是现成的 OpenCode 与 Codex，默认 harness 编辑器是 Claude Opus 4.8 跑在 OpenCode 下；主表数字是单步（k=1），「+Recursion」是在此之上加并行任务级递归 k=5；三个基准各跑三次、每次打乱任务顺序，报均值与标准差；同时报 #Steps（每任务执行步数），使分数变化能与所需执行量对照。改进库在每条基准流开始时为空，每任务后更新。

配置 基准 / 单位 基础 harness Harness² 单步 变化
GLM-5 / OpenCode WorkBuddy-Bench 平均分 64.2 75.7 +11.5
Gemini 3.5 Flash / OpenCode JobBench 分数 31.5 36.0 +4.5
GLM-5 / OpenCode LAB Partial（逐条判据通过率） 59.6 71.4 +11.8

摘要里的三个「up to」正是这三行，分别来自不同的模型–harness–基准组合，不能合并成一个统一的提升幅度。同一张表里，GLM-5/OpenCode 在 WorkBuddy 上的 #Steps 从 13.5 增至 13.7。附录 B 将它定义为执行器会话中的模型轮数，并非整个改进过程的 token 账单。论文 Figure 6 另行统计提交最终产物之前的全部 token，包含执行与改进开销；质量—成本判断应使用这种完整边界。表 1–2、附录 B

消融在 Gemini 3.5 Flash / OpenCode、k=1 下做，隔离掉测试时预算的干扰：去掉改进库降 3.1（WorkBuddy）与 1.8（JobBench）；去掉「分范围提议」（用两个通用编辑器替代不变式/领域编辑器）降 2.9 与 3.7；去掉组合降 1.6 与 1.9。三者都贡献，其中分范围提议在 JobBench 上影响最大。

DuoDiscover：当真实评估本身成为瓶颈

瓶颈的量化

DuoDiscover 的问题设定更朴素：设真实目标 f: X → ℝ ∪ {⊥}，正确性检查失败即返回 ⊥，单次调用成本 c_f 从几分钟到几小时。为了给 vLLM 做多目标服务优化，一次真实评估要 85 分钟，20 小时预算里前沿编码代理也只能做十几次真实评估。这不是信号噪声问题，是采样次数问题。

论文的观察是：大的加速往往来自对少数小区域（targets）的集中改动，而这些区域的进展可以比整体便宜得多地度量。于是它要求代理同时发现「优化什么」和「怎么便宜地量」。这个双重发现是必要的：一个 target 只有在能为它造出与 f 相关的廉价 yardstick 时才有价值；一个 yardstick 只有在它对应的 target 真能改变 f 时才有价值。

对运行时间优化，可以用 Amdahl 定律理解区域选择：如果一个区域占原始耗时的比例为 w，即使将该区域耗时降到零，整体加速上限也只有 1/(1−w)；w=20% 时上限为 1.25 倍。这是对单一耗时目标的解释，不能不加定义地套用到任意综合分数。

yardstick 只需要保序

关键的形式条件不是数值接近，而是排序一致：对同一 target 内的两个编辑 x, x′，要求

sign(g_T(x) − g_T(x′)) = sign(f(x) − f(x′))

yardstick 的绝对值完全不需要追踪 f，因为它只用来决定追哪个编辑。orchestrator 度量 yardstick 的便宜程度为比值 r = c_f / c_g 并回传给代理，由代理决定是否保留。

一个真实例子：优化 vLLM 时，一个代理把调度器的 prefill 批处理选为 target，写了一个解码步时间的简单模型作为 yardstick，秒级完成，而真实评估要 85 分钟。

保真测试：因为搜索会利用缺口

这里有一段必须读的推理。搜索是针对 yardstick 优化的，因此它会因为利用 yardstick 与 f 之间的缺口而获得奖励——这就是 reward hacking。所以一个初始与 f 同序的 yardstick，可能在搜索针对的那批编辑上失效。

机制是：用 Kendall τ 秩相关度量 yardstick 是否与 f 同序，且只在真实分数差异超过评估噪声的状态对上计算，避免为真实评估自己都分辨不了的差别记功。当这些对上的 τ ≥ 0.5，yardstick 算作已验证。新造的 yardstick 尚未被检验，这不阻止代理去爬它。一旦累计到足够多被 g_T 与 f 双评的状态且相关性过线，即验证；若之后相关性下降，即失效，代理要么重建要么换 target。orchestrator 在每次真实评估之后重测每个 yardstick。

vLLM 案例里就发生过一次完整循环：由短负载扫描建成的 yardstick 先通过验证，再在高负载下排序反转而失效，重建后再次通过。

自底向上的编队

编队没有中心化的问题分解。每个代理在自己的代码库副本上选 target、造 yardstick，跑两个循环：快的循环用 g_T 打分、好了就留下、坏了就回退；慢的循环用真实评估确认 yardstick 报告的增益。orchestrator 定期读每个代理的进度摘要，只做三件事：终止没有进展的代理、在有望或未被覆盖的 target 上孵化新代理、向运行中的代理简报其余代理的发现。孵化的新代理有三种起点：全新开始、以最好代理的已确认真实状态为种子（transfer）、或把多个代理的已确认改动在同一个地方重新实现并逐项真实验证（combine）。

真实增益的确认是硬约束：每一次被报告的增益都必须由真实评估确认，按这一评测协议，代理分数的提升不能单独算作确认收益；真实评价器自身仍可能存在测量误差或覆盖不足。

上述过程依据 DuoDiscover §2。代理评估器的排序保真检查依赖真实评估提供的数据。

DuoDiscover 的读数与条件

主表口径：除注明外，所有运行 8 小时、相同硬件、N=4 个并行代理，骨干是 Claude Code v2.1 跑 claude-opus-5，小型快速辅助模型为 claude-sonnet-5，DuoDiscover 与所有基于 Claude Code 的基线同条件；FormulaCode 长任务 24 小时、TPU-Inference 10 小时。主结果是单次运行，方差在 20 个 SWE-fficiency 任务与 50 个 SOL-Exec kernel 上跑三次报告。仓库类按端到端加速比计分并检查正确性，kernel 按相对参考代码的加速或理论峰值吞吐百分比（SOL）计分；一次运行的报告分数是最终候选多次重评的中位数，从不报告运行中见过的最好分数，未通过正确性检查的候选记为无结果。

基准 / 单位与分母 对照 DuoDiscover
FormulaCode-V 的 25/108 个任务子集，几何平均加速比 Claude Code 1.778×；人类 PR 1.048× 2.156×
SWE-fficiency-Lite，100 个任务，几何平均加速比 Claude Code 12.81×；人类补丁 6.90× 15.02×
SOL-Exec，235 个 kernel，平均理论峰值吞吐百分比 Claude Code 67.31%；KDA 70.22% 79.74%

以上来自同一论文 Table 1 与 §3.1；它们的单位不同，不能横向排名。结果与条件

Table 3 的 yardstick 质量表提供了机制层面的证据（20 个 SWE-fficiency 任务、50 个 SOL-Exec kernel）：仓库上真实评估中位数 15 分钟、yardstick 40 秒，快 22 倍；kernel 上 14 分钟对 16 秒，快 53 倍。每任务被验证的 target 数在仓库上为 9.2 中的 5.3，kernel 上 15 个中 11 个；随后因排序漂移而失效的比例为 41% 与 45%；已验证 yardstick 与真实评估的中位 τ 为 0.66 与 0.76。

Table 4 的增量消融更能说明各部分的作用（SWE-fficiency ×/SOL-Exec %SOL）：Claude Code 12.85/69.12；只加 target 选择 12.71/69.68（几乎不变，因为真实评估仍是瓶颈）；加 yardstick 但不做保真测试掉到 10.33/66.91，低于不加 yardstick；加保真测试回到 13.25/72.57；加协同发现 13.76/74.43；加 orchestrator 到 14.93/80.80。

固定维度比较

维度 Harness² DuoDiscover
被改进对象 执行 harness（8 组件）+ 改进 harness 的库 代码库/内核本身的程序状态
基础模型权重 冻结，明确声明不变 不变（代理是现成的编码代理）
反馈信号 同任务下候选与参考执行的行为对比 yardstick 分数（廉价），关键增益由真实评估确认
真值对搜索是否可见 改进回路没有真值反馈；研究者另行评价最终产物 存在且可执行，但单次成本极高
搜索反馈的作用 诊断行为差异，不提供正确性保证 排序候选，增益仍要由真实评估确认
递归/层次结构 双层：任务级 + 改进方法论级 单层搜索，加一个协调层
递归深度控制 预先指定形式与预算 k，一次种群更新 编队规模 1–16，预算耗尽即止
升级判据 采纳（H_t★），不是验证最优 真实评估确认，否则计为无结果
主要成本项 额外的执行与编辑器会话 真实评估次数、前置预热、yardstick 重建
迁移证据 库的跨任务/跨基准转移与消融 跨骨干（Opus 5 / Gemini 3.8 Flash）与跨套件泛化

任务改善与改进方法迁移

Harness² 改的是运行框架与经验库，模型权重和固定流程规则保持不变。DuoDiscover 改的是目标程序，并在搜索期间建立或废弃代理评估器。两者的最终产物变好，都不自动证明“改进器更会改进自己”。

Harness² 额外做了库的迁移和消融：用 JobBench 得到的库支持 WorkBuddy 的改进，以及去掉某个任务自身条目后的跨任务复用。后一项利用了任务流中后续任务的经验，是回顾性测试，不能改称严格在线适应。库的这些实验支持经验有复用价值；要把它提升为改进能力持续增强的结论，还应比较早晚改进器在相同起点、相同预算和未见任务上的收益。Harness² §4 与附录 E.2

DuoDiscover 在另一编码代理与模型组合上也测到了收益，支持方法具有一定跨骨干适用性。但“相同方法换一个骨干仍有效”与“演化出的改进程序自身变强”是不同实验命题。论文更直接的贡献是缓解评估瓶颈，并用真实测试确认最终程序的优化结果。DuoDiscover Table 6

预算限制同样重要。Harness² 的并行实现只进行一次种群更新，k 控制宽度；顺序实现才把多个改进步串起来。二者均预先限定预算。DuoDiscover 也有明确的墙钟时间与编队规模。当前结果没有证明无上限递归增长。

结果与成本的解释边界

第一，「在 SWE-fficiency 上，它把人类专家的平均加速比翻了一倍」。这里是 15.02× 对 6.90×，是两个加速比之比约为 2.18 倍，不是绝对时间再省一半，也不是「比人类快两倍」。同一批任务上 Claude Code 已到 12.81×，所以相对该代理基线的加速比增量约为 17%；它与摘要中的比较使用了不同参照对象。

第二，成本。DuoDiscover 对单个 SOL-Exec kernel 的完整 8 小时、四代理搜索，按 50 个 kernel 平均后的 API 费用为 $375，而 Claude Code 是 $309——完整运行其实更贵。被引用的 $79.60（或 Claude Code 全程的 25.8%）是「在 2.8 小时达到 Claude Code 最终 8 小时分数」那一刻的花费，不是整次运行的花费。该账单按论文使用的 2026 年 9 月 API 标价估算，且不含真实评估消耗的 GPU 时间；追平点成本和跑满预算成本必须分别报告。附录 F.3、Table 17

还有一处口径需要注意：SOL-Exec 的 79.74% 是在全部 235 个 kernel 上，而 80.80% 是分析部分 50 个 kernel 的子样本，两者的分母不同，不能相减。同理，Harness² 摘要的 11.5 点是 GLM-5/OpenCode 的单步结果，不是 +Recursion 的结果，也不是 Gemini 的结果。

作者自己的限定值得原样保留。Harness² 附录 F：无真值监督时，精炼依赖行为对比与模型判断，这些信号有助于评估提议改动的效果，但对执行波动与共有模型偏置敏感，不保证正确性，也不确立被采纳的改动会迁移到另一个任务；递归预算增加必然增加推理成本，并行只降低延迟不消除计算，实验只在有界预算范围内刻画了这一权衡。它的附录 A.1 还有一句自制的提醒：这类对比表中的检查项记录的是更新机制的存在，不是改进能力的已验证增益。DuoDiscover 结论中的两条局限同样具体：当一个 target 造不出可信 yardstick 时，系统退回在昂贵真实目标上的常规搜索；造 yardstick 与跑初始保真测试有前置预热开销，因此在极短的评估预算下优势变小。

代理评估器不能替代最终验收

把两篇放在一起，最容易被误读成「代理评估器足够好，真实测试可以省掉」。机制上恰恰相反。

DuoDiscover 的结构里，yardstick 只决定追哪个编辑，判据是排序而非数值；保真测试本身也是用真实评估的结果去算的——它复用任何共享该 yardstick 的代理已经真评过的状态，正因为如此，一次 kernel 运行的 54 次真实评估才能覆盖 11 个已验证 yardstick。也就是说，保真测试不是真实评估的替代品，它消费真实评估。而且论文诚实记录了 τ 的双向选择效应：真实评估只发给 yardstick 偏好的候选，这压缩了分数区间、降低 τ；而只统计已验证的 yardstick，又抬高 τ。在从未通过验证的 kernel yardstick 上，中位 τ 只有 0.03。另一个不依赖这两重选择的视角是「被真评的候选中最终成为增益的比例」：kernel 上 DuoDiscover 为 37.0%（54 个中 20 个），Claude Code 为 21.1%（76 个中 16 个）。

Harness² 的结构更彻底：改进回路里根本不存在任务级真值，因此它也不产出任何可替代验收的东西。它产出的是「在相同条件下，这个改动让行为朝被诊断的缺陷方向改变了」这一条证据，以及围绕这条证据的决策记录。真实部署里判断交付物对不对，仍然要靠人或下游流程。

在 vLLM 与 FreeToken 两个案例上，论文做了一件值得单独标出的事：让这两个项目的维护者参与结果的初步审查，检查正确性并排除明显的 reward hacking，FreeToken 的部分方案已合入上游。这不是自动化验收，而是把最终判断交回真实系统与真实维护者——恰好说明代理评估器能加速搜索，但不能替代那个判断。

来源与复现状态

本文属于论文与原始表格审计，没有复现两套系统。示例是教学构造。论文中的结果均是对应实验设置下的作者报告，不能代替实际部署的验收。

更新于 2026-10-27 · 研究方法