开源项目第258期：Harness² —— Google Research 的「递归式 Agent Harness 优化」，模型权重不动，只改 Agent 的外壳

冬奇Lab
0 阅读9分钟

引言

"A harness is the system around a model that enables it to act as an agent. Harnessing is the process of optimizing that system."

这是「每日一个开源项目」系列的第 258 篇。今天的项目是 Harness²（读作 Harness Squared）—— Google Research 开源的递归式 Agent Harness 优化框架，23,451 颗 Star，2,354 个 Fork，Apache-2.0 协议，2026 年 10 月 6 日创建。

过去一年大家越来越清楚：同一个模型，装在不同的"外壳"里，表现可以差很多。这个外壳就是 Harness —— 提示词、工具、记忆、技能、编排逻辑，等等。但外壳基本靠人调：试一版、跑几个任务、再改。Harness² 想回答的问题是：能不能让 Agent 在遇到一个设计 Harness 时没见过的新任务时，自己改进自己的外壳，并且不需要标准答案反馈？ 它的做法是在模型权重完全不变的前提下，做两层递归。

你会学到什么

  • Harness 与 Harnessing 的区别，以及 Harness² 暴露的八个可编辑组件
  • 两层递归：任务级的「提议—探测—合成」（Propose–Probe–Compose）和 Harnessing 级的「改进 Harness」
  • 并行递归与顺序递归的差别，以及 --k 预算怎么用
  • 快速上手：不需要任何模型凭证的本地 demo，和跑一次 LAB 基准的完整命令
  • 使用前必须知道的两件事：API 成本，以及评测时的网络访问风险

前提知识

  • 了解 AI Agent、工具调用的基本概念
  • 知道 Claude Code、Codex、OpenCode 这类编码 Agent 执行器会更容易理解它的接入方式
  • 本地跑基准需要 Linux、Python 3.12 和 uv；真实基准需要 Vertex AI 项目

项目背景

概述

Harness² 是一个 plug-and-play 的框架，目标场景是 open world：Agent 会遇到 Harness 设计时没有预料到的任务。它在固定模型权重的前提下，连接两层递归：

  • 任务级递归（Task-level recursion）：针对当前任务，通过一个对比式的 Propose–Probe–Compose 步骤改进执行 Harness —— 提出修改、在同一任务上探测这些修改的效果、再根据不同执行之间的行为对比合成出一个改进后的 Harness。整个过程不需要标准答案反馈。
  • Harnessing 级递归（Harnessing-level recursion）：维护一个持久的改进 Harness（improvement harness），把每个任务中被采纳的 Harness 和有证据支持的经验教训写进去，用来指导之后的改进。

作者 / 团队

  • 开发方: Google Research（google-research 组织）。论文作者包括 Ruiyao Xu、Yanfei Chen、Zhongying CuiZhu、Bhavana Dalvi Mishra、Yifei Ming、Han Yu、Rujun Han、Chen-Yu Lee、Tomas Pfister
  • 论文: arXiv:2610.14224《Harness²: Recursive Agent Harnessing for an Open World》
  • 主要语言: Python
  • 许可证: Apache-2.0；third_party/、基准和数据集保留各自上游的许可证
  • 创建时间: 2026-10-06，最近一次提交 2026-11-02
  • 声明: README 末尾明确写着"这不是 Google 官方支持的产品"，也不在 Google 开源漏洞奖励计划范围内

项目数据

  • ⭐ GitHub Stars: 23,451+
  • 🍴 Forks: 2,354+
  • 📄 许可证: Apache-2.0
  • 📅 创建时间: 2026-10-06
  • 📬 Open Issues: 163
  • 👥 贡献者提交数很分散：rudycelekli 8 次，其余多为 1–2 次，说明主体开发多半在仓库之外完成后整体发布
  • 🌐 项目网站: harness2.github.io

快速上手

要求 Linux、Python 3.12 和 uv。

1. 本地 demo（不需要任何模型凭证）

uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

demo 会用确定性的编辑器和真实的 Python 执行跑完两种递归模式，不调用任何模型。想先搞懂流程，从这里开始最省钱。

2. 跑一个真实基准

需要 Node.js 20+、Google Cloud CLI，以及各基准自己的依赖（LAB 需要 Pandoc 和 Poppler，WorkBuddy-Bench 需要 Docker）。然后配置模型：

cp .env.example .env
# 在 .env 里填 Vertex AI 项目和模型 ID
gcloud auth application-default login

README 的示例是跑一道 LAB（法律工作）任务，再评判并出报告：

harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel \
  --only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel

几个要点：--k 是任务级递归预算；评判和报告必须使用与优化运行相同的基准、执行器、子集、--k、--mode 和随机种子；加 --dry-run 可以只预览任务选择而不调用模型。README 明确提醒：基于模型的运行会产生 API 费用，建议从很小的任务选择开始。

核心剖析

八个可编辑组件：Harness 到底能改什么

Harness² 把模型外围拆成八个可编辑组件，并按运行时角色分组：

角色组件
构造上下文系统提示词（system prompt）、护栏（guardrails）、记忆（memory）、技能（skills）
定义工具接口工具说明（tool guidance）、脚本（scripts）
编排委派工作子 Agent（subagents）
控制中间件插件（plugins）

这个拆分的意义在于：它把"改 Agent"从一个模糊的手工活，变成对一组明确对象的编辑操作。优化器改的不是模型，而是这八样东西，因此结果可以被保存、被审阅、被复用。

任务级递归：提议—探测—合成

对一个具体任务，一个 Propose–Probe–Compose 步骤是这样的：

  1. 执行：Agent 执行器先用初始 Harness 跑一遍任务
  2. 提议：Harness 编辑器提出两类修改 —— 不变量（invariant）修改和领域（domain）修改
  3. 探测：把候选修改各自在同一任务上真跑一遍，看行为变化
  4. 合成：Harness 合成器根据这些执行之间的行为对比，合成出最终的 Harness

关键在于第 3、4 步用的是"同一任务上不同执行的对比"，而不是对错判断，所以不需要标准答案。代价也很直接：每次探测都是一次真实的 Agent 执行，成本会随预算增长。

任务级递归的预算有两种扩展方式：

选项行为
--k 1一次 Propose–Probe–Compose 步骤
--k K --mode parallel探测 K 个通用、K 个领域特定的候选，再产出 K 个合成结果（探索得更宽）
--k K --mode sequential把改进后的 Harness 和累积证据带入连续 K 步（改进得更深）
--substrate cx用 Codex 代替默认的 OpenCode 作为执行器

Harnessing 级递归：把经验沉淀下来

每个任务结束后，被采纳的 Harness 和"有证据支持的经验教训"会被写进持久的改进 Harness，用来指导后续任务的改进。流程图里对应的角色是"经验反思器（experience reflector）"：它对这一步做反思，并更新下一个任务要用的改进 Harness。

这一层是整个框架区别于"每个任务从头调一遍"的地方。需要留意的是，README 展示的结果主要来自单步，对这一层长期积累的效果，我没有在 README 里看到单独的数据；更完整的消融要看论文。

论文给出的结果，和该怎么读

README 的结论是：在三个专业基准、四种模型—Harness 配置上，单个 Harness² 步骤就能让 GLM-5 和 Gemini 3.5 Flash 超过各自的基础 Harness，最高提升：

  • WorkBuddy-Bench：最高 +11.5 分
  • JobBench：最高 +4.5 分
  • LAB 的部分通过率：最高 +11.8 个百分点

并说明增加任务级递归预算会带来进一步提升。支持的基准是 JobBench（专业工作）、LAB（法律工作）和 WorkBuddy-Bench（办公、网页和代码），执行器支持 OpenCode 和 Codex，递归模式支持并行与顺序。

读这组数字时有两点要留意。第一，这些是"最高提升"，并非每个配置、每个基准都有这个幅度。第二，这些数字是论文和作者自己的评测，我没有复现。

一个必须看的安全提示：评测时的网络访问

README 的 Web access 一节写得很直接：执行器的网络访问默认不受限制，Codex 运行时沙箱是关闭的。 公开基准的评分标准（rubric）可能在网上就能查到。所以评测之前要先按 docs/EXPERIMENTS.md 配置网络限制，防止 Agent 访问到基准答案和评分标准，否则结果不可信。

这提醒的不只是学术诚实问题：一个会自己改自己提示词、护栏和脚本的 Agent，再叠加无沙箱和不受限的网络，在你自己的机器上跑之前，值得先想清楚它能碰到什么。

项目地址与资源

总结

Harness² 把"调 Agent"从手艺活变成了一个可以递归执行的优化过程：模型不动，外壳可编辑、可保存、可复用。

三点值得注意：

优化对象是 Harness，不是模型。 在权重固定的前提下，八个明确的可编辑组件构成了搜索空间，这让结果可以审阅和迁移，也让它适用于你无法微调的闭源模型。

不依赖标准答案，靠"行为对比"做改进。 Propose–Probe–Compose 通过同一任务上不同执行的差异来合成新 Harness，这是它能面对开放世界任务的关键，也是它成本的来源：每次探测都是一次真实执行。

能力和风险是同一枚硬币。 它默认不限制网络、Codex 沙箱关闭、会产生真实 API 费用，README 自己也提醒要在评测前配置网络限制。把它接入真实环境前，先用无需凭证的 harness2-demo 理解流程，再从最小任务选择开始。另外这是研究代码，README 声明不是官方支持的产品，仓库有 163 个未关闭 Issue。

如果你在研究 Agent 的自我改进、想对比不同 Harness 的表现，或者在评估"改外壳"与"换模型"哪个更划算，这个项目是个有参照价值的起点。

探索 PrimeSkills —— 精选 AI agent 和技能工具，每一个都经过真实工作流验证。没有炒作，只有真正好用的工具。

访问我的个人主页，获取更多见解和有趣的产品。

avatar
文章
阅读
粉丝