PAPER · 论文信息
标题HarnessPro: Recursive Harness Self-Improvement with Pareto Optimization for Performance-Cost Trade-offs
作者Zhuoshi Pan¹、ZhiYuan Feng¹、Yukuo Cen²、Honglin Lin³、Junru Lu⁴、Zhongxia Chen⁵、Shuo Yang⁵、H. Vicky Zhao¹、Jie Tang¹
机构¹清华大学；²智谱（Z.AI）；³上海交通大学；⁴华威大学；⁵快手科技
原文https://arxiv.org/abs/2610.26770
INSIGHT · 核心洞察
编程 Agent 已经可以读自己过去的执行轨迹，找出失败原因，再改写包在模型外面的 harness，也就是提示词、工具、技能、钩子和验证规则这一层。这篇论文给出的判断标准很朴素：一次 harness 改动有没有价值，要同时看通过率和每题花了多少钱，而且只认那些没有被别的候选在两项上同时压过的版本。按这个标准，自改进的产物就不该只有一个“最强 harness”，而是一组面向不同预算的选项。
设想一个配置邮件服务的任务：Agent 三次都做对了，却每次都把整份配置文件和软件包源码倒进上下文，输入 token 动辄上百万。只看通过率，这条轨迹没有问题；如果诊断还能指出哪些探索和重复验证对结果没有贡献，下一版 harness 就可以在不丢掉关键检查的前提下少花钱。从“修失败”扩展到“修浪费”，是 HarnessPro 关注的路径。
论文在 Terminal-Bench 2、SWE-Bench Pro、ProgramBench 三个基准上验证，搭配 GPT-5.5 × Codex 和 GLM-5.2 × Claude Code 两组模型与 Agent，测试集分别为 59、100、100 题。这是一篇尚在评审中的 arXiv 预印本；HarnessPro 的结果是 2–3 次测试运行的均值，基线只报告单次数值，因此 1 个百分点左右的差距应当谨慎看待。
📌 一句话总结 本文提出 HarnessPro，一种不依赖标注的递归 harness 自改进（Recursive Self-Improvement，RSI）方法，围绕“改进能否同时提高通过率与降低成本”和“没有官方测试时如何可靠地评判候选”两个问题，区分省钱（lite）、均衡（medium）与求稳（heavy）三档 harness。
01
BACKGROUND
研究背景：自我改进也要算账
1.1 只盯通过率，账单会悄悄变高
harness 决定了 Agent 能看到什么信息、能调用哪些动作、动作怎样执行，因此同时决定成功率和资源消耗。近来的 RSI 方法让 Agent 读过去的轨迹来改 harness，但改进往往来自更多探索和更强的验证。论文举的例子是 RHO：在 SWE-Bench Pro 上，它把每题平均成本从 1.88 美元推到 2.68 美元，增加 42.6%。这并不说明 RHO 的改进无效，它的通过率确实从 59.0% 升到 80.0%；问题在于部署时，延迟和 token 账单同样是约束，单目标优化看不到这部分代价。
由此，作者把问题写成一个双目标优化：在所有 harness 中同时最大化通过率、最小化每题平均成本，并要求通过率不低于初始 harness。成本按 token 计算，区分未缓存输入、缓存输入和输出三种价格；延迟只作辅助指标，因为它受服务器负载和网络波动影响。这个设定有两个难点：harness 的组件组合是一个离散、无法求梯度的巨大空间；而更多推理和验证既能提分也会加钱，一刀切地削减又可能掉分。要区分“必要计算”和“可避免的开销”，只能回到轨迹本身。需要注意，这里的成本是按公开价目表折算的估计，不等于某个团队的真实账单。
1.2 同一张表上的四个维度
表 1 把几类相关方法放在同一组维度上比较：优化目标、改动范围、反馈来源、是否多轮迭代、输出一个还是一组 harness。AFlow 在工作流图上搜索，依赖标准答案；SkillMOO 同样同时看通过率和成本，但只改技能文档，也依赖标准答案；RHO 不用标签，改技能和工具，但只做一轮、只输出一个；AHE 改整个 harness，仍依赖标准答案。HarnessPro 在表里同时占据“通过率加成本、整个 harness、无标签、递归、帕累托集合”五个格子。
表 1｜五种 harness 自改进方法在目标、范围、反馈、迭代与输出上的对比；这是作者对各方法的归类，格子覆盖得多不等于效果更好。
这张表的价值在于给出一套共同语言：讨论一个自改进系统时，先问它优化什么、改哪一层、靠什么信号评判、跑几轮、交付几个结果。它不能替代实验对比，表中只有 RHO 进入了正式的数值比较，AFlow、SkillMOO、AHE 没有出现在表 2 的基线里。
02
METHOD
方法解析：把成本写进每一轮进化
2.1 先诊断轨迹，再按三种取向出方案
图 1 把每一轮（epoch）拆成三段：轨迹诊断、规划与编辑、评估与选择。起点是用行列式点过程（Determinantal Point Process，DPP）从训练任务里选出的 10 题“核心集”，挑选时兼顾难度和失败模式的多样性。每个候选 harness 在每道训练题上独立跑 G=3 次，轨迹分析器把三次轨迹和指标放在一起读，输出三类信息：发现了什么问题、它对通过率和成本的影响、问题来源及轨迹文件里的证据位置。合在一起看三次，是为了不把一次偶然失败当成 harness 的缺陷。
图 1｜HarnessPro 每一轮的流程：诊断轨迹、按三种取向规划并编辑、用生成测试验证后按帕累托前沿选出 lite/medium/heavy；模型本身始终冻结，只有 harness 在变。
附录的诊断样例能说明“修浪费”具体指什么。在一个 Mailman 邮件列表配置任务中，三次运行都通过了生成测试，分析器仍然指出：三次运行分别消耗约 106 万、176 万和 252 万输入 token，大段倾倒配置与源码、重复运行已经通过的评估脚本是主要来源。这类诊断在只看对错的系统里不会出现。它是分析器的判断而非实验测量，论文没有单独评估诊断本身的准确率。
沿着诊断结果，进化规划器为每个候选写三份方案，分别由三条指令引导：I1 优先降本，I2 兼顾两者，I3 优先提分但仍要消除可避免开销。规划器还会读其他候选与自己的代码差异和它们的诊断，借此判断哪些机制有效。harness 编辑器在各自独立的工作区实现每份方案，并提交到 Git，便于追溯和回滚。三条指令都写明“预测的节省不算数，由固定的外部评估器说了算”，也要求方案可泛化、不针对具体题目；验证集和测试集对规划器不可见。这些约束能减少泄漏风险，但无法从机制上保证规划器写出的规则对未见任务同样有效。
2.2 用固定测试代替 LLM 评委
没有官方测试时，怎样判断一个候选 harness 更好？RHO 的做法是让 LLM 直接比较轨迹，作者发现这种评委过于乐观，常把有缺陷的实现判为成功。HarnessPro 改为引入测试合成智能体：对每道训练和验证题，它只读任务描述和初始 harness 的那次轨迹，写出 10 个可执行用例，在冻结的初始产物上试跑、修正测试自身的缺陷并自查；测试生成一次后在整个进化过程中保持不变，保证所有候选在同一把尺子下比较。
图 2｜LLM 评委与 LLM 生成测试在官方结果上的混淆矩阵，汇总自两个基准的训练任务；样本只有 20 条轨迹，属于初步对照。
图 2 的数字需要连同样本量一起读。官方判为失败的 12 条轨迹里，LLM 评委只抓出 5 条，失败召回率 41.7%；生成测试抓出 10 条，召回率 83.3%，提高 41.7 个百分点，相当于 12 条里多抓出 5 条。代价是官方判为通过的 8 条里，生成测试误判 1 条为失败，通过召回率从 100% 降到 87.5%。这说明生成测试在这批样本上更不容易放过坏实现，但 20 条轨迹不足以给出稳定的误差估计，也不能推出它在所有任务类型上都优于 LLM 评委。
2.3 帕累托筛选，再按权重挑三档
每轮结束后，父代和新生成的候选一起在验证集上各跑一次，用固定测试计算通过率和成本。筛选分两步：先淘汰验证通过率低于初始 harness 的候选，再淘汰被帕累托支配的候选，即存在另一个候选在两项上都不差、至少一项更好。剩下的候选把通过率和成本各自归一化到 0–1，计算与“最高通过率、最低成本”这一理想点的加权平方距离，权重 (α, β) 在 lite、medium、heavy 三档分别取 (1, 2)、(1, 1)、(2, 1)。
图 3｜三轮更新、筛选与选择的示意：每个保留的 harness 衍生三个子代，筛选后最多保留三个进入下一轮；示意图中的具体编号仅为举例，不对应某次真实运行。
图 3 显示了一个容易忽略的细节：被保留的未必是新生成的子代。示例里第二轮的 lite 仍是初始 harness，最终的 heavy 来自第二轮而非第三轮；论文脚注也说明，筛选后可能少于三个不同的 harness。整个筛选只用验证集指标，测试集只在所有轮次结束后用于最终评估。归一化以当前存活集合的极值为基准，所以同一个 harness 的距离会随其他候选而变化，“medium”的含义是相对的，不是固定的成本档位。
03
EXPERIMENTS
实验解析：省下来的钱从哪里来
3.1 评测协议：同样的切分，不同的运行次数
三个基准分别覆盖终端任务、仓库级 issue 修复和从文档重建程序。按 RHO 的切分协议，测试集分别留出 59、100、100 题，训练集各 10 题，其余为验证集。进化在 Terminal-Bench 2 和 SWE-Bench Pro 上跑三轮，在 ProgramBench 上跑四轮。基线包括原始 Codex 或 Claude Code（Vanilla）、Dynamic Cheatsheet、ReasoningBank、Sleep-time Compute、RHO，以及两个用来拆分因素的 RHO 变体：Balance 只把 RHO 的优化指令改成“更好且更省”，RHO+Iteration 在此基础上跑与 HarnessPro 相同的轮数。
指标口径并不完全一致。Terminal-Bench 2 和 SWE-Bench Pro 要求一道题的官方测试全部通过才算通过；ProgramBench 按官方协议取每题测试通过比例的宏平均。HarnessPro 的数字是三次测试运行（ProgramBench 为两次）的均值和样本标准差，基线只给单次数值。Terminal-Bench 2 的测试集只有 59 题，一道题约等于 1.7 个百分点，读这个基准上的差距时要换算成题数。
3.2 数字要与测试对象一起读
表 2 是全文的主结果。在 GPT-5.5 × Codex 下，heavy 档在三个基准上都取得最高通过率，且成本低于 RHO：Terminal-Bench 2 上通过率 80.8%（±1.0），比 RHO 的 76.3% 高 4.5 个百分点，约合 2.7 道题，每题成本从 1.09 美元降到 0.72 美元，降低 33.9%；ProgramBench 上 69.6% 对 68.8%，成本 2.95 美元对 3.59 美元，降低 17.8%。三个基准平均，heavy 比 RHO 通过率高 2.0 个百分点，成本低 26.1%，这就是摘要里的两个数字。
表 2｜两组模型与 Agent 在三个基准上的通过率、每题成本与耗时；HarnessPro 为多次运行的均值 ± 标准差，基线为单次结果，粗体为作者标注的最优值。
同一张表换个角度读，结论的强弱并不均匀。SWE-Bench Pro 上 heavy 的 80.7%（±0.6）只比 RHO 的 80.0% 高 0.7 个百分点，落在一个标准差附近，基线又没有重复运行，这里能确认的是“通过率持平而成本从 2.68 美元降到 1.97 美元”，不宜读成通过率领先。ProgramBench 上 heavy 的领先只有 0.8 个百分点。论文没有报告显著性检验，平均 2.0 个百分点的增益主要由 Terminal-Bench 2 的 4.5 个百分点拉动。
medium 和 lite 的价值更多体现在成本一侧。SWE-Bench Pro 上 medium 通过率 79.0%，比 RHO 低 1.0 个百分点，每题成本从 2.68 美元降到 1.26 美元，降低 53.0%。lite 在三个基准上都超过 Vanilla，成本低 17.7% 到 57.4%。但边界同样清楚：ProgramBench 上 lite 的平均耗时是 985 秒，高于 Vanilla 的 669 秒；medium 的 67.9% 也低于 Dynamic Cheatsheet 的 68.5% 和 RHO+Iteration 的 68.3%。省钱不总是同时省时间，三档也并非在每个基准上都优于所有基线。
换成 GLM-5.2 × Claude Code，趋势大体一致：heavy 在三个基准上都超过 RHO，通过率分别高 3.4、2.3、1.1 个百分点，成本都更低；SWE-Bench Pro 上平均耗时从 RHO 的 520 秒降到 412 秒。不过 ProgramBench 上 medium 和 heavy 的每题成本（13.74 和 14.95 美元）都高于 Vanilla 的 11.34 美元，只是低于 RHO 的 17.00 美元。这组结果支持“方法在两套模型与 Agent 组合上都能工作”，第二组只和 Vanilla、RHO 比较，还不足以说明对所有基线都成立。
3.3 多轮迭代与消融：增益来自哪里
图 4 回答“为什么要跑多轮”。在 Terminal-Bench 2 上，heavy 档的测试通过率从第一轮的 74.6% 升到第三轮的 80.8%，每题成本从 0.91 美元降到 0.72 美元；lite 和 medium 在第二到第三轮通过率持平，成本分别从 0.61 降到 0.43 美元、从 0.68 降到 0.56 美元。SWE-Bench Pro 的 medium 档更能说明问题：第一到第二轮通过率从 70.0% 升到 77.0%，成本却从 1.57 升到 1.66 美元，直到第三轮才两项同时改善，通过率 79.0%，成本 1.26 美元。
图 4｜GPT-5.5 × Codex 下各轮保留 harness 的测试集通过率与成本，菱形为基线；中间轮次的测试指标只用于作图，未参与筛选。
这张图只有最后一轮的点是多次测试运行的均值，中间轮次没有说明做过重复运行，因此逐轮的细小起伏不宜过度解读。更直接的证据来自 Balance 和 RHO+Iteration：只把 RHO 的指令改成兼顾成本，在 Terminal-Bench 2 上就能把成本从 1.09 降到 0.79 美元，但通过率从 76.3% 降到 74.6%；再加上同样的轮数，RHO+Iteration 回到 76.3%、成本 0.82 美元。HarnessPro 的 medium 以 0.56 美元取得相同的 76.3%，成本低 31.7%。可见单靠“提醒省钱”和“多跑几轮”都不够，选择机制和评估信号也在起作用。
表 3 进一步拆分组件。去掉测试合成器影响最大：三档在两个基准上的通过率下降 3.4 到 10.0 个百分点，其中 SWE-Bench Pro 的 medium 从 79.0% 降到 69.0%。去掉规划器在多数设置下也是掉分加钱，例如 SWE-Bench Pro 的 medium 通过率从 79.0% 降到 73.0%，成本从 1.26 升到 1.42 美元；但 Terminal-Bench 2 的 lite 去掉规划器后通过率不变，成本反而从 0.43 降到 0.41 美元。表中还给出“每次成功的成本”（Cost-of-Pass，CoP），即总成本除以成功题数。
表 3｜GPT-5.5 × Codex 下的组件消融与“把单个策略移植到 RHO”的对照；消融未报告标准差，单格差异不能单独建立显著性。
表 3 上半部分检验另一种可能：把进化出的单项策略直接加到 RHO 上，能否得到同样效果。按任务动态选推理强度、或加入工具预算钩子，都能降低成本，但在 SWE-Bench Pro 上通过率分别降到 76.0% 和 75.0%；统一用低推理强度最省钱，代价是 Terminal-Bench 2 掉到 62.7%、SWE-Bench Pro 掉到 59.0%。作者据此认为三种变体都被 HarnessPro 的某一档帕累托支配，增益来自多种机制的配合。这一推论成立的前提是这些变体忠实复现了对应机制，论文没有给出移植的细节。
3.4 进化出了什么，还有哪些没回答
拆开最终的 harness，省钱的方式并不是简单压缩上下文或调低推理强度。以 Terminal-Bench 2 的 medium 档为例，一次独立的 GPT-5.5 调用先按评分细则，从任务描述中把任务归入 compact、lean、standard、deep、research 五种执行档位之一，每档对应一个推理强度和一组工具调用阈值。运行时钩子按阈值分阶段介入：standard 档在第 14 次工具调用时提醒批量调用、避免重复检查，第 26 次进入收敛阶段，超过 44 次后拒绝继续调用。提醒附加在工具返回结果里，而不是改写提示词前缀，这样可以保留缓存命中。另外，工具输出会被折叠重复行、截断首尾，开发者指令也被精简。
这些机制是从轨迹中进化出来的，并不意味着它们能直接搬到别的任务分布上。ProgramBench 的 medium 档就没有路由，固定使用高推理强度并关闭了输出压缩工具，说明不同基准进化出的结构差别很大。还有几处证据缺口：论文没有单列诊断、规划、编辑和测试合成这些进化环节本身花了多少钱，所以“降本”只针对部署后的每题执行成本；测试合成器的有效性只在 20 条轨迹上做过初步对照；训练、验证和测试都来自同一基准，跨基准迁移没有测试。
04
TAKEAWAY
总结：把“性价比”做成可交付的 harness
这篇论文把轨迹诊断、按取向规划、固定测试评估和帕累托选择接成一条链：先找出失败和浪费，再分别朝省钱、均衡、求稳三个方向改 harness，用不变的生成测试衡量，留下不被支配的候选进入下一轮。HarnessPro 真正优化的对象，是 harness 在通过率与成本平面上的前沿位置，而不只是通过率这一个点。
对搭建编程 Agent 或维护内部 harness 的读者，一个可借鉴的出发点是：诊断轨迹时把“做对了但很贵”也当作问题记录，按任务描述分档分配推理强度和工具预算，并把预算提醒放在工具返回结果里以保住缓存；评估时，再为每类任务准备一套固定的可执行测试，不只依赖 LLM 评委，并且对新旧 harness 做多次运行、报告方差。把“同等通过率下更便宜”当作一项可测量、可交付的产物，自改进系统就有了比“最高分”更贴近部署的目标。
— END —
我是大语言模型论文跟踪。
如果你觉得今天这篇有收获，欢迎关注、点赞、转发、喜欢四连，我们下篇见。