玄姐聊AGI公众号文章2026-10-22

谷歌开源 Harness²：架构拆解 + 企业落地指南

科技与互联网

玄姐聊AGI

公众号 · 40 篇文章

查看主页 →

大家好，我是玄姐。

PS：AI 落地点击预约直播。

过去一年，我在企业里落地 Agent 项目时，被问得最多的一个问题是：模型都换了三轮了，为什么 Agent 的效果还是上不去？

我的回答通常很直接：大多数时候，瓶颈根本不在模型，而在模型外面那一圈系统，也就是 Harness。提示词怎么写、工具怎么描述、记忆怎么组织、子任务怎么拆、出错时怎么兜底，这些加起来，才决定了一个 Agent 在真实业务里能走多远。

问题在于，Harness 一直是靠人手工调出来的。工程师盯着 Trace 一条条看，改一句提示词，跑一遍回归，再改一句。模型一升级，之前调好的那套又得推倒重来。

就在本月，Google Research 联合西北大学开源了Harness²（读作 Harness 的平方），它要回答的问题是：能不能让 Agent 自己去改自己的 Harness，而且是在没有标准答案的开放任务上改？

这篇文章，不打算做新闻复述，而是从架构师的视角，把 Harness² 拆开讲清楚：它的设计骨架是什么，关键机制为什么成立，和同期其它自进化 Harness 路线有什么区别，以及企业到底该怎么用、什么时候不该用。

PS：Harness 更多案例深入免费学习去这里，扫码直达：

1.打开 AITutor 新一代 AI 原生学习伙伴：www.aiaitutor.com 2.在首页输入"Harness” 就能看到更详细更丰富案例。3.包含了图文、视频、播客、闪卡、代码、测验等9种学习模态。

一、先把概念对齐：Agent = 模型 + Harness

在讨论 Harness² 之前，先统一一个公式：

AI Agent = 大模型 + Agent Harness

模型负责“想”，Harness 负责让模型“能干活”。Harness² 的 README 给了一个很干净的定义：Harness 是让模型成为 Agent 的那套外围系统，包括提示词、工具、记忆、技能、编排等；而 Harnessing，是指优化这套系统的过程。

这句话的分量在于，它把“调 Agent”这件事正式变成了一个可以被自动化的优化问题，优化对象不是权重，是系统。

1.1 Harness² 把 Harness 拆成了 8 个可编辑组件

Harness² 把可以被修改的部分明确列成 8 类，并按运行时角色分成 4 组。我觉得这个分法本身就值得企业架构师直接借鉴：

运行时角色	组件	管什么
上下文构建	系统提示词、护栏（Guardrails）、记忆、Skills	模型每一步“看到什么”
工具接口	工具指导（Tool Guidance）、脚本（Scripts）	模型“能做什么、怎么做”
任务编排	子智能体（Subagents）	活怎么拆、交给谁
中间件	插件（Plugins）	工具循环内部的拦截与控制

这张表的意义在于：它给“Agent 改自己”划定了明确的修改边界。能改的就是这 8 类，每一类都有清晰的职责，改动可以被追踪、被比较、被回滚。没有边界的自进化，在企业里是不可能过安全评审的。

1.2 它不碰权重，只碰系统

Harness² 全程保持模型权重不变。这一点对企业极其关键：你不需要训练算力，不需要标注数据，也不需要私有化部署一个可微调的模型。哪怕你用的是闭源 API，Harness² 这套思路依然适用。

二、核心难题：开放世界里，没有“标准答案”怎么办？

自进化 Harness 不是新概念，今年学术界和社区已经有一大批工作。但绝大多数方法都依赖一个前提：有一个可以打分的评测器。单测能跑通、答案能比对、奖励能算出来，优化器才知道这次修改是变好了还是变坏了。

Harness² 的论文点出了开放世界里的两个致命问题：

第一，任务没见过，也没有裁判。真实业务里大量任务在 Harness 设计阶段根本不存在，上线时才第一次出现，自然也就没有现成的验证器来指导在线修改。

第二，改进经验不能迁移。很多自进化过程高度绑定在某一个任务上，换个场景就失效，学到的东西无法沉淀。

和我在企业里看到的情况完全一致。比如一份法律尽调报告、一份行业研究、一个跨系统的办公流程，你很难写出一个“标准答案”去自动判分。这正是大量企业 Agent 项目卡在 POC 阶段的根源。

Harness² 的解法，是用两层递归分别对付这两个问题。

三、架构拆解：两层递归是怎么咬合在一起的

我把 Harness² 的整体架构画成了一张黑板报图（见文末总体架构图），这里逐层拆开讲。

3.1 第一层：任务级递归，用“对照实验”代替“标准答案”

任务级递归发生在单个任务内部，核心是一个叫Propose、Probe、Compose（提出、探测、组合）的对比式改进步骤。按照仓库给出的流水线，它由 4 个角色协作完成：

1. Agent Executor（执行器）：先用初始 Harness 把任务跑一遍，拿到基线执行轨迹。

2. Harness Editor（编辑器）：基于执行情况提出修改方案。这里有个很聪明的设计，修改分两类：

通用修改（Invariant Edits）：跨任务都成立的改进，比如“交付前先自检格式”。
领域修改（Domain Edits）：只针对当前领域的改进，比如“反垄断分析先界定相关市场”。

3. Candidate Probes（候选探针）：把每个修改版本的 Harness 拿去真实执行同一个任务。

4. Harness Composer（组合器）：对比不同候选之间的行为差异，把有执行证据支撑的修改组合成最终 Harness。

关键点在第 4 步。它不问“哪个答案是对的”，而是问“同一个任务，换了这条规则之后，Agent 的行为发生了什么变化，这个变化是不是我们想要的”。

这就是对照实验的思路。你不知道绝对分数，但你能看清相对差异。用行为对比替代真值判分，这是 Harness² 在开放世界里能成立的根本原因。

3.2 第二层：Harnessing 级递归，让“改进的方法”本身也在进化

如果只有第一层，每个任务都是从零开始摸索，成本高，也学不到东西。

第二层递归发生在任务之间。每个任务结束后，一个Experience Reflector（经验反思器）会复盘这次改进过程，把两样东西写进一个持续存在的Improvement Harness（改进 Harness）：

这次最终被采纳的 Harness 方案；
有执行证据支撑的经验教训。

下一个任务到来时，Harness Editor 就不再是盲目提案，而是在 Improvement Harness 的指导下提案。

用一句话总结两层的关系：

第一层优化的是“这个任务怎么做”，第二层优化的是“下次怎么更快找到好做法”。

前者是解题，后者是学会解题的方法。这也是标题里“平方”的含义：Harness 在优化 Harness 的过程中，自己也被优化。

3.3 两种扩展方式：宽搜与深挖

任务级递归可以通过参数 --k 加预算，有两种模式：

模式	做法	适合场景
并行递归（parallel）	同时探测 K 个通用候选和 K 个领域候选，再基于共享证据产出 K 个组合	方向不明确，需要广撒网
顺序递归（sequential）	把上一轮的 Harness 和累积证据带入下一轮，连续做 K 步	方向已明确，需要精雕细琢

官方一句话概括得很好：并行探得更宽，顺序挖得更深。

四、效果与代价：11.5 分的提升，不是白来的

4.1 实验数据

Harness² 在 3 个专业类 Benchmark 上做了验证：JobBench（职业任务）、LAB（法律任务）、WorkBuddy-Bench（办公、网页和代码），覆盖 4 种“模型加 Harness”组合，底座模型是 GLM-5 和 Gemini 3.5 Flash。

只做一步递归，在权重完全不动的情况下：

WorkBuddy-Bench 最高提升11.5 分
JobBench 最高提升4.5 分
LAB 部分通过率最高提升11.8 个百分点

继续加大任务级递归预算，还能继续涨。

提醒两点：一是这些数字来自 Google Research 自己的论文，目前还没有独立第三方复现，建议当作方向性信号看待；二是社区已经有开发者反馈，在自己的 Agent 上接入后效果明显，但个例不能替代你自己业务上的验证。

4.2 成本账必须算清楚

这是我最想让企业技术负责人看到的部分。Harness² 的提升，本质上是用测试时计算换成功率。

拆开看，一步 --k 1 至少包含：一次基线执行、若干候选探针的完整执行、一次组合、一次反思。如果开到 --k 4 --mode parallel，就是 8 个候选探针外加 4 次组合。每个探针都是一次完整的 Agent 任务执行，Token 消耗是成倍放大的。

社区在 Issue 区已经在提 --max-usd 成本上限、本地 Benchmark 支持、允许人工介入选择 Harness 等需求，这恰恰说明：Benchmark 上划算，不等于生产环境划算。为了几个百分点的提升付出数十倍 Token，在多数业务里是算不过账的。

4.3 安全提醒

官方明确说明两点：执行器默认网络访问不受限，Codex 执行器会关闭沙箱。公开 Benchmark 的评分细则可能在网上找得到，正式评测前要先配置网络限制。

在企业环境里，这意味着：不要把 Harness² 直接接到生产环境跑。先放进隔离的评测沙箱。

五、横向对比：今年的自进化 Harness 都走了哪几条路？

Harness² 不是孤例。2026 年，“让 Agent 自己当 Harness 工程师”已经成为一条清晰的技术主线。把几条代表性路线放在一起对比：

路线	核心思路	依赖真值评测？	适合场景
AutoHarness（DeepMind）	让模型直接合成代码形式的 Harness，作为动作校验器甚至策略	依赖环境反馈	规则明确的环境，如游戏、结构化输出
Self-Harness	Agent 从自身 Trace 挖失败模式，提最小修改，用回归测试决定是否接受	依赖回归测试	失败模式可复现的长流程
Meta-Harness	用文件系统存档历史，Coding Agent 作提案者	依赖评测	有稳定评测集的研发场景
Continual Harness	单次持续运行中交替执行与改进，不重置任务	弱依赖	长时程任务，如长期游戏 Agent
Adaptive Auto-Harness	不维护唯一 Harness，建 Harness Tree 按任务路由，保留人工入口	依赖反馈	任务类型持续变化的开放任务流
Harness²	任务内对照实验加任务间经验沉淀	不依赖	无标准答案的开放专业任务

这张表里有两个结论值得记住：

第一，Harness² 的独特位置是“不需要真值裁判”。其它路线大多在“有测试可跑”的前提下工作，Harness² 把战场推到了没有裁判的地方。

第二，Adaptive Auto-Harness 的发现值得警惕。研究者观察到，在开放任务流中，反复修改同一个 Harness 可能导致性能反而下降。这和 Harness² 的 Improvement Harness 设计形成了一个有意思的张力：经验在不断累积，但累积本身也可能变成负担。企业落地时，经验库一定要有淘汰机制。

另外，工程侧也有可以直接上手的开源工具：NeoSigma 的 auto-harness 主打“挖失败、改 Harness、拦回归”；kayba-ai 的 autoharness 不要求你换掉原有 Agent，用一个配置文件定义优化活动，管理候选、评测和冠军 Harness，并支持 Codex CLI、Claude Code 等作为提案者。

六、企业落地：建议的五步走

结合我们这一年做企业 AI 原生研发体系的实践，我把 Harness² 这类自进化 Harness 的落地拆成五步。

6.1 第一步：先让 Harness“可编辑”

如果你的提示词散落在代码各处，工具描述写死在函数注释里，那么任何自进化框架都无从下手。

先做组件化：参照 Harness² 的 8 组件分类，把系统提示词、护栏、记忆、工具指导、Skills、子智能体、脚本、插件全部外置成独立文件，纳入版本管理。这一步本身就能让人工调优效率提升一截。

6.2 第二步：建 Trace 与评测底座

不管有没有标准答案，你都需要看得见 Agent 在干什么。

全链路 Trace：每次工具调用、每段上下文、每次子任务委派都要记录。
多维评测：只看最终答案对不对已经不够了。Agent 可能答案仍然正确，但执行方式已经从精准检索退化成全量扫描，Token、延迟、成本一起飙升。评测维度至少要包含：任务完成度、工具调用效率、Token 消耗、延迟、成本。
历史失败案例集：每次 Harness 或模型更新，先跑一遍过去解决过的问题，旧病复发就禁止上线。

6.3 第三步：先在“有裁判”的场景跑通，再挑战开放任务

不要一上来就在开放任务上做自进化。

建议先在有明确验收标准的场景（代码生成、格式化报告、数据抽取）用回归测试驱动的方式跑通闭环，积累信心和基础设施，再把 Harness² 的对照实验机制引入到研报、方案、法务审查这类开放任务。

6.4 第四步：给自进化装上“护栏的护栏”

这是很多团队会忽视的一步。

自进化 Harness 如果只改系统提示词，风险可控；一旦允许改工具、脚本、插件、中间件，本质上就是 Agent 在生成并执行新程序。社区里已经有人指出，某些框架产生的候选 Harness 代码在加载阶段就会执行模块级逻辑，而前置门禁只做了语法检查。

企业必须做到：

分级授权：提示词、记忆类修改可自动采纳；工具、脚本、插件类修改必须人工审核。
沙箱执行：候选探针一律在隔离环境运行，默认断网或白名单网络。
可回滚：每一个被采纳的 Harness 都有版本号，随时可以一键退回。

6.5 第五步：建立 ROI 闸门，学会做减法

给每个任务类型设定递归预算上限（--k 和成本上限），只在高价值、高频、失败代价大的任务上开启深度递归。

更重要的是学会删除。社区有开发者分享过用 8 个月、800 多次提交搭一套 Harness 的经历，最后维护 Harness 本身花的时间比真正用 Agent 还多。自进化的目标不是让 Harness 越来越胖，而是形成完整闭环：发现失败、理解失败、尝试修改、验证修改，没收益就删掉。

七、快速上手：15 分钟跑通 Harness²

环境要求：Linux、Python 3.12、uv。

1. 不需要任何模型凭证，先跑本地 Demo：

uvvenv--python3.12.venvsource.venv/bin/activateuvpipinstall-e'.[render]'harness2-demo--outputruns/demo--k2

Demo 会用确定性编辑器和真实 Python 执行，把并行和顺序两种递归模式都跑一遍，非常适合理解流程。

2. 跑真实 Benchmark（以 LAB 法律任务为例）：

需要 Node.js 20+、Google Cloud CLI，LAB 还需要 Pandoc 和 Poppler。

cp .env.example .env   # 填入 Vertex AI 项目与模型 IDgcloud auth application-default loginharness2-setup labharness2-check --bench labharness2 --bench lab --k 1 --mode parallel \  --only-domains antitrust-competition --max-tasks 1harness2-judge --bench lab --k 1 --mode parallelharness2-report --bench lab --k 1 --mode parallel

几个实用参数：

--mode sequential：切换为顺序递归；
--substrate cx：执行器从默认的 OpenCode 切换为 Codex；
--dry-run：只预览任务选择，不调用模型，先算清楚要跑多少；
评测和报告必须与优化阶段使用相同的 Benchmark、执行器、子集、--k、--mode 和随机种子。

运行结果保存在 runs/ 目录下，包含任务摘要、交付物、被采纳的 Harness、反思笔记和评测结果。建议重点看“被采纳的 Harness”和“反思笔记”，这是你理解它到底学到了什么的最好材料，也可以直接作为人工调优的参考。

八、判断：Harness 工程正在从“手艺”变成“系统”

最后说三个判断。

第一，竞争焦点正在从“用哪个模型”转向“Harness 有多好”。DeepMind 的 AutoHarness 研究里，小模型加自动合成的 Harness，已经能在大量游戏环境里胜过不带 Harness 的大模型。模型会趋同，Harness 才是企业自己的护城河。

第二，工程师的角色正在上移。未来你不再是一条条去改提示词的人，而是去设计“让 Agent 学会改提示词”的那套系统：Trace 体系、评测体系、权限体系、经验库治理。这正是 AI 原生研发体系里 Harness 工程与 Loop 工程要解决的问题。

第三，Harness² 现阶段是研究项目，不是生产系统。官方明确它不是谷歌正式支持的产品。它最大的价值不是“拿来就用”，而是给出了一个在没有标准答案的情况下，依然能做严谨改进的方法论：对照实验加证据驱动加经验沉淀。这套方法论，今天就可以搬进你的 Agent 工程体系里。

模型在变，任务在变，Harness 必须跟着变。能自己变的 Harness，才是 AI 原生时代的标配。

如果你对企业级 AI 原生研发体系（Skills、SDD、Harness、Loop、知识飞轮、评测、治理度量）感兴趣，去 AITutor 领取福利。

AITutor 福利：AITutor 每个人的 AI 原生学习伙伴，业界最丰富 AI 实践和案例，4500+ 门多模态 AI 课程、7×24 小时 AI 导师已全面开放，快来免费体验吧。

打开 AITutor，新一代 AI 原生学习伙伴：www.aiaitutor.com
在首页输入「你想学习的 AI 知识」，就能看到更详细、更丰富的案例
包含图文、视频、播客、闪卡、代码、测验等 9 种学习模态

扫码直达：

PS：AI 落地点击预约直播。

九、加我微信

扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇

加星标★，不错过每一次更新！

⬇戳”阅读原文“，立即体验 AITutor

前往微信阅读全文

内容来自公众号，可前往微信查看原文。