HarnessCompass: Guiding Automatic Harness Evolution toward Generalizable and Effective Agent Harnesses
Luan Zhang, Ruochen Zhou, Dandan Song, Zhengyu Chen, Yuhang Tian, Jun Yang, Huipeng Ma, Chenhao Li, Guangyuan Feng, Xudong Li, Yizhou Jin, Yan Xu
cs.LG, cs.CL
2026-08-03
给智能体脚手架的自动进化加三条约束(只改可迁移项、引入第一人称反馈、分组件优化)后,GPT-5.4 在 SWE-bench Verified 的 Pass@1 从 54% 升到 66%,5 轮跑完,泛化到新任务与新模型都更强。
一个代码智能体能不能修好 bug,取决于两件事:底座模型,以及包裹它的「脚手架」(harness)。脚手架是模型和环境之间的软件层,包括系统提示、工具、中间件、记忆和校验逻辑,决定模型怎么看到状态、怎么调用工具、怎么从失败里恢复。已有研究证明,单换脚手架带来的提升,有时跟换一个更强的底座模型相当。
问题是最好的脚手架跟模型强绑定,模型一换就得重调,而这活一直靠人干:读轨迹、定位故障、手动改脚手架。模型迭代一快,人就追不上。于是出现了「自动脚手架进化」,让一个元智能体去分析任务轨迹、提出脚手架改动、跑评测、循环迭代。这类方法(AHE 是其中代表)宣称在公开榜单上大涨,但作者把账细算了一遍,发现它有三个毛病:
一是过拟合搜索任务,因为元智能体可以对着固定的任务集随便改,容易塞进只在搜索集上有效的取巧;二是只看轨迹结果信号,元智能体能看到「失败了、卡在哪」,却看不到「脚手架为什么难用」,于是经常把模型自身的推理失误错怪到工具头上;三是所有组件一起改,提示、工具、中间件、记忆的编辑互相干扰,本来能叠加的提升被抵消成封顶。
HarnessCompass 把这三条毛病各开一剂药,合成一个有纪律的进化循环。
第一剂,泛化门(constrained evolution)。每一处候选改动都要先过一道全局门:门会拦掉任何提到具体任务实例、测试函数名、私有符号或任务专属 token 分支的编辑,只放行「带适用条件、能迁移到没见过的任务」的通用准则。门还规定改动的落点:新增可执行能力的改动必须落在中间件、工具或子智能体里;只给行为指示的改动必须落在系统提示或记忆里,不准写成可执行代码。为了确保每一份提升都是循环自己挣来的,作者故意从一个极简脚手架起步,只有一条 shell 命令、一段短提示,没有中间件、技能或子智能体。
第二剂,第一人称反馈(proactive feedback)。任务失败后,让跑这条轨迹的同一个代码智能体自述脚手架哪里卡手,分两次问:盲报(不告诉它结果,避免事后诸葛亮式归因)加事后报(告诉它结果,让它把失败归到脚手架、模型推理、任务歧义、环境四类之一)。然后拿每条报告去和轨迹对质,只保留轨迹能佐证的,丢掉无根据的抱怨和错怪。这样元智能体就多了一个轨迹给不了的「为什么」信号。
第三剂,分组件优化(component-wise optimization)。每轮并行进化两个变体,一个只动结构组件(中间件、工具、子智能体),一个只动引导组件(系统提示、技能、工具描述、记忆),取 Pass@1 高的当赢家。输家也不是全丢,走 R3 合并:Revision 只留独立有益、不冲突的输家编辑,Recombination 把它们叠到赢家身上(冲突时赢家优先),Refinement 删掉功能重叠的冗余。三条组件互不干扰,又能保留互补的提升。
主实验在 SWE-bench Verified 上做,500 道真实 GitHub issue,其中 50 道作进化集、450 道全程不见,底座是 GPT-5.4(非思考模式)。
| 方法 | 进化集(50) | 留出集(450) | 总分(500) | 进化轮次 |
| 极简种子 H0 | 54.0% | 51.6% | 51.8% | 0 |
| AHE | 63.0% | 54.7% | 55.5% | 20 |
| HarnessCompass | 66.0% | 60.4% | 61.0% | 5 |
留出集上的差距(5.7 个百分点)比进化集上(3.0)更大,说明提升确实来自可迁移的设计,而不是针对搜索集的取巧。消融把三条原则逐个加上去:单加泛化门,2 轮就把种子从 54% 拉到 62%,留出集从 51.6% 涨到 58.4%;再加第一人称反馈,进化集冲到 66%,但留出集反而掉到 55.8%、轮次涨到 12(开始过拟合);最后加 R3 合并,保住 66% 的进化集,同时把留出集救回 60.4%、轮次压到 5。
跨模型迁移是更硬的考验。把在 GPT-5.4 上进化出的脚手架冻结,原样放到 Claude-Sonnet-4.6(非思考模式)上跑,总分从 70.0% 升到 73.8%,留出集从 70.2% 到 73.6%。按仓库拆,sphinx-doc 从 35.2% 到 58.0%,pytest-dev 从 52.6% 到 68.4%,django 从 59.3% 到 70.1%,而本来就近满分的 scikit-learn(73.4%)几乎不动;在 Claude 上 astropy 从 45.5% 到 63.6%。提升集中在「多步改了再验」、最吃脚手架的仓库。
对部署代码智能体的团队,脚手架是比训练新模型便宜得多的杠杆。HarnessCompass 给的不是又一个榜单分数,而是一套可复用的纪律:在很小的搜索集上进化,产出的脚手架能迁移到没见过的任务和其他模型。这把「调脚手架」从手艺活变成可复现的工程步骤。要诚实的是,提升真实但不算颠覆,在一个已经 54% 的底座上把分数往上抬;更值钱的是效率(5 轮对 20 轮)和迁移性。
验证面偏窄。只测了 SWE-bench Verified,也就是 Python 仓库的英文软件工程任务,十二个仓库;这套纪律在非编码智能体领域(网页、终端、工具编排)成不成立,论文没碰。跨模型只试了两个前沿模型(GPT-5.4、Claude-Sonnet-4.6),对小模型或开源模型是否同样奏效不清楚。进化只切了两条组件轨,更细的拆分可能更好也可能更乱。留出集仍落后进化集(60.4% 对 66%),说明搜索集亲和还没消干净。第一人称反馈会让每个失败任务多一倍模型调用,成本不低。所有评测都在非思考模式下做以隔离脚手架的贡献,而真实部署常开思考模式,那时脚手架的贡献可能被压缩。