HarnessPro: Recursive Harness Self-Improvement with Pareto Optimization for Performance-Cost Trade-offs —— 精读

论文链接：https://arxiv.org/abs/2610.26770 发表时间：2026年10月（arXiv v2 更新于 2026-10-20，Under review） 机构：清华大学（一作单位，通讯作者 Jie Tang、H. Vicky Zhao）、Z.AI、上海交通大学、University of Warwick、Kling AI——高校主导方法设计、企业提供模型与算力的产学研合作；两位共同一作 Zhuoshi Pan 与 ZhiYuan Feng 均来自清华 领域标签：cs.LG（机器学习）、agent harness 优化、递归自改进（RSI）、多目标进化

一、论文背景

要理解这篇论文，先要理解 agent harness 这个概念。大模型本身只是一个"大脑"，当它被派去执行真实任务——修复仓库里的 bug、在终端装环境跑训练、从零重建一个程序——它需要一个完整的"躯壳"：系统提示词决定它收到什么指令、工具集决定它能做什么动作、上下文管理策略决定历史信息如何被截断或压缩、hooks 在运行时拦截和改写行为、验证规则决定何时算完成。这套软件基础设施就是 harness，Anthropic 的 Claude Code 和 OpenAI 的 Codex CLI 都是典型产品。harness 之于 agent，有点像机床夹具之于刀具：模型能力再强，装夹方式不对，加工精度照样崩掉。

harness 的质量直接决定两件事：任务能不能做成（pass rate），以及做成的代价有多大（token 消耗、API 账单、等待时间）。而 harness 的手工打磨极其昂贵——每个基准、每个模型的"最优配置"都不同，工程师调一遍的功夫够模型换代了。于是出现了 递归自改进（Recursive Self-Improvement, RSI）：让 LLM 自己读过去的执行轨迹，诊断"harness 哪里拖了后腿"，然后自动修改 harness，在下一批任务上验证，如此循环。

问题在于，已有的 RSI 方法几乎都在单维度上狂奔。以 RHO（本文最重要的对比对象）为代表的方法用 LLM 对比轨迹好坏来选择候选 harness，追求的是 pass rate 最大化。而提升 pass rate 最容易的路子是"多探索、多验证、多推理"——这些全是烧 token 的动作。论文里有个扎眼的数字：RHO 在 SWE-Bench Pro 上把 pass rate 从 59.0% 提到 80.0%，但每任务平均成本从 $1.88 涨到 $2.68，涨幅 42.6%。性能涨了，账单也涨了，在真实部署里这买卖未必划算——尤其是当任务量以百万计时。

还有一个更隐蔽的问题：**没有标签时怎么评估一个 harness 好不好？**真实场景中往往拿不到 ground-truth 解答或官方测试。RHO 的方案是让 LLM 当裁判直接判断轨迹优劣（self-preference），但作者实测发现 LLM 裁判过于乐观——明明实现有缺陷，裁判却经常判为成功。这种系统性高估会让劣质候选混过筛选，整个进化方向被带偏。

所以论文提出的核心问题是：**递归 harness 自改进，能不能在降低执行成本的同时提升任务性能？**这不是"少干活省点钱"的工程小聪明，而是把 harness 优化从单目标推到多目标 Pareto 前沿的范式问题——就像模型评估不能只看准确率不看推理成本一样（OpenAI 系的 cost-of-pass 框架正是这一思潮的体现）。

从更宏观的视角看，这个问题处在两条趋势的交汇处。一条是 agent 基础设施的工业化：Codex、Claude Code 这类编码 agent 已经进入生产环境，部署侧开始算细账——一次内部评估动辄成百上千任务，任务量上到百万级时，每任务省 30% 成本就是真金白银；“能跑通"的演示标准正在让位于"性价比最优"的采购标准。另一条是 自改进系统的可靠性追问：早期 RSI 工作证明了"LLM 能改自己的 harness”，接下来的问题自然是"改了之后到底变好还是变贵"“怎么知道变好了”。HarnessPro 把这两个问题接在一起：用多目标优化回应前者，用可执行的合成测试回应后者。这也是为什么它的实验设计如此强调成本核算的颗粒度——token 分三档计价、时延单独测量、进化开销本身也被控制在 10 任务核集的量级——一切都在回答"这套自改进在经济上是否可持续"。

二、论文定位和关联工作

这个方向的工作可以按"优化对象是什么"梳理成几个谱系。

**谱系一：从工作流搜索到 harness 全量修改。**AFlow（ICLR 2025）较早把 agent 工作流建模成模型调用算子的图，用执行反馈搜索更优的图结构，但它的搜索空间是预定义算子的组合，且依赖 ground-truth 标签。之后的系统开始直接改 harness 本身：AHE（Agentic Harness Engineering）强调让每处编辑可追溯；HarnessFix 先诊断失败原因再修复；HarnessX 用类型化的原语从轨迹证据中组装 harness。HarnessPro 与它们的根本区别在于目标函数——前述工作都只盯 pass rate，HarnessPro 显式优化 (pass rate, cost) 双目标并产出三档部署选项。

**谱系二：组件级优化。**另一批工作不动整个 harness，只优化某个组件：SkillOpt 优化技能文档，SkillMOO 把成本约束纳入技能进化并同样输出 Pareto 集，FRAMES 在策略治理的工作流里做带防护的双目标技能演化；Dynamic Cheatsheet 和 ReasoningBank 从历史经验中沉淀可复用策略，Sleep-time Compute 在查询到达前预构建可复用记忆，MemoryCPT 端到端联合优化记忆的构建、检索与摘要。这些方法证明了"组件级自改进"有效，但组件之外的工具、hooks、验证规则仍是静态的。HarnessPro 反其道行之：用轨迹证据演化整个 harness，包括指令、技能、工具、hooks 和验证规则。

**谱系三：推理时预算分配。**BATS 学习一个预算感知策略来分配模型 token 与外部工具调用，COMPAS 按任务难度联合选择模型、提示与解码配置。这类方法解决"给定任务该花多少算力"，HarnessPro 则是让预算分配机制本身成为演化的产物——最终演化出的 harness 里确实包含按任务描述动态选择执行档位的路由器，但这是进化"发现"的机制而非人工预设的模块。

**谱系四：通用自改进的远亲。**更早的 Darwin Godel Machine（ICLR 2026）探索了自指 agent 的开放式进化，是 RSI 思想的重要先声；Dynamic Cheatsheet 与 ReasoningBank 则代表"经验沉淀"路线——前者维护可复用策略手册，后者检索从历史轨迹蒸馏的策略。它们与 HarnessPro 的分野在于修改对象的粒度与目标的维度：沉淀类方法在既有 harness 内增加知识，HarnessPro 直接改写 harness 本身并显式管理成本。

按机制拆解的对照表（据论文 Table 1 扩展）：

**谱系四：label-free 评估。**RHO 是 label-free harness 优化的代表：不依赖 ground-truth，用 LLM 自偏好比较轨迹来选候选。HarnessPro 继承了 RHO 的 label-free 设定和 DPP 核集选择，但用 LLM 生成的固定测试取代自偏好判断——这是对 RHO 评估环节的直接修复。

按机制拆解的对照表（据论文 Table 1 扩展）：

定位结论：HarnessPro 站在 RHO 的正上方——它继承 RHO 的 label-free 设定与递归框架，同时在两个维度上突破：把单目标变双目标 Pareto 优化，把不可靠的自偏好评估换成可执行的合成测试。它是"harness 自改进从研究演示走向实用部署"这一叙事里的关键一环。

还有一层时代背景值得一提。同期 arXiv 上 harness 主题的工作密集涌现（本精读写作时检索范围内可见 HarnessFix、HarnessX、AHE、EvoHarness-RL、HarnessBank、EvoTrainer 等），研究社区正在把 2023-2025 年集中在 prompt 与工作流上的自动化热情，转移到"模型外圈的整套执行设施"上。这个转移的驱动力不难理解：前沿模型的能力差距在缩小，而同一模型配不同 harness 的表现差异可以达到数十个百分点——优化边际收益最高的地方已经从模型内部挪到了模型外部。在这个坐标系里，HarnessPro 填补的格子是明确的：别的优化工作要么有标签依赖、要么单目标、要么优化范围受限，它是第一个（就本文 Related Work 表格与我们的检索范围而言）同时满足 label-free、递归、全 harness 范围、双目标 Pareto 输出四个条件的方法。

三、问题定义

论文的抽象方式很干净：把 harness 优化从"找一个好 harness"重构为"推进性能-成本的 Pareto 前沿并取出三个代表点"。

具体场景：给定任务 x，harness h 决定 agent 收到什么信息、能做什么动作、动作如何执行，产出轨迹 τ_h(x)。harness 包含指令、工具与技能、上下文与记忆机制、hooks、验证策略——全部可在进化中修改。

形式化：三个评估指标先行定义——

• Pass rate：任务按 train/val/test 三集划分（防测试集泄漏），官方测试评最终产物，PR(h) 为测试集通过率；
• Cost：按未缓存输入、缓存输入、输出三类 token 分价计费（因为它们单价差异巨大，如 GPT-5.5 输出价是缓存输入的 60 倍），C(h) 为测试集平均每任务成本；
• Latency：墙钟时间，因服务器负载波动只作辅助指标不作优化目标。

优化目标写成：

min_{h∈H} (−PR(h), C(h)) s.t. PR(h) ≥ PR(h_0)

即在不低于初始 harness h_0 性能的约束下，同时最小化负通过率与成本。论文明确不追单点最优，而是寻找 Pareto 前沿并选出三个代表操作点：cost-focused（lite）、balanced（medium）、performance-focused（heavy）。

这个抽象的精妙之处在于它承认了两个结构性的困难。**困难一：搜索空间巨大且离散。**指令、工具、技能、hooks、规则的组合构成庞大离散空间，梯度下降无能为力，只能靠轨迹证据引导的进化搜索。**困难二：性能与成本天然张力。**更多推理、探索、验证通常提升性能但也消耗更多 token；反过来一刀切地砍这些活动又会伤性能。推进 Pareto 前沿要求区分"必要计算"与"可避免开销"——这恰恰是轨迹分析能做到而静态规则做不到的。约束条件 PR(h) ≥ PR(h_0) 也很讲究：它禁止进化以牺牲性能为代价省钱，把"劣化型降本"直接排除在解空间之外。

值得单独一提的是三个指标背后的测量纪律。pass rate 的三集划分（train/val/test）切断了"进化过程见过测试结果"的泄漏通道——训练集用于更新 harness、验证集用于筛选与选代表、测试集只在冻结后碰一次。cost 的三档计价（未缓存输入/缓存输入/输出）捕捉了真实账单结构：一次 rollout 里反复膨胀的上下文走缓存价，输出 token 走高价，把三者混为一个"token 总数"会让优化目标与实际开销脱钩。latency 被降级为辅助指标的理由也坦率——模型响应时间受服务器负载与网络波动影响，把它当优化目标会让进化追逐噪声。这种"哪些量值得优化、哪些量只值得观测"的区分，是多目标系统设计的隐形功力。

四、问题解法

HarnessPro 的总体架构是一个三阶段循环：轨迹诊断 → 计划与编辑 → 评估与选择。每个 epoch 里，候选 harness 在训练核集上并行 rollout，多个专职智能体把执行反馈变成新一代 harness。

4.1 训练核集选择：DPP 平衡难度与多样性

类比：与其在 1000 道题上都浅尝辄止，不如挑 10 道最有代表性的题深挖。方法沿用 RHO 的 DPP（Determinantal Point Process）核集选择：LLM 裁判给每个任务打难度分并生成抽象失败模式指纹（剔除任务名等表面细节，让相似度反映共性问题），构建难度加权的 DPP 核，贪心选出行列式最大的 10 个任务作为训练核集，全程固定。难度权重偏向挑战性任务，行列式惩罚冗余指纹——保证这 10 道题覆盖尽量多的失败模式。

4.2 阶段一：轨迹分析器（Trajectory Analyzer）

诊断的输入证据散落在长序列的模型响应和工具输出里，人工（或单次 LLM 调用）很难定位。轨迹分析器对每个候选 h 和任务 x 联合检查 G=3 次独立 rollout 的轨迹与指标，而非单次尝试——这是为了对冲随机性（一次失败可能是运气差，三次都卡在同一步就是结构性问题）。输出 z(h,x) 包含三要素：发现的问题、对性能与成本的影响、问题来源与证据（轨迹摘要或摘录 + 轨迹文件路径与事件范围）。

附录里的真实诊断案例能让读者直观感受这个环节在做什么。Caffe-CIFAR-10 任务三次 rollout 全部在训练前失败：分析器分检出"高并行编译导致 OOM"“最顺利的一次卡在 CIFAR-10 下载"“配置缺 OpenCV 将在未来堵塞均值计算"等五个问题，每个都标注了质量影响、成本影响和精确到行的证据。Mailman 任务三次全过但代价高昂：探索远超必要范围（三次 rollout 的输入 token 分别达 106 万、176 万、252 万），最终评估重复了已覆盖的行为——“成功但昂贵"被显式诊断为可优化项。这个"失败诊断"与"开销诊断"并重的设计，正是双目标优化在微观层面的体现。

4.3 阶段二：进化规划器 + harness 编辑器（Planner & Editor）

规划器为每个候选生成三份改进计划，分别由三条指令驱动：I_1 强调降成本（明确警告"不要靠跳过必要工作、放弃难任务或削弱验证来省账单”）、I_2 平衡性能与成本、I_3 优先性能。类比：给同一个病人开三个方向的处方——省钱方案、均衡方案、不惜代价方案——然后都拿去临床试验。

规划器的输入不止于当前候选的诊断：它还能看到其他候选 harness 的代码差异 Diff(h_ti, h_tk) 及其诊断与指标（式 3），通过横向比较识别"哪个同行的机制有效、自己还差在哪”。默认不提供完整轨迹，需要时可按诊断记录中的文件路径调阅。规划器被要求提出可泛化的更新而非任务特调，且验证集与测试集在进化全程对规划器隐藏。

编辑器把每份计划落成可执行的候选 harness，三份计划各自在独立工作区实施并 commit 到 Git——可追溯、可回滚。新候选集合 C_t 与父代 A_t 合并为 eC_t 进入评估。

4.4 阶段三：测试合成器（Test Synthesizer）——对自偏好评估的修复

这是方法层面最关键的替换。RHO 用 LLM 自偏好直接比较轨迹，但论文的混淆矩阵实验显示：在官方判定的失败任务中，LLM 裁判只识别出 41.7%（大量有缺陷的实现被误判为成功）；而 LLM 生成的测试套件把这一失败检出率提升到 83.3%，同时保持 87.5% 的成功任务识别率。

测试合成器的产出为何可靠？附录 C.3 的指令文本揭示了三层防护。证据边界层：合成代理只许读公开任务文件与冻结的参考产物（“Empty 只是实现与执行诊断的上下文，绝不是答案钥匙”），明确禁止寻找官方隐藏测试、评分器、解答——线上线下一概不许。判据强度层：每条测试必须断言"被交付产物与独立公开证据之间的有意义关系”，文件存在、进程退出码为零、输出非空、取值在合理范围这类弱信号被逐一点名批评；oracle 的选择顺序是公开参考 > 已知答案 > 必要内容性质 > 区分性蜕变关系，并且"永远不得从参考产物反推期望常量、哈希或容忍值"。动机对齐层：status=ok, passed=false 被规定为"有效执行、产品可能失败"，修复测试缺陷时"不得跳过用例、不得捕获所有异常、不得把期望值朝产品行为调"——这四条"不得"精准封堵了测试合成最常见的腐败路径。自审环节要求逐用例复核期望值与共享辅助函数，产出包括覆盖清单（哪些公开要求映射到哪些用例、什么没查、有何局限）与修复日志。

4.5 候选过滤与三档选择

每个 epoch 结束后，所有候选在验证集上用固定测试评估一次，得到 (PR_val, C_val)。两级筛选：

1. 过滤：丢弃低于初始 pass rate 地板 PR_val(h_0) 的候选，以及被 Pareto 支配的候选（另一候选在两指标上均不差且至少一项严格更好）；
2. 选择：对过滤后集合，用 normalized weighted squared-distance 准则（Marler & Arora 2004 的多目标补偿函数）为三档各选一个代表。先把 pass rate 与 cost 归一化为到最优点的偏差 d_perf、d_cost（式 8），三档目标 J_m(h) = α_m·d_perf² + β_m·d_cost²，其中 (α,β) 为 lite (1,2)、medium (1,1)、heavy (2,1)，每档独立取 J 最小者。

选出的三个 harness 构成下一 epoch 的候选集 A_{t+1}，循环往复直到 epoch 上限（TB2/SWE-Bench Pro 3 轮，ProgramBench 4 轮），最后冻结 harness 在测试集上做最终评估。全程过滤与选择只用验证集指标，测试集结果只在进化完成后触碰一次——防泄漏的纪律贯穿始终。

附录 B 披露的三条进化指令同样值得细读，因为它们解释了"为什么演化产物是通用机制而非任务特调"。I_1（成本优先）开宗明义：“寻求真实的效率增益，而不是通过跳过必要工作、放弃困难任务或削弱验证换来的低账单”，并要求把不成功尝试与改动自身引入的开销都计入总成本——“步骤更少或输出更短本身不构成改进”。I_2（均衡）强调"不要通过忽视必要行为来换取节省，也不要假设更多计算必然提升质量"，并要求对比同类候选时"理解其强弱与交互，而非整套照抄机制"。I_3（性能优先）则反过来防膨胀：“在能解决实质性失败的地方投入精力，而不是在所有任务上均匀增加计算”。三条指令都附了同样的免责声明：可选方向不是清单，“不预设路由 rubric、固定阈值、profile 分类法或按任务的规则”——最终产物中的五档路由系统完全是规划器从轨迹证据里自生的，这个细节对"演化而非手工设计"的 claim 至关重要。

4.6 全景小结

一次完整 epoch 的算术账：3 个候选 harness × 10 任务 × 3 rollouts = 90 次训练集执行（诊断用）+ 最多 12 个候选（3 父代 + 9 子代）× 验证任务数 × 1 rollout 的验证执行。以 TB2 为例验证集百余任务，单轮验证约千余次执行——与最终测试评估同量级。这说明进化循环自身的开销大约是"多测几遍验证集"的水平，远低于许多进化搜索方法动辄数万次评估的预算，工程上真正可行。

五、评估指标与实验证据

5.1 实验设置

基准：Terminal-Bench 2（终端任务，59 测试任务）、SWE-Bench Pro（仓库级 issue 修复，100）、ProgramBench（从零重建程序，100）——覆盖三种长时程 agent 场景。模型组合：GPT-5.5 × Codex 0.147.0 与 GLM-5.2 × Claude Code 2.1.231，两套生态双保险。训练核集仅 10 任务、每任务 G=3 rollouts、每轮最多保留 3 个 harness——进化本身的开销被控制在很小的量级。HarnessPro 结果报告多次运行的均值±标准差。

Baseline：Vanilla（原始 Codex/Claude Code）；三个组件类方法 Dynamic Cheatsheet、ReasoningBank、Sleep-time Compute；RHO（最重要对照）；以及两个为分离变量而设的 RHO 变体——Balance（只改 RHO 的优化指令为"更好性能更低成本"）、RHO+Iteration（让 Balance 跑同样轮数）。这两个变体的设计意图很清楚：证明"光改指令或光加轮数"不够，必须动方法本身。

实验预算与环境配置的细节也有助于判断结论的可信边界。求解器时间预算按基准原生限制执行（TB2 测试集每任务 600–3600 秒、SWE-Pro 对 GPT-5.5 限 1200 秒、ProgramBench 7200 秒外加 14400 秒评分外层限制）——这些墙钟限制与 harness 层的工具调用预算是两套独立的闸门，前者管基础设施，后者管行为经济学。任务环境方面 TB2 与 ProgramBench 每求解器配 8 CPU/32 GiB 内存，SWE-Pro 跑宿主工作区无显式资源上限。基础设施故障（容器崩溃、网络中断等与 harness 无关的失败）被排除并重试，避免把环境噪声算到方法头上。生成参数使用两家默认（GPT-5.5 Responses API 默认采样、GLM-5.2 温度 1.0/top-p 0.95）——不做任何有利于本方法的采样调优。

5.2 主结果：三档全面占优

GPT-5.5 × Codex 下（pass rate % / 成本 $ / 时延 s）：

关键读法：

• Heavy 模式三基准 pass rate 全部第一，且成本全部低于 RHO——TB2 上 80.8% vs 76.3%（+4.5pp）同时成本降 33.9%（$1.09→$0.72）；SWE-Bench Pro 上 80.7% vs 80.0% 且省 26.5%；ProgramBench 上 69.6% vs 68.8% 且省 17.8%。这直接回答了引言之问：性能提升不必以更高执行成本为代价。
• Medium 是性价比之王：SWE-Bench Pro 上 79.0%（仅比 RHO 低 1.0pp）但成本只有 $1.26，比 RHO 的 $2.68 便宜 53.0%。
• Lite 是省钱模式：三基准全部超过 Vanilla，成本反而比 Vanilla 低 17.7%–57.4%。
• 对 RHO+Iteration 的胜利最有说服力：同等迭代预算下，medium 在 TB2 上以低 31.7% 的成本打平其性能，ProgramBench 上 heavy 还高 1.3pp——说明收益来自方法而非轮数。
• GLM-5.2 × Claude Code 完全复现同样格局（heavy 81.4/77.3/64.4 全超 RHO 且更便宜），排除了"只在 OpenAI 生态成立"的担忧。

GLM-5.2 × Claude Code 侧的完整数字（论文 Table 2 下半）：

这侧的亮点是 medium 在 SWE-Bench Pro 上以 $0.87（RHO 的 40%）完全打平 RHO 的 75.0%，lite 在 TB2 上超过 Vanilla 0.5pp 而成本只需 47%。两个模型生态、三个基准、六个对比方法，Pareto 支配关系无一例外——对一篇实证论文而言，这种格式的整齐本身就是证据强度。

• 时延是免费搭车：成本优化并非目标，但 heavy 在 SWE-Bench Pro 上把 RHO 的平均时延从 520s 降到 412s。

补充一个容易被忽略的读表细节：GLM-5.2 × Claude Code 下 ProgramBench 的绝对成本高出一个数量级（Vanilla $11.34 vs GPT-5.5 侧的 $2.65），因为该基准单任务执行长度大、GLM-5.2 的 max effort 默认设置会诱发大量推理与工具使用（论文附录 A.2 专门说明为此把 GLM-5.2 在 ProgramBench 的默认 effort 从 max 调回 high）。在这种"贵"的配置上，HarnessPro 三档的降本幅度依然显著（heavy $14.95 vs RHO $17.00）——说明方法对"起始配置贵贱"不敏感，收益来自结构性的开销治理而非碰巧赶上便宜默认值。

5.3 消融：每个组件都在挣自己的饭钱

两个结论：测试合成器贡献最大（去掉后 pass 掉 3.4–10.0pp，且往往成本还升——选不出好候选自然乱改一气）；规划器去掉后性能降成本升（medium 在 SWE-Pro 从 79.0% 掉到 73.0%，成本反升 $1.26→$1.42），说明三优先级计划不是摆设。

5.4 反向消融：单抄一个策略进 RHO 行不行？

作者把演化产物里的单个策略嫁接回 RHO：+dynamic routing（任务描述选执行档位）、+budget hooks（工具预算提醒）、+low reasoning effort（统一低推理）。结果：前两个都能降成本但 SWE-Pro 上 pass 掉到 76.0/75.0（低于 RHO 的 80.0）；统一低推理更是掉到 62.7/59.0。三个变体全部被演化 harness Pareto 支配——证明收益来自多机制的协同选择与组合，而非任何单一技巧。

5.5 演化动力学与产物分析

逐 epoch 追踪显示 Pareto 前沿持续外推：TB2 heavy 从 epoch 1 的 74.6%/$0.91 到 epoch 3 的 80.8%/$0.72；SWE-Pro medium 前两轮"涨性能也涨成本"（70.0%/$1.57→77.0%/$1.66），第三轮才双改善（79.0%/$1.26）——递归多轮的价值正在于此，单轮进化很容易停在"性能换成本"的半山腰。lite 与 medium 在 TB2 的 epoch 2→3 间性能不掉、成本分别从 $0.61/$0.68 降到 $0.43/$0.56，说明前沿的便宜端也在被持续推挤；ProgramBench 的第 4 轮在三档上同步降成本而性能持平。值得注意的是论文对中间 epoch 测试集指标的处理方式：图表中画出了各 epoch 的测试集位置，但明确声明这些数字"仅供可视化，不用于过滤与选择"——把可视化与决策依据分开陈述，这种透明度在同类论文里不多见。

对最终 harness 的解剖揭示了它实际发明了什么：按任务描述路由执行档位（五档 profile：compact/lean/standard/deep/research，各配推理档位与工具调用预算，档位判定规则是一份精细的证据学 rubric——“未知质量的验证器默认 standard"“能构造确定性本地 oracle 才够格 deep”）；运行时 hooks 分阶段推进收敛（如 standard 档在 14 次工具调用后提醒批量操作、26 次后进入收敛阶段只修当前失败、44 次后直接拒绝新调用；提醒文本追加在工具结果尾部以保住前缀缓存）；RTK 式工具输出压缩与指令瘦身。注意论文特意强调：这些机制是进化从轨迹证据中"发现"的，三条进化指令里从未预设任何路由 rubric、固定阈值或 profile 分类法。

三档之间的差异也值得端详。lite 不是简单调低 medium 的参数：它保留共享 rubric 但把 deep/research 两档的推理 effort 压到 medium、各档 finalize 阈值收紧（standard 从 44 降到 38 次调用）——档位体系仍在，只是天花板降低。heavy 则反向放宽：lean 升到 medium 推理、standard 升到 high、standard 的收敛/停止阈值扩到 38/60 次调用，且 rubric 有独立的改写（lean 的准入门槛从"约 8 次调用以内"放宽到"约 12 次以内”）。这种"共享骨架 + 差异化参数与 rubric"的三档结构，说明 Pareto 前沿上的三个点不是同一个 harness 的三个旋钮档位，而是各有独立进化历史的成熟配置——它们从 epoch 2 起就沿不同支线分叉演化（论文 Figure 3 的谱系图清晰展示了三条支线的继承关系）。跨基准的对比同样有信息量：SWE-Bench Pro 的演化 harness 相比 TB2 版本整体上调了各档预算（standard 收敛 26→42 次）、给 lean 档加了"仅限窄实现面修复"的准入限制、并引入了"置信度低于 0.9 时 lean 自动升级为 standard 预算"的保险机制——同一个方法框架在不同任务形态上长出了不同的解剖结构，这是"harness 需要按域定制"这一判断的有力证据。

5.6 指标体系小结

把第五部分的指标做个分层收束：

CoP 值得单独一提：总成本除以成功任务数，它把"便宜但做不对"与"做对但贵"统一成单一经济口径——TB2 上 heavy 的 CoP $0.89 vs RHO $1.43（便宜 38%），lite 更低到 $0.59。这个指标天然惩罚"低成本低通过率"的伪效率，是 pass rate 与 cost 之外最有解释力的第三视角。

六、效果优势的根源解释

6.1 根源机制与证据链

**因果链一：评估保真度决定进化方向。**RHO 的自偏好评估对失败任务的检出率只有 41.7%——超过一半的失败被误判为成功，进化规划器拿到的诊断信号本身就是错的，选出的"最优"候选是系统性高估的产物。HarnessPro 用固定合成测试把失败检出率提到 83.3%（论文实验，Figure 2），诊断与选择两个环节同时吃到更准的信号。【论文实验已支持：消融中去掉测试合成器 pass 掉 3.4–10.0pp，是最大单项贡献】机制上这类似于把"教练主观打分"换成"计分板"：进化搜索的每一步选择压力都落在真实可执行的行为上。

**因果链二：双目标需要显式的双目标搜索结构。**单目标方法（RHO）的每一步更新都朝 pass rate 梯度方向走，成本只是外部性；指令改成"兼顾成本"（Balance 变体）不够，因为选择机制仍在单点上比较。HarnessPro 在两个层面同时改：规划层三优先级并行探索（cost/balanced/performance 三条线各自深入），选择层 Pareto 支配过滤 + 三档代表保留——每轮结束后前沿上不同区段的候选都有幸存者，下一轮从多个区段继续外推。【论文实验已支持：Balance 74.6%/TB2 弱于 RHO 本身；三档在所有基准上形成对 RHO 及其变体的支配】

**因果链三：成本节约来自"区分必要计算与可避免开销"而非削减计算。**产物分析表明演化 harness 保留了最终验证、按需高推理，砍掉的是重复探索（Mailman 案例：成功任务的 252 万输入 token 中大量是无效的广撒网式 dump）、冗余上下文（重复日志折叠、长输出压缩）和无差别的高档位默认（五档路由让简单任务用 low effort）。【论文实验已支持：+low reasoning effort 变体统一降档导致 TB2 掉到 62.7%，证明关键不是"少算"而是"按需算"；而演化 harness 同时拿到 80.8% 与 $0.72】这里有个值得强调的反事实：如果优势只是"砍计算"，那 +low effort 应该最便宜且不至于太差——实际它性能崩盘且成本($0.45)仍被 lite 模式（$0.43, 72.9%）支配。优势必须在"区分"能力里，而区分能力来自轨迹级的开销诊断。

**因果链四：递归多轮解锁单轮无法到达的点。**SWE-Pro 的动力学显示单轮进化常常落在"性能升成本也升"的位置，需要后续轮次在保持性能的前提下降本。【论文实验已支持：RHO 单轮 vs HarnessPro 多轮 vs RHO+Iteration 的三方对比；RHO+Iteration 弱于 HarnessPro 说明"多轮"要配合"Pareto 结构化选择"才有效——单纯 best-of-N 链式迭代每轮收敛到单点，丢掉了前沿多样性】

**因果链五：候选间的横向比较产生单一候选自身无法提供的信号。**规划器的输入包含其他候选的代码 diff 与各自诊断（式 3）——这让"哪个同行的机制有效"成为可学习的对象。论文 Figure 3 的谱系显示最终三档 harness 分别来自不同支线（lite 的祖先是 epoch 2 的 H23、heavy 的是 H29），且后续支线能继承并改造前代的机制（lite 计划明确针对"前代 router 偏好 high/xhigh"的观察做修正）。【此链条属阅读者推测成分较高：论文未做"去掉跨候选比较"的独立消融，仅从计划文本（如 lite plan 直接回应 router 偏差）与谱系图间接支持】机制类比：这近似于遗传算法中的种群多样性红利——若每轮只保留单点，任何一轮的局部最优都会锁死后续搜索方向。

6.2 相关工作检索与对照

围绕上述因果假设，检索外部相关工作进行交叉验证（含论文 Related Work 之外的对照）：

检索范围说明：以上对照主要来自论文 Related Work、其引用文献及本精读写作时的补充检索；在本次检索范围内未发现与 HarnessPro 完全同构（label-free + 递归 + 全 harness + 双目标 Pareto）的已发表工作，SkillMOO 是最接近的先行者但域与设定差异显著。

6.3 综合判断与未决问题

多项证据共同支持的机制：(1) 评估保真度是自改进系统的第一瓶颈（本文消融 + RL 奖励演化文献一致）；(2) 双目标优化需要显式的 Pareto 搜索与保留结构（本文 + SkillMOO）；(3) 成本节约的来源是按需分配而非削减计算（本文消融 + BATS）。

仍属推测的部分：演化 harness 中档位 rubric 的具体阈值（14/26/44 次调用等）是否在其它模型或任务分布下仍然接近最优，论文未做跨分布敏感性分析；三档权重 (1,2)/(1,1)/(2,1) 的选择依据论文未给出搜索过程，可能存在工程调参成分。

适用边界与潜在失效条件：label-free 依赖合成测试的质量——若任务的行为契约难以从公开描述推断（如主观创意任务），测试合成的失败检出率可能退化；成本优势部分依赖 API 的缓存计价结构，纯输出计价或本地部署的经济学下 Pareto 形状会变；10 任务核集的小样本诊断对罕见失败模式的覆盖有天然上限。

此外还有几个开问题值得点名。合成测试的分布偏移：测试从初始 harness 的轨迹生成，天然偏向"初始 harness 能触达的行为空间"——若某个候选 harness 探索出全新解法路径，固定测试能否公允评价它？论文的混淆矩阵实验只在训练任务上做，未检验测试质量随候选行为分布漂移的稳健性。进化开销的外推：实验中每轮 3 候选 × 10 任务 × 3 rollouts 的诊断成本可忽略，但若扩到大核集或长程任务（如多日级 agentic 工作流），rollout 本身的费用会成为进化的主要开销，届时"进化几轮就停"的预算决策本身需要被优化。跨模型迁移：论文中每个模型组合独立进化，未检验"GPT-5.5 上演化的 harness 给 GLM-5.2 用"的迁移性——若 harness 与模型能力强耦合，每换一次模型就要重跑全套进化，这会削弱方法的部署吸引力；反之若迁移良好，则暗示演化产物捕捉的是任务结构而非模型怪癖。论文未提供此维度的数据，这是一个清晰的后续实验方向。

七、必要知识反推

假设一个完全没有背景的人要复现这项工作，最少需要掌握什么？

方法论知识层。必须掌握多目标优化的基本概念——Pareto 支配、Pareto 前沿、补偿函数选择（normalized weighted squared-distance 出自 Marler & Arora 2004 的工程多目标综述）；不需要这些就无法把"又好又便宜"从口号变成可计算的搜索问题。必须掌握 RHO 的 label-free 递归框架与 DPP 核集选择（Kulesza & Taskar 2012）——本文直接站在其上。必须理解 LLM-as-judge 的失效模式（自偏好、乐观偏差）——这是替换评估机制的动机起点。理解混淆矩阵与失败检出率（recall）的度量语言也是必需的——论文用一张 2×2 混淆矩阵就把"自偏好 vs 合成测试"的评估差距钉死，这种论证方式本身值得学习。

领域知识层。必须理解 agent harness 的解剖结构——指令、工具、技能、hooks、上下文管理、验证策略各是什么、分别影响执行链路的哪一段；不理解这个就无法定义"演化什么"。必须理解真实 agent 任务的执行形态：一次 rollout 是几十次工具调用的长序列，token 成本分布在输入缓存、未缓存输入与输出三个价位上，时延由模型响应与工具执行叠加。不理解成本结构就无法设计 C(h) 这类三档计价指标。

工程知识层。必须会搭建大规模 agent 评测基础设施：三集划分防泄漏、并行 rollout、轨迹与 token 计量落盘、Git 管理候选工作区。必须会设计多智能体流水线：分析器/规划器/编辑器/合成器的职责边界、上下文预算（诊断超 64K tokens 时摘要）、错误传播的阻断。必须掌握测试合成的证据边界设计——防窥探官方测试、防"让产品通过"的动机漂移，这些是 label-free 评估不塌方的关键。还必须熟悉两家 agent CLI 的扩展机制（Codex 的运行时配置、Claude Code 的 hooks 协议）——演化产物最终要落成这些系统可执行的原语（runtime.json、hook.py、rubric 文件），不熟悉目标平台的可编程点位，编辑器写得再好也无法部署。

知识融合的关键节点。第一个融合点是"轨迹诊断 × 成本会计"：把失败模式分析（质量视角）与 token 三档计费（经济视角）叠加在同一份轨迹证据上，才产生了"区分必要计算与可避免开销"的判断力——单独任何一边都做不到。第二个融合点是"Pareto 选择 × 递归进化"：每轮保留三档代表而非单点，让下一轮的多方向探索有多个出发点，这是 SWE-Pro 动力学里第三轮双改善得以发生的结构前提。第三个融合点是"LLM 生成测试 × 固定评估"：用生成式智能体造测试，但用冻结与统一比较来消除生成侧的不稳定性——生成与冻结的张力被制度化了。

八、论文中可以提取的通用性灵感

**灵感一：自改进系统的瓶颈首先在评估器，不在生成器。**核心思想：当系统能大量生成候选时，决定进化方向的是选择压力的保真度；评估器失真，生成器再强也是加速跑偏。论文证据：把自偏好评估换成固定合成测试（失败检出 41.7%→83.3%），单此一项消融就贡献 3.4–10.0pp 的性能差。推广场景：代码生成管线的评审模型校准、A/B 测试的指标设计、自动化科研的假设筛选、教育中的自适应测评、内容推荐的质量信号治理。

**灵感二：多目标优化要"并行探索多方向 + 前沿保留"，不能只改指令或只加轮数。**核心思想：让不同优先级的搜索线各自深入，再在结果层面做 Pareto 支配过滤与代表性保留，双目标才能同时推进。论文证据：Balance（只改指令）与 RHO+Iteration（只加轮数）均被完整方法支配；三档选择每轮保留前沿多区段代表。推广场景：模型压缩的性能-延迟权衡、数据库查询计划的代价估计、供应链的成本-韧性配置、产品迭代的速度-质量路线图、个人任务的精力分配策略。

**灵感三：降本的正解是"按需分配"，不是"统一削减"。**核心思想：先建立"这个任务/环节值得花多少"的判别能力，再执行分配；一刀切的 austerity 必然伤及要害。论文证据：统一低推理档掉到 62.7% 而成本仍被 lite 支配；演化产物是五档路由 + 阶段推进 hooks，保留高推理给需要的任务。推广场景：云资源的弹性伸缩策略、code review 的分级深度、测试金字塔的执行预算分配、医疗资源的分诊制度、卫星通信的带宽调度。

**灵感四：机制组合的价值大于单机制移植——“抄作业"要抄整套协同结构。**核心思想：一个系统里的有效机制往往依赖隐性配套（判定规则、阶段逻辑、缓存友好性），孤立移植会失去协同红利。论文证据：把 dynamic routing 或 budget hooks 单独嫁接回 RHO，成本降了但性能也掉了，三变体全部被支配。推广场景：跨公司流程再造的失败模式、开源组件的拼装陷阱、生物器官的协同演化、管理制度的局部移植风险。

**灵感五：诊断要同时覆盖"做得不好"与"做得太贵”。**核心思想：对已完成任务的复盘通常只看正确性；把开销（冗余探索、重复验证、上下文膨胀）纳入诊断粒度，才能解锁一个全新的优化维度。论文证据：Mailman 案例对"成功但烧掉 252 万 token"的结构化开销诊断；演化出的输出压缩与指令瘦身直接源于此。推广场景：软件团队的 retro 议程设计、生产系统的浪费审计、科研经费的执行效率评估、个人时间日志的分析框架。

**灵感六：防作弊的评估设计要"证据边界前置"。**核心思想：任何生成式评估都要在制度上禁止评估者接触答案源、禁止朝讨好被评者方向漂移，并把"执行失败"与"评估失败"显式区分。论文证据：测试合成器的指令明确禁止寻找官方测试/评分器；status=ok, passed=false 的语义约定阻断"让产品通过"的动机。推广场景：学生自测系统的防作弊设计、AI 对齐评估的隔离协议、企业内部审计的独立性保障、竞赛评测的沙箱规则。

**灵感七：缓存友好的干预位置影响隐性成本。**核心思想：同样的干预内容，注入在序列的不同位置，对下游系统（缓存、前缀复用）的成本结构影响完全不同。论文证据：演化 harness 的阶段提醒被刻意追加在工具结果尾部而非系统提示里，正是为了保住 prompt 前缀的缓存复用——在缓存输入单价是未缓存 1/10 的计价结构下，前缀失效是巨大的隐性开销。推广场景：CDN 的内容分层失效策略、数据库的写放大控制、编辑器协作的增量同步协议、多轮对话系统的上下文版本管理。

**灵感八：交付"方案集"而非"最优解"，让用户按预算自选。**核心思想：当优化目标天然多维且用户约束异质时，输出前沿上的代表性档位比输出单点更有价值——它把"最后一次权衡"留给持有预算信息的人。论文证据：lite/medium/heavy 三档共享演化基础设施但各有独立支线，覆盖从"严格预算约束"到"性能优先"的部署谱系；lite 在三基准上比 Vanilla 便宜 17.7–57.4% 还更强，medium 在 SWE-Pro 上打平 RHO 但便宜 53%。推广场景：云服务的实例规格档位设计、模型 API 的多档计价、汽车动力总成的配置级别、软件的免费/专业/企业版分层、编译器 -O0 到 -O3 的优化档。

附录：与同期 HarnessRL 的对照

本期同日精读的 HarnessRL（arXiv:2610.26426）同样使用"harness"一词但所指不同：HarnessPro 演化的是推理时执行 harness（prompt/工具/hooks），服务于部署侧的 pass rate-成本权衡；HarnessRL 演化的是训练时 harness（任务采样/rollout 指导/rubric 标准），服务于 RL 训练侧的奖励信号有效性。两者共享同一设计哲学——把过去被视为固定配置的周边设施变成可优化的对象，并且都在"接受一个更新前先实测其效果"上做文章（前者用固定测试评估候选 harness，后者用 JIT critic 在冻结策略上实测候选更新）。把两篇对读，能看到"harness 工程"正在从推理侧向训练侧全线渗透的趋势。

最后落一笔对论文写作本身的观察：这篇论文的附录质量在同类工作中属于第一梯队——四份演化指令全文、两份完整诊断案例、三份计划节选、测试合成器的完整配置、三个基准演化 harness 的运行时文件与 policy diff，几乎构成一份可复现的工程档案。对后续研究者而言，这些材料的价值不亚于主表：它们让"演化到底产出了什么"从黑箱变成可审计的工件，也为"harness 演化产物能否跨基准迁移、能否被人类工程师直接取用"这类后续问题准备好了分析素材。论文声明使用了生成式 AI 辅助实现与写作并经人工复核——在这个以 LLM 改进 LLM 的研究领域里，这份声明的坦诚本身也是研究伦理实践的一个样本。