企业官网建设流程全解析

Google 开源 Harness²：为什么 AI Agent 的瓶颈常常不在模型，而在「工作环境」

做 Agent 久了，大概都撞过这种墙：模型没换，只是改了系统提示、工具封装、记忆策略，或者把编排逻辑重写一遍，结果就能差出一截。反过来也成立——模型看着够聪明，长链路里照样漏步骤、乱调工具，写完文件也不回头核对。

很多人第一反应是换更大的模型。Google Cloud AI Research 开源的 Harness²（论文Harness²: Recursive Agent Harnessing for an Open World，Apache 2.0）换了个角度看这件事：把 Agent 拆成Model + Harness。权重先冻住，真正能动刀、能迭代的，是提示、工具、记忆、技能和编排这一整套「马具」，也就是工作环境。

对正在搭办公流、法律辅助或编码 Agent 的人来说，这话很实在：翻车了别急着微调，先问问 harness 是不是还能改，以及这套改法下次能不能复用。

换模型之外，还有一条路

常见做法大致就这几条：上更强的基座、反复打磨 system prompt、给每个业务场景手写工具说明和流程。开放世界里这些很快不够用——线上任务设计 harness 时根本没见过，测试时也很少有靠谱的标准答案；好不容易调通的执行环境，换个任务又容易过拟合。

于是工程上其实就两个问题：没有标准答案时，怎么安全地改 harness？以及，怎么让「改 harness」这件事本身沉淀成经验，而不是一次性补丁？

Harness² 的做法是两层递归：当前任务里改执行环境；任务结束后，再更新「以后该怎么改」这一层。

Harness² 在干什么

一句话：模型权重不动，专门折腾外围那套可插拔脚手架，而且这套折腾本身还能递归地变好。

几个关键词先对齐一下：

仓库在google-research/harness2，Apache 2.0。README 写得很清楚：这不是 Google 官方支持的产品。执行器侧试过 OpenCode、Codex 这类现成 coding agent 外壳，评测覆盖 WorkBuddy-Bench、JobBench、Harvey LAB 等专业域基准。

两层递归，中间是 Propose–Probe–Compose

图：任务层递归与 Harnessing 层递归（中文标注示意）

执行环境拆成八块

Harness² 把执行 harness 拆成 8 个文件级组件（在 AHE 分解上扩展）：

1. System prompt— 角色和顶层流程，始终在上下文里
2. Guardrails— 跟具体任务无关的硬约束
3. Memory— 跨任务还能留住的领域事实
4. Skills— 按需加载的专项流程
5. Tool guidance— 已有工具什么时候用、怎么用
6. Scripts— 确定性的辅助能力，比如用 bash 跑一段 Python
7. Subagents— 独立上下文窗口的委托工人
8. Plugin— 插在工具循环里的中间件钩子，能强制行为，不只是「建议一下」

这一点对工程同学很有用：不是所有改进都该塞进永远挂着的长提示。Skill、Script、Subagent、Plugin 往往比堆散文更省上下文，也更好复用。

第一层：先把当前任务改好

目标很明确——没有 ground-truth 也要改「这一次」的执行 harness。核心动作是对比式的 Propose → Probe → Compose。

Propose：先跑一轮参考执行，看清楚当前 harness 实际怎么干活（不是判对错）。再结合任务、当前 harness、参考轨迹和改进库，提出候选改动。候选分两类：一类是跨域都会复发的 Agent 毛病（规划、工具使用、上下文管理、委托等），一类是当前域的知识、流程和约束。每个候选都是可执行的 harness 文件树差分。

Probe：同样的模型、同样的环境，换上候选 harness 再跑同一任务，把轨迹和交付物跟参考执行做行为对比——是缓解了目标缺陷、毫无影响，还是引入了回退。注意，这只是编辑证据，不是任务正确性证明。

Compose：把参考、候选、diff 和任务内证据摊开，有选择地合并、修订、采纳某一个，或者干脆留着原 harness。决策要落到具体观察上，不能靠「猜分数会涨」。组合完再跑一遍，留下后继执行记录。

预算参数k可以往两个方向扩：并行递归一次探测多组候选，再做多次独立组合，用宽度换证据；串行递归则把精炼后的 harness 和累积证据带进下一步，用深度迭代。k=1时两者都退化成单次 Propose–Probe–Compose。k>1时还有个选择器，只看匿名交付物和任务要求挑一个结果，并不声称全局最优。

第二层：别把定制好的环境直接搬到下一题

任务交完之后，系统不会把高度定制的执行 harness 原样继承到下一任务——分布一漂，噪声会被放大。它做的是：复盘整段改进记录；把被采纳的 harness，以及有执行对比撑腰的教训写进改进库（例如EXPERIENCE.md加索引）；下一任务仍从公共初始执行 harnessH0起步，但 Propose / Probe / Compose 会读更新后的库——挑着复用组件，而不是盲继承。

多出来的这一层，才是「递归 harnessing」的意思：改进机制自己也在学。

实验上看到了什么

论文在三个专业基准、四种「执行模型 × 初始 harness」配置上给了结果（主表多为k=1单步；+ Recursion是并行k=5）。执行模型包括 GLM-5 和 Gemini 3.5 Flash；基线有 Base harness、ReasoningBank、Meta-Harness、Harness Scaling。

相对 base harness，单步改进的上限大致是：WorkBuddy-Bench 最高约 +11.5（比如 GLM-5 + OpenCode），JobBench 约 +4.5，LAB Partial（按准则通过率）约 +11.8 pp。并行k=5还能再往上加一点（WorkBuddy 大约再 +2.9～3.9，JobBench +3.0～4.2，LAB Partial +2.6～6.7 pp）。预算扫下来，并行和串行随k增大总体都受益；单纯加 test-time 探索并不保证同样稳。

几条更值得记的定性结论：

弱执行器配上更好的 harness，有时能超过强执行器配原 harness——WorkBuddy / LAB 上 GLM-5 的绝对收益更明显。Ablation 里去掉改进库、去掉不变/领域分工、去掉 Compose，都会掉分，说明不是「多跑几次就行」。同模型兼任执行器和编辑器仍有提升，收益不完全依赖更强的编辑模型。库还能跨任务甚至跨基准迁移（比如 JobBench 的库帮 WorkBuddy 做一步精炼），但幅度有限，而且很吃证据质量。

论文 Limitations 也写明了：递归精炼要额外的执行和编辑会话，算力和延迟是真成本；没有 ground-truth 时只能靠行为对比和模型判断，对随机性和共享偏差敏感，既不能保证正确，也不能保证跨任务一定可迁移。个别回归来自选择器挑了更弱的交付物，或者错误前提在候选之间传来传去——开放世界里的 harness 自改进，远谈不上「自动正确」。

落到自己的项目里可以怎么做

如果在自研 Agent 或多智能体平台，不必一上来复刻整条论文管线，但下面几件事值得借鉴。

把模型能力和 harness 能力分开记账，同一模型换 harness 前后最好有 A/B。system prompt、护栏、技能、脚本、插件尽量分文件挂载，编辑就是 diff，回滚和审计都方便。改配置之前先看参考轨迹，找到最早分叉的地方，再选最便宜的组件形态：能写成技能就别堆成长提示，能脚本化就别让模型反复手搓，必须强制的行为交给插件，别指望模型「自觉」。

没有标准答案时，别假装有 verifier；在匹配条件下用行为差指导合并。经验库里记的不只是「改完的配置」，还要记适用情境、教训和支撑证据，免得下一任务盲继承过拟合的 harness。预算k可以换宽度也可以换深度，先用k=1验证有没有收益，再往上扩。另外官方也提醒过：执行器联网时可能碰到公开基准答案，评测前最好限制对 rubric / 答案的访问。

国内团队可以先在内部办公流、客服 SOP、代码助手上，用「冻结模型 + 可编辑 harness 树 + 任务后经验库」跑一个最小闭环，够用了再考虑扩展。

怎么读这篇开源更有用

Medium Daily Digest 里 Nikhil（Neural Notions）那篇导读的切入点很准：人们总怪模型，而 Harness² 想说的是——很多时候缺的是更好的 working environment。我自己多看了几眼论文和仓库之后，大概有这三点印象。

它把 Agent 工程从「提示词手艺」往前推了一步，变成可审计的流水线。Propose–Probe–Compose 加上改进库，对要规模化交付的团队，往往比再追一个排行榜模型更关键。

它也比较老实：很多 harness 优化依赖训练集、单元测试或成对裁判；Harness² 坚持在部署任务流上、没有正确性标签地改，用行为对比当弱监督。这更贴近真实产品——客户任务经常没有 golden answer。

同时别把「自改进」神话化。RSI 叙事很容易写成科幻；论文把对象限定在 harness、权重冻结，也承认成本和失败模式。更健康的读法大概是：test-time 算力与其只砸在多采样最终答案上，不如砸一点在可复用的脚手架上。

如果你已经在用 OpenCode / Codex 一类外壳，Harness² 更像给外壳加了一间可递归改装的车间，而不是另起一个聊天机器人框架。

参考来源

1. Medium 导读（付费墙/摘要，本文未据全文翻译）：Why Google’s New Harness² Open Source Release Changes How I Think About AI Agents — Nikhil / Neural Notions
2. 开源仓库（Apache 2.0，非官方支持产品）：https://github.com/google-research/harness2
3. 论文 HTML / arXiv：Harness²: Recursive Agent Harnessing for an Open World— https://arxiv.org/html/2610.14224 · https://arxiv.org/abs/2610.14224

技术细节与数字以论文和官方 README 为准；文中判断是二次解读，不代表 Google 立场。