发布日期：2026-10-22

Harness² 是西北大学与 Google Cloud AI Research 研究者于 2026 年 10 月公开的递归 Agent Harness 框架：它保持模型权重不变，通过 Propose–Probe–Compose 在同一任务上提出、执行并合成 harness 修改，再将被采用的 harness 与有证据支持的经验写入持续改进库。论文报告三个专业基准上的单步最高提升分别为 11.5 分、4.5 分和 11.8 个百分点；这些特定配置结果不是任意业务任务的效果承诺。

Harness² 公开了什么：优化的不是模型权重

Agent Harness 是模型之外、让模型能够作为 Agent 工作的执行系统；Harness² 做的是自动改进这套系统，而不是训练一个新模型。

据官方 README 2026 年 10 月版本，可编辑内容被拆成 8 类：system prompt、guardrails、memory、skills、tool guidance、scripts、subagents 和 plugins。

它们共同决定上下文如何组织、工具怎样暴露、任务如何委派，以及工具循环中的行为边界。

这里的“open world”也不是单指联网，而是指 Agent 在 harness 设计完成后仍会遇到未见过的新任务。静态配置很难预先覆盖所有流程与领域约束，Harness² 因而把修改时机推迟到任务到来之后。

截至 2026 年 10 月 22 日，作者已公开项目页、论文预印本和 Apache-2.0 代码仓库。

仓库提供 OpenCode 与 Codex 执行器适配，以及 WorkBuddy-Bench、JobBench、LAB 三个基准入口；README 同时注明，该仓库不是 Google 官方支持产品。

Propose–Probe–Compose：先看执行差异，再决定怎么改

Propose–Probe–Compose 的关键，不是让模型凭直觉重写提示词，而是让每项修改都经过同一任务上的行为对照。

  1. Propose（提出修改）：系统先用当前 harness 执行任务，取得轨迹与交付物作为参考；编辑器随后分别提出跨领域候选和领域候选。前者处理规划、工具使用、上下文管理或委派等通用缺陷，后者补充当前领域的知识、流程与约束。

  2. Probe（执行探测）：两个候选在相同任务、模型和环境配置下实际运行。系统比较参考执行与候选执行的轨迹、工具调用和交付物，观察目标缺陷是否缓解，以及是否引入回退。

  3. Compose（证据合成）：合成器读取候选 harness、差异和执行证据，可以合并有支持的修改、修正冲突、只采用一个候选，或者保留原 harness。每项决定都要对应具体观察。

这里的“无需 ground-truth feedback”有严格边界：在线修改阶段不依赖任务正确答案，但参考执行也不能证明结果正确。论文仍用隐藏检查、rubric 或判定标准评估最终交付物；行为对照只负责指导修改，不能替代正确性验证。

为什么需要两层递归

Harness² 的递归发生在两个时间尺度：任务级递归解决“这次怎么做”，Harnessing 级递归学习“以后该怎么改”。

每个新任务都从共同的基础 execution harness 出发，再在当前任务内运行 Propose–Probe–Compose。

任务结束后，Harnessing 级循环才把被采用的完整 harness 与有执行证据支持的经验写入领域库，用来更新后续任务使用的 improvement harness。

这意味着后一个任务不会直接继承前一个任务的 execution harness。它读取的是先前任务留下的经验与可复用组件，再按新任务重新提出修改。同一领域内的任务按顺序运行且只读取更早的条目，不同领域可以并发处理。

据官方实验文档 2026 年 10 月版本，任务级预算 k 有两种扩展方式。两种模式都会先让同一基础 harness 做 k 次参考执行：

模式

k 如何生效

侧重点

必须看到的代价

Parallel

探测 k 个通用候选、k 个领域候选，再做 k 次独立合成

扩大候选广度

需要更多并发资源，总计算量不会因并行消失

Sequential

连续执行 k 轮三步循环，把精炼后的 harness 与累计证据传给下一轮

累积修改深度

后一步依赖前一步，执行与编辑成本随预算增加

当 k=1 时，两种模式都退化为一次基础步骤；当 k>1 时，选择器从匿名交付物中采用一个现有结果。论文中的星号表示“被采用”，并不表示“已验证最优”。

实验提升了什么，结论又止于哪里

据论文主表 2026 年 10 月版本，Harness² 的主实验是 2 个模型乘以 2 个初始 harness，共 4 种配置，而不是 4 个模型：Gemini 3.5 Flash、GLM-5 分别运行在 OpenCode 与 Codex 上。

据论文 2026 年 10 月预印本，WorkBuddy-Bench 测试集包含 Code 40 个、Web 35 个、Office 25 个任务，JobBench 使用 34 个测试任务，LAB 使用 100 个留出任务。主表结果是三次独立、任务顺序打乱的流式运行均值。

论文报告的单步最高增幅分别是：

  • WorkBuddy-Bench：GLM-5/OpenCode 从 64.2 升至 75.7，2026 年 10 月报告提高 11.5 分。

  • JobBench：Gemini 3.5 Flash/OpenCode 从 31.5 升至 36.0，2026 年 10 月报告提高 4.5 分。

  • LAB Partial：GLM-5/OpenCode 从 59.6% 升至 71.4%，2026 年 10 月报告提高 11.8 个百分点。

这三组数字是各基准上的最高报告值，不能拼成一个“平均提升”。

据论文表 2（2026 年 10 月），单步结果在 12 个“基准 × 配置”组合中都超过各自的 base harness，但并非处处超过所有对比方法：例如 LAB 的 Gemini 3.5 Flash/Codex 配置中，Meta-Harness 为 76.5，Harness² 单步为 75.6。

论文还报告，提高任务级预算可以继续带来收益，但没有给出适用于所有任务的最优 k。更大的 k 会增加执行器、编辑器与探测成本；并行只能在资源充足时缩短等待时间，不能消除总计算量。以上均是作者预印本报告的结果，并非本文独立复现。

现在就能试：先跑无需模型凭据的本地 Demo

本地 Demo 是理解两种递归模式的最短路径。前提是 Linux、Python 3.12、uv，并且已经进入官方仓库根目录：

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

官方 README 说明，这个 Demo 使用确定性编辑器和真实 Python 执行，同时演示 Parallel 与 Sequential，不需要模型凭据。它能验证递归工作流和结果落盘，但不代表已经复现论文中的模型成绩。

进入真实基准前，还需要 Node.js 20+、Google Cloud CLI 与相应模型权限和凭据；LAB 需要 Pandoc、Poppler，WorkBuddy-Bench 需要 Docker。

可以先给 harness2 增加 --dry-run 预览任务选择，它不会发起模型调用；--max-tasks 限制的是每个 domain 的任务数，不是全局总数。

从 Demo 到业务验证，还要补齐五件事

把 Harness² 用到企业任务时，最重要的不是直接增大 k，而是先建立可比较、可隔离、可追溯的验证环境。

  1. 准备任务流与留出评测：为同一领域准备连续任务，同时保留不参与改进的验收集。没有在线 ground truth，不等于最终结果不需要质量标准。

  2. 固定对照变量：比较模式或预算时，保持任务、执行器、改进模型、裁判、网络访问和采样条件一致。官方 --seed 只控制任务流的打乱顺序，不控制模型采样。

  3. 记录完整成本：把参考执行、候选探测、合成、选择和反思的调用都计入，而不是只统计最终执行器回合。

  4. 限制评测期网络访问：公开版本默认不限制执行器网络，Codex 适配还会关闭 sandbox。官方实验文档记录过一次 JobBench 验证运行自行下载公开 rubric 的情况，因此需要在主机网络层阻断答案与评分材料。

  5. 保存版本与证据：为不同模型、任务子集和预算使用独立的 HARNESS2_RUNS_DIR，同时记录数据修订版本。官方依赖说明明确，公开工作流与历史论文运行可能使用不同任务、模型部署和本地工具。

Harness² 真正公开的不是一个“会自我进化”的口号，而是一套把修改、执行证据、采用决策和跨任务经验连接起来的方法。根据官方 README 与 2026 年 10 月 arXiv 预印本，它为递归改进 Agent Harness 提供了可运行起点。

能否进入业务流程，仍取决于任务评测、成本预算、访问隔离与复现实验。本文数据截至 2026 年 10 月 22 日，来源见文末参考资料。

参考资料

相关文章

以下文章讨论的是另一套 DeepSeek Harness，用作基础、安装与排错延伸阅读，不代表其与 Harness² 存在隶属或兼容关系。