HarnessPro 让 AI 智能体成本减半，通过率仍达最佳水平

清华大学与智谱 AI 的研究团队上周发布了一个新的智能体优化框架，颠覆了递归自我改进领域的一个主流假设：让 AI 智能体更擅长完成任务，必然让它们运行起来更贵。HarnessPro 于 10 月 19 日发表在 arXiv 上，并同时在 GitHub 上开源。它表明，只要把成本当作优化目标而不是事后才考虑的问题，修改基础模型外围的脚手架（而不是重新训练模型本身）就能同时提升通过率和降低单任务成本。

在 Scale AI 包含 1,865 道题的仓库级编程基准 SWE-Bench Pro 上，HarnessPro 的中性能配置在通过率上追平了此前最好的无标注方法（微软的 RHO），同时把平均单任务开销从 2.68 美元降到 1.26 美元，降幅 53%。它的高性能配置在 Terminal-Bench 2 上取得了已发表结果中最高的通过率；Terminal-Bench 2 是一项来自ICLR 2026 论文的 89 道题命令行基准；与此同时，其单任务开销比 RHO 低 33.9%。同一个 RHO 方法在 SWE-Bench Pro 上提升通过率的同时，相对未优化的基线把单任务成本提高了 42.6%，这样的交换让许多生产场景的部署经济账算不过来。

HarnessPro 与前人方法在结构上的不同，不在于某一项技术，而在于两个架构决策：它把成本和通过率作为联合目标，从帕累托前沿上选择脚手架配置，而不是只优化一个指标；它用合成的可执行单元测试，取代了以大语言模型充当评判的评估方法（论文显示后者对失败的召回率只有 41.7%）。这两个选择都改变了系统的优化方向。结果不是一个进化出来的脚手架，而是三个：Lite、Medium 和 Heavy，由同一次进化运行产生，分别对准成本与性能权衡上的不同位置。

通讯作者是清华大学计算机系教授、智谱 AI 首席科学家唐杰，以及清华大学自动化系副教授 H. Vicky Zhao。共同第一作者潘卓识（Zhuoshi Pan）和冯致远（ZhiYuan Feng）均来自清华。

业界其他方法尚未解决的递归自我改进成本膨胀问题

要理解 HarnessPro 在回应什么，有必要先了解它在前人工作中指出的具体失效模式。

智能体脚手架的递归自我改进是这样运作的：基础模型用某个初始脚手架配置（提示词、工具定义、重试逻辑、记忆管理和编排代码）在一组任务上运行，得到的执行轨迹被交给另一个模型（或同一个模型），由它提出对脚手架的改进。改进后的脚手架再次运行，产生新的轨迹，循环往复。不需要人工标注正确输出，系统自己给自己打分。

清华团队指出的问题是，提高通过率最直接的办法，就是更彻底的探索和更充分的验证。更多探索意味着更多工具调用、更多推理步骤和更多 token；更多验证意味着运行额外的检查、更频繁地调用模型，以及在确定答案前增加推理次数。两者都会推高成本。

微软研究院的 RHO 框架于 2026 年 6 月发表，清楚地展示了这种模式。RHO 使用一种无标注的回顾式评估方法，由语言模型判断每条轨迹是否成功，在多个编程基准上取得了可观的通过率提升。但在 SWE-Bench Pro 上，它的代价是把平均单任务成本从 1.88 美元提高到 2.68 美元，增幅 42.6%。在单目标优化之下，朝着更高分脚手架前进的轨迹，也就是朝着更贵脚手架前进的轨迹。

这种动态并非 RHO 独有。它反映了单目标递归自我改进的一个结构性特征：当唯一的信号是任务成功时，系统就没有动力去寻找更便宜的路径。脚手架会朝着任何能最大化通过率指标的方向进化，而不管 token 成本。在研究基准的语境下，这可以接受；在生产部署中，每个任务都按真实的 API 账单计费，每做一轮递归自我改进优化成本就上涨 42%，这项技术就很难站得住脚。

HarnessPro 的前提是，要解决这个问题，必须从一开始就把成本作为优化目标中的一等公民：不是事后加上的正则项，而是候选选择中同等重要的一条坐标轴。

一个会诊断、规划、编辑和测试的四智能体进化循环

HarnessPro 的进化过程一次运行一个轮次，每个轮次都让整个候选脚手架池经过一条四阶段流水线，然后才进入下一轮选择。

第一阶段是轨迹分析器（Trajectory Analyzer）。它不只评估脚手架在每个任务上是成功还是失败，而是读取每个候选脚手架在训练集上的三次独立执行。三次执行可以减少语言模型在采样下的随机性带来的噪声；单次评估会把真正的脚手架缺陷与从模型分布中抽到坏运气混为一谈。从这三次执行中，轨迹分析器识别的不只是结果，还有模式：哪些工具调用序列是多余的，智能体在哪里陷入了重试循环，上下文在哪里被塞进了对最终输出毫无影响的信息。论文附录中的一个案例说明了它能抓到的问题有多大。在一个配置邮件服务器的任务中，智能体成功完成了设置，但轨迹分析器指出，它在中间步骤里反复倾倒无关的配置文件日志，在对最终答案毫无贡献的内容上消耗了 251 万个输入 token。任何通过/失败指标都发现不了这一点，只有轨迹级分析可以。

第二阶段是进化规划器（Evolution Planner）。它接收轨迹分析器的诊断、成本指标（消耗的 token、API 开销），以及池中各候选脚手架之间当前的代码差异。比较代码差异是刻意为之：这让进化规划器能看到其他候选做了哪些修改，判断成功的改动能否借鉴。对每个候选脚手架，进化规划器提出三个独立的修改方案：一个偏向降低成本（I₁），一个寻求平衡（I₂），一个不受成本约束、追求最高性能（I₃）。这种三分支设计意味着，即使一个最初为成本优化的脚手架，也会生成一个偏重性能的变体，反之亦然，从而避免过早收敛到权衡空间中的单一区域。

第三阶段是脚手架编辑器（Harness Editor）。它在隔离的工作区中执行进化规划器的每个方案：修改脚手架的 Python 代码、配置文件和提示词模板。每次修改都提交到 Git，形成完整的版本历史，一旦某个候选的性能意外下降就可以回滚。使用隔离工作区意味着一个脚手架谱系的修改不会污染另一个；在选择发生之前，池中的候选各自独立进化。

第四阶段，也是方法论上最重要的一环，是测试合成器（Test Synthesizer）。在无标注的设定下，要评估脚手架的输出是否正确，需要某种不依赖参考答案的自动判断。标准做法是以大语言模型充当评判：把执行轨迹交给语言模型，让它判断任务是否正确完成。论文报告，这种方法对失败的召回率是 41.7%，也就是说，当脚手架确实没完成任务时，大语言模型评判只有 41.7% 的时候能把它识别为失败，另外 58.3% 的失败被判为成功。这是大语言模型评估文献中已有充分记录的系统性乐观偏差，在需要精确核验终端状态、而非定性判断文本的任务中尤为明显。

测试合成器用生成的代码取代了大语言模型的判断。给定任务描述，测试合成器使用 Python 的 unittest 框架编写十个单元测试。这些测试验证输出的具体、确定性的属性，而不是整体印象。测试要么通过要么失败，不存在关于成功的概率分布。由此得到的失败召回率升至 83.3%，比大语言模型评判高出 41.6 个百分点。由于测试是从任务描述而不是参考答案生成的，不需要任何标注数据，无标注的特性得以保留。

基准数字说明了什么，又证明不了什么

每一轮进化之后，所有候选脚手架都在测试集上评估，确定它们在成本与通过率平面上的位置。被帕累托支配的候选，即存在另一个候选既更便宜又更准确的，会被剔除出池。从构成帕累托前沿的幸存非支配候选中，HarnessPro 选出三个特定的脚手架：最接近最低成本目标的（Lite）、最接近平衡目标的（Medium），以及最接近最高性能目标的（Heavy）。选择依据是到这些目标的归一化加权平方距离，不同档位使用不同的权重向量，分别侧重成本或性能。三个被选中的脚手架作为初始池进入下一轮进化，让每个档位在其成本与性能区间内继续改进。

论文用两种模型组合，在三个基准上评估了这三种配置。GPT-5.5 + Codex 组合与 GLM-5.2 + Claude Code 组合，用来检验进化出的脚手架能否跨模型家族泛化。以下所有性能数据均为论文自报；截至本文写作时（arXiv 提交后五天），尚无外部研究人员独立复现。

在测试 89 道命令行界面任务的 Terminal-Bench 2 上，HarnessPro Heavy 取得了 80.8% 的平均通过率，比 RHO 高 4.5 个百分点，论文称这是最佳水平。Terminal-Bench 2在 ICLR 2026 发表时，给出的前沿模型基线上限低于 65%，因此如果能被独立复现，80.8% 这个数字意义重大。Heavy 配置下的单任务成本比 RHO 低 33.9%。

在需要解决 1,865 个仓库级真实 GitHub 问题的 SWE-Bench Pro 上，HarnessPro Medium 取得了 79.0%，与 RHO 的 80.0% 大致持平，单任务成本为 1.26 美元，而 RHO 为 2.68 美元。HarnessPro Heavy 的通过率超过了 RHO，花费却更少。SWE-Bench Pro 的结果有一个基准层面的保留：论文作者指出，数据污染仍是一个隐患，因为脚手架底层的模型（GPT-5.5 或 GLM-5.2）可能在预训练中见过相关的仓库模式。HarnessPro 修改的是脚手架代码而不是模型权重，这降低但没有消除这一隐患。

在需要从零重建程序的 ProgramBench 上，HarnessPro 的三个档位在两种模型组合下都超过了未优化的基线和 RHO。

最低成本档位 HarnessPro Lite 在全部三个基准上的通过率都高于未优化的原始基线，同时开销比原始基线降低 17.7% 到 57.4%。这是一个不寻常的结果：一个主要为成本优化的配置，依然比未优化的基线表现更好，说明进化过程找到的是真正的效率改进，而不只是削减了智能体的能力。

一个并非设计目标的附带发现：在 SWE-Bench Pro Heavy 上，平均任务完成时间从 520 秒降到 412 秒，延迟降低 20.7%，尽管延迟并不在优化目标中。作者将此归因于降低成本的同一套 token 效率机制：脚手架在多余操作上浪费的 token 越少，完成任务也越快。

AI 进化出了工程师没有写的东西

HarnessPro 更有启发性的一面，是考察进化过程究竟产出了什么。团队检查了进化后脚手架的源代码，发现了三种机制；他们报告说，这些机制在初始脚手架设计中并没有被显式编写，而是在多智能体递归自我改进循环中涌现出来的。

第一种是动态路由。在未优化的脚手架中，同一套配置（推理强度、工具调用预算、上下文管理策略）不管任务复杂度如何都适用于每一个任务。进化后的脚手架则在执行前读取任务描述，把任务分配到五个配置档位之一：compact、lean、standard、deep 或 research。每个档位对推理强度和最大工具调用次数有不同的设置。compact 档的任务使用最少的推理和很少的工具调用；research 档的任务允许长时间推理和大量工具预算。这种随任务自适应的资源分配，意味着简单任务只消耗它所需的资源，而不是得到和基准套件中最难任务一样的分配。

第二种是论文所说的运行时预算钩子，实现在一个进化出来的hook.py 文件里。该机制在三个逐级升高的阈值上强制执行工具调用预算。当智能体在一次会话中达到 14 次工具调用时，hook.py 会在该次工具调用的返回内容后附加一条消息，提示智能体正在进入「节约阶段」，应当合并后续步骤、停止重复相同的查询，并合并验证步骤。达到 26 次时，会注入一条更强的警告：智能体已进入「收敛阶段」，应停止大范围探索，只专注于敲定答案。达到 44 次时，钩子执行硬性拦截：截下下一次工具调用，返回一条拒绝消息，指示智能体基于现有证据提交最佳答案。

让钩子机制格外高效的一个工程细节是：进化后的脚手架没有把预算提示注入系统提示词或用户轮次（那会在长会话中破坏前缀 KV 缓存，推高成本），而是把提示附加在工具返回值的末尾。系统提示词保持不变，提示词前缀缓存就能在整个会话中正常工作。这种保留缓存的细节，是工程师经常手动实现的那类优化；递归自我改进过程独立地得出了它，这一点值得注意。

第三种机制是日志折叠。在终端和仓库任务中，命令行工具的输出经常包含成千上万行重复内容：在循环中反复出现的相同错误信息、冗长的构建系统输出，或者把同一种模式重复几百次的编译诊断。进化后的脚手架会检测工具输出中连续重复的模式，把它们折叠成一行，并加上「[上一行又重复了 N 次]」的标注，思路与 RTK（Rust Token Killer）工具相似。它还会截断过长的输出，只保留开头和结尾几行。初始脚手架模板中这两个功能都没有；两者都直接针对轨迹分析器发现的那个 251 万 token 日志倾倒的失败案例。

消融实验证实，这三种机制单独移植到 RHO 上都不能干净地生效。只把动态路由移植到 RHO 上，成本下降但通过率也下降；只给 RHO 加上预算钩子，也出现类似的情况。论文将此归因于协同进化：这些机制是共同发展出来的，相互依存地发挥作用。动态路由之所以有效，是因为预算钩子强制执行了路由层定义的分配；日志折叠之所以有效，是因为路由层避免把重度推理分配给那些折叠输出会丢掉关键诊断信息的任务。把它们拆开只能得到部分收益，失去协同效应。

HarnessPro 在不断扩张的递归自我改进版图中处于什么位置

脚手架递归自我改进这一子领域在 2026 年明显加速。微软研究院的 RHO（2026 年 6 月）确立了无标注、基于轨迹的优化范式，HarnessPro 是在此基础上的延伸。Sakana AI 与加州大学伯克利分校的 RHI（2026 年 7 月）从另一个抽象层面入手：RHI 不直接修改脚手架代码，而是进化描述智能体行为的提示词级规范。这种范围上的差异有实际影响。提示词级规范的进化比脚手架代码的进化更轻量、运行更快，后者需要隔离的执行环境和 Git 提交循环；但它无法产生 HarnessPro 代码级修改所生成的那种运行时钩子约束或结构化日志折叠逻辑。两种方法是互补而非直接竞争的；一个先做提示词规范进化、再做代码级脚手架进化的系统，可以覆盖两个层面。Harness-of-Harnesses 框架（arXiv:2609.01481）采用分层方法，用一个脚手架监督和改进另一个，而不是让同级候选一起进化。这种设计引入了一个元层面的优化循环，但没有解决 HarnessPro 所针对的帕累托多目标选择问题。

HarnessPro 在这一领域占据一个特定位置：它在可执行的脚手架代码层面运作（与 RHO 相同，与 RHI 不同），它不需要标注（与 RHO 和 RHI 相同，与全监督的变体不同），而且它是这一脉络中第一个采用帕累托多目标优化、而非单一指标优化的系统。多档位输出（一次进化运行得到 Lite/Medium/Heavy）在前人工作中没有直接对应物，以往的进化只产出一个为通过率调优的配置。

这种帕累托产品线式的输出，可以说是对部署实践最有影响的贡献。把 HarnessPro 投入生产的团队，不会只拿到一个进化出的脚手架，然后不得不用不同的超参数重跑进化，在通过率和成本之间做选择。相反，一次进化运行就能产出三个从同一进化池中同时协同优化的配置，每个都代表一个经过验证的帕累托最优工作点。Medium 配置实际上是 RHO 的降本直接替代品：通过率相近，开销低 53%。Heavy 配置适用于准确率是首要约束、成本居次的工作流。Lite 配置则让对成本敏感的应用也能用上：它们需要比未优化基线更高的通过率，但负担不起最佳准确率的全部成本。

这些说法有几项重要的局限。所有性能数据都来自 HarnessPro 论文本身；截至本文写作时，还没有独立研究团队复现这些结果。论文作者承认，在广泛互联网数据上训练的模型可能在预训练中见过相关的仓库模式；虽然只修改脚手架并不涉及模型微调，但底层模型的预训练数据仍是 HarnessPro 论文无法完全控制的变量。进化出的脚手架也只适用于进化时所用的模型组合：为 GPT-5.5 + Codex 进化出的配置，不重新跑进化就不能移植到 GPT-5.5 + Claude Code 组合上，因为脚手架的动态路由阈值、工具调用预算和日志折叠参数，都是按特定模型组合的延迟和 token 消耗特性校准的。

进化过程本身需要在每个轮次中对多个训练集任务进行多次执行，这本身就有成本。论文没有报告包含进化开销在内的摊销总花费，而对于正在考虑是自己跑进化循环、还是把开源的进化配置直接用在兼容模型组合上的团队来说，这一点非常重要。对于已经在 SWE-Bench 类任务上使用 GPT-5.5 + Codex 或 GLM-5.2 + Claude Code 的团队，预先进化好的配置可以直接使用。对于使用其他模型组合的团队，进化基础设施（四个专门智能体、Git 版本管理、隔离执行环境、多次执行评估）会在任何成本节省到来之前，先带来不小的工程开销。

GitHub 上发布的进化配置，是针对所测试的特定模型预先跑出的进化结果。使用不同模型版本或组合的团队需要自己运行进化轮次；在多轮进化循环中为每个候选跑三次执行的 API 成本，可能是一笔可观的前期支出，单任务的节省需要在足够大的生产运行量上才能摊销回来。

帕累托前沿：智能体基础设施的一种新设计原语

HarnessPro 朝着把智能体部署视为多目标工程问题、而非单一指标优化竞赛迈出了具体的一步。只用基准排行榜名次来衡量智能体性能（单目标递归自我改进自然会鼓励这种做法），会形成一种压力，促使系统朝着只优化基准分数、不顾运营成本的方向进化。基于帕累托的选择从一开始就把成本的可见性纳入进化循环，防止选择动态把所有进化候选都推向昂贵的高准确率配置。

对于更广泛的研究社区，测试合成器的结果（失败召回率从 41.7% 提升到 83.3%）为评估方法论设定了一个具体目标：仍在使用大语言模型评判的无标注递归自我改进研究，所依赖的信号漏掉了一半以上的失败。这一改进表明，只要任务成功可以表述为确定性的代码级断言，从任务描述生成的单元测试就应当成为无标注评估流水线的标准组成部分。其影响超出了递归自我改进这一子领域。任何依赖大语言模型对执行轨迹作出判定的智能体评估框架，包括自动化红队流水线、能力评估和智能体安全测试，都面临测试合成器所解决的同样的偏正问题。凡是任务结果可以归结为可执行断言的地方，生成的测试套件都是比模型生成的文本判断更可靠的信号。

据 HarnessPro 论文的作者简介，第一作者潘卓识的 ContextPilot 论文已被 EMNLP 2026 接收，它提供了一条相邻的技术线索。ContextPilot 使用细粒度强化学习训练智能体主动管理上下文，决定在上下文窗口中保留什么、丢弃什么。这项工作和 HarnessPro 从不同角度解决 token 效率问题：ContextPilot 通过强化学习训练在模型行为层面运作，HarnessPro 则通过脚手架代码进化在脚手架层面运作。把两种方法结合起来，让一个为上下文效率而训练的模型运行在一个强制执行预算纪律的进化脚手架里，是两篇论文都尚未探索的开放研究方向。

这个框架接下来最重要的是独立复现。这些基准说法，尤其是 Terminal-Bench 2 上 80.8% 的通过率和 SWE-Bench Pro 上 53% 的成本降幅，需要外部验证，才能被视为既定事实而不只是有前景的发现。在 GitHub 上开源的代码让复现成为可能；社区的反应将决定，HarnessPro 基于帕累托的架构会成为下一代智能体优化框架的基础，还是一个仍待更广泛验证的研究原型。