一个模型权重都不动的框架，让GLM-5在编码任务上从58分涨到77分，让"弱模型+好harness"反超"强模型+普通harness"。
2026年10月8日，Google Research在GitHub上开源了一个名为 Harness² 的框架（github.com/google-research/harness2），同期发布了论文《Harness²: Recursive Agent Harnessing for an Open World》（arXiv: 2610.14224）。
上线不到三周，这个仓库已经拿到 18000+ star。
它做的事情用一句话概括：不动模型一个参数，让AI Agent的"外壳"自己越用越强。
什么是Harness
如果你一直在关注Agent开发，会发现行业的重心正在悄悄转移。
Harness，指的是模型之外、让模型能够作为Agent行动的那一整套系统：系统提示词、工具、记忆、技能、子Agent、编排逻辑等等。Harnessing，就是优化这套系统的过程。
这个概念其实你早就在接触了。Claude Code、OpenCode、Codex这些编程Agent，本质上就是不同厂商为同一批底层模型打造的不同harness。同一个模型，套上不同的harness，表现可以天差地别——这在今天的Agent圈已经是共识。
于是问题来了：harness是人工设计的。人写的harness，有天花板。
开放世界的两难
一个自然的想法是递归自我改进（Recursive Self-Improvement, RSI）：让Agent自己改自己的harness，越改越好。
但真要做，会撞上两堵墙：
第一，开放世界没有标准答案。 已有的自我改进系统，大多依赖基准测试分数或正确性验证来指导改进方向。但真实工作场景中的任务是设计harness时没见过的、新来的，没有ground truth，你怎么知道这次修改是变好了还是变糟了？
第二，改进过程太"任务特化"。 很多系统针对单个任务反复打磨，改出来的harness换个场景就失灵，经验无法积累和迁移。
Harness²就是冲着这两个问题来的。
核心方法：两级递归
Harness²的解法是把递归拆成两个互相咬合的层级，全程保持模型权重冻结。
第一级：任务级递归——"提议-探测-组合"
针对当前任务，用一个对比式的 Propose–Probe–Compose 三步来精炼harness：
Propose（提议）：先跑一次参考执行，目的是暴露当前harness的行为模式（注意，不是判断对错）。然后基于任务、当前harness、参考执行和历史，提出两个候选修改：
-
• 不变式候选（Invariant candidate）：针对可能跨领域复现的通用Agent缺陷，比如规划混乱、工具使用不当、上下文管理失控、委派失职； -
• 领域候选（Domain-specific candidate）：针对当前领域的知识、流程和约束。
Probe（探测）：把两个候选harness在完全相同的任务、相同的模型和环境配置下执行，与参考执行做对比，得到"行为对比"（behavioral contrast）——这个修改缓解了目标缺陷？没有变化？还是引入了退化？
Compose（组合）：综合所有执行证据，生成后继harness。这里的关键词是"选择性组合"——可以合并有证据支持的修改、修订互相冲突的编辑、只采纳某个候选、甚至保留原harness不动。每一个决策都必须绑定具体观察，而不是假设的分数增益。
这套机制的精妙之处在于：它完全不依赖正确性标签。它不问"这次执行对了没有"，只问"这次修改让Agent的行为发生了什么可观察的变化"。这就绕开了开放世界没有验证器的死结。
第二级：Harnessing级递归——让经验跨任务复利
任务级递归解决的是"当前这件事"，第二级递归解决的是"以后所有事"。
每个任务完成后，一个经验反思器（Experience Reflector）检视完整的改进记录，提炼经验教训——但有一条铁律：只有有执行对比证据支持的经验才会被保留。仅仅"最终选中了某个输出"不足以证明可迁移性，证据不足就不新增条目。
这些经验连同被采纳的harness一起，写入一个持久的 harness改进库（improvement library）。每个条目包含一份可执行的harness加一份EXPERIENCE.md（适用情形、经验、支持证据），并有索引供后续任务按需检索。
下一个任务来了，Agent依然从通用harness起步，但整个改进过程由更新后的库来引导。模型权重、阶段指令、决策规则全部固定，只有这个库在持续演化。
这就是"复利"：你今天在法务任务上踩的坑，明天在做表格任务时就能被绕开。
八块可编辑的积木
Harness²把harness分解为八个文件级组件，都是编辑器可以动刀的对象：
-
1. 系统提示词（System prompt） -
2. 护栏（Guardrails） -
3. 记忆（Memory） -
4. 技能（Skills） -
5. 工具指引（Tool guidance） -
6. 脚本（Scripts） -
7. 子Agent（Subagents） -
8. 中间件插件（Middleware plugin）
这套分解覆盖了上下文构建、工具接口、委派编排和工具循环内的行为控制，和当下主流Agent框架的架构高度对齐——这也是它敢自称"即插即用"的底气。
数字说话：一周期的提升
实验横跨三个专业基准、四种模型-harness配置：
-
• JobBench（职业工作，来自Job-Bench） -
• LAB（法务工作，来自Harvey） -
• WorkBuddy-Bench（办公/网页/代码，来自腾讯）
只做一次Propose–Probe–Compose（k=1），相比各自的初始harness：
|
|
|
|
|---|---|---|
|
|
+11.5 |
|
|
|
+4.5 |
|
|
|
+11.8pp |
|
把任务级递归预算加大（k=5并行递归），还能继续涨：WorkBuddy-Bench的编码子集从76.5提到80.8，且提升随k单调上升，没有出现多数自我改进系统的"越改越崩"。
几个值得咀嚼的细节：
弱模型获益更大。 GLM-5（相对较弱的执行模型）的提升幅度显著大于Gemini 3.5 Flash。更惊人的是，改进后的GLM-5+harness可以反超原始配置下的Gemini——一个好harness，能部分补偿模型能力差距。
差距被抹平。 在JobBench上，递归让不同初始harness之间的差距从3.0分缩到0.5分——无论你从哪个harness出发，最终都趋向相似的优良配置。
跨基准迁移成立。 用JobBench上积累的经验库去改进WorkBuddy-Bench的任务，依然能带来正收益；即使排除任务自身的条目，迁移增益依然存在。
每个部件都不可少。 消融实验显示，去掉经验库掉3.1分，去掉领域限定（scoping）掉2.9分，去掉组合步骤掉1.6分。而如果完全去掉参考执行和探测、直接让Agent自我精炼，效果不升反降——对比式证据正是这套方法成立的前提。
冷思考
几个需要留意的地方：
-
• "采纳"不等于"验证最优"。组合器选择的是有证据支持的修改，但行为对比不能验证正确性——执行随机性和模型的共同偏差都会污染证据。 -
• 有额外算力开销。探测候选意味着每个任务要多跑几次完整执行，并行模式的实际延迟取决于并发能力。 -
• 递归不保证收敛。个别配置下，递归反而扩大了不同初始harness间的差距。 -
• 项目README明确标注：这不是Google官方支持的产品。
写在最后
Harness²没有挑战"模型能力决定上限"这条铁律，但它提醒我们：在上限之下，模型实际发挥出几成，取决于我们给它套了什么。而现在，这部分工作也可以交给机器自己了。
当harness工程本身被递归自动化，Agent开发的下一轮竞争，可能不再是"谁家prompt写得好"，而是"谁家的改进循环转得更快"。
END
#agent #harness #google #RSI #GLM #CodingAgent
如果这篇文章对你有帮助，欢迎点赞、在看、转发