冻结权重不动，脚手架递归优化：Harness²让GLM-5单步超越Gemini 3.5 Flash基线

2026年10月9日，Google Cloud AI Research联合西北大学在arXiv发布论文《Harness²: Recursive Agent Harnessing for an Open World》，代码同日以Apache 2.0协议在GitHub开源。论文核心结论：在模型权重完全冻结的前提下，递归优化包裹模型的脚手架——系统提示、工具、记忆、子智能体等八个组件——让GLM-5在WorkBuddy-Bench上的得分从64.2跳升至75.7，单步提升11.5分；Gemini 3.5 Flash在Harvey法律基准LAB上提升11.8个百分点；在专业任务基准JobBench上，Gemini提升4.5分（31.5→36.0）。论文发布约两周后，代码仓库已积累约6,600个GitHub Stars。

这组数字的真正震撼之处，不在于绝对提升幅度，而在于跨模型对比所揭示的结构性事实：在同一执行器OpenCode下，使用自改进脚手架的GLM-5（75.7分）超过了使用默认脚手架的Gemini 3.5 Flash（72.4分）。换言之，一个能力相对较弱的基础模型，凭借更好的"包装"，在基准测试上击败了更强的基础模型。同样的逆转在另一个执行器Codex下亦有重现（75.3 vs 74.5）。这不是边缘案例，是在三个基准、四种模型-脚手架配置下反复出现的系统性现象。

八个文件，两层递归，不碰权重

理解Harness²的运作方式，需要先明确该框架对"脚手架"的定义。Harness²将智能体脚手架拆解为八个可编辑的运行时文件：系统提示、护栏（guardrails）、记忆、技能库、工具指引、脚本、子智能体，以及一个中间件插件。模型本身从不被触碰，所有优化发生在这八个文件上。

优化机制分为两个嵌套的递归层。第一层是任务级递归：每次执行任务时，脚手架编辑器会先用基础脚手架跑一遍任务，得到参考执行轨迹，再生成两类候选修改——一类针对跨领域的通用智能体弱点（规划、工具调用、任务委派），另一类携带当前领域的专有知识与流程。两个候选版本都在相同任务设置下探针执行，通过"行为对比"而非与标准答案比对来评估修改效果：改动有没有真正改变它所针对的行为？最后，一个合成器将有效的修改融合进新脚手架。

这个"Propose-Probe-Compose"三步循环解决了一个实际部署难题：真实世界任务通常没有可以直接对比的标准答案。以往的递归自改进方案依赖奖励函数或人工标注，在开放领域部署时往往失灵。Harness²用行为对比代替真值验证，绕开了这个约束。

第二层是脚手架级递归：任务完成后，一个反思器会将此次采纳的修改和有证据支持的经验教训写入一个持久性"改进脚手架"库。后续任务仍从同一基础脚手架出发，但提案阶段会参考这个积累的经验库，使改进建议随使用时间不断收敛。论文设计中，脚手架的编辑器本身使用的是Anthropic的Claude Opus 4.8，在OpenCode框架下运行；被评测的冻结执行器则是Gemini 3.5 Flash和GLM-5。

工具调用错误率下降36.8%，才是企业用户最在意的数字

学术基准的分差容易被当作数字游戏，但Harness²将工具调用错误率降低了最高36.8%，没有任何权重更新。对于依赖AI智能体执行实际任务——文件操作、代码执行、数据库查询、API调用——的企业来说，工具调用失败的代价是真实的：它意味着任务中断、人工介入、错误传播。如果一个无需重新训练的框架能把这类失败减少三分之一以上，采购决策者的计算就会发生变化。

对开发者而言，Apache 2.0协议下的开源意味着可以合法地将这套优化框架用于商业产品。实际使用时，开发者不需要改动模型调用逻辑，只需将脚手架的八个组件以文件形式暴露给Harness²的编辑器，就可以启动自改进循环。这比LoRA微调或RLHF对基础设施的要求低一个数量级。

对于希望降低大模型依赖成本的团队，这里有一个更直接的使用路径：如果价格更低的GLM-5经过脚手架优化后能达到或超过Gemini 3.5 Flash的默认表现，那么在应用层引入脚手架优化就是一种有效的成本套利手段。论文中的数据已在两个执行器下验证了这条路的可行性。

排行榜的可比性问题，比Harness²本身更深远

Harness²引发的产业影响，超出了这个框架本身的边界。多数现有大模型排行榜——无论是综合榜单还是垂直领域评测——报告的是"模型+其默认脚手架"的联合得分。Harness²的数据以实验方式表明，同一模型在不同脚手架下的得分差距可以超过11分；不同模型在优化vs默认脚手架下的排名可以互换位置。

这意味着当前排行榜上的相邻名次之间，至少有一部分差距可能不是模型能力的差距，而是脚手架工程投入的差距。对于依赖评测结果做选型决策的企业和开发者，这构成一个实质性的信息问题：你看到的第N名和第N+2名，可能只是"工程团队在默认脚手架上投入不同"的结果，而非基础模型能力的真实反映。

Hacker News等平台上围绕这篇论文的讨论集中在这一点上：脚手架对最终结果的贡献究竟有多大，而现有评测体系对这一贡献几乎没有任何标准化的测量或披露。一个没有统一脚手架标准的排行榜，公布的数字更接近"最优秀的提示工程成果展示"，而非模型基础能力的横向比较。

从历史先例看：工程层的收益往往先于架构层被低估

这并非第一次出现"不改模型本身、靠工程层取得显著收益"的先例。思维链提示（Chain-of-Thought）被系统性研究以前，研究界对提示设计的能力上限普遍持保守估计；工具调用（Tool Use / Function Calling）在标准化之前，各家的实现效果差异同样巨大。回溯这些历史，可以发现一个模式：在某个能力层尚未被系统化、标准化之前，它的贡献容易被低估，而当出现一篇将其量化的论文后，行业往往才意识到这一层对总得分的实际贡献比之前认为的大得多。

Harness²做的事，是把"脚手架工程"从经验性操作推进到可测量、可递归优化、结果可复现的方法论层面。这个动作本身——不管Harness²这个框架的最终采用率如何——给出了一个可以被引用和比较的量化基准：脚手架优化在专业任务上的单步收益是11分量级，不是1-2分量级。

不确定性与待验证的边界

目前已发布的实验数据来自三个基准和四种模型-脚手架配置组合。论文中的被测模型为GLM-5和Gemini 3.5 Flash；编辑器为Claude Opus 4.8。这一方法在更广泛的模型范围（例如参数量更大或更小的模型）和更多基准上的普适性，以及在高并发生产环境中的稳定性，目前还没有独立的第三方复现数据。

此外，递归优化本身的计算成本值得关注：每次任务级递归需要探针执行多个候选脚手架，并由一个独立的编辑器模型（Claude Opus 4.8）驱动提案和合成。对于延迟敏感或预算受限的应用场景，这一额外开销是否合理，取决于具体任务的价值密度。论文中并没有披露每次改进循环的推理成本数据，这是选型时需要自行测量的变量。

接下来最可能发生什么

以下是基于以上分析的前瞻判断，明确标注为分析而非事实。

短期内，最可能的行业连锁反应是主流评测机构被迫在结果页面上增加脚手架配置的披露字段。就像FLOPS透明度推动了算力归一化对比一样，Harness²提供了一个可以被引用的论文依据，让"报告时应同时披露脚手架设置"这个诉求从从业者的直觉变成可以注脚的学术共识。

中期来看，如果Harness²的独立复现实验验证了其跨模型普适性，"脚手架优化"很可能成为大模型API提供商的标准增值服务方向——类似于现有的Fine-tuning API，但不涉及权重更新，部署周期更短，可以更频繁地迭代。

未来六个月内，是否有独立研究团队在MMLU、SWE-Bench、GAIA等更通用基准上复现类似量级的提升；现有排行榜（例如Chatbot Arena类产品）是否开始在提交要求中加入脚手架披露规范。前者决定这个方向的普适性边界，后者决定它能否实质改变行业比较标准。

对于当下需要做决策的开发者：如果你的智能体应用已经稳定运行但瓶颈在工具调用稳定性和任务完成率上，Harness²提供了一个不用等待下一代基础模型、也不需要标注数据就可以立即尝试的改进路径。代码已开放，成本是测试脚手架变体所需的额外推理费用，下限低，可以先小规模实验验证收益后再决定是否引入完整的递归优化循环。