Google Harness² 架构解构：不改一行权重，让智能体自己重写自己的脚手架

背景：开放世界里的自我改进缺两样东西

过去两年，智能体工程有一个被反复验证的观察：同一个模型，换一套脚手架，分数能差出一截。系统提示词怎么写、工具描述给多细、什么时候该委派子智能体、记忆怎么回灌，这些围绕模型的东西合起来被称为 Harness。业界已经有大量经验性结论，但这些结论大多靠人工试出来，且高度依赖具体任务。

递归自我改进（Recursive Self-Improvement，RSI）是想把这件事自动化：让系统自己改自己。论文作者在摘要里点明了开放世界场景下 RSI 的两个硬伤：其一，开放世界的任务在 Harness 设计阶段往往没见过，测试时才是新的，因此不存在可信的真实校验器（ground-truth verifier）来指导在线改写；其二，已有的 RSI 过程高度任务特化，改出来的东西很难迁移到新场景。

这两条恰好解释了为什么此前一大批自动优化方法在学术基准上好看、在企业环境里不好用：学术基准自带答案，企业任务没有。一次合同审查、一份投标文件的口径核对、一个跨系统的数据核对，往往不存在可以自动判分的正确答案，甚至连「什么算做完了」都需要人来定义。

Harness² 是什么：一个插件式框架与两层递归

论文《Harness²: Recursive Agent Harnessing for an Open World》于 2026 年 10 月 9 日提交 arXiv（编号 2610.14224v1，PDF 约 6.87 MB），作者为 Ruiyao Xu、Yanfei Chen、Zhongying CuiZhu、Bhavana Dalvi Mishra、Yifei Ming、Han Yu、Rujun Han、Chen-Yu Lee、Tomas Pfister，所属学科为人工智能、计算语言学与机器学习。代码以 google-research/harness2 之名开源，许可为 Apache 2.0，第三方代码与基准数据集保留各自上游许可。

整个框架由两个互相咬合的递归层构成。任务级递归针对当前任务改写执行 Harness，手段是一步对比式的「提出—探测—组合」；Harnessing 级递归则在每个任务结束之后，把被采纳的 Harness 与有证据支撑的经验沉淀下来，更新一个持久存在的改进 Harness，用来指导后续任务的改写。用论文的表述：执行 Harness 是被改进的系统，改进 Harness 是改进它的机制。

这种两层结构解决的是「每次都从零开始」的问题。只有任务级递归时，每个新任务都要重新试错；有了 Harnessing 级递归，上一个任务总结出的经验会成为下一个任务的起点，经验库随着任务数增长而变厚。

八类可编辑组件：把「智能体」拆成八个文件

Harness² 把智能体周围的东西拆成八个可编辑组件，每个组件在运行时挂载为一个文件。这一层拆分是整套方法的前提：如果 Harness 是一坨不可分的代码，就没法「改写其中一项、观察行为差异」。

组件	运行时角色	改写后可能影响什么
系统提示词（system prompt）	构造上下文	角色定位、输出格式、总体行为倾向
护栏（guardrails）	构造上下文	哪些动作被禁止、何时必须停下求助
记忆（memory）	构造上下文	跨轮次保留什么、回灌多少、何时遗忘
技能（skills）	构造上下文	可复用的作业程序与领域知识
工具指引（tool guidance）	定义工具界面	工具描述粒度、参数示例、调用纪律
脚本（scripts）	定义工具界面	确定性动作是否下沉为可执行代码
子智能体（subagents）	编排委派	任务怎么切、派给谁、结果如何汇总
插件（plugins）	中间件	执行前后的拦截、日志、鉴权与改写

这个划分延续了此前 Agentic Harness Engineering 工作的七文件切分，并在其基础上多出一个组件。从工程角度看，它相当于把「调智能体」这件事从玄学变成了配置管理：每一项都能单独改、单独回滚、单独做 A/B。

任务级递归：提出—探测—组合

任务级递归是一次三步走的循环：

• 提出（Propose）。先用基础 Harness 把任务跑一遍，得到一个参考执行。随后由编辑模型提出两类候选改动：一类是不变量候选（invariant candidate），针对跨领域通用的智能体失效模式，例如规划不足、工具调用错误；另一类是领域候选（domain candidate），针对当前任务所属领域的知识与作业程序。
• 探测（Probe）。两类候选分别在同一个任务上真实执行，产出各自的轨迹。执行器默认为 OpenCode，也可通过参数切换到 Codex。
• 组合（Compose）。组合器把候选轨迹与参考执行做行为对比，只保留那些有观测行为支撑的改动，拼装成该任务最终的 Harness。

关键点在于「组合器只采纳被行为验证过的编辑」。这不是让编辑模型自我评分，而是让不同版本的实际执行结果互相对照：某个候选在轨迹里确实少犯了两次工具调用错误，这条改动才被保留；某个候选只是提示词写得更漂亮但轨迹没差别，就被丢弃。

没有标准答案时，用什么判断好坏

这一步是 Harness² 与依赖评测集的自动优化方法最本质的区别。它不问「这个答案对不对」，而是问「这两个版本的行为有什么不同，哪个不同更像改进」。

这个设计选择的优势是可迁移：只要任务能被反复执行、轨迹能被记录，就能做对比，不需要标注。代价则有两条。其一，行为差异不等于效果提升——一次执行里多调用了一次工具，可能是更严谨，也可能是更啰嗦，判断权仍在组合器手中，而组合器本身也是模型。其二，对比是在「同一任务」上做的，因此每次改写都附着在具体任务上，需要靠 Harnessing 级递归才能抽象成可复用的经验。

论文把这种机制称为对比式的（contrastive），并明确其目标是不依赖真实校验器来引导在线编辑。对工程团队来说，这一条其实是最容易借用的部分：即便不采用整套框架，「先跑一遍拿到基线轨迹、再让候选改动在同一任务上跑、只保留有行为证据的改动」这个流程本身就可以手工实现。

Harnessing 级递归：经验库与改进 Harness

每个任务结束之后，一个经验反思器（reflector）会把本轮被采纳的 Harness 连同经验教训写进持久存储，形成可复用的改进库，用来指导后续任务的候选提出。每个新任务仍然从基础 Harness 出发，但候选方案会参考历史经验。

项目自己给出了这条链路的消融证据：移除经验库之后，WorkBuddy-Bench 的成绩从 77.5 降到 74.4。这 3.1 分的差额，是「跨任务经验沉淀」这一层的净贡献。

k 预算：并行铺开与串行深挖

任务级递归的搜索规模由一个参数 k 控制，且有两种扩展方式：并行递归先探测 k 个通用候选与 k 个领域候选，再由共享证据组合出 k 个结果；串行递归则把精炼后的 Harness 与累积证据连续传递 k 步。仓库 README 的原话是：并行递归探索得更宽，串行递归精炼得更深。

配置	行为	执行器回放次数
k 等于 1	一步提出—探测—组合	每个任务 4 次
k 等于 K，并行模式	探测 K 个通用候选与 K 个领域候选，产出 K 个组合	随 K 线性放大
k 等于 K，串行模式	连续走 K 步精炼	随 K 线性放大
substrate 设为 cx	改用 Codex 执行器，默认仍为 OpenCode	不变

这里有一个必须自己算的账。公开读数显示，Gemini 3.5 Flash 在 OpenCode 上基础分为 72.4，k 等于 1 时到 77.5，k 等于 5 时到 80.8。也就是说：前面一步拿到 5.1 分，后面四步合计再拿 3.3 分，平均每步约 0.83 分。而按并行模式的口径，k 等于 1 时每个任务 4 次执行器回放，k 等于 5 时约 20 次——回放次数变成 5 倍，换来的边际增益只有 3.3 分，且明显递减。

这个递减曲线对工程决策的意义是：如果预算有限，把 k 从 0 提到 1 的性价比远高于从 1 提到 5；而 k 提到 5 之后，单次任务的推理成本与端到端时延会显著上升，是否值得取决于该任务是否需要反复执行以摊薄成本。

三基准四配置：数字该怎么读

论文与仓库给出的三个基准分别是 JobBench（专业工作）、LAB（法务工作）与 WorkBuddy-Bench（办公、网页与代码，可细分为 office、web、code 三个子集）。四组配置由两个执行模型（GLM-5 与 Gemini 3.5 Flash）与两个执行器（OpenCode 与 Codex）组合而成，结果为三次运行的均值，编辑模型默认为 Claude Opus 4.8。

配置	基准	基础 Harness	一步自我改进后	增益
GLM-5 加 OpenCode	WorkBuddy-Bench	64.2	75.7	加 11.5 分
Gemini 3.5 Flash 加 OpenCode	WorkBuddy-Bench	72.4	77.5	加 5.1 分
Gemini 3.5 Flash 加 OpenCode	JobBench	未单独披露	未单独披露	加 4.5 分
四配置的合计口径	LAB 部分通过率	未单独披露	未单独披露	加 11.8 个百分点
对照：Gemini 3.5 Flash 加 OpenCode（k 等于 5）	WorkBuddy-Bench	72.4	80.8	加 8.4 分

这组数字里有三条值得单独拎出来。

其一，增益大小与基线强弱负相关。基础分 64.2 的 GLM-5 拿到 11.5 分增益，基础分 72.4 的 Gemini 3.5 Flash 只拿到 5.1 分。本文据此判断：Harness 自动优化填补的主要是「脚手架欠账」，而不是替模型补能力。基线越差，说明原本的 Harness 越不匹配，可挖的空间越大；基线已经较高时，剩下的往往真是模型能力问题，改提示词改不动。

其二，更弱的模型配更好的脚手架，可以打赢更强的模型配出厂脚手架。GLM-5 自我改进后的 75.7 超过了 Gemini 3.5 Flash 出厂的 72.4；在 Codex 执行器下同样成立，读数为 75.3 对 74.5。这条结论被多家转述为「脚手架才是护城河」，但更准确的说法是：在这三个基准、这两组模型、这两个执行器的范围内，Harness 差距可以覆盖约 3 分的模型差距。换成别的模型对，这个覆盖幅度未必成立。

其三，工具错误率下降 36.8%。公开转述提到，框架通过调优八个组件，在未重训任何权重的前提下把工具错误率最多降低了 36.8%。这个数字与分数提升之间的因果关系没有被拆开：是工具错误减少带来了分数提升，还是两者都源自某一次具体的 Harness 改动，论文未给出中介分析。

项目页还给出过一个单任务案例：某个 JobBench 任务经过四次 Harness 干预——增加校验护栏、增加对账技能、细化工具指引、加入记忆组件——从 43.1 提升到 77.8。这是个体案例，不能外推为期望值，但它说明了改动的形状：四次干预分别落在护栏、技能、工具指引、记忆四类组件上，恰好对应八组件划分。

同期七种方法的坐标

递归 Harness 自我改进在 2025 至 2026 年间已经是一个拥挤的子方向。公开汇总中与之并列的方法包括斯坦福 IRIS 实验室的 Meta-Harness、Google 自身的早期工作 ReasoningBank、Wang 等人的 Harness Scaling、Sakana AI 与加州大学伯克利分校的 RHI（arXiv 2607.15524）、PluginRSI 以及 Recuris。按论文自己的对比，在 k 等于 1 的 WorkBuddy-Bench 与 JobBench 上，Harness² 领先上述方法。

需要说明的是，这类对比表由论文方给出，各方法的执行器、基准子集、运行次数未必一致，跨方法比较的口径风险高于同一方法内的前后对比。对选型者来说，更有参考价值的其实是方法论差异：是否需要真实校验器、是否跨任务沉淀、是否支持并行探索，这三条比分数差更决定能否用在自己的场景。

工程清单：装上它要准备什么

按仓库 README 的安装路径，本地演示与模型驱动的基准运行是两套准备。演示模式使用确定性编辑器与真实 Python 执行，不需要模型凭证，可以先用来验证流程是否跑通。

项目	要求	说明
操作系统与运行时	Linux，Python 3.12 与 uv	通过 venv 隔离安装
本地演示	无模型凭证	命令行为 harness2-demo，可指定输出目录与 k 值
模型驱动基准	Node.js 20 以上、Google Cloud CLI	需配置 Vertex AI 项目与模型 ID
LAB 基准	Pandoc 与 Poppler	法务文档解析依赖
WorkBuddy-Bench	Docker	办公、网页与代码任务需要容器环境
执行器切换	参数 substrate 设为 cx	从默认 OpenCode 切到 Codex

运行时流程是四条命令串起来：setup 装基准、check 自检环境、harness2 跑精炼、judge 判分与 report 出报告。仓库明确要求判分与报告必须使用与精炼运行相同的基准、执行器、子集、k 值、模式与随机种子，否则结果不可比对。这个约束看起来琐碎，实际是这类框架最容易出错的地方——参数不一致导致的「提升」往往只是噪声。

还有一条容易被忽略的成本：编辑模型默认是 Anthropic 的 Claude Opus 4.8。也就是说，一套 Google 出品的框架在默认配置下依赖竞品模型来做改写决策，推理成本与可用性都受制于外部供应商。对企业部署来说，这是一个必须提前评估的依赖项。

冷静判断：它改变了什么，没改变什么

Harness² 真正推进的是「无标准答案场景下的自动 Harness 优化」这个具体问题。它给出的不是一个新的智能体，而是一套把智能体脚手架变成可搜索空间、并用行为对比替代判分的方法。对工程团队来说，这套方法的可借鉴性高于框架本身：即便不引入代码，把八组件拆分、同任务双版本对比、只保留有行为证据的改动这三条做起来，也能立刻用在自己的智能体上。

它没改变的则有四条。其一，模型权重不动意味着模型能力本身的天花板没有被抬高，Harness 优化只是在既有能力上做匹配。其二，增益存在明显的边际递减，k 从 1 到 5 的性价比显著低于从 0 到 1。其三，编辑模型外依赖竞品，成本与供应链风险并存。其四，所有公开读数均由论文方自行报告，尚无独立复现；论文为预印本，未经同行评审；仓库亦声明其为研究项目而非官方支持产品。此外，公开转述中出现的仓库创建日期与初始提交日期存在 10 月 6 日与 10 月 8 日两种口径，星标数约为六千六百并随时间变化，本文均已如实标注。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。