谷歌开源 Harness²：不改模型权重，只改“外挂”，智能体就能自己变强

大多数人提升智能体能力的办法是换更强的模型。谷歌研究团队换了个思路：模型不动，只改它外面的那层“壳”。

一分钟速览

• 谷歌研究开源 Harness²，Apache 2.0 协议，代码在 GitHub
• 不改模型权重，通过调整提示词、记忆、工具指导等 8 类外部组件提升能力
• 默认支持 OpenCode，也可切换到 Codex
• 核心是任务级与跨任务两层递归，经验会沉淀到 Improvement Harness
• 官方强调这仍是研究项目，不是谷歌正式支持的产品

“壳”里到底有什么

Harness² 把可修改的部分拆成 8 类：系统提示词、护栏、记忆、工具指导、子智能体、Skills、脚本和插件。它们共同决定智能体如何构建上下文、调用工具、委派任务，以及如何在多轮工具调用中把活干完。

这个拆法本身就有价值。过去我们说“调提示词”，其实混在一起改了很多东西：角色设定、工具说明、失败重试策略、记忆写入规则。拆成组件之后，每一次修改都能定位到具体模块，也更容易比较哪个改动真的带来了行为差异。

两层递归

第一层是任务级递归。遇到没见过的任务时，系统不会完全依赖预先写好的固定策略，而是执行一轮“提出—探测—组合”：先生成多个 Harness 修改方案，让不同版本实际执行同一个任务，观察行为差异，再重新组合出一套更合适的方案。

第二层是跨任务的 Harnessing 级递归。一个任务结束后，经验不会被丢掉，而是存进持续存在的 Improvement Harness，指导之后的优化。由此形成闭环：面对任务、修改执行方式、实际运行验证、保留有证据支持的改动。

不要求标准答案

许多自动优化方法依赖评测集、奖励信号或标准验证器来判断改动好坏。但真实企业环境里的大量任务没有唯一答案，甚至在智能体上线前从未出现过。Harness² 因此更多依靠“执行证据”：不判断哪个方案更接近标准答案，而是看哪个方案在实际运行中产生了更好的行为。

这也是它和 Terminal-RSI 这类方法的分野。后者在可验证的沙盒里反复试错，追求通过率；前者在开放世界里工作，追求“下次做得更顺”。两种思路并不冲突，一个偏训练，一个偏运行时。

实测与局限

有开发者把 Harness² 接入 Jev 1.14，在不调整模型权重的情况下，视觉任务表现有明显提升。底层系统会自行调整提示词、构建执行能力并提炼经验。不过这些结果目前多来自社区实测，缺少大规模、跨任务的系统评测。

谷歌自己也划了边界：这是研究原型，不是生产产品。它更像一份“如何把上下文工程做成系统”的参考实现，而不是拿来即用的框架。对 Agent 开发者来说，最值得借鉴的是组件拆分和证据驱动的迭代方式，而不是照搬代码。

参考链接：google-research/harness2