Google Harness²：部署、基准测试与真实成本

返回

Kevin Riedl

14 分钟 阅读 · 2026年10月16日
最近审核 2026年10月16日

下一篇

你的 AI 智能体或许不需要更聪明的模型，而需要更好的工作方式。

这正是 Google Harness² 值得关注的地方。它不是简单地让智能体再试一次，而是修改模型周围的指令、工具和可复用流程，测试不同方案，再把经验保留下来供后续任务使用。

这种机会是真实的，但社交媒体上的概括省略了重要条件。Harness² 不是开箱即用的无代码办公助手，基准成绩提升不等于生产效率必然提高，可修改的约束文件也不等于安全隔离。

本文分别讨论 Google 发布了什么、这些成绩意味着什么、递归过程会增加哪些成本，以及如何开展第一次评估，而不把企业凭据直接交给实验性智能体。

资料核查日期：2026 年 10 月 16 日。下文命令已与固定版本的源码核对，但未实际执行付费模型实验。基准数据来自论文作者，不是 Wavect 的实测结果。

Google Harness² 是什么？

**Google Harness²，也写作 Harness2，是采用 Apache-2.0 许可证的研究框架。它在保持模型权重不变的前提下，针对陌生任务改进智能体的执行框架。**它结合当前任务上的试验与持续保存的经验库，为后续改进提供参考。官方代码仓库支持 OpenCode 和 Codex 执行环境，以及三类基准测试。仓库也明确说明，这不是获得 Google 官方支持的产品。

Harness 可以理解为包围模型的工作系统，包括指令、工具、记忆和执行行为。Harness² 修改的是这套系统，而不是模型训练得到的参数。软件包元数据显示，本次核查的代码版本为 0.1.0，支持 Python 3.12 或 3.13。

“开放世界”指设计执行框架时未预先考虑的任务。它不表示必须允许无限制联网，也不表示系统能解决任何新任务，更不保证结果正确。

需要了解通用架构，可以先阅读我们的 AI 智能体执行框架指南。本文聚焦 Google 的递归方法，以及是否值得开展实际评估。

递归改进是如何工作的？

Harness² 包含两个相互连接的循环。论文的方法部分将当前任务上的改进称为 Propose、Probe、Compose，即提出修改、执行试验、组合改进。任务完成后，系统再进行反思，为后续任务留下经验。

首先，参考运行展示原始执行框架的行为。系统随后提出一个通用改进方案，例如改善工具使用方式，再提出一个任务或领域专用方案，例如加入更合适的检查程序。两个方案在相同任务、相同执行模型和相同环境配置下运行。系统根据行为差异，组合出修改后的执行框架，并实际运行它。

可以用一个假设的表格对账任务理解。一个候选方案改善工作计划，另一个增加可复用的对账脚本。比较的重点是哪些修改真正改善了观察到的行为，而不是哪段解释更有说服力。这只是说明性例子，不是我们已经测试过的 Harness² 集成。

第二个循环保存被采用的执行框架及有证据支持的经验，其中包括 EXPERIENCE.md 文件。这些记录会影响后续修改建议。关键在于：**每个新任务仍从同一个基础执行框架开始。**系统不会把上一个任务的所有修改自动继承下来。反思得到的证据不足时，也可以不添加新的经验条目。

对企业而言，这一区别十分重要。这里的学习来自持久化文件和配置改进，不是持续训练模型。行为对比也不是独立的正确性验证：多次运行仍可能重复同一种误解。

八个可编辑组件

我们的部署原则是：允许系统改进工作方法，但把权限放在它无法编辑的边界之外。文件中写着“禁止导出客户数据”，不应该是阻止数据导出的唯一措施。

+11.5 和 +4.5 的成绩究竟代表什么？

宣传中的提升确实出现在作者的结果表中，但它们是不同模型与执行框架组合的最大增益，不是通用收益。主要结果和实验设置报告了三次运行的平均值，每次都打乱任务顺序。下列比较使用一个改进步骤，即 k=1。

WorkBuddy 的数字不表示每个办公任务都会“提升 11.5%”。使用 Gemini 3.5 Flash 和 OpenCode 时，该基准的平均值由 72.4 上升到 77.5，增益是 5.1 分。必须对应具体基线。

还有一个容易忽略的细节：主要实验默认使用 Claude Opus 4.8 作为执行框架编辑器，即使执行任务的是 Gemini 或 GLM-5。比较前后保持不变的是执行模型，而不是整个改进流程只能使用这一个模型。论文另行研究了执行器和编辑器采用同一模型的情况。

+ Recursion 行显示的是并行递归达到 k=5 后的额外变化，不属于基础单步配置的结果。也不能把不同表格行中的最大值拼接成一个并不存在的最佳组合。

更准确、也更实用的积极结论是：论文提供了证据，表明改变现有模型的工作方式，能够改善多个专业基准中的结果。它并没有因此证明你们的生产验收率、运营成本或人工复核工作量。

运行 Harness² 需要多少成本？

**代码许可证不等于运行账单。**递归运行既要为最终交付付费，也要为探索替代方案付费。

按照文档中的并行设计，系统执行 k 次参考运行、k 次通用候选试验、k 次领域专用候选试验，以及 k 次组合后框架运行。合计为 4k 次执行器运行：k=1 时是四次，k=5 时是二十次。这是根据算法推导出的次数，不是实测账单必然变为四倍或二十倍。

编辑、组合、反思、必要时的最终选择，以及单独的评分，还会产生额外工作。实际成本取决于 token 长度、缓存、模型价格、失败和重试。资源足够时，并行运行可以缩短总等待时间，但不会消除调用成本。

论文并没有忽视这个问题。计算开销分析统计了交付之前使用的 token，包括执行与改进过程，并在所比较的配置中展示了较好的质量与计算量权衡。但主表中的执行步数不是完整的生产成本账本，基准里的 token 效率也不能直接替代以欧元计价的商业论证。

衡量每个通过验收的结果的成本

固定执行框架和 Harness² 必须采用相同、独立定义的验收标准：

每个通过验收的结果的成本 = 被评估任务组的全部执行、改进模型、评分、基础设施和人工复核成本 / 独立验收通过的交付数量。

每项成本只计算一次。如果没有任何交付通过验收，就不能报告一个有限的单位成本。

这个例子中，递归方案成功完成的工作更多，但每个通过验收的结果更贵。如果交付价值更高，或者速度更快，它仍可能值得采用。重点是明确做出取舍，而不是把基准分数提高误认为自动节省成本。

更通用的运营成本模型见 AI 智能体单次操作成本。Harness² 试验应该聚焦于：额外尝试是否换来了足够多的可用成果？

可以安全地把 Harness² 接入企业系统吗？

不能仅凭默认研究配置就这样做。实验指南明确指出，当前发布不限制执行器的网络访问，而且 Codex 的沙箱被禁用。

指南还记录了一次验证运行：Codex 在没有收到指令的情况下，下载了对应 JobBench 任务的公开评分规则。这是复现实验时需要认真处理的警告，但不能据此认定原论文的主要结果受到了污染。

需要分清两个问题。基准智能体找到评分答案，会破坏评估的有效性；智能体访问真实凭据、无关文件或外部系统，则会威胁运行环境。给 guardrails.md 增加一句话，不能解决其中任何一个问题。

我们建议第一次运行采用可丢弃的隔离环境、合成或清理后的文件、受限的模型凭据、在外部强制执行的出站网络规则，以及智能体无法自行提高的执行预算。不要把个人云配置、生产密钥、敏感主目录或不受限制的主机 Docker socket 挂载进去。

基准测试的安装阶段与运行阶段需要不同的网络策略：安装要下载依赖，执行时则不应获取公开答案或评分标准。必须实际测试阻断效果，而不是看到配置文件就默认已经生效。

持久化经验在复用前也需要审查。按领域组织的经验库并不自动构成客户数据隔离。租户分离、保留期限、文件访问和删除权限都应由模型之外的机制控制。生成的脚本、插件和交付物在审查前都应视为不可信内容。

如何先试用 Google Harness²，而不启动付费基准？

部署指南建议基准运行采用 Linux 和 Python 3.12。使用模型的运行还需要 Node.js 20 或更新版本、Google Cloud CLI，以及对已配置模型的访问权限。LAB 增加文档处理依赖，WorkBuddy 则需要 Docker。

这是开发者级别的部署流程，不是无代码产品的注册页面。非程序员可以定义任务并判断结果是否有用，但仍需要有人负责运行环境、凭据、隔离和故障处理。

从不需要模型凭据的演示开始

在可丢弃的隔离 Linux 环境中，经过源码核对的命令顺序如下：

git clone https://github.com/google-research/harness2.git
cd harness2
git checkout 1cfe254e8d25b15f37048c3730134686abe60335
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

这些命令固定了本次核查的仓库版本。演示采用确定性编辑器和真实 Python 执行，不需要模型凭据。它展示的是递归机制，不是语言模型在基准上的提升效果。安装环境及其依赖仍需要联网。

预览范围很小的模型运行

只有在配置了受限云项目、所需执行模型、改进模型和评分模型，以及前述外部控制措施后，才应继续。默认值并不保证复现论文中的每一种配置。请检查 .env.example；文档中的 Vertex 接入方式使用 Application Default Credentials。

基准指南分别介绍 JobBench、LAB 和 WorkBuddy 的部署。数据集和第三方代码保留各自的使用条款。特别是 WorkBuddy 的上游自定义许可证包含地域限制，应在下载前核查。Harness² 的 Apache 许可证不会覆盖或取消这些条款。

以下 LAB 示例只选择一个指定领域，并预览该领域中最多一个任务：

export HARNESS2_RUNS_DIR=runs/lab-first-k1
harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel --seed 42 \
  --only-domains antitrust-competition --max-tasks 1 \
  --workers 1 --dry-run

harness2-check 在不调用模型的情况下检查依赖、凭据和配置，但不证明每个所选模型实际可用。--dry-run 同样只预览任务选择，不发起模型调用。

**最容易误解的是 --max-tasks：它限制每个领域的任务数，而不是整个运行的总任务数。**第一次试验应搭配一个明确的 --only-domains 值。--workers 1 限制同时运行的领域数，不能限制总 API 账单。仍需设置外部支出上限。

去掉 --dry-run 就会启动付费模型工作。把执行和评分分开，有助于看清这条边界：

harness2 --bench lab --k 1 --mode parallel --seed 42 \
  --only-domains antitrust-competition --max-tasks 1 --workers 1
harness2-judge --bench lab --k 1 --mode parallel --seed 42
harness2-report --bench lab --k 1 --mode parallel --seed 42

评分和报告必须保持相同的基准、执行器、适用时的子集、递归预算、模式和随机种子。种子只影响任务顺序，不固定模型采样。更换模型或任务选择时，应使用新的输出目录。要评分参考运行，在对应评分命令中增加 --bases；默认报告针对改进后的结果。

不要把这个基准接口误认为已经能接入企业办公流程的成品。真实业务任务仍需要合适的适配器、数据访问、验收检查和明确的运营责任。

什么样的试点能够支持采用决策？

在增加 k 前，应确认改进并非只存在于系统自己的反思中。Anthropic 的智能体评估指南区分了执行记录与环境中实际产生的结果。这正是关键：一句自信的完成声明，不等于表格已经正确对账，也不等于业务记录被正确更新。

因此，我们建议的验收矩阵比“演示运行成功”严格得多：

发布版本会把评分失败的任务保留为未评分，而不是记为零分。报告必须明确包含这一覆盖率。只统计成功评分的任务，可能掩盖实际运行故障。

还应评估哪些任务根本不需要递归。一个成本低的确定性脚本，可能已经能可靠完成稳定的数据转换。把探索性模型调用留给含糊且高价值的任务，是合理的试点假设，而不是可以默认已经配置好的功能。

Harness² 适合怎样的 Wavect 项目？

当某类高价值任务反复出现、变化又足以超出单一固定流程，但结果仍能有效评估时，Harness² 值得研究。对于已经确定性的工作、极低延迟要求，或每次额外尝试都会产生不可接受副作用的流程，它的吸引力就弱得多。

我们的 AI 工程服务从业务流程和验收标准出发，而不是承诺某个框架会自动变得可靠。Twinsoft AI 案例提供的是另一个项目的交付背景，并不表示 Twinsoft 正在运行 Harness²。可以用我们的上线前 QA 检查清单确定试点应提供哪些证据，再与 Wavect 讨论范围明确的试点。

有价值的商业问题不是“买了多少次智能体尝试”，而是“这些尝试带来了哪些通过独立验收的结果，总成本是多少”。