HarnessDev论文解读：反馈分数与留出分数仅53%一致，自我改进循环存在选择偏差

Reddit社区最近讨论的一篇论文HarnessDev，测量了一个此前少有人量化的过程：让AI agent自行修改其执行框架（harness），根据反馈决定是否保留修改，如此循环。这类「自我改进」的叙事在AI圈并不少见，但真正把反馈信号与留出信号的一致性摊开来算的，HarnessDev算是第一篇。

反馈分数为什么不可靠

论文的核心数据很直接。在64次相邻版本切换中，反馈分数和留出分数只有34次同向移动，一致率53.1%。换句话说，如果你只依赖反馈信号来判断一次harness修改是否真的变好了，准确率跟抛硬币差不多。

更值得关注的是最终结果：9个演化谱系中，只有2个最终停在留出集上表现最好的版本。演化阶段的平均增益是+3.11分，但这个增益能否泛化，反馈门控本身给不出可靠答案。

这指向一个被长期忽略的问题——选择策略。论文作者和Reddit发帖者的判断一致：这不是提案器（proposer）能力不足的问题，而是选择策略（selection policy）的问题。即使agent能提出好的修改候选，如果筛选机制本身有偏差，好的修改也可能被拒绝，坏的修改反而被保留。

反馈分数（feedback score）与留出分数（held-out score）的区别是理解整篇论文的关键前提。反馈分数指的是agent在演化循环中实际接收到的评估信号——通常来自它正在优化的那批任务，这些任务对提案器是可见的、可被反复访问的。留出分数则是在一组提案器从未见过、也未参与选择的独立任务上测得的分数，目的是检验修改是否真正泛化。两者一致率低，本质上是过拟合与泛化差距在agent自我改进场景下的具体体现：agent能把可见任务上的分数推高，但这个提升未必迁移到不可见任务。机器学习中经典的「训练集—验证集—测试集」三分法正是为了防止这种泄漏，而HarnessDev的贡献在于量化了当agent既是提案者又是被评估对象时，这种泄漏有多严重——53.1%意味着反馈信号几乎不携带关于泛化的有效信息。

执行器依赖：同一个harness在不同模型下表现悬殊

论文还揭示了一个令人不安的现象：执行器依赖极其严重。同一个harness在一个模型下得分69.3，换到另一个模型下只有33.0。这意味着harness的评估结果高度依赖于它运行在哪个基础模型上，跨模型的可迁移性远没有想象中那么好。

这个发现对实际部署有直接影响。如果你的评估流程只用一个模型来跑反馈分数，那这个分数很可能在换模型后完全失效。而论文中53.1%的一致率，某种程度上也是这种依赖性的一个侧面反映。

**执行器（executor）**在这里指承载agent运行的基础模型，harness则是包裹在模型外层的执行框架——包括提示模板、工具调用协议、循环控制、结果解析等。执行器依赖意味着harness的收益并非模型无关：一个在GPT-4上有效的工具调用格式，在能力较弱或指令遵循风格不同的模型上可能完全失效。这种耦合在工程上有直接后果。首先，它使harness的评测结果无法跨模型搬运，今天调好的框架换模型后可能清零。其次，它让「自我改进」的循环更脆弱——如果演化过程中底层模型升级或降级，之前累积的harness修改可能集体失效。论文中69.3到33.0的落差提示，评测harness时必须报告完整的模型—harness组合，而非孤立地宣称某个harness「更好」。

改进思路：拒绝记忆与保守发布策略

发帖者提出了两条与论文循环不同的改进方向，并在自己维护的工具reef中实现了这些策略。

发布门槛：从净胜改为无回退

默认策略是：候选方案在任务对比中赢的次数多于输的次数，且超过设定的噪声底线，就允许发布。方法指南中的Pareto策略更严格——只有当没有任何任务回退、且至少有一个任务改善时才发布。

但这里有一个微妙的陷阱：这条规则只能在门控运行的列表上拒绝候选，而一旦你在某个列表上做选择，这个列表就成了你的反馈分数，而非留出分数。所以它并不能单靠自己恢复论文中那30个坏切换的损失。它能做的是：阻止一个在列表上任何位置都输了的候选，仅凭净胜就发布出去。留出检查必须是提案器从未见过的列表，这一点需要使用者自己保证。

Pareto策略借用了多目标优化中的帕累托改进概念：一个候选方案只有在不使任何单个任务变差、且至少让一个任务变好的情况下才被接受。相比「净胜为正」的规则，Pareto排除了「赢多输少但存在明显回退」的候选——后者在平均值上好看，却可能在某些任务上引入严重退化。代价是接受率极低，因为真实改进往往伴随局部权衡。这也是文中开放问题的技术根源：Pareto规则天然保守，在信号噪声大时能过滤假阳性，但也可能因要求过于严格而拒绝掉真实但非均匀的收益。理解这一点，才能看清「无回退」并非单纯的风险厌恶，而是一种在反馈信号可靠性仅53%时的统计防御策略。

拒绝记忆：让提案器不再重复失败

提案器可以接收最近被拒绝的提案及其裁决理由，以及上一步的失败清单。这样它就能避免反复提出同一个已经被否决的切换。这是一个低成本的改进，但论文的循环中似乎没有包含这一机制。

**提案器（proposer）**是自我改进循环中负责生成候选修改的组件，通常由LLM驱动，依据当前harness状态和历史反馈提出下一步改动。「拒绝记忆」是一种上下文工程手段：把此前被否决的提案及其裁决理由作为额外上下文喂回给提案器，使其不再重复已知失败的路径。这与强化学习中的负经验回放、或软件工程中的回归测试思路相通，但实现成本极低——只需在提示中附带一份拒绝日志。其局限在于上下文窗口有限，长期演化后日志会膨胀，需要摘要或检索机制来压缩；此外，它只能避免重复错误，不能直接引导提案器发现新方向。论文的循环中缺失这一机制，意味着agent可能在同一个死胡同里反复试探，浪费演化预算。

任务列表才是根本瓶颈

发帖者最后指出了一个所有改进都无法绕开的问题：任务列表本身。

列表之所以短，是因为每一步都有成本。但整篇论文恰恰在警告：一个短的、分布内（in-distribution）的任务列表，会被反馈循环逐渐「钻空子」。Agent会学会在这个特定列表上刷分，而不是真正提升能力。

这就引出一个开放问题：以留出任务上的无回退作为接受规则，是正确做法，还是过于保守以至于永远无法推进？论文中那30个坏切换的数据，让发帖者倾向于保守。在反馈信号可靠性只有53%的情况下，保守可能是更理性的选择——宁可错过一些真实增益，也不要让回退悄悄混入。

这个问题的答案可能取决于具体场景：如果你的harness演化周期短、人工审核成本低，激进策略或许可行；但如果是长时间无人值守的自动演化，保守的接受规则几乎是唯一合理的选择。