当评估者落后时：用于持续智能体自我改进的评估标准与执行框架协同进化

1. 问题与价值

这篇论文解决的是持续智能体自改进过程中诊断信号僵化的问题。具体来说：当智能体系统（agent）反复从执行经验中优化自身的 harness（即围绕大模型的外部执行基础设施，包括提示词、工具、记忆、控制逻辑等）时，用于指导优化的监督信号往往保持相对静态。随着 harness 不断演化，智能体的行为弱点分布会发生变化——早期占主导的失败模式被缓解后，更细微或此前未见的失败模式会浮现。如果诊断标准不跟着变，优化就会逐渐过拟合到演化阶段暴露的特定失败模式上，导致对未见任务的泛化能力下降。

这个问题重要，是因为近年来自改进智能体的研究重心正从「优化模型参数」转向「优化外部 harness」。如果 harness 优化只在训练分布内有效、一换任务就退化，那么这种自改进的实际价值会大打折扣。论文引用的受控评估（Wang et al., 2026c）已经提示了这种风险。

受益方是需要长期部署自改进智能体系统的开发者。他们可以获得一个能持续追踪行为弱点漂移、并在多轮演化中保持泛化能力的框架，而不是每轮都依赖人工重新审视失败模式。直接受益方式体现在：在未见任务（held-out）上的平均 Pass@1 比最强基线高 4.5 到 5.3 个百分点（Qwen 模型上从 49.2 到 53.7，GLM 模型上从 32.7 到 38.0，均为 held-out 平均）。

2. 已有工作的不足

在 RuHarness 之前，harness 演化方向的代表性工作有三类：

• Self-Harness（Zhang et al., 2026a）：从轨迹中挖掘模型特定弱点并提出针对性更新。不足在于它用任务级反馈（成功/失败）作为优化信号，对失败背后的行为缺陷提供的信息有限。
• Meta-Harness（Lee et al., 2026b）：用累积候选和轨迹搜索可执行的 harness 代码。不足在于搜索过程缺乏对「当前哪些弱点最值得解决」的动态诊断。
• Agentic Harness Engineering / AHE（Lin et al., 2026a）：通过可观察、可验证的组件更新改进 harness。不足在于其诊断信号在演化过程中基本保持固定。

共同的核心不足是：这些方法把诊断信号当作相对静态的东西。它们没有显式机制追踪不同弱点的重要性如何随 harness 演化而变化。论文用 Figure 1 的示例说明：在某一轮，工具误用占失败的 70%，是首要问题；但 harness 更新后，工具误用降到 12%，而「缺失验证」升到 65%。如果诊断标准还停留在「工具误用优先级最高」，优化就会瞄准已经缓解的问题，而真正的新弱点得不到关注。

3. 重建作者的思考路径

如果面对第 2 项里的不足，我大概会这样推：

第一步：先想到「把诊断做得更细」。 既然任务级反馈太粗，那就从轨迹里提取失败模式，比如「工具调用后没有验证结果」「推理步骤跳步」。这其实就是 Self-Harness 已经在做的事。但问题来了：提取出来的失败模式怎么排序？如果每轮都重新提取、重新排序，那排序依据是什么？

第二步：撞上「排序依据会过时」的矛盾。 假设第一轮发现「工具误用」是最常见的失败，于是优先修它。修完之后，第二轮再跑，工具误用大幅减少，但「缺失验证」冒出来了。如果排序依据还是第一轮的统计，那第二轮还是会优先修工具误用——但它已经不是主要问题了。这说明诊断标准的优先级必须随 harness 状态更新。

第三步：想到「让诊断标准本身也演化」。 既然 harness 在变，行为分布在变，那诊断标准也应该跟着变。但这里有个新问题：怎么判断一个诊断标准是否还有用？不能只看它「是否被违反」，因为一个标准被违反得少，可能是因为问题真的解决了，也可能是因为这个标准本身已经不再适用于当前行为模式。需要区分「已缓解」和「已过时」。

第四步：撞上「用结果标签会泄漏信息」的问题。 如果判断标准是否有用时直接看「违反该标准的轨迹是否失败」，那这个判断本身就用到了任务结果。这会让诊断标准变成对成功/失败标签的简单代理，而不是对行为缺陷的独立描述。于是需要结果盲判：判断者只看行为证据，不看最终结果。

第五步：改完发现「少量观察不可靠」的新问题。 演化早期，轨迹数量有限。某个标准可能因为恰好覆盖了几个失败案例而显得很有诊断价值，但这可能是小样本噪声。如果直接按点估计排序，会选中一批「看起来有用但其实不稳定」的标准。于是需要保守的后验估计：用 Dirichlet 后验的下分位数来排序，压低那些只靠少量观察支撑的高分标准。

第六步：再想「标准选出来了，怎么指导 harness 更新」。 一个行为弱点可能涉及 harness 的多个部分。比如「缺失验证」既涉及终止条件（Terminate），也涉及观察处理（Observe）。如果只改一个组件，可能治标不治本。于是需要协调式候选生成：每个候选是一个多组件联合修改方案，而不是单点修补。同时，候选必须通过验证集筛选，避免在演化轨迹上过拟合。

与论文实际路径的差异：我上面的推理把「结果盲判」放在比较靠后的位置，作为防止信息泄漏的手段。论文实际把它放在 rubric evolution 的核心位置（§3.2 的 Outcome-blind behavioral assessment），并且把它和「标准生命周期管理」绑定在一起——新标准要经过 birth check，进入 probation，再根据诊断价值晋升为 active。我最初没有明确想到「生命周期」这个机制，而是倾向于每轮重新评估所有标准。论文的生命周期设计实际上更节省计算，也避免了旧标准被反复重新评估的浪费。另一个差异是：我倾向于直接按诊断价值的点估计排序，论文则用了 Dirichlet 后验下分位数，这个保守化处理在我最初的推理中没有出现。

4. 核心 intuition

可以把 RuHarness 想象成一个持续更新的体检报告系统。

一个病人（智能体）在长期治疗（harness 演化）中，病情会变化。最初的主诉是「头痛」（工具误用），医生据此开了药。复诊时头痛缓解了，但出现了「胃痛」（缺失验证）。如果医生还拿着第一份体检报告，继续按头痛的优先级开药，胃痛就被忽略了。更糟的是，旧报告里「头痛」那一项可能还标着「高风险」，医生会继续针对一个已经缓解的问题用药。

RuHarness 的做法是：每次复诊都重新做检查（从当前 harness 的轨迹中提取失败证据），重新评估每项指标对当前病情的诊断价值（结果盲判 + 诊断效用），然后只把当前最有区分力的几项指标（rubric frontier）交给医生，让医生针对这些指标开处方（协调式 harness 更新）。处方生效后，病情又变，下一轮复诊再更新报告。

这个类比能对上机制的关键点：诊断标准不是一次性生成的，而是随被诊断对象的状态变化而持续更新的。静态诊断标准之所以有害，不是因为它「错了」，而是因为它「过时了」——它描述的是过去的病情，却还在指导现在的治疗。

5. 方法 pipeline 举例

假设我们在做知识工作（Knowledge Work）任务，当前是第 3 轮演化，harness 为 H3。

输入：一个具体任务——「读取 sales_data.csv，计算 2024 年各季度总销售额，将结果写入 quarterly_summary.csv」。

第 1 步：执行当前 harness 收集轨迹。 用 H3 在演化集 Devo 上跑任务，得到一批成功和失败轨迹 T3。假设这个具体任务失败了：智能体生成了一个 Python 脚本，但没有实际执行它，就直接声称「已完成」，最终输出文件不存在。

第 2 步：失败分析。 对这条失败轨迹生成结构化失败报告，提取可观察事实：divergence_step 指向「生成脚本后直接给出最终答案」那一步，failure_mode 标记为「未执行生成产物」。

第 3 步：发现新标准。 汇总多条失败报告后，发现「生成脚本但未执行」是跨任务反复出现的模式。于是提出新标准 c_new：「在声明任务完成之前，智能体执行或检查其生成的产物并验证输出结果。」

第 4 步：结果盲判。 对 c_new 和现有标准在 T3 的所有轨迹上做判断。判断者只看行为证据，不知道每条轨迹最终成功还是失败。对这条失败轨迹，c_new 被判为 Violated；对另一条成功轨迹（智能体执行了脚本并检查了输出），c_new 被判为 Satisfied。

第 5 步：计算诊断效用。 基于判断结果和任务结果，计算 c_new 的五个分量。假设在 60 条失败轨迹中，c_new 在 39 条上判为 Violated，在 21 条上判为 Satisfied 或 N/A；在 36 条成功轨迹中，c_new 在 3 条上判为 Violated。那么 discrimination 约为 39/(39+21) - 3/(3+33) = 0.65 - 0.083 = 0.567，coverage 约为 39/60 = 0.65。综合效用较高。

第 6 步：保守排序并选 frontier。 用 Dirichlet 后验下 0.2 分位数估计 c_new 的保守效用。假设它排进 Top-10，进入本轮 rubric frontier R̂4。

第 7 步：frontier 引导 harness 更新。 c_new 映射到 Terminate 坐标（完成控制）和 Observe 坐标（观察处理）。生成最多 3 个候选更新。候选 A：在 Terminate 中增加完成前检查——要求确认输出文件存在且文件名匹配。候选 B：在 Observe 中增加规则——脚本执行后必须读取并检查错误输出。候选 C：同时修改 Terminate 和 Observe。

第 8 步：验证集筛选。 在独立验证集 Dval 上评估 H3 和三个候选。假设候选 A 的验证分数比 H3 高 0.08，超过阈值 ε = 0.05，被接受。H4 = H3 ⊕ ΔA。

第 9 步：进入下一轮。 用 H4 重新执行任务，收集新轨迹 T4，开始新一轮 rubric evolution。

6. 核心数学推导

论文的核心公式是诊断效用的定义（公式 4）和保守排序（公式 5）。这里推导诊断效用的各个分量。

符号先解释：设 c 是一个行为标准。对一批轨迹，结果盲判给每条轨迹一个标签：Violated（违反）、Satisfied（满足）、N/A（不适用）。同时我们知道每条轨迹的任务结果是成功（pass）还是失败（fail）。定义：

• vfail：失败轨迹中被判 Violated 的数量
• sfail：失败轨迹中被判 Satisfied 的数量
• nfail：失败轨迹中被判 N/A 的数量
• vpass、spass、npass：成功轨迹中对应的三个数量

Discrimination（区分度）：衡量标准能否区分失败和成功轨迹。它比较失败组和成功组的违反率：

D(c) = vfail / (vfail + sfail) - vpass / (vpass + spass)

第一项是失败轨迹中的违反率，第二项是成功轨迹中的违反率。如果标准在失败轨迹上经常违反、在成功轨迹上很少违反，D(c) 接近 1；如果两组违反率相同，D(c) 接近 0。注意分母排除了 N/A，因为不适用的情况不提供行为证据。

Coverage（覆盖率）：衡量标准覆盖了多少失败轨迹：

C(c) = vfail / (vfail + sfail + nfail)

分母是所有失败轨迹。这个分量保证选出的标准不是只对极少数失败有效。

Predictive Validity（预测效度）：衡量观察到违反是否增加任务失败的概率。先看违反轨迹中失败的比例：

Pr[fail ∣ violated] = vfail / (vfail + vpass)

再看标准适用（即非 N/A）的轨迹中失败的基线比例：

Pr[fail ∣ applicable] = (vfail + sfail) / (vpass + spass + vfail + sfail)

两者相减：

P(c) = vfail / (vfail + vpass) - (vfail + sfail) / (vpass + spass + vfail + sfail)

如果违反该标准时失败概率显著高于基线，P(c) 为正。

Novelty（新颖性）：衡量标准是否识别了其他标准没识别的失败。设 Uc 是只被标准 c 违反的失败轨迹集合，NF 是失败轨迹总数：

N(c) = ∣Uc∣ / NF

Redundancy（冗余度）：衡量标准 c 与其他标准的行为重叠。设 V(c) 是被 c 违反的轨迹集合：

Red(c) = max_{c' ≠ c} Jaccard(V(c), V(c'))

取与其他标准的最大 Jaccard 相似度。如果某个标准和 c 几乎总是违反同样的轨迹，Red(c) 接近 1。

总效用：把五个分量加权组合：

U(c) = α·D(c) + β·C(c) + γ·P(c) + δ·N(c) - λ·Red(c)

论文设 α = γ = 1.0，β = δ = λ = 0.5。冗余度是惩罚项，所以前面是减号。

保守排序：直接按 U(c) 的点估计排序不可靠，因为小样本下 D、C、P 的估计方差大。论文对每个标准构造一个 2×3 列联表（结果：pass/fail；判断：Violated/Satisfied/N/A），加 Jeffreys 先验（每格加 0.5），得到 Dirichlet 后验。从后验中采样 B = 2000 次，每次重算 D、C、P（N 和 Red 保持固定），得到效用分布。取这个分布的 0.2 分位数作为保守效用：

Ũ(c) = Quantile_{0.2}({U^(b)(c)}_{b=1}^{2000})

然后从 active 标准池中选保守效用最高的 Top-K（K = 10）个标准组成 frontier。

一句话总结：这个公式在算「在考虑统计不确定性后，每个行为标准对当前 harness 的诊断价值有多可靠」，目的是选出既有效又稳定的标准来指导下一轮 harness 更新。

7. 实验设计

数据集：EvoAgentBench，覆盖五个领域——信息检索（基于 BrowseComp-Plus）、知识工作（基于 GDP-Val）、软件工程（基于 SWE-Bench）、代码实现（基于 LiveCodeBench）、数学推理（基于 OmniMath）。数据分为三部分：演化集（held-in）、验证集、测试集（held-out）。测试集在演化过程中完全不接触。五个领域的演化集（held-in）规模分别是 100、60、45、128、380，把这五项相加：100+60+45+128+380=713 个任务（数据取自原文 Table 3 的 Evol. Held-in 列，验证集与测试集另计）。

模型：Qwen3.5-35B-A3B 和 GLM-4.7-Flash 两个骨干模型。智能体框架用 DeepAgent。

基线：ACE（上下文演化）、EvoSkill（技能演化）、Self-Harness、Meta-Harness、AHE（后三个是 harness 演化）。加上 Vanilla Agent 作为起点。

指标：Pass@1，按领域用各自基准的评估器打分。主结果报告 held-in 和 held-out 的宏平均。

消融：三个变体——去掉 rubric 模块（w/o Rubric Module）、固定初始 rubric 不演化（w/o Rubric Evolution）、用整个 rubric 池而非 frontier（w/o Rubric Frontier）。在 Qwen3.5-35B-A3B 上做。

实验能否支撑结论：主结果表（Table 1）支撑「RuHarness 优于基线」和「held-out 增益更大」两个主张。消融表（Table 2）支撑「rubric 模块必要」「静态 rubric 有害」「frontier 选择有用」三个主张。Figure 3 的 Jaccard 相似度分析支撑「frontier 确实在变化」的主张。Figure 4 的三张子图支撑「frontier 转换追踪诊断相关性」「优先化的弱点被逐步缓解」「提交的 harness 更新带来更持久的缓解」三个主张。Figure 5 的演化轨迹支撑「RuHarness 在后期仍能持续改进」「held-out 更稳定」两个主张。附录的种子鲁棒性实验（Table 6）支撑「结果对随机性稳健」的主张。

缺什么：第一，所有实验都在 DeepAgent 单一框架内完成，没有验证六坐标 harness 抽象在其他智能体架构上的通用性——论文自己在 Limitations 里也承认了这一点。第二，演化轮数固定为 10 轮，没有考察更长周期的行为。第三，没有报告计算成本——每轮要跑演化集、验证集、多个候选，LLM 调用量可能很大，但论文没有给出 token 或时间开销。第四，held-out 的绝对分数仍然不高（Qwen 上 53.7，GLM 上 38.0），说明泛化问题远未解决，只是相对改善。

8. take-aways

• 静态诊断标准会随 harness 演化而失效，甚至比没有 rubric 更差。消融中 w/o Rubric Evolution 的 held-out 平均为 44.4，比 w/o Rubric Module 的 45.8 还低 1.4 个百分点，说明过时的诊断标准会产生误导性引导。
• 诊断标准需要结果盲判。判断标准是否被违反时不能看任务结果，否则标准会退化成成功/失败标签的代理，失去对行为缺陷的独立描述能力。
• frontier 选择比用全部标准更有效。w/o Rubric Frontier 的 held-out 平均为 49.0，比完整 RuHarness 的 53.7 低 4.7 个百分点。附录 Figure 8 显示完整池中 29.9% 的标准诊断价值非正，而 frontier 中只有 0.5%。
• 优先化的弱点不会立刻被解决，但会在后续轮次逐步缓解。Figure 4b 显示标准进入 frontier 后第一轮违反率几乎不变，之后才明显下降，说明 frontier 的作用是引导后续优化而非即时修复。
• RuHarness 的 held-out 增益大于 held-in 增益。Qwen 上 held-in 比最强基线高 1.7 个百分点，held-out 高 4.5 个百分点；GLM 上分别为 2.7 和 5.3 个百分点。这说明动态诊断的主要价值在于改善泛化而非单纯提升演化集表现。

9. 最脆弱的假设

最脆弱的假设是：结果盲判的可靠性。整个框架的有效性依赖于 LLM 判断者能够在不知道任务结果的情况下，仅凭行为证据准确判断一个标准是否被满足、违反或不适用。如果这个判断本身噪声很大，那么后续所有的诊断效用计算、frontier 排序、harness 更新引导都会建立在不可靠的信号上。

论文没有直接给出这个假设成立的证据。它没有报告判断者的一致性（如多次判断的吻合率）、判断者与人工标注的一致率、或者判断错误对最终性能的敏感性分析。附录 A.2 的公式都假设判断标签是准确的，但从未验证这个前提。Figure 4 的间接证据（frontier 转换与诊断分量变化一致、优先化后违反率下降）只能说明整个 pipeline 在统计上有效，不能分离出「判断错误」的贡献。如果判断者系统性偏差——比如倾向于把长轨迹判为 Violated，或者对某些行为模式视而不见——那么诊断效用会被系统性扭曲，而论文没有排除这种可能。

10. 一周最小复现

目标：复现核心结论——动态 rubric 比静态 rubric 在 held-out 上更好，且 frontier 选择优于全量 rubric。

硬件：1 张 24GB 消费级显卡。Qwen3.5-35B-A3B 是 MoE 模型，35B 总参数、3B 激活，用 4-bit 量化后可以在 24GB 上跑推理。GLM-4.7-Flash 是 API 模型，不需要本地显存。

步骤：

1. 第 1 天：选一个领域，建议用 Knowledge Work（演化集只有 60 个任务，验证集 36 个，测试集 50 个，规模最小）。用 DeepAgent 或类似的轻量 agent 框架搭好基础 harness。如果 DeepAgent 不可用，可以用 LangGraph 或自写一个简单的 ReAct 循环替代，只要暴露提示词、工具配置、终止条件这几个可编辑接口即可。

1. 第 2 天：实现三个变体——完整 RuHarness、静态 rubric（初始 rubric 固定不演化）、无 frontier（用全部 active 标准）。简化 rubric 生命周期：跳过 probation/dormant/retired 的复杂状态机，只保留 birth check 和 active 判定。诊断效用计算照搬公式 4，保守排序可以简化为直接用点估计（如果时间不够跑 2000 次后验采样）。

1. 第 3-4 天：跑 5 轮演化（不是论文的 10 轮，时间不够）。每轮在 60 个演化任务上收集轨迹，做失败分析，更新 rubric，生成最多 2 个候选 harness 更新（不是 3 个），在 36 个验证任务上筛选。用 4-bit 量化的 Qwen3.5-35B-A3B 本地跑，或者直接用 GLM-4.7-Flash API 以节省时间。

1. 第 5 天：在 50 个 held-out 任务上评估三个变体的最终 harness。预期结果：完整 RuHarness 的 held-out 分数比静态 rubric 高，且静态 rubric 可能比无 rubric 更差。论文中 Knowledge Work 在 Qwen 上的 held-out 分数是 52.0（完整）、34.0（静态 rubric）、44.0（无 rubric），差距很大，5 轮演化应该能看到方向一致的趋势，虽然绝对值会低一些。

1. 第 6-7 天：分析 frontier 的 Jaccard 相似度变化（应该看到与初始 frontier 的相似度下降），并统计 frontier 中标准的诊断价值分布（frontier 应该比全量池有更高的平均诊断价值）。写报告。

预期指标：完整 RuHarness 的 held-out 分数比静态 rubric 高至少 5 个百分点，frontier 与初始 frontier 的 Jaccard 相似度在 5 轮后降到 0.5 以下。

11. 反例设计

核心主张：动态演化的 rubric 通过追踪行为弱点漂移，改善了 harness 演化的 held-out 泛化能力。

反例实验：构造一个行为弱点不随 harness 演化而漂移的场景。具体做法：选一个任务领域，其中失败模式高度集中且稳定——比如数学推理任务，如果主要失败模式始终是「跳步推理」和「未验证中间结果」，无论 harness 怎么改，这两个弱点都占失败的 80% 以上。

操作：在这个场景下跑完整 RuHarness 和静态 rubric 变体，各 10 轮。如果 RuHarness 的 held-out 分数没有显著超过静态 rubric（差距小于 2 个百分点），则说明动态 rubric 的价值确实依赖于弱点漂移的存在。更进一步，如果 RuHarness 的 frontier 在 10 轮内几乎没有变化（Jaccard 相似度始终高于 0.8），但 held-out 仍然没有优势，那就直接推翻了「动态诊断是泛化改善的原因」这个因果主张。

判据：在弱点分布稳定的场景下，RuHarness 与静态 rubric 的 held-out 差距应趋近于零。如果差距仍然很大，说明 RuHarness 的增益来自其他机制（比如 frontier 选择本身、协调式候选生成、验证集筛选），而不是论文强调的「追踪漂移」。这不会完全推翻方法有效性，但会推翻论文对有效原因的解释。

12. 落地判断

能否用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」：可以，但有明确边界。

怎么用：27B 模型（假设是 Qwen 系列或类似规模）在 24GB 显卡上做 4-bit 量化推理是可行的。RuHarness 的六坐标抽象可以映射到多智能体脚手架的配置层——Equip 对应工具和技能库，Instruct 对应各角色的系统提示词，Act 对应行动策略，Observe 对应消息解析和过滤，Remember 对应共享记忆和上下文管理，Terminate 对应任务完成判定。每轮演化时，用当前脚手架配置跑一批任务，收集失败轨迹，让同一个 27B 模型做失败分析和结果盲判，更新 rubric，生成候选配置更新，在验证集上筛选。

成本量级：这是最大的坑。每轮演化需要跑演化集（至少几十个任务）、验证集（几十个任务）、多个候选（最多 3 个）。每个任务是多步 agent 执行，单任务可能消耗几万到几十万 token。按 60 个演化任务 + 36 个验证任务 + 3 个候选（每个候选也要在验证集上跑）估算，一轮的推理量大约是 60 + 36 + 3×36 = 204 个任务执行，加上失败分析、rubric 判断、候选生成的 LLM 调用。在单张 24GB 卡上，27B 模型 4-bit 量化的吞吐大约每秒 20-40 token，一个多步任务可能需要几分钟到十几分钟。204 个任务执行加上辅助调用，一轮可能需要 10-20 小时。10 轮就是 100-200 小时，约 4-8 天。如果用 API 模型做判断和生成（而非本地 27B），时间会缩短但成本转移到 API 费用。

最大的坑：验证集与真实部署分布的偏移。RuHarness 的候选筛选完全依赖验证集分数。在自托管多智能体脚手架场景中，任务分布可能高度动态——用户发来的任务类型会变，工具 API 会更新，其他智能体的行为会变。如果验证集不能代表真实部署分布，验证集筛选会选出一个在验证集上表现好但在真实场景中退化的 harness。论文用 held-out 测试集证明了在固定基准上的泛化，但没有证明在分布持续漂移的开放环境中的泛化。落地时需要在验证集之外增加一个真实流量的影子评估通道，持续监控部署表现，一旦发现验证集分数与真实表现背离，就要重新划分验证集或调整接受阈值。