同一个模型，换一套提示词、工具说明和记忆结构，在办公任务上的平均分能从 72.4 抬到 77.5；再让这套脚手架自己迭代五轮，能到 80.8。这是 Google Cloud AI Research 与西北大学在 Harness² 上给出的实测结果，模型权重一个参数都没改。问题在于，绝大多数人调 Agent 的方式还是靠手工试：改一版提示词，跑几个任务，觉得好了就留下，觉得不行再改回去，换一个任务场景又从零开始。经验留在个人脑子里，没有变成可以复用的资产。自动化的做法也有，但多数要么针对单个任务做一次性搜索，要么依赖标准答案告诉你哪次改动是对的。Harness² 换了个思路：把手写的部分变成可编辑的八个组件，让「改写脚手架」这件事本身也递归起来——当前任务里改执行脚手架，任务之间改那个负责改脚手架的东西。整套流程不需要标准答案，靠的是同一次任务里不同候选脚手架之间的行为差异。本文会讲清它的两级递归到底怎么转、八个组件分别管什么、三个 benchmark 怎么跑起来，以及在什么情况下它并不适合你。
Harness²是什么？
Harness² 是 Google Research 开源的一个研究框架，用来在不修改模型权重的前提下，自动改进模型外部的 Agent 脚手架。它把「harness」定义为围绕模型、让模型能够像 Agent 一样行动的那套系统——提示词、工具、记忆、技能、编排等等；把「harnessing」定义为优化这套系统的过程。项目由 Google Cloud AI Research 与西北大学合作，2026 年 10 月 6 日建仓，配套论文《Harness²: Recursive Agent Harnessing for an Open World》挂在 arXiv（编号 2610.14224），当前版本 0.1.0，Apache-2.0 许可，主要语言是 Python。它和常见的 Agent 框架区别在于目标不同：那些框架提供一套固定的脚手架让你往里填业务，Harness² 提供的是改脚手架的方法，脚手架本身是它的待优化对象。仓库明确写着这不是 Google 官方支持的产品，定位是研究代码而非生产组件。
核心功能
它的价值不在于多提供一套工具调用协议，而在于把「怎么改脚手架」变成一个有反馈回路、能积累经验的流程。目标读者有两类：做 Agent 评测的研究者，想验证某个改动到底有没有用；做脚手架优化的工程团队，想在固定模型下把任务通过率抬上去。
- 两级递归——任务内一次递归改执行脚手架（这份任务用哪套提示词和工具说明），任务间一次递归改「改进脚手架」（把这次采纳的版本和带证据的经验存进库，指导下一个任务的改写方向），经验因此不会随任务结束而清零。
- Propose–Probe–Compose 三步——先提出候选编辑，再在同一任务上真实执行以观察效果，最后综合各候选的行为差异合成新版本；全程不需要标准答案，也不需要评分器介入，靠的是自己跟自己比。
- 八个可编辑组件——系统提示词、护栏、记忆、工具说明、子智能体、技能、脚本、插件，覆盖上下文构建、工具接口、任务编排与工具循环内的中间件，改动可以发生在提示词之外的层次。
- 并行与顺序两种扩展方式——并行递归同时探索多个候选（每个方向 k 个），顺序递归则把上一轮的成品继续往下滚；`–k` 控制任务级递归预算，两种模式的收益曲线不一样。
- 三个专业基准适配器——JobBench 覆盖职业任务、LAB 覆盖法律文书、WorkBuddy-Bench 覆盖办公/网页/代码三个子集，每个都带自己的安装、评分与报告命令。
- 两套执行器——默认走 OpenCode，加 `–substrate cx` 换成 Codex；Codex 场景下需先起 `harness2-bridge` 做中转，让容器里的执行器能连到桥接服务。
- 零凭证的本地演示——`harness2-demo` 用确定性的编辑器加真实 Python 执行跑完两种递归模式，不需要任何模型凭证，适合先看清流程再决定要不要接模型。
- 结果可续跑——所有产物落在 `runs/` 下，按 benchmark 与子集分目录，存任务摘要、交付物、采纳的脚手架、反思笔记与评分；原命令再执行一次就是续跑。
使用场景
它面向的不是「想快速搭一个客服机器人」的产品团队，而是需要用可复现方式回答「这套改动到底有没有用」的人。因为每次改动都要真实跑任务，模型调用按量计费，所以更常见的使用方式是小样本试跑、看趋势、再决定是否放大。
| 人群/角色 | 场景描述 | 推荐指数 |
|---|---|---|
| Agent 方向的研究者 | 在固定模型下验证脚手架改动的净增益，用 `–k 1` 跑少量任务做对照 | ★★★★★ |
| 做内部办公或代码 Agent 的工程团队 | 把现有提示词与工具说明接进八个组件，跑 WorkBuddy-Bench 找短板 | ★★★★☆ |
| 法律科技与文档处理团队 | 用 LAB 适配器评估长文档核对、条款比对类任务的通过率 | ★★★★☆ |
| 预算有限的个人开发者 | 先跑 `harness2-demo` 理解流程，再用 `–max-tasks 1` 做单任务验证 | ★★★☆☆ |
| 想直接当生产框架用的团队 | 研究代码、0.1.0 版本、仅支持 Linux，缺少服务化与权限边界 | ★★☆☆☆ |
操作指南
整套流程拆成「装环境 → 配模型 → 装某个 benchmark → 跑 → 评 → 出报告」六段，每一步都有独立命令。本地演示不需要模型凭证，建议先用它确认环境没问题，再决定接哪个 benchmark。项目地址在 Harness²，下面的命令都从仓库根目录执行。
- 准备 Linux 环境与 Python 3.12（3.13 也支持），装好 `uv`、`git`、`curl`，LAB 还要 `pandoc` 与 `poppler-utils`；WorkBuddy-Bench 另需 Docker 与可执行 `docker info` 的权限。
- 建虚拟环境并装包：`uv venv –python 3.12 .venv`，激活后执行 `uv pip install -e ‘.[render]’`（`render` 额外带 openpyxl 与 python-pptx，处理表格与幻灯片时要装）。
- 先跑 `harness2-demo –output runs/demo –k 2` 看两种递归模式的完整流水，这一步不需要任何密钥。
- 接模型时复制 `.env.example` 为 `.env`，填 `GOOGLE_CLOUD_PROJECT`，再按角色配 `HARNESS2_SOLVER_MODEL`、`HARNESS2_IMPROVER_MODEL`、`HARNESS2_JUDGE_MODEL`，其中 solver 与 improver 用 `provider/model` 格式，judge 只写裸模型 ID；然后执行 `gcloud auth application-default login` 完成应用默认凭证登录。
- 装数据：`harness2-setup lab`（法律）、`harness2-setup jb`（职业）、`harness2-setup wb –subset office|web|code`（办公三选一），随后 `harness2-check –bench <名字>` 自检依赖。
- 跑一次小样本：`harness2 –bench lab –k 1 –mode parallel –only-domains antitrust-competition –max-tasks 1`，想先看会选中哪些任务就加 `–dry-run`，不产生模型调用。
- 评分与出报告：`harness2-judge –bench lab –k 1 –mode parallel` 再 `harness2-report –bench lab –k 1 –mode parallel`。这两条命令的 benchmark、executor、子集、`–k`、`–mode`、seed 必须与跑的那次完全一致，否则会对不上账。
- 换模型或换任务选择时，先设一个新的 `HARNESS2_RUNS_DIR` 再跑，避免新旧结果混在 `runs/` 里。
支持平台
官方安装口径是 Linux，Python 要求 `>=3.12,<3.14`，包声明里只列了 POSIX 操作系统，Windows 与 macOS 没有出现在支持清单中，不要假设能直接照抄命令。执行器支持 OpenCode 与 Codex 两种，Codex 需通过 bridge 中转。跑 benchmark 时还会用到 Node.js 20 及以上、Google Cloud CLI、Docker（WorkBuddy-Bench），以及 Pandoc 与 Poppler（LAB）；benchmark 的 setup 会在 `dependencies/` 下自行装一套固定版本的 Bun 运行时。方法说明与结果表格都在项目官网上，仓库里另有 `docs/SETUP.md`、`docs/BENCHMARKS.md`、`docs/EXPERIMENTS.md` 三份文档对应环境、基准与实验细节。
产品定价
免费。代码以 Apache-2.0 发布，仓库里没有任何付费档、订阅计划或授权报价，核心包 `dependencies` 一栏为空，不引入第三方运行依赖，`render` 与 `bridge` 是可选的扩展组。真正的开销在模型侧：跑 benchmark 时 solver、improver、judge 三个角色都会调模型，按 Vertex AI 的用量计费，`harness2-demo` 因为是确定性编辑器加本地执行所以完全免费。另外 WorkBuddy-Bench 沿用了上游腾讯的自定义许可，带地域使用限制，商用前需自行阅读该许可；LAB 与 JobBench 分别沿用 harveyai 与 Job-Bench 的上游条款。
常见问题
Q：必须自己准备模型 API 吗？
跑 benchmark 是的。默认配置走 Vertex AI 的 Gemini 执行器与评分器，improver 可用 Vertex 上的 Claude 或 Gemini，需要项目 ID 和 ADC 凭证。只想看流程的话不用，`harness2-demo` 不需要任何模型凭证。
Q：跑一次大概花多少？
框架本身不报价，成本等于 solver、improver、judge 三处模型调用的用量，随 `–k`、任务数、并发和选用的模型线性变化。稳妥做法是先 `–dry-run` 确认任务选择，再用 `–max-tasks 1` 跑单条，摸清单任务消耗后再放大。
Q：评测时会不会让 Agent 直接查到答案？
这正是项目自己在文档里点明的风险：执行器网络访问不受限制，Codex 还以关闭沙箱的方式运行，而 JobBench 的评分标准 `RUBRICS.json` 就公开挂在 Hugging Face 上。官方要求在评测前按 `docs/EXPERIMENTS.md#web-access` 配置网络限制，屏蔽这些域名，否则分数会被检索行为污染。
开发者小结
它的长处是把「脚手架优化」从手工试错变成有回路、有记忆的过程：模型权重锁死，改动只发生在八个组件上，候选方案靠同任务内的行为对比筛选，不需要标准答案；任务间还会把采纳的版本与经验沉淀回改进库，这一点是多数一次性搜索方案没有的。适合做 Agent 评测、想量化脚手架改动增益的研究与工程团队，也适合拿它当现成的对照基线。不适合直接当生产框架用：它是 0.1.0 的研究代码，只有 2 位贡献者、3 次提交、没有发布过任何 release，支持面仅限 Linux，还要承担 Vertex 凭证与 Docker 的部署成本；WorkBuddy-Bench 的许可带地域限制，Codex 关闭沙箱也会带来评测污染风险。想先判断值不值得投入，跑一遍那个零凭证的本地 demo 最快。
相关文章
