模型不动，只改外壳：Google Research 开源的 Harness² 是怎么让 Agent 自己变好的
Google Research 开源 Harness²：模型权重不动，用 Propose–Probe–Compose 两层递归，让 Agent 在没有标准答案的任务上自己改进提示词、工具与记忆这层“外壳”。
同一个模型，为什么表现不一样
用过几个 AI 编程工具的同学，可能有过这样的体会。
同一个模型，放进这个工具里很聪明，放进那个工具里就有点笨。
模型没变，变的是什么？
变的是模型外面那一层东西：系统提示词怎么写，给了哪些工具，记不记得之前的事，有没有现成的技能可以调用，任务怎么拆分、怎么编排。
这一层东西，英文叫做 harness。
harness 的原意是马具，就是套在马身上、让马能拉车的那一套挽具。马的力气是天生的，但是没有挽具，它拉不了车。
大模型也是这样。模型决定了力气有多大，harness 决定了这股力气能不能用到活上。
所以，想让 Agent 变强，除了换一个更强的模型，还有一条路：把 harness 调好。
问题是，调 harness 是一件苦差事。
本周，我看到 Google Research 的一个开源项目 Harness²，它想把这件苦差事交给 Agent 自己来做。
Harness² 是什么
先说事实。
这个仓库叫 google-research/harness2，2026 年 10 月 6 日创建，采用 Apache 2.0 许可证。
配套的论文编号是 arXiv 2610.14224，作者来自 Google Cloud AI Research 和西北大学。
需要注意的是，仓库的 README 写明了，它"不是 Google 官方支持的产品"。所以，它更接近一个研究项目，而不是一个可以放心依赖的商业服务。
论文给了两个定义，我觉得值得记住。
（1）harness，就是模型外面那套让它能当 Agent 的系统，包括提示词、工具、记忆、技能、编排等等。
（2）harnessing，就是优化这套系统的过程。
Harness² 做的事情，用一句话说，就是模型权重一点不动，让 Agent 自己去改自己的 harness。
据 mlllm.io 的报道，它可以改的组件包括系统提示词、护栏、记忆、工具说明、子 Agent、skills、脚本和插件。
没有标准答案，怎么判断改得好不好
这是我读这个项目时，最好奇的一个问题。
通常，优化一个东西，你得知道什么是"好"。
比如做数学题，有标准答案，对一下就知道。但是，很多真实任务没有标准答案----写一份调研报告、整理一个项目、回复一封复杂的邮件，谁来打分？
Harness² 的办法是：不需要标准答案（论文里叫 ground-truth 反馈），而是比较几次执行的行为差异。
它把这个过程叫做 Propose–Probe–Compose，可以翻译成"提议----试跑----合成"。
1、提议（Propose）：先提出若干个 harness 修改方案。
2、试跑（Probe）：在同一个任务上，用这些方案分别跑一遍，对比效果。
3、合成（Compose）：根据几次执行在行为上的差异，合成一个新的 harness。
打个比方，这有点像厨师试菜。
没有人告诉你这道菜的"标准答案"，但你可以同一道菜做几个版本，这个多放点盐，那个火候大一点，然后对比尝一尝，把各个版本里做得好的地方合在一起，成为下一版菜谱。
（这个比方是我自己的理解，论文的具体做法以原文为准。）
两层递归
项目名字里的"平方"，我的理解是指它有两层递归。
第一层是任务级递归。 就是上面说的提议、试跑、合成，在单个任务上反复改进 harness。
第二层是 harness 级递归。 每个任务最后采纳的 harness，以及有证据支撑的经验，会被存进一个持续存在的"改进 harness"里。这是一个按领域划分的库，用来指导以后的任务。
也就是说，第一层是"这道菜怎么做得更好"，第二层是"把每道菜的心得记进菜谱本，下次做别的菜也能参考"。
任务级递归又分成两种模式。
（1）并行递归：一次提出 k 个通用候选和 k 个领域候选，全部试跑，再做 k 次独立合成。
（2）顺序递归：连续跑 k 次"提议----试跑----合成"，每一次都带上上一次的结果。
前者像同时开几个灶台，后者像一道菜连续改几遍。
效果怎么样
执行器方面，它支持 OpenCode 和 Codex。基准测试方面，它支持 JobBench、LAB 和 WorkBuddy-Bench。
下面是作者自己报告的结果。
只做一步改进，就让 GLM-5 和 Gemini 3.5 Flash 都超过了各自的基础 harness。
具体来说，WorkBuddy-Bench 最多提高 11.5 分，JobBench 最多提高 4.5 分，LAB 的部分通过率最多提高 11.8 个百分点。
论文还说，加大任务级递归的预算，成绩还会继续上涨。
大家看到这些数字，先别急着兴奋。我觉得，有几点必须说清楚。
1、"最多"是最好的情况，不是平均值。
2、论文没有公开方差和置信区间。
3、这些基准都是作者自己跑的，目前还没有独立复现。
4、试跑这一步，需要把同一个任务多跑几遍。成本是多少、延迟有多长，项目没有公布。
5、论文作者自己也承认，这种对比信号比较弱，不保证结果一定正确。
第 4 点尤其值得注意。
不需要标准答案，听上去很省事，但代价是要多跑几遍。省下的是人工打分的功夫，花出去的是 Token 和时间。 这笔账到底划不划算，要看你的任务（这是我的推断，项目没有给出成本数据）。
怎么上手
这个项目用 Python 3.12 和 uv。
按照仓库说明安装以后，可以先跑一下演示。
harness2-demo --output runs/demo --k 2
这里的 --k 2，就是上面说的 k 取 2。
如果要跑基准测试，需要单独配置，还要准备模型的凭据。SETUP.md 里提到，可以用 Vertex 上的 Claude 或 Gemini 来做 improver，也就是负责改 harness 的那个模型。
实验的细节，可以看仓库里的 EXPERIMENTS.md。
GitHub 上，这个项目在搜索时大约有 5,000 个 star（这个读数会变）。
我的看法
过去一段时间，大家比较的往往是模型：谁的参数多，谁的跑分高。
但是，真正用 Agent 干活的人都知道，模型只是发动机，harness 才是整辆车。很多时候，调好一个 harness 带来的提升，不一定比换一个模型小。
Harness² 有意思的地方在于，它把"调 harness"这件事，从工程师的手工活，变成了 Agent 的自动化流程，而且不依赖标准答案。
我觉得，下面这些人会特别用得上。
首先是自己搭 Agent 的开发者，手上的任务五花八门，根本没有现成的评测集。
其次是用开源模型的人。模型本身改不动，或者不想花钱微调，那么改 harness 就是成本最低的一条路。
当然，它还是一个研究项目，结论还需要更多人复现。
如果你正在为自己的 Agent 发愁，又没有现成的评测标准，可以试试它。
（完）
来源：GitHub：google-research/harness2；论文 arXiv 2610.14224；EXPERIMENTS.md；mlllm.io。README 写明它不是 Google 官方支持的产品；全部基准结果为作者自报，“最多”为最好情况，未公开方差，未独立复现；可修改组件清单出自 mlllm.io 报道。