谷歌开源Harness²，Agent学会自改

Google Research 把优化目标从模型转向了 Harness

Google Research 近日开源 Harness²，试图让 AI Agent 在部署阶段通过修改自身的提示词、工具说明、记忆、Skills 和编排方式，提高处理陌生任务的能力，而不需要重新训练模型。项目已经以 Apache 2.0 协议发布在 GitHub，目前支持 OpenCode 与 Codex 两种执行后端，默认使用 OpenCode。

Harness 是围绕基础模型搭建的一整套运行系统，包括系统提示词、上下文、工具、记忆、安全规则和任务编排。它决定了模型能看到什么、可以调用什么，以及复杂任务被拆成多少步骤；同一个模型装进不同 Harness，最终表现可能像两款完全不同的产品。

Harness² 是一个面向开放世界任务的递归 Agent Harness 优化框架。这里的「开放世界」并不是指联网搜索，而是指系统上线后会持续遇到设计阶段没有见过、没有标准答案、也没有现成验证器的新任务。

这个项目真正值得关注的地方，不是又多了一个 Agent 框架，而是它把「Agent 如何改进自己」变成了一套可以观察、比较和积累的工程流程。过去更换模型通常是提升 Agent 能力最直接的办法，Harness² 则提出另一个判断：很多失败并非模型能力不足，而是上下文组织、工具描述和执行流程没有把现有能力释放出来。

没有标准答案，先比较不同执行轨迹

Harness² 首先要解决的是无 ground truth 条件下的在线优化问题。传统自动优化方法通常需要测试集、奖励模型或确定性验证器，例如代码是否通过测试、数学答案是否匹配、游戏得分是否提高；但在撰写研究报告、整理企业资料或处理跨工具办公任务时，结果往往没有唯一正确答案。

任务级递归是 Harness² 在单个任务内执行的 Propose–Probe–Compose 对比式改进循环。系统不会直接相信编辑器生成的新方案，而是让基础 Harness 与候选 Harness 处理同一个任务，再根据真实执行轨迹判断哪些改动得到了行为证据支持。

Propose：提出两类候选修改

Propose 阶段会生成面向不同问题的候选 Harness。论文实现重点区分两种方向：一种是不依赖具体领域的 invariant candidate，用于处理规划、工具选择、上下文管理等通用失误；另一种是 domain candidate，用于补充当前领域的知识、操作规程与任务结构。

这种拆分避免了把所有故障都粗暴归因于提示词。假设一个 Agent 没有正确处理表格，一种可能是它缺乏「先检查字段类型再批量修改」的通用规划规则，另一种可能是它不知道财务表中的特定口径；两类问题需要修改的 Harness 组件并不相同。

Probe：让候选方案真正执行任务

Probe 阶段会分别运行参考 Harness 和候选 Harness，并保存工具调用、文件变更、模型响应及中间决策。这里的关键不是让另一个模型凭文字描述打分，而是让不同方案在相同任务上暴露可比较的行为差异。

执行轨迹不能等同于正确答案，但它比纯粹的自我评价更有信息量。候选方案如果减少了无效工具调用、补上遗漏的检查步骤，或产出了更完整的文件，即使系统不知道唯一正确结果，也能找到支持这次修改的具体证据。

Compose：只吸收有证据的改动

Compose 阶段负责比较参考轨迹与候选轨迹，再组合出新的执行 Harness。这个过程不是在多个完整方案中简单选出一个，而是尝试保留被实际行为支持的局部改动，降低一次错误提案污染整个系统的概率。

Propose–Probe–Compose 本质上是一种没有绝对分数时的相对实验。它和软件工程中的 A/B 测试更接近：系统未必知道什么是理论最优，但可以观察一次改动是否让 Agent 少走弯路、正确使用工具，或者完成了参考方案遗漏的步骤。

第二层递归，优化的是「如何优化」

Harnessing 级递归是 Harness² 跨任务积累改进经验的第二层循环。系统维护一个持续存在的 Improvement Harness，用来记录已采用的改动、适用场景及其执行证据，并以此指导后续任务中的 Propose、Probe 和 Compose。

Harness² 的双重含义正在于两层递归同时存在。第一层针对当前任务修改执行 Harness，第二层则持续修改负责提出和筛选改进方案的 Improvement Harness；换句话说，被优化的不只是 Agent 的工作方式，还包括「如何改进 Agent 工作方式」的方法本身。

跨任务积累并不意味着把上一个任务的执行配置原样带到下一个任务。根据项目披露的机制，新任务仍从公共基础 Harness 出发，上一任务生成的执行 Harness 不会直接继承，但已经沉淀的改进经验会影响新一轮候选方案和证据判断。

这种设计在泛化与污染之间做了相对克制的取舍。直接继承全部配置容易把某个任务的特殊技巧错误推广到其他领域，而完全重置又无法积累经验；Harness² 保留的是改进过程中的证据和方法，不是无限膨胀的任务提示词。

八类组件都能改，但风险并不相同

Harness² 将可编辑的 Agent 外部系统拆成八类组件。它们覆盖上下文构建、工具接口、任务编排和确定性扩展，修改成本与安全风险存在明显差异。

| 组件 | 主要作用 | 对运行时的影响 | |---|---|---| | 系统提示词 | 定义角色、目标与总体行为 | 每次模型调用都会进入上下文 | | 护栏 | 规定权限、限制和检查流程 | 约束工具使用与输出行为 | | 记忆 | 保存经验、事实和历史信息 | 影响后续任务的上下文构建 | | 工具指导 | 解释工具能力、参数与使用时机 | 影响工具选择及调用顺序 | | Skills | 按需加载领域流程与知识 | 仅在需要时进入上下文 | | Subagents | 将子任务委派给其他 Agent | 会增加额外推理与上下文成本 | | 脚本 | 提供可重复的确定性能力 | 通过执行代替部分模型推理 | | 插件 | 在工具循环中插入 TypeScript 中间件 | 可以在运行时强制执行行为 |

Skills 与脚本是其中较有工程价值的两类组件。Skills 适合封装低频但专业的流程，避免把所有知识塞进常驻提示词；脚本则适合处理格式转换、校验和批处理等确定性任务，让模型不必每次重新推理同一套机械步骤。

插件是能力最强、也最需要审慎对待的组件。提示词只能要求模型遵守规则，插件却可以在工具调用环中强制执行规则，因此更适合权限检查和结构化拦截，但错误插件也可能直接改变 Agent 的运行语义。

子智能体是八类组件中唯一明确增加额外推理上下文的组件。它能改善复杂任务的分工，却不是免费的性能按钮；如果任务本身不需要并行调查或角色分离，增加 subagent 可能只会带来更多 token、延迟和协调成本。

一步优化最高增加 11.8 个百分点

Google Research 在 JobBench、LAB 和 WorkBuddy-Bench 三类专业任务基准，以及四种「模型—Harness」配置上测试了 Harness²。公开结果涉及 Gemini 3.5 Flash、GLM-5、OpenCode 与 Codex，单步实验使用 Claude Opus 4.8 承担 Harness 编辑工作。

| 基准 | 单步 Harness² 的公开最佳提升 | 指标口径 | 说明 | |---|---:|---|---| | WorkBuddy-Bench | +11.5 分 | 基准得分变化 | GLM-5 配置的最高公开提升 | | WorkBuddy-Bench | +5.1 分 | 基准得分变化 | Gemini 3.5 Flash 与 OpenCode 配置 | | JobBench | +4.5 分 | 基准得分变化 | 不修改基础模型权重 | | LAB | +11.8 个百分点 | 通过率变化 | 单步 Harness 优化的最高结果 |

这些数字证明 Harness 调整可以带来可测量收益，但还不足以证明 Agent 已经具备稳定的递归自我进化能力。基准提升是在特定基础模型、编辑模型、任务集合和计算预算下测得，不能直接外推为任意 Agent 都能免费获得两位数增长。

编辑成本也是结果中不能忽略的一部分。基础执行模型可以是 Gemini 3.5 Flash 或 GLM-5，但单步实验使用 Claude Opus 4.8 作为编辑器，这意味着较强模型承担了分析轨迹和生成修改方案的工作；最终收益来自「基础模型、执行 Harness、编辑模型与额外试跑预算」的组合，而不只是框架本身。

Harness² 同时提供 parallel 与 sequential 两种扩展模式。parallel 会同时探测 k 组候选，并让多个独立组合会话处理证据；sequential 则进行 k 步链式精炼，让后一轮携带前面累积的证据。项目报告称，两种模式从 k=1 扩展至 k=5 时，测试成绩均呈单调提升。

递归预算增加后性能继续上升，代价则是更多模型调用、工具执行和等待时间。对于高价值、低频率的研究或软件任务，这笔开销可能合理；对于需要亚秒响应的大规模在线服务，先运行多个候选再组合答案通常不现实。

它和微调、提示词优化不是一回事

Harness² 与微调的核心区别是完全不修改模型权重。微调把能力或行为写进模型参数，适合数据分布相对稳定、调用规模足够大的场景；Harness² 修改模型外部的运行环境，更适合任务持续变化、工具频繁更新或缺少训练数据的场景。

Harness² 与传统提示词优化的区别是可编辑范围更大。提示词优化通常只搜索指令文本，而 Harness² 还可以改变记忆、工具文档、Skills、脚本、插件及 subagent 编排，因此它优化的是整个 Agent 系统，而不是某一段文字。

| 路线 | 是否修改权重 | 是否依赖明确评分 | 可修改范围 | 主要代价 | |---|---|---|---|---| | 模型微调 | 是 | 通常需要训练数据与评测集 | 模型参数 | 训练、数据与版本维护 | | 提示词优化 | 否 | 多数方法需要评分器 | 提示词 | 多轮搜索与评测调用 | | 固定 Agent Harness | 否 | 不需要在线评分 | 由开发者人工修改 | 人工调试与迭代 | | Harness² | 否 | 可在没有 ground truth 时工作 | 提示词、记忆、工具、Skills、脚本、插件与编排 | 候选执行、轨迹比较和编辑模型调用 |

Harness² 最直接的竞争对象不是某个基础模型，而是人工维护 Agent 工作流的方式。过去开发者发现 Agent 不会用工具，通常要重写提示词、补文档、增加检查脚本，再手工回归测试；Harness² 希望把这一流程自动化，并让改进证据跨任务积累。

真正难点是权限边界，而不是生成候选

递归修改 Harness 会放大 Agent 系统原有的安全问题。一个只会改提示词的优化器，最坏情况通常是性能退化；一个可以改护栏、脚本和插件的优化器，则可能在追求任务完成率时删除确认步骤、扩大文件权限，或绕过出站访问限制。

安全边界不应和性能策略放在同一个自由搜索空间中。更稳妥的部署方式是冻结沙箱、凭据、网络白名单、审计日志和人工审批规则，只允许 Harness² 修改提示词、工具说明、Skills 及受限的编排配置；脚本与插件变更则应经过静态检查、隔离执行和人工审核。

无 ground truth 也不等于无约束。企业可以没有唯一正确答案，但仍然可以设置不可违反的验证条件，例如文件不能写出工作目录、外部消息必须人工确认、数据库操作只能只读，以及所有候选执行必须使用临时环境。

Improvement Harness 还需要防范错误经验的长期沉淀。一次偶然成功可能来自外部服务状态、随机采样或数据泄漏，如果系统把它错误归因于某项 Harness 改动，后续任务就可能持续继承错误策略；因此证据记录需要包含任务类型、环境、模型版本、成本和失败案例，而不能只保存一条「这次有效」的结论。

对开发者而言，Harness 正在成为独立工程层

Harness² 释放出的行业信号是 Agent 竞争正在从模型能力转向系统能力。基础模型越来越接近的情况下，工具定义是否清晰、上下文是否按需加载、确定性任务是否交给脚本，以及失败经验能否沉淀，都会成为产品差异。

这套框架目前更适合研究验证和高价值异步任务，而不是直接接管生产 Agent。Google Research 已明确将其定位为研究项目而非官方支持的 Google 产品，开发者需要自行承担依赖变化、运行成本、权限控制和回归测试。

Harness² 的价值也不在于让 Agent 神奇地「自我觉醒」。它提供的是一套实验框架：提出有限改动，让候选方案真实运行，用轨迹证据筛选改动，再把改进方法带到下一项任务。这个过程仍然依赖强编辑模型、足够的试跑预算和严格的安全边界。

短期看，Harness² 最可能影响的是编码 Agent、企业办公 Agent 和研究 Agent。此类任务通常具备可记录的工具轨迹、较高的单次任务价值和一定的容错空间，允许系统多跑几次候选；面向消费者的实时聊天产品则很难承受同等递归成本。

长期看，模型升级不再会是 Agent 产品提高能力的唯一途径。更现实的产品形态可能是：模型保持相对稳定，Harness 根据任务持续演化，而权限和合规边界由不可编辑的外层系统固定下来。Harness² 尚未证明这条路线可以在生产环境长期稳定运行，但它已经把「如何让 Agent 在部署后继续变好」从概念讨论推进到了可复现的开源实验。

参考来源

• Google Research / Harness² GitHub 仓库：项目代码、安装说明、支持后端、实验结果与 Apache 2.0 开源许可的主要来源。