HarnessCompass：5轮迭代升至66%，Agent外壳为何能真正泛化？
HarnessCompass: Guiding Automatic Harness Evolution toward Generalizable and Effective Agent Harnesses
在大模型驱动的软件工程 Agent 体系中，决定模型最终解决问题能力的，往往不只有底座模型本身的推理水平，还取决于包裹在模型外部的 Harness（即脚手架或交互外壳）。这个软件层囊括了系统提示词、工具实现、中间件逻辑、记忆机制以及子代理协同逻辑，它直接规定了模型如何感知环境、调用工具并验证结果。过去几个月，社区逐渐意识到 Harness 的重要性不亚于升级模型本身，但人工调试 Harness 成本高昂且难以跟上模型迭代速度。为此，自动化脚手架演化（Automatic Harness Evolution）应运而生：让一个 Meta-Agent 根据任务执行轨迹，自主编写并修改脚手架代码。
ArXiv URL：https://arxiv.org/abs/2608.01918
然而，现有的脚手架自演化技术很快撞上了天花板。最近多项基准测试揭示了一个尴尬的事实：自动化演化系统在见过的训练任务上得分节节攀升，但一旦放到从未见过的留出任务（Held-Out Tasks）上，性能便出现断崖式下跌。这种“虚假繁荣”暴露出当前演化范式的根本缺陷——Meta-Agent 实际上是在针对固定任务集做过拟合的特定规则修补，而非探索通用的软件工程原理。
论文《HarnessCompass: Guiding Automatic Harness Evolution toward Generalizable and Effective Agent Harnesses》正是针对这一核心痛点展开的。作者团队认为，脚手架自演化之所以失控，根源在于整个搜索过程缺乏约束与结构化纪律。他们提出了 HarnessCompass 框架，通过引入全局泛化约束、Agent 第一人称主动反馈，以及分组件解耦优化三大机制，重新规范了脚手架演化流程。在 SWE-bench Verified 基准测试中，以 GPT-5.4 为底座的 HarnessCompass 仅经历 5 轮迭代，就将极简种子的 Pass@1 从 54% 提升至 66%，不仅在演化效率与最终效果上显著超越现有最先进方案 AHE，更关键的是在 450 个完全未见过的留出任务上取得了 60.4% 的高成功率，甚至能将演化出的脚手架无缝迁移给 Claude-Sonnet-4.6。这项研究表明，唯有戴上制度化的“紧箍咒”，大模型的自我演化系统才能产出具备真正泛化价值的通用工程组件。
现有脚手架自演化的三重困境
在深入 HarnessCompass 的机制之前，有必要剖析现有自动化脚手架演化方案究竟在何处失效。当前的典型方案通常采用外循环闭环搜索：让 Agent 在一组任务上跑出轨迹，由 Meta-Agent 阅读这些执行日志，分析失败原因，直接对脚手架代码提出修改，然后在基准上验证改动是否提分。表面上看这一逻辑天衣无缝，但在实际执行中存在三个相互交织的致命缺陷。
其一，演化过程极易向搜索任务严重过拟合。由于 Meta-Agent 拥有自由修改全部脚手架代码的权限，而评估标准仅仅是在当前任务集上的成功率，Meta-Agent 很快就会学会“走捷径”。例如，针对某个 Python 库报错，它可能会在提示词或中间件中硬编码特定的模块查找逻辑或关键词匹配规则。这些规则在当前 50 个搜索任务上能立竿见影地提高测试通过率，但因为高度绑定特定仓库结构，到了未见过的实际任务中立刻失效，甚至引发负迁移。
其二，单纯依赖轨迹衍生的外部信号会导致严重的归因错误。现有的 Meta-Agent 观察任务执行完全处于第三人称视角，它只能看到轨迹中的行为序列和最终报错。这就带来一个盲区：Meta-Agent 知道任务失败了，却无法获知代码 Agent 在使用脚手架时的真实心理状态和操作阻力。当一个任务执行失败时，究竟是代码 Agent 本身推理失误，还是脚手架提供的工具接口晦涩难用？如果是工具摩擦，代码 Agent 究竟需要什么样的环境支持？仅凭外部日志，Meta-Agent 极易发生误判，要么把脚手架的交互缺陷归咎为模型能力不足，要么把模型本身的逻辑硬伤错误地补偿为新增一个冗余工具。
其三，全组件联合优化引发恶性干扰。一个完备的 Agent 脚手架由结构性组件（如工具实现、中间件逻辑、子代理调度）与指导性组件（如系统提示词、技能库、工具说明、记忆模块）共同构成。现有演化框架习惯在单轮迭代中对提示词、工具脚本和控制中间件进行全盘修改。然而，不同组件之间存在复杂的隐式耦合：一个提示词的小幅微调可能会彻底改变模型调用某项工具的频次，而中间件的改动又可能让原本有效的提示指导失效。当所有模块混杂在一次提交中时，各项改动带来的微小收益不仅无法线性叠加，反而往往相互抵消，演化系统最终陷入低效震荡。
上述三个困境追根溯源，均指向同一个本质原因：给予了演化算法过高的自由度，却未能提供高质量的归因线索与隔离机制。HarnessCompass 的核心哲学，正是通过结构化的规则与流程，将无序的自由搜索转变为受控的定向演化。
泛化门禁：从源头斩断任务特化捷径
针对过拟合问题，HarnessCompass 确立的第一项原则是约束演化（Constrained Evolution），其物理载体是一个覆盖全部七类脚手架组件的全局泛化门禁（Generalization Gate）。
这个门禁的核心逻辑在于，在任何候选修改被写入脚手架之前，强制进行静态与语义上的两重检验。首先是对表达内容的检验：门禁严厉禁止任何与具体任务、具体仓库名称或特定文件路径硬绑定的代码注入。如果 Meta-Agent 试图通过添加特定错误码的特判分支，或是将某些特定库的安装命令硬编码进系统提示词，该改动会在第一时间被拦截驳回。其次是对组件职责归属的检验：演化框架严格界定了七类组件的功能边界，例如结构层面的中间件只允许处理执行流调度、错误捕获与环境重置，禁止包含任务导向的先验推理；而指导层面的系统提示词则专注于通用工程工作流规范，不得夹杂具体工具的执行黑盒代码。
通过双重检验，泛化门禁强迫 Meta-Agent 只能通过抽象的、可复用的通用工程准则来提升任务表现。例如，与其针对某一次 Git 冲突编写专用修复脚本，Meta-Agent 在门禁倒逼下会倾向于演化出一套标准的“先拉取分支状态、对比差异、再进行局部变基”的通用交互工具与指引。这种演化出来的能力具有天然的跨仓库可移植性，从源头上遏制了为了刷分而在演化集上进行特异化适配的冲动。
主动反馈：第一人称视角的轨迹接地验证
为了化解外部观察带来的归因失真，HarnessCompass 引入了第二项支柱机制——主动第一人称反馈（Proactive Feedback）。
在每一次演化评估轮次结束后，对于所有未通过验证的失败任务，框架并不急于把原始轨迹直接丢给 Meta-Agent，而是重新唤醒执行该任务的基础模型自身，让它扮演第一人称复盘者，汇报在操作脚手架时的真实体验。为了保证反馈的客观性，系统设计了两个互为补充的查询视角：一个是盲测汇报（Blind Report），在不提前告知标准答案和外部评估详情的情况下，询问模型在刚才的交互中究竟卡在哪个环节、哪个工具给出的环境反馈造成了误导；另一个是事后复盘（Hindsight Report），在结合最终失败结果的背景下，让模型反思脚手架是否缺失了某种关键的观察能力或干预手段。
然而，大语言模型自身的“自我辩护”往往存在幻觉，模型很可能会习惯性地将自身的逻辑推演错误甩锅给外部环境。因此，HarnessCompass 严禁直接采信第一人称汇报，而是建立了一道严密的轨迹接地（Grounding against trajectories）过滤层：
-
针对现有组件的摩擦投诉：如果模型抱怨某个 Bash 工具的截断机制导致重要日志丢失，该断言必须在原始执行轨迹中具有明确的证据支撑——例如轨迹中确实出现了关键堆栈被
... [truncated]掩盖，进而引发模型盲目重试的记录。若轨迹中没有显式体现，该投诉立刻作废。 -
针对全新能力的缺失请求：当模型提出希望获得一个新的代码结构搜索工具时，由于该工具此前并不存在，轨迹中自然不可能有调用记录。此时接地验证转向需求场景：轨迹中是否出现了模型多次手动编写复杂的
grep或find正则表达式却接连语法报错的挫败片段？只有当失败轨迹确实暴露出具体的工程能力空缺时，新增工具的请求才会被认可。
通过这套接地程序，虚假的甩锅言论和无效的冗余诉求被剔除，只有得到运行日志交叉印证的痛点才会沉淀为结构化证据。框架进一步按照组件类别对幸存反馈进行聚类，结合跨任务出现频次与双重视角的一致性打出置信度得分，最终递交给 Meta-Agent。这使得演化中枢能够准确获悉脚手架究竟在何处阻碍了模型的发挥，使得后续的补丁设计具备极高的诊断精度。
分轨演化与 R3 合并：兼顾独立探索与全局协同
即便有了清晰的诊断和泛化约束，如果把所有类型的脚手架组件混在一起修改，依然不可避免地会遭遇组件冲突。为此，HarnessCompass 在优化流程上采用了分组件演化（Component-wise Optimization）策略，彻底解耦不同性质组件的改动。
框架在每一轮迭代中，将脚手架拆解为两条平行且互不干扰的演化轨道：一条是结构轨（Structural track），专门负责可执行代码层面的改造，包括工具代码实现、子代理调度机制以及交互中间件；另一条是指导轨（Guidance track），专注于对模型心智的塑造，包括全局提示词编排、技能库注入、工具说明文档修正以及长期记忆格式。在每一轮搜索中，Meta-Agent 针对这两条轨道分别生成独立的修改方案，并在演化任务集上并行评估。
分轨评估后，单轮得分更高的轨道将被确立为本轮优胜版本（Winner）。但另一条轨道（Loser）并非一无是处，它所探索出的组件改动依然可能蕴藏着极高的互补价值。为了将另一轨道的有效改动吸纳进来同时避免引入回退，框架提出了名为 R3 的三阶段合并协议：
-
审视（Revision）：逐一审查未获胜轨道上的每一处局部修改，独立评估其有效性。凡是引发性能负迁移、暗含特定任务倾向、或因置信度不足而难以判断的修改全部被丢弃，仅筛选出被证明独立有益且与获胜轨不存在冲突的高价值补丁。
-
重组（Recombination）：将审视通过的优质补丁整合至获胜版本代码库中。如果在底层文件层面出现修改重叠，系统严格以获胜轨道的代码为最高优先级，确保本轮核心突破不被稀释。
-
精炼（Refinement）：在更高维度的功能语义层面排查隐性冗余。例如，如果指导轨新增了一条教导模型如何分块阅读超长文件的技能说明，而结构轨恰好在同一个迭代中直接为文件查看工具增加了智能自动分页机制，两者的功能便产生了语义重叠。精炼阶段会主动识别并剔除功能重复项，优先保留执行更稳定、确定性更高的结构层组件。
R3 机制在理论上优雅地解决了脚手架协同优化中的“干扰与共生”矛盾：既让不同的工程构想在无干扰的沙盒中独立自证其价值，又在收敛阶段通过严格的语义裁决实现了优势代码的无损融合。
SWE-bench 实证：高效率与真泛化的双重突破
为了全面检验 HarnessCompass 的有效性与鲁棒性，作者团队在真实的软件工程基准 SWE-bench Verified 上开展了严密测试。
实验设计本身就体现了极高的学术严谨性。为了彻底杜绝数据泄露并验证跨任务泛化，研究人员从 SWE-bench Verified 的 500 个真实 Python 仓库任务中随机抽取了 50 个作为演化搜索集，而其余 450 个任务作为留出集（Held-Out Set），在整个演化生命周期中对所有 Agent 绝对隔离，仅用于最终评估。此外，为了剥离初始脚手架质量的干扰，演化起点被设定为一个极其简陋的“极简种子”（Minimal Seed）$\mathcal{H}_0$：它仅包含一条最基础的 Shell 终端执行工具和一句简短提示词，完全不包含任何中间件、记忆库或高级技能。底座模型则统一采用非思考模式的 GPT-5.4，代码代理、轨迹分析、反馈生成与 Meta-Agent 全部共享同一模型，以保证性能收益完全来自脚手架代码本身的进化，而非外部模型的智商差异。
在这一严苛设定下，HarnessCompass 展现出了惊人的突破能力。基准种子 $\mathcal{H}_0$ 的初始 Pass@1 为 54.0%。对比现有最前沿的脚手架自演化算法 AHE，后者耗费了整整 20 轮漫长的演化迭代，在搜索集上达到了 63.0% 的通过率，但在 450 个留出任务上仅仅取得 54.7% 的成绩，总分 55.5%，留出集的提升幅度极其微弱，印证了前述的严重过拟合假说。
与之形成鲜明对比的是，HarnessCompass 仅用了 5 轮迭代，就将搜索集上的 Pass@1 提升至 66.0%。更具说服力的是其在未见任务上的表现：在 450 个留出任务上，HarnessCompass 取得了 60.4% 的通过率，较 AHE 高出整整 5.7 个百分点；全量 500 个任务的总评分为 61.0%，大幅刷新了该基准上的脚手架自动化演化记录。
5 轮对比 20 轮，不仅意味着演化开销与 API 调用成本呈现数量级下降，更说明由泛化门禁和精准反馈驱动的优化路径极其明确，几乎没有在无效的局部盲搜中浪费算力。
消融实验进一步厘清了三大核心原则各自承担的角色。如果在种子模型上仅开启泛化门禁，脚手架在第 2 轮就能将留出任务成功率拉升至 58.4%，这直接证明限制任务特化逻辑是跨任务迁移的决定性因素；若在门禁基础上叠加主动反馈，搜索集得分可进一步攀升至 66.0%，但因为丰富的第一人称信号带来了更多复杂的边缘改动，留出集得分出现了小幅回落（降至 55.8%），迭代轮次也延长到 12 轮；而最终当 R3 分轨合并机制介入后，结构与指导层面的隐性冲突被彻底抹平，演化步数骤降回 5 轮，留出任务得分一举恢复并冲上 60.4%。这充分印证了论文的核心洞见：三大机制是一个相互咬合的有机整体，缺一不可。
跨越模型边界：冻结脚手架的零样本迁移
评估一个系统工程设计是否真正具备通用性，另一个更为苛刻的试金石是跨模型迁移能力。学术界一直存在一种担忧：针对 GPT 系列模型演化出的脚手架，会不会只是隐式拟合了该模型特定的语言习惯或工具调用缺陷，一旦换成其他架构的模型就会失效？
为了回答这一问题，研究团队设计了一组极具启发性的交叉实验：将利用 GPT-5.4 经过 5 轮演化出的最终脚手架彻底冻结，在不做任何微调、不进行任何额外演化迭代的前提下，直接套用到完全不同架构的 Claude-Sonnet-4.6 上进行评估。
实验数据再次给出了极具说服力的结论。Claude-Sonnet-4.6 在极简种子 $\mathcal{H}_0$ 下的基础性能本身非常强劲，全量 500 任务的 Pass@1 为 70.0%（搜索集 68.0%，留出集 70.2%）。当直接换上由 GPT-5.4 演化出来的 HarnessCompass 脚手架后，Claude-Sonnet-4.6 的总评成绩直接上扬至 73.8%；在 50 个演化集任务上跃升至 76.0%，在 450 个未见留出任务上同样提升至 73.6%。
这意味着，HarnessCompass 在演化过程中提炼出的并非适配某一特定模型行为的私有“补丁”，而是总结出了一套真正契合复杂软件工程逻辑的通用交互范式。无论是中间件对于代码执行异常的优雅降级处理，还是工具层面对仓库全局信息的高效检索组织，这些经过严格检验沉淀下来的工程资产，对于具备高阶推理能力的通用大模型而言具有普适的增益价值。
脚手架自演化走向工程成熟
回顾 Agent 领域近两年的演进历程，人们起初将大部分精力倾注在底座模型的预训练与后训练对齐上。随后，以 SWE-agent、OpenHands 为代表的工作让业界深刻意识到，给模型配备怎样的“交互手眼”在很大程度上决定了其实际落地能力的上限。然而，纯人工手写脚手架很快陷入了人力瓶颈，这也是过去一段时间“让模型自我改进脚手架”成为前沿热点的原因。
早期脚手架自演化研究往往抱有一种理想主义的情怀，试图通过完全无约束的自由强化或元学习，让系统从零“顿悟”出一切工具和规则。但 HarnessCompass 用详实的对比实验表明，缺乏工程规范的纯自由搜索在复杂的软件工程场景中几乎必然滑向过拟合与内耗的泥潭。
HarnessCompass 的成功提供了一种极具现实意义的方法论转向：大模型的自我演化并不意味着彻底的放任自流。相反，构建高阶自主智能系统的关键，在于人类工程师如何提炼出正确的“元规则”——通过建立泛化门禁确立红线，通过接地反馈打通内省通道，通过分轨解耦规避模块冲突。在这套受控框架的指引下，大模型才能从无序的代码修补匠，真正蜕变成为自身构建通用工具体系的系统架构师。这一范式不仅为软件工程代码 Agent 的自动化迭代扫清了障碍，也为未来更广泛的复杂自治智能体系统的自我完善提供了具有高度借鉴价值的参考样本。