Google Research 开源 Harness²：让 agent 自动改进自己的 harness，单步最高 +11.5 分
Google Research 开源 Harness²（Apache 2.0）：用 Propose–Probe–Compose 在无标准答案的开放任务里递归优化 agent 的提示词、记忆、工具与子 agent。
2026-10-19 · google-research/harness2 官方仓库 README（Apache-2.0，一手）与 arXiv:2610.14224 论文页（一手）
发布 2026-10-19核实 2026-10-19要点速览
- Google Research 开源了 Harness²（Harness Squared），仓库
google-research/harness2，许可 Apache-2.0。配套的论文《Harness^2: Recursive Agent Harnessing for an Open World》已挂在 arXiv:2610.14224（提交日 2026-10-09）。 - 它优化的不是模型权重，是 harness——即模型周围那套让模型能当 agent 用的东西：prompts、tools、memory、skills、orchestration。官方对 harness 的定义："A harness is the system around a model that enables it to act as an agent."
- 核心机制是两层递归：① Task-level recursion——用 contrastive Propose–Probe–Compose 为当前任务改 harness；② Harnessing-level recursion——把被采纳的 harness 与有证据支撑的经验沉淀进一个持续演进的 improvement harness，用于指导以后的任务。
- 关键突破点：Propose–Probe–Compose 不需要 ground-truth verifier（不需要预先知道正确答案）。它靠同一任务上不同执行之间的行为对比来合成改进后的 harness——这正是开放世界任务此前做不了 RSI 的原因。
- 官方公布的收益：在三个专业基准、四组「模型 × harness」配置上，单步即可让 GLM-5 与 Gemini 3.5 Flash 超过各自基线 harness——WorkBuddy-Bench 最高 +11.5 分、JobBench +4.5 分、LAB 部分通过率 +11.8 个百分点，且加大 task-level 递归预算还能继续涨。
- 已支持的现成组合：parallel / sequential 两种递归、OpenCode 与 Codex 两种 executor、JobBench / LAB / WorkBuddy-Bench 三个基准。
① 什么是 harness，为什么它比模型更容易被忽略
官方 README 开宗明义：
"A harness is the system around a model that enables it to act as an agent: prompts, tools, memory, skills, orchestration, and more. Harnessing is the process of optimizing that system."
把这句话翻译成一线体感：你换模型是换发动机，你改 harness 是改整套传动、仪表和驾驶规则。 论文摘要更进一步指出，agent 的能力"depend not only on their underlying models but also on their execution harnesses"——不只取决于模型。
对用 Claude Code、Codex、OpenCode 的开发者来说，你日常手调的这些东西全都是 harness：
| harness 组件 | 在你手里的具体形态 |
|---|---|
| prompts | CLAUDE.md / AGENTS.md / 自定义 slash 命令 |
| tools | MCP server 清单、允许的命令白名单 |
| memory | 项目记忆、会话摘要与压缩策略 |
| skills | 子 agent、插件、可复用工作流 |
| orchestration | 并行 / 串行、子 agent 调度方式 |
Harness² 做的事，是把这张表的调参过程自动化。
② Propose–Probe–Compose：没有标准答案时怎么判断「改对了」
这是全篇最值得讲的一点。开放世界任务（open-world tasks）的两个死结，论文摘要写得很直白：
- 任务在 harness 设计阶段没见过，测试时也是新的 → 没有 ground-truth verifier 能可靠地指导在线修改。
- 以往的 RSI 过程高度任务特定，换场景就失效。
Propose–Probe–Compose 的解法是三步：
- Propose：harness editor 提出 edits（官方图中分 invariant edits 与 domain edits 两类）。
- Probe：把这些候选 harness 放到同一个任务上实际跑一遍（candidate probes）。
- Compose：harness composer 根据**各次执行之间的行为对比（behavioral contrasts）**合成出 refined harness。
妙处在于「对比」替代了「判分」。你不需要知道正确答案，只需要能分辨「这版跑得和那版不一样，且更接近任务完成态」。这让 RSI 第一次能落在没有标准答案的真实任务上，而不只是有单元测试的编程题。
第二层递归（Harnessing-level）做的是跨任务积累："...updates a persistent improvement harness with adopted harnesses and evidence-supported lessons from each task to guide future refinement."——每个任务留下的不是一条分数，而是一批有证据的教训。
③ 数字怎么读：先看「单步」，再看基准名字
官方 README 与论文摘要口径完全一致：
"Across three professional benchmarks and four model–harness configurations, a single Harness² step improves GLM-5 and Gemini 3.5 Flash over their base harnesses, with gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB's partial pass rate."
| 基准 | 单步增益 | 说明 |
|---|---|---|
| WorkBuddy-Bench | +11.5 分 | 三个里增益最大 |
| JobBench | +4.5 分 | 增益最小，不到 WorkBuddy-Bench 的一半 |
| LAB | +11.8 个百分点（部分通过率） | 注意单位是部分通过率，不是总分 |
三条必须一起读的限定：
- 是「up to（最高）」，不是平均分。三个数字都是上界。
- 只有两个模型被测：GLM-5 与 Gemini 3.5 Flash。官方未公布 Claude / GPT 系列的结果，本站不作外推。
- 增益是相对于各自的 base harness，不是相对于「别的框架」。base harness 强弱不同，同样的 +11.5 含金量也不同。
增益在三个基准上差了近 3 倍（11.5 vs 4.5），这本身就是信息：harness 自动优化高度依赖基准任务的性质。别用「平均提升 X%」来概括它。
④ 对普通开发者现在能用吗：能跑，但别指望一键涨分
官方 README 给出了完整的本地跑法（以 JobBench 为例）：
uv pip install -e '.[render]'
harness2-setup jb
harness2 --bench jb --k 1 --mode parallel
已经能用的部分：parallel / sequential 递归、OpenCode 与 Codex 两个 executor、三个基准的安装脚本。
三条现实约束：
- 它优化的是「跑基准」这件事。要把这套思路落到你自己的业务任务上，你得先有自己的任务集与可对比的执行记录——Probe 那一步需要「同一任务跑多次」。
- 成本不低。Propose–Probe–Compose 一轮要跑多个候选 harness，token 与时间是按候选数线性增长的。官方未公布单轮成本数据。
- 仓库很新：
created_at为 2026-10-06，pushed_at为 2026-10-14（GitHub API 一手），社区实践与踩坑记录几乎为零。
AI 之家 观点
第一，这是「agent 能力」与「模型能力」正式被拆成两条独立轴线的信号。 过去两年的默认心智是「效果不好就换更强的模型」。Harness² 用一组可复现的数字说明：不动权重，只改模型周围那套系统，单步就能拿到最高 +11.5 分。 对买不起前沿模型、或者被数据合规锁在本地小模型上的团队，这条轴线的性价比明显更高。本站的判断是：2026 年下半年开始，团队之间的 agent 差距会更少来自「用谁的模型」，更多来自「谁把 harness 调明白了」。
第二，Propose–Probe–Compose 真正的价值不是涨分，是它绕开了「标准答案依赖」。 绝大部分真实业务任务没有 ground truth——你没法给「把这份周报写好」写单元测试。以往所有自动优化方法在这里都卡住。用「行为对比」替代「对错判分」，是把自动优化从基准题推向真实任务的关键一步。 这也解释了为什么三个基准的增益差这么多：越接近开放任务、越难判分的场景，这套方法的相对收益越大。
第三，本站要提一个反向代价：自动改 harness 会放大「你本来就测不到的东西」。 系统靠行为对比选优，但行为对比只在你能观察到的维度上成立。如果你的评估只覆盖「任务是否完成」，那么一个让 agent 更激进地改文件、删测试、绕过审批的 harness，在基准上依然是「更优解」。harness 自动优化必须先解决「什么算更好」的可观测性，否则它优化的是你的指标，不是你的目标。 这一点和本站此前对 提示注入 的判断同源：当 agent 能自己改自己的规则，规则本身的审计就要升级成一等公民。
第四，实操建议：现在就值得做的不是跑 Harness²，而是先把你的 harness 显式化——把 CLAUDE.md / AGENTS.md、MCP 清单、子 agent 定义、命令白名单从「散在各处」收敛成可 diff、可版本化、可回滚的一组文件。写法见 CLAUDE.md 最佳实践 与 AGENTS.md 协议。等这类自动优化工具成熟时，你手上有没有一份结构化的 harness，决定了你能不能吃到那一轮红利。
待核实
- WorkBuddy-Bench / JobBench / LAB 三个基准的权威性：官方在
docs/BENCHMARKS.md中给出说明，本站未打开该文档逐项核对基准构造方式、数据切分与是否公开排行榜。 - 论文的版本与页数：arXiv:2610.14224 标注 Submitted on 9 Oct 2026，本站取得的是 v1 摘要；未核对是否有后续版本修订。
- 仓库 star 数的时点：本站经 GitHub API 核对时为 5,439（核对日 2026-10-19）。star 数随时间变化，引用时请标注日期，不要把「曾到过多少」当「现在有多少」。
- 是否支持 Claude Code / Gemini CLI executor：官方 README 只列出 OpenCode 与 Codex 两种，未说明是否计划支持其他 executor。
- 单轮优化的成本数据：官方未公布 token 消耗、耗时或候选数默认值，本站不作估算。
- GLM-5 与 Gemini 3.5 Flash 之外模型的表现：官方未公布，本站不作外推。
- 官方是否另有博客公告：本站仅在 arXiv 与 GitHub 仓库取证，未检索到 Google Research 官方博客的长文公告页；第三方媒体对该项目的报道日期多记为 2026-10-18，晚于论文提交日（10-09）与仓库创建日（10-06）。
来源
- google-research/harness2 官方仓库（Apache-2.0，一手核对 README 与仓库元数据）
- Harness^2: Recursive Agent Harnessing for an Open World（arXiv:2610.14224，Submitted on 9 Oct 2026，一手核对标题与摘要原文）
- 延伸阅读：Claude Code 工具卡、Codex 工具卡、OpenCode 工具卡、Agent 编排概念页、上下文工程概念页、提示注入概念页
口径说明：本文机制描述与收益数字均转录自官方仓库 README 与 arXiv 摘要原文（一手），英文引语为官方原句。所有增益均为「up to」上界且仅覆盖 GLM-5 与 Gemini 3.5 Flash 两个模型，已在上文逐条标注限定。star 数与仓库时间戳取自 GitHub API，核对日 2026-10-19。凡官方未给出的内容，均已列入待核实，不作推断。