做 Agent 的同学大概都有过这种感受：同一个大模型，换一套提示词、工具编排和记忆策略，干活稳定性就能差出一大截。模型没变，结果先变了。
模型表现拉胯时，很多人的第一反应是升级模型，但这条路成本高、周期长，未必是当下最划算的选择。
谷歌研究院 2026 年 10 月开源的 Harness²，把目光放在模型之外那层 “运行外壳”上：权重一个参数不动，让智能体在执行任务中自动调整提示词、护栏、工具指引和经验库，实现递归式自我改进。
论文《Harness²: Recursive Agent Harnessing for an Open World》（arXiv:2610.14224）显示，仅一步优化，办公基准 WorkBuddy-Bench 上 GLM-5 最多提升 11.5 分，并反超未优化配置下的 Gemini 3.5 Flash。
本文将依次讲清 Harness² 解决什么问题、机制怎么跑通、实测数据、社区落地与未来边界，并保留本地演示命令和检查脚本。
先搞懂：什么是 Harness，为什么它决定真实水平
Harness 本意是马具、挽具，放到 Agent 语境里，指模型之外让模型真正成为 “智能体” 的整套运行系统：系统提示词、可调用工具、历史记忆、任务拆分、子智能体委派、工具循环里的校验规则。
模型负责 “想”，Harness 负责 “怎么想、怎么做、做错了怎么纠正”。
这个概念大家早就在用。Claude Code、Codex、OpenCode 这类编程 Agent，本质就是不同团队为同一批底层模型打造的不同 Harness；同一模型套上不同外壳，在代码、网页、表格等任务上各有胜负，已是行业共识。
由此得到关键判断：不存在一款通吃所有任务的固定式 Harness。人工规则只能覆盖设计者预料到的场景，任务结构一变，原先调好的提示词就可能失效。
Harness² 的目标，就是在测试阶段根据实际运行表现动态调整外壳，即便面对设计者没预料过的新任务，也能逐步收敛性能差距。
老办法为什么走不通：堆提示词和盲目自改都不行
顺着 “Harness 很重要” 的直觉，一个简单想法是让模型自己改写系统提示词，把踩过的坑补进规则里。实测却容易越改越差，主要卡在两个瓶颈。
1. Token 成本膨胀
系统提示会在每一轮工具调用、每一次推理时反复送入上下文，每新增一条约束就意味着每一轮都为它付费；提示词越堆越多，留给观察工具返回、规划下一步的 Token 反而被挤占，预算耗尽时，任务常常做到一半就被截断。
2. “建议” 和 “强制” 的区别
提示文本里的规则模型可以选择性忽略，压力一大就忘；可靠校验必须落在代码层，比如脚本检查产出完整性、中间件拦截异常调用。
Harness² 把这个区分贯穿设计：能交给脚本和中间件执行的约束，就不依赖模型自觉。
传统递归自我改进（RSI）落地开放世界时，还卡在两堵墙上：
• 开放任务没有标准答案，新任务来了没人告诉你修改是变好还是变坏；
• 很多系统只针对单任务反复打磨，换个场景就失灵，经验无法沉淀迁移。
Harness² 的双层递归正是冲着这两个问题设计的。
核心机制：双层递归，一层改当下，一层攒经验
Harness² 里的平方（²），指两层互相咬合的递归循环，全程冻结模型权重，不做任何微调。
1. 任务级递归：提议-探测-合成，不依赖标准答案
面对当前任务，系统走对比式三步闭环，论文称为 Propose-Probe-Compose。
• 提议（Propose）：先用基础 Harness 跑一遍任务得到参考轨迹，目的是暴露行为模式而非判断对错。
随后两个分工不同的编辑器读日志：一个盯着通用缺陷（工具反复失败、规划断裂、上下文失控、委派不当），产出 “不变式候选”；另一个针对当前任务的知识流程产出 “领域候选”。
• 探测（Probe）：两份候选 Harness 在完全相同的任务、模型和环境下各跑一次，与参考轨迹横向对比，看改动是缓解了缺陷、没有变化还是引入退化。
• 合成（Compose）：综合三份轨迹做选择性组合，即合并有证据支持的修改、修订冲突编辑、只采纳一份，或保留原 Harness 不动；每个决策都绑定可观察的执行证据，而非预估分数增益。
这套机制的精妙之处在于完全不依赖正确性标签：不问 “答案对不对”，只问 “修改让行为发生了什么可观察的变化”，绕开了开放世界没有验证器的死结。
消融实验证明探测不是形式主义：跳过参考执行和探测、直接让模型自我精炼，性能不升反降；去掉合成步骤，WorkBuddy-Bench 平均掉 1.6 分、JobBench 掉 1.9 分。
任务级递归还分两种模式：并行同时探索多套变体，偏向 “搜得宽”；串行把上一轮结果带入下一轮，偏向 “钻得深”；预算参数 k 控制深度，k 越大调得越细，代价是更多次完整执行。
2. 改进级递归：把验证过的经验沉淀下来，供以后复用
任务级递归解决 “眼前事怎么做对”，第二层 Harnessing 级递归解决 “以后的事怎么少走弯路”。
任务结束后，经验反思器检视完整改进记录并提炼教训，但有一条铁律：只有带执行对比证据的经验才允许入库，仅凭 “这次选中了某输出” 不足以证明可迁移性，证据不足就不新增条目。
经验连同被采纳的 Harness 写入持久化改进库，每条含可执行配置、适用场景、改进方案和支持证据。
下一个任务仍从通用基础 Harness 出发，但先检索经验库作参考；模型权重、阶段指令和决策规则全程固定，只有经验库持续演化。
论文显示，JobBench 积累的经验库迁移到 WorkBuddy-Bench，代码、网页、办公子集仍分别带来 0.6、0.5、2.9 分提升；排除任务自身条目后，跨任务复用依然有正收益。
八块可编辑 “积木”：改什么、不改什么
Harness² 把外壳拆成八个文件级组件，编辑器只能在这个边界内 “动刀”，分层方式也与主流 Agent 框架对齐，这是它自称 “即插即用” 的底气。
• 系统提示词：模型行动前，看到的基础指令与角色设定。
• 护栏：流程级强制规则，如步数上限、先核对再产出。
• 记忆：长期经验与上下文管理策略，并非堆得越多越好。
• 技能：面向特定领域的操作套路，如财务对账、法律条款检索流程。
• 工具指引：工具描述、入参规范与调用时机说明。
• 脚本：可执行的校验与处理逻辑，把 “建议遵守” 变成 “代码强制”。
• 子智能体：哪些子任务隔离到干净上下文执行、如何返回结果。
• 中间件插件：嵌入工具调用循环的拦截、监控与校验行为。
按职责归类：系统提示、护栏、记忆、技能属上下文层，决定 “行动前看到什么”；工具指引和脚本属工具接口层；子智能体负责委派边界；中间件负责循环内行为控制。
论文案例里两个修复很有代表性：
1. 加步数监控，在 Token 预算见底前，强制从检索切换到产出，防止无休止搜索；
2. 用脚本遍历表格校验公式完整性，缺公式就拦截交付。
这类护栏写在脚本里，不依赖模型配合。
实测成绩：三个基准的提升与几个反直觉发现
实验覆盖 WorkBuddy-Bench（办公、网页、代码）、JobBench（职业工作）和 LAB（Harvey 法律基准，统计部分通过率）三个基准；执行模型为 Gemini 3.5 Flash 与 GLM-5，分别跑在 OpenCode 和 Codex 两套初始 Harness 上共四种配置；默认编辑器为 Claude Opus 4.8；主表报告单步优化（k=1）结果，三次随机运行取均值。
核心提升数据（k=1 单步优化）：
• WorkBuddy-Bench：GLM-5 配 OpenCode 平均分从 64.2 升至 75.7，提升 11.5 分，为该基准最大单步增益；优化后，反超原始配置下 Gemini 3.5 Flash 的 72.4 分（OpenCode）与 74.5 分（Codex）。
• JobBench：Gemini 3.5 Flash 配 OpenCode 平均分从 31.5 升至 36.0，提升 4.5 分；GLM-5 对应从 20.6 升至 24.2。
• LAB 法律基准：GLM-5 配 OpenCode 部分通过率从 59.6% 升至 71.4%，提升 11.8 个百分点。
递归预算加到 k=5 并行探索后，继续上涨：
• WorkBuddy 额外增加约 2.9 到 3.9 分，JobBench 增加约 3.0 到 4.2 分，LAB 额外增加约 2.6 到 6.7 个百分点，增益随 k 单调上升，没有出现 “越改越崩”。
• JobBench 上两套初始 Harness 原本 2.4 到 3.0 分的差距，优化后收敛到 0.5 分。无论起点如何，递归都把配置推向相似的优良水平。
几个值得开发者反复琢磨的细节：
• 弱模型受益更大。GLM-5 在 WorkBuddy 和 LAB 上的绝对增益明显高于 Gemini 3.5 Flash；成熟 Harness 能在相当程度上补偿模型能力差距，对预算有限的团队是实质利好。
• 记忆不是万能药。对照组 ReasoningBank（固定 Harness、只做历史轨迹检索记忆）在编码任务上最多比基础 Harness 低 6.6 分，无脑存记忆反而引入噪声。
• Harness 可跨模型迁移。把为 Gemini 3.5 Flash 打磨好的 Harness 直接给 GLM-5，代码子集 58.5 升至 75.8（+17.3 分）；迁移给 Gemini 3.7 Flash、Claude Opus 4.8 也都有正收益。
• 编辑器未必需要更强模型。同模型兼任执行器与编辑器的实验中，从 GLM-5 到 Claude Opus 5 共五个模型在三个基准全部提升，GLM-5 在 LAB 拿到 13.7 分增益，说明 “必须用顶配模型改配置” 并非前提。
• 每个部件都不可省。去掉经验库掉 3.1 分（WorkBuddy）和 1.8 分（JobBench）；去掉分工式编辑器角色掉 2.9 和 3.7 分；去掉合成步骤掉 1.6 和 1.9 分。
论文案例：某 JobBench 任务基线 43.1 分，轨迹显示失败并非知识欠缺，而是流程问题，跨文件数据从未对账、产出后从不复查。
优化时，加入流程护栏（盘点全部输入、数字溯源到来源、用校验脚本重开产出检查）和领域技能（对账机制与数字格式指引），重跑得分达到 77.8。
上手跑一遍：本地安装、免费演示与运行检查
项目对本地调试友好，演示模式不需要 API 密钥和云账号，几秒就能跑通调度循环。以下基于 Linux、Python 3.12、uv 环境实测。
克隆仓库并安装依赖
git clone --depth 1 https://github.com/google-research/harness2.git
cd harness2
uv venv --python 3.12 .venv
. .venv/bin/activate
uv pip install -e '.[render]'注意这三点：
• 仓库本体约 15 MB，渲染依赖含 lxml、openpyxl、pillow、python-pptx、xlsxwriter 等；
• 要求 Python 版本大于等于 3.12 且小于 3.14，低版本会在创建虚拟环境时报错；
• 安装后自带七个 CLI 命令：harness2、harness2-demo、harness2-setup、harness2-check、harness2-judge、harness2-report、harness2-bridge。
无密钥本地演示，k=2 递归预算
harness2-demo --output runs/demo --k 2演示内置两个会计任务和确定性编辑器，实测结果为两任务全部通过、零失败：
演示运行摘要
[accounting] 1/2 ok ledger-1
[accounting] 2/2 ok ledger-2
Local demo: 2 tasks completed; 0 failed. runs/demo/demo.json本次实测规模：2 个任务零失败，累计 28 次执行、32 次编辑器调用，写出 2360 个文件、文本约 265 KB。
磁盘占用与文件系统关系很大：ext4 上每个小文件占 4 KB 块，落盘约 13 MB；APFS 压缩稀疏处理后仅约 0.3 MB，跑大规模基准前要提前规划存储。
28 次执行构成为：并行模式每任务 8 个变体（base、inv、dom、agg 各两个），串行模式每任务 6 个变体（inv、dom、c 各两个）；inv 为不变式编辑，dom 为领域编辑，agg/c 为组合结果。论文给出的单任务成本约 4 到 20 次完整执行，本次 k=2 落在区间下限。
必须提醒：免费演示只验证机制，不展示真实优化能力。
实测检查发现：护栏、长期记忆、工具指引三个文件为空；插件、技能、子智能体目录只有 README 占位；真正有内容的只有 56 字节系统提示和 243 字节摘要脚本，两种任务、两种模式下完全相同。
确定性编辑器不会生成实质性规则改写，调度逻辑都在转，但没有真正约束被优化；想看到真实增益，必须配置模型凭证跑正式基准。
正式基准的前置依赖更多：Node.js 20 及以上、Google Cloud CLI 与 Vertex AI 凭证；LAB 另需 Pandoc 和 Poppler，WorkBuddy-Bench 需要 Docker。
典型流程如下：
正式基准：配置、执行、评判、报告
cp .env.example .env # 填入 Vertex 项目与模型 ID
gcloud auth application-default login
harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel \
--only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel四个易踩的坑：
• 评判与报告命令必须和执行时的基准、执行器、子集、k 值、模式、随机种子完全一致，否则分数对不上；
• 加 --dry-run 可零成本预览任务；
• 建议先从 --max-tasks 1 起步；
• 默认 OpenCode 执行器，加 --substrate cx 可切 Codex。
官方提示：公开基准评分细则可能被联网检索到，正式评测需额外限制网络访问。
运行目录层级深、文件多，手动翻日志效率低。下面这段独立脚本不属于官方仓库，用于汇总执行数据、统计产物、列出变体、检查组件是否为空、展示经验笔记结构。
inspect_run.py：提取运行目录关键指标（作者补充工具）
import json,pathlib,sys,collections
root=pathlib.Path(sys.argv[1] if len(sys.argv)>1 else "runs/demo")
s=root/"demo.json"
if s.exists():
d=json.loads(s.read_text()); print("RUN SUMMARY")
for k in ("domain","n_tasks","done","failed","execution_count","editor_calls"):
if k in d: print(f" {k:<16} {d[k]}")
files=[p for p in root.rglob("*") if p.is_file()]
mb=sum(p.stat().st_size for p in files)/1024**2
print(f"ARTEFACTS: {len(files)} files, {mb:.1f} MB")
for md in sorted((root/"executions").glob("*")):
tasks=[p for p in md.glob("*") if p.is_dir()]
if tasks:
vs=sorted(p.name for p in tasks[0].glob("*") if p.is_dir())
print(f" {md.name:<16} {len(vs)} variants")
sz=collections.defaultdict(set)
for p in root.rglob("harness/**/*"):
if p.is_file():
key=str(p.relative_to(p.parents[1])) if p.parent.name!="harness" else p.name
sz[key].add(p.stat().st_size)
for name,vals in sorted(sz.items()):
v=sorted(vals); flag=" <- EMPTY" if v==[0] else ""
disp=v[0] if len(v)==1 else f"{v[0]}-{v[-1]}"
print(f" {name:<34} {disp:>8}{flag}")
for e in list(root.rglob("EXPERIENCE.md"))[:1]:
print("EXPERIENCE.md headings:")
for line in e.read_text().splitlines():
if line.startswith("#"): print(" ",line)每个任务都会生成一份 EXPERIENCE.md，固定三段：为何采纳该项修改、每项编辑的作用、可迁移经验；第三段正是跨任务复用的关键。
另有调试细节：重复指向同一输出目录会断点续跑、跳过已完成任务，但 demo.json 计数会清零；要统计准确数字，请用 --output 指定全新目录。
社区落地：从基准成绩走向工程实践
基准之外，社区已在尝试把双层递归接入自有执行引擎，代表性路径有两类。
第一类：基准场景的业务复现
• 办公场景中，任务级递归生成提示词与工具策略多版候选并试跑对比，有效配置进入经验库，同类任务冷启动直接复用；
• 法律文书场景中，递归产出护栏规则与引用核对脚本候选，沉淀领域技能包；
• 求职文书场景中，简历优化等子任务交付合格率提升最明显。
第二类：接入开源 Agent 引擎
以字节跳动开源的 DeerFlow 2.0 为例，社区接入思路可归纳为八步：
1. 统一模型通道与密钥审计；
2. 编排层映射 Model、Agent、Harness、Executor、Improver 五个角色；
3. 八类组件纳入统一配置与可回滚边界；
4. 编排图新增优化子图实现提议-探测-合成；
5. 任务结束后，把 “触发场景加改进方案加执行证据” 写入经验库；
6. 复用上下文压缩能力防止长任务漂移；
7. 基于内置沙箱定义黑名单与执行边界；
8. 用调研报告类长任务端到端验证。
简化数据模型如下：
DeerFlow 接入时的组件与任务状态建模
from typing import List, Dict, Any
from pydantic import BaseModel
class HarnessComponent(BaseModel):
system_prompt: str = ""
guardrails: List[str] = []
memory_strategy: str = "summary"
tool_instructions: Dict[str, str] = {}
skills: List[str] = []
scripts: List[str] = []
class TaskState(BaseModel):
task_id: str
current_harness: HarnessComponent
execution_history: List[Dict[str, Any]] = []
improvement_evidence: List[Dict[str, Any]] = []
optimized_harness_library: List[Dict[str, Any]] = []该结构的价值在于：组件、优化器、经验库解耦，符合模块化引擎的可替换原则；先检索历史经验、再执行任务级优化、最后沉淀新经验，闭环清晰；执行历史与证据全程留痕，便于审计复盘。
公开报道中还有开发者把它接入视觉智能体 Jev 1.14，全程未调视觉基座权重，通过双层递归优化提示词、记忆策略与工具调用逻辑。
说明：这些属社区工程实践，效果需结合自身业务重新验证，不等同于官方承诺的生产能力。
冷思考：成本、边界与适用场景
1. 额外算力与延迟开销
每个候选都要完整跑一遍任务，并行模式执行次数成倍增长，Token 成本和端到端延迟上升；更适合批处理、异步后台和低频高精度场景，不适合毫秒级响应的高并发在线接口。
2. “有证据支持” 不等于 “全局最优”
行为对比只能观察变化方向，无法保证行为绝对正确；执行随机性和模型系统性偏差都可能污染证据，需人工抽检与版本回滚兜底。
3. 递归不保证单向收敛
个别配置下，递归反而扩大初始 Harness 差距，k=5 在部分子集出现小幅负波动；工程上应保留基线做 A/B 对照，不无条件采用最新配置。
4. 安全合规需自行补齐
框架会自动改写执行环境周边文件，默认执行器网络不受限；生产环境必须自行配置沙箱隔离、敏感资源黑名单和操作审计。
README 明确标注：这不是谷歌官方支持产品；代码为 Apache 2.0 可商用，但第三方依赖、基准与数据集保留各自原始许可。
5. 基准到真实世界仍有距离
现有数字来自三个专业基准，与真实开放任务存在分布差异；社区也反馈维护复杂 Harness 的人力成本不低，接入前要算清 “优化收益减执行成本减维护成本” 这笔账。
未来趋势：竞争焦点从模型参数转向脚手架进化
Harness² 并非孤立探索：离线搜索最优 Harness 的 Meta-Harness、只做记忆复用的 ReasoningBank、无评论家强化学习调长程智能体的 TreeOPSD 等思路先后出现。
它的差异化在于把 “当前任务即时优化” 和 “跨任务经验沉淀” 焊在同一闭环，并直接开源可运行代码，支持 OpenCode 与 Codex 两套执行器。
往后看，有三条趋势值得跟踪。
1. Agent 运维产品化
轨迹分析、缺陷定位、候选试跑对比、经验库版本管理，会逐步沉淀为类似 APM 的智能体自适应运维体系。
2. 存量系统低成本升级
已上线的智能体不必重训底座，接入递归循环迭代外壳即可，论文跨模型迁移实验提供了初步证据。
3. 与 RAG、多智能体编排融合
经验库与检索增强天然互补，委派策略也可纳入自动优化范围，长期方向是让整个执行架构持续演化。
对应用团队而言，先把 Harness 的可观测、可对比、可回滚工程基础打好，往往比急于换大模型投入产出比更高。
常见问题速答
1. 任务级递归和改进级递归的差别在哪？
前者面向当前单任务即时调优，效果不自动延续；后者面向未来所有任务，把带证据的经验沉淀进持久化经验库，支持跨领域迁移。
2. 必须用更强模型当编辑器吗？
消融显示同模型兼任执行器与编辑器在五个模型上均有提升；编辑器强弱影响质量上限但非硬性前提，可先用现有模型跑通闭环，再按需升级。
3. 哪些场景适合用 Harness²？
适合任务类型多样、允许额外延迟、人工调优成本高的异步流程，如报告生成、法务核对、数据分析后台；不适合强实时、高并发、预算刚性的在线接口。
