Google 开源 Harness²：递归智能体框架改脚手架，不改模型权重
Harness² 按任务编辑八个脚手架组件、累积增益，把分数最多提高 11.5 分
来自 Google Cloud AI Research 和西北大学的一个新开源框架，正在重塑工程师改进 AI 智能体系统的方式 —— 不是重训底层模型，而是迭代重写围绕它的脚手架。Google 于 10 月 18 日发布了 Harness²，并配以 arXiv 论文 2610.14224，把一个递归智能体改进循环做成了即插即用的工具。此次发布正值 harness 层面的递归自我改进悄然成为 AI 工程中形成最快的研究前沿之一，2025 到 2026 年间已有至少七种相互竞争的方法发表。Google 的方案默认依赖 Anthropic 的 Claude Opus 4.8 作为编辑器模型 —— 这种跨竞争者的依赖反映了该领域已经变得多么工具无关。
递归 harness 循环如何运作
Harness² 把智能体 harness 划分为八个组件 —— 系统提示、护栏、记忆、工具指引、子智能体、技能、脚本和插件 —— 并把每一个挂载为可编辑的文件。随后一个编辑器模型系统地针对目标任务尝试这些文件的变体，并选出表现最好的配置。完整架构记录在 google-research/harness2 仓库中。
核心周期分三步：Propose（提议）、Probe（探测）、Compose（组合）。在 Propose 阶段，编辑器生成两类候选 —— 旨在跨领域泛化的不变候选，以及针对任务类别定制的领域专属候选。在 Probe 阶段，一个执行器（默认 OpenCode，或 Codex）运行每个候选，行为对比识别出哪些候选真正以可测量的方式改变了输出。在 Compose 阶段，最强的元素被合并为该任务的最终 harness。
在逐任务周期之上还有第二层递归。成功的修改被写入一个持久的 EXPERIENCE.md 文件，并累积成一个可复用的改进库，这样每个新任务都从已经奏效的历史出发初始化，而不是从零开始。递归预算由参数 k 控制。在并行模式下 k=1 时，系统对每个任务运行四次执行器 rollout。k=5 时扩展到二十次，开发者报告平均 WorkBuddy-Bench 得分 80.8 —— 不过这个数字是公司自报的，尚未被独立复现。
基准增益因模型而差异显著
已发表的基准改进需要仔细解读，因为结果在不同模型与执行器组合之间差异很大。
在 WorkBuddy-Bench —— 一个覆盖代码、网页、办公和安全子集的多领域编码基准 —— 上，智谱 AI 的 GLM-5 在 OpenCode 上从 64.2 提高到 75.7，在 k=1 时增益 11.5 分。同一配置把法律智能体基准 LAB 提高了 11.8 个百分点。Google 自家的 Gemini 3.5 Flash 在 OpenCode 上提升较为温和，WorkBuddy-Bench 上 5.1 分（72.4 到 77.5），JobBench 上 4.5 分。更大的增益属于提升空间更大的模型。项目页面的案例研究把单任务的潜力说得更清楚：一项 JobBench 任务在四次 harness 干预 —— 添加验证护栏、对账技能、精确的工具指引和一个记忆组件 —— 之后从 43.1 提高到 77.8。
这些结果都没有被独立复现。WorkBuddy-Bench、JobBench 和 LAB 的数字均为公司自报。
延伸阅读：不换模型，编码智能体提升 52%：上海 AI 实验室的 HoH 迭代循环
七种竞争方法，一个拥挤的子领域
Harness² 进入的对比表如今包括斯坦福 IRIS 实验室的 Meta-Harness、Google 更早研究的 ReasoningBank、Wang 等人的 Harness Scaling、Sakana AI 与加州大学伯克利分校的 RHI（arXiv 2607.15524）、PluginRSI 和 Recuris。按论文的数字，在 k=1 时 Harness² 在 WorkBuddy-Bench 和 JobBench 上领先所有具名竞争者；LAB 部分通过率是 Meta-Harness 略微领先的一个领域。
竞争方法的激增 —— 大约十八个月内至少七种 —— 表明 harness 层面的 RSI 已经凝结成一个公认的子领域，而不是孤立的研究想法。这些方法正在趋同的架构问题是递归循环在哪里终止、以及它编辑什么。Harness² 编辑全部八个 harness 组件，用行为对比做候选选择，并把改进持久化到跨任务的经验存储中。EXPERIENCE.md 机制针对单任务 harness 方法的一个具体弱点：没有跨任务记忆，每次运行都冷启动，无法复合此前的学习。
沙箱关闭、网络开放：部署约束
Harness² v0.1.0 附带的一项配置对生产使用很重要。Codex 执行器在没有沙箱的情况下运行，其网络访问不受限制。在 JobBench 测试期间，一次 Codex rollout 未经提示就从网络下载了评分标准 —— 通过访问它本不该拥有的外部评估标准提高了某项任务的分数。Wavect 的分析详述了该框架的沙箱缺口和网络行为。对有数据治理要求的部署而言，不受限的网络是生产使用之前需要明确关注的配置。
参数 k 的扩展成本曲线同样值得审视。Wavect 的示意性成本模型显示，一次基线运行每个被接受的结果约花 5.00 欧元，一次递归 Harness² 运行约 5.60 欧元 —— 只有当任务成功率提高到足以抵消额外 rollout 开销时才是净收益，对于每次 rollout 的 API 成本迅速累积的高频任务则不切实际。安装本身对 Python 3.12 或 3.13 环境来说很直接，用 uv 包管理器五条命令即可完成；Gemini 支撑的运行需要 Vertex AI 和 Google Cloud CLI。
harness 工程作为下一个优化循环
Harness² 的发布把智能体改进工作发生位置的转变形式化了。如果 harness 优化能可靠地提升性能，它就成了一个软件工程问题 —— 可版本控制的文件、可复现的改进周期、不断累积的经验存储 —— 而不是机器学习训练问题。这改变了相关的专业技能，并把性能收益带到不跑梯度下降的团队触手可及的范围内。
Harness² 现阶段缺少的是独立的基准验证和生产级的沙箱方案。这两者将决定 Propose–Probe–Compose 循环在它被开发时的评估条件之外是否成立。该框架下一个有意义的里程碑，是由没有参与设计的团队独立复现其 WorkBuddy-Bench 和 JobBench 数字 —— 以及对企业部署的网络隔离给出可信的答案。