先用一分钟，抓住这件事
过去，人给 AI 设计工作流程。Harness² 想让 AI 参与改进这套流程，并积累「怎样改进才有效」的经验。
不是反复润色同一份答案，
而是修改产生答案的工作系统。
改方法，不改大脑
模型参数保持不变。它编辑指令、技能、脚本等外围组件，再用新方法重新执行任务。
看执行差异，不等标准答案
没有现成答案时，比较改动前后的过程与产物，寻找改动是否奏效的证据。
留下经验，不盲目继承
新任务从共同的基础配置开始，按需参考之前的组件与经验，而非照搬上一次整套配置。
能改善，不保证正确
作者报告了多组性能提升，也记录了错误选择与效果回退。自动优化不能替代独立验收。
Harness，究竟是什么？
把模型理解为员工的能力，Harness 就像员工的工作手册、工具台和协作规则。
同一个员工，拿到不完整的材料、模糊的要求和难用的工具，表现可能很差；换一套清晰的操作方法与检查机制，表现就可能改善。这是理解 Harness 的类比，不代表系统真的改变了模型本身。
Skills · 把专业方法变成可调用的能力
例如，把多份源文件对账的方法写成一份技能说明，让 Agent 在遇到相关任务时读取，而不是每次临时想一套流程。
这里改变的是「怎么做」，不是给模型重新训练。知识是否适用，仍要结合当前材料核实。“改工具说明”不等于“自动获得任何工具”Skill 可以告诉 AI 怎样调用某个服务，但不会凭空带来 API 权限、数据许可或原生 Office 编辑能力。外围组件仍要在实际运行环境中生效。
对应原文：§2.1、附录 D.3：八类可编辑组件。
一次改进，怎样发生？
先执行一次，再提出两类改法，用同一个任务试跑，最后有选择地组合。
想象 Agent 需要根据多份文件制作一份工作备忘录。初次产物看似完整，却没有核对文件之间的数字，也没有重新打开生成文件检查。Harness² 不只是让它“再认真一点”，而是修改导致这些遗漏的工作方法。
先看到问题发生在哪里
基础 Agent 执行当前任务，留下操作过程和最终文件。这个记录告诉我们它做了什么，却不自动说明答案对不对。
论文中的执行记录同时包含 trajectory（过程）和 deliverable（产物）。
00 基线：执行原任务，记录行为与产物。
01 提案：通用改法补齐核对流程；领域改法提供具体对账方法。
02 试跑：在同一任务、相同模型和环境下运行候选配置。
03 组合：保留有证据支持的改动，也允许不采用改动；再执行组合版本。
04 复盘：把适用条件、改法与证据留给后续任务。
通用改法：工作习惯哪里有问题？
例如，先盘点输入文件，给数字标注来源，生成文件后用脚本重新打开。这些方法可能适用于多种行业。
领域改法：专业方法哪里缺失？
例如，如何核对排期、场地、人工和预算文件，如何处理特殊数字格式。这些方法依赖具体业务。
Compose 不是把两个 Prompt 简单拼起来它可以合并有依据的修改、修正冲突、只采用一个候选，甚至保持原配置。组合之后还要重新执行，而不是直接把候选答案拼接成一份新答案。
为什么是「平方」？
一层改进「这次怎么做」，另一层积累「下次怎么改」。平方指向两层递归，不是性能翻倍。
经验库中的一个条目，不只是“这个办法很好”，而是记录：什么场景、改了什么、看到了什么证据、下次适用的条件是什么。项目用可执行的 Harness 加上 EXPERIENCE.md 保存这些信息。证据不足时，可以不新增经验。
分别组合
并行像同时请几个团队尝试不同改法，再基于共同证据形成多个组合版本。它扩展的是探索宽度。
图为 k = 3 的概念示意。实际会生成 k 个通用候选、k 个领域候选与 k 个组合版本；不是简单挑一份原始答案。
这还不是“无限自我进化”当前实现主要通过经验库改善后续改进，核心阶段流程并未无限递归重写；递归方式与预算预先指定。何时继续、何时停止的自动决策，是作者列出的未来方向。
实验到底说明了什么？
作者在三个专业任务基准、四种模型与执行环境组合中，报告了单步改进带来的提升。
64.2 → 75.7
31.5 → 36.0
59.6% → 71.4%
上面是各基准报告的最大单步增益，来自不同配置，不能合并为一个“平均提升”，也不能等同于真实用户任务成功率。
办公、网页与代码任务
GLM-5 / OpenCode：平均分 64.2 → 75.7。WorkBuddy 数值为三个领域的平均评分。
是不是仅仅因为“多花了算力”？
不能只凭基础配置与优化配置的对比，就把全部提升归因于方法。作者另做了计算开销比较和消融实验：固定条件后，分别去掉经验库、提案分工和组合步骤，看效果如何变化。以下是 Gemini 3.5 Flash / OpenCode、k = 1 的结果。
| 实验设置 | WorkBuddy | JobBench | 怎么理解 |
|---|---|---|---|
| 完整 Harness² | 77.5 | 36.0 | 三项机制都保留 |
| 不读写经验库 | 74.4 | 34.2 | 之前试过的方法不再帮助后续任务 |
| 不区分通用 / 领域提案 | 74.6 | 32.3 | 候选数量不变，但诊断角度不再分工 |
| 不组合，只选候选 | 75.9 | 34.1 | 无法整合不同候选中有效的改动 |
这些结果支持三项机制在该实验设置中的作用，不代表它们的贡献可以相加，也不证明所有业务上都成立。论文的计算开销分析计入了交付前的执行与改进 Token。
一个更直观的办公案例
文件生成了，核对没做完
未对多份源文件的数据进行一致性核对；生成后没有重新打开文件验证。
补齐对账与产物检查
加入输入清点、来源追踪、重新打开验证，以及专业对账 Skill 与数字格式说明。
论文 Figure 9 的单个 JobBench 案例，Gemini 3.5 Flash / OpenCode。评分是事后评估，不是优化时可见的反馈；不能作为整体平均效果。
数据来源：§3、Table 1–2；§4、Table 3、Figure 9。基础模型固定，不意味着总成本固定。
没有标准答案，为什么仍需测评？
系统能看见“工作行为发生了变化”，却未必能证明“用户得到了正确结果”。
确实重新打开了文件
部分数字通过核对
可能仍有问题
论文刻意把两件事分开：优化时不看标准答案与评分细则；研究结束后，用独立基准评价效果。“不靠标准答案来改进”，不等于“不需要评测来证明改进”。
系统选择了较差的候选
事后评分显示它更好
论文附录 E.6 的一个 WB-code 失败案例。分数是事后评价，优化系统当时看不到；九个回退案例也不等于整个系统只有九次失败。
共同的错误前提，可能被一起放大
两个候选如果相信同一条错误假设，相互比较也不能自动纠正它。执行更顺畅，不代表业务判断更准确。
多跑几轮，要付真金白银
提案、候选试跑、组合、选择与反思都可能消耗模型调用。并行能缩短部分等待，但不会消除计算开销；论文未给出通用的最优预算。
经验有效，不代表处处有效
旧任务中的方法未必适合新任务。过时经验、相互冲突的规则和不断增长的上下文，都需要后续管理。
研究默认设置，不等于生产安全配置
仓库提示：执行器网络默认不受限，Codex 沙箱关闭。接入真实文件前要隔离运行环境、限制权限，并防止读取公开测评答案或评分细则。
把自动改进当作候选方案生成器，
不要直接当作上线批准器。
对应原文：附录 E.6、附录 F–G；README：Web access。上线门禁建议为本文分析。
把它放进办公 Agent，会怎样？
最值得借鉴的，不是“让 AI 随便改自己”，而是把失败记录变成可验证的能力改进。
以“根据课件生成课堂练习与答案”为例。生成内容之后，可能发现题目超出材料、答案有误，或导出的文档无法正常编辑。与其立刻让 AI 重写整套专家，不如先定位是哪一种失败，再测试最小改动。
留住失败证据
输入材料、使用的版本、工具记录、输出文件和人工修改。
尝试两类改法
通用层补文件检查；专业层补知识范围与答案核对。
独立验收
用保留任务、确定性校验和教师抽检，防止自评自证。
小范围采用
记录版本与适用条件；效果回退时能够撤回。
| 实验组 | 配置 | 回答的问题 |
|---|---|---|
| A · 基线 | 现有 Agent / 专家包 | 当前能做到什么程度？ |
| B · 人工改进 | 根据同类失败，人工修改方法 | 现有产品与研发经验能带来多少改善？ |
| C · 自动改进 | 借鉴 Propose–Probe–Compose | 自动方案能否减少人工改造投入？ |
| D · 等预算多试 | 不改 Harness，只增加原配置运行与选择 | 提升来自改方法，还是仅仅来自多花算力？ |
各组都用同一套独立验收。固定执行模型、工具权限与任务分布，完整记录改进成本；保留未参与调优的任务，并对关键任务重复运行。先离线试验，经过人工审查后才考虑真实流量，不把线上用户当无保护的试验对象。
产品经理最值得盯的，不只是平均分有效任务成功率、关键错误率、人工核验与返工时间，以及每次有效交付的总成本。一个得分更高、但让用户检查更久的方案，未必值得上线。
这也解释了测评的价值为什么没有消失：当改方案越来越容易，决定什么值得改、什么算变好、多少成本值得付、何时可以放行，反而成为连接技术能力与真实产品价值的工作。
本节为基于论文机制的产品应用推演；课堂示例、实验分组与发布门禁均是建议，尚未运行或证明在具体业务中有效。
从读懂，到一次小步试验
先看流程是否跑得通，再验证真实效果。不要把“Demo 成功”当成“产品可上线”。
产品同学先准备什么？
选一类有反复需求、结果能检查的任务；找几份公开或脱敏材料；写清哪些错误不可接受，保存一组不参与调优的验收样本。
和研发一起确认什么？
哪些组件允许修改、工具权限在哪里、如何记录完整过程、一次实验的成本上限，以及失败后怎样恢复原版本。
清单只保存在当前浏览器，不上传信息。
给技术同事：最小本地 Demo 怎么运行？
仓库建议 Linux、Python 3.12 与 uv。下面运行的是无模型凭据的流程演示：使用确定性编辑器与真实 Python 执行，不代表大模型自主优化效果，也不是复现论文分数。
git clone https://github.com/google-research/harness2.git
cd harness2
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2真正的模型实验还需要模型鉴权、基准依赖与独立评测步骤，并会产生 API 成本。先执行官方环境检查，从极少量任务开始；不要直接接入生产文件或敏感凭据。
不用先读代码：按这条路线看仓库
runs/ 是执行后产生的结果目录，不是“下载仓库就有的实验结果”。代码测试通过，也不等于业务任务质量通过。
技术说明依据官方仓库 README；试验准备清单为本文建议。
原文、术语与继续阅读
理解机制后，推荐回看论文 §2、§4 与附录 E.6、F。前两部分解释“怎么改、为什么有效”，后两部分防止把研究结果理解成可靠性保证。
论文 HTML 原文
Harness²: Recursive Agent Harnessing for an Open World
Xu 等，arXiv:2610.14224v1，2026-10-09。
Google Research 开源仓库
阅读安装与使用说明、八类组件、默认安全设置及项目免责声明。
↗03 / EXPERIMENTS实验与复现指南
从小任务集开始，核对模型、执行器、子集、随机种子与评测配置。
↗04 / DESIGN REFERENCEKami 紙 · 设计系统
本阅读版参考 tw93 的暖纸底、油墨蓝、衬线字与低装饰排版原则。
论文作者：Ruiyao Xu、Yanfei Chen、Zhongying CuiZhu、Bhavana Dalvi Mishra、Yifei Ming、Han Yu、Rujun Han、Chen-Yu Lee、Tomas Pfister。中文阅读版整理：2026-10-30。
AI 不一定要先变得更聪明。
它也可以先学会，更好地使用自己。
但谁来证明它真的做得更好？
这正是产品判断、独立测评与真实用户反馈应该接上的地方。