Google 开源 Harness²：不改模型权重，靠递归改写 Agent 外围组件提升表现
来源MarkTechPost查看原文
速览
- 不改权重、只改 harness，单步即可带来最高 11.5 分提升
- 用行为对比替代标准答案标签，瞄准无验证器的开放任务
- 8 个组件各对应一个文件，编辑器可直接改写
- 经验库跨任务积累，但每个新任务仍从基线 harness 重启
- 弱模型受益更大，GLM-5 单步后在 WorkBuddy 反超基线 Gemini
- 代价是每任务多跑若干次，且需自行做沙箱隔离
- 在 LAB 上未超过 Meta-Harness，优势并非全面
Google Cloud AI Research 与 Northwestern 合作开源了 Harness²（版本 0.1.0），这是一个递归式 agent harnessing 框架，思路是不动模型权重，只优化模型外围的 harness——包括 prompt、工具、记忆、技能与编排逻辑。框架把 harness 拆成 8 个可编辑组件，每个组件对应一个文件，由编辑器在任务执行过程中改写。方法分两层递归：任务级用 Propose、Probe、Compose 三步，先跑一遍基线 harness，再提出 invariant 与 domain 两个候选，在同一任务上分别运行，对比轨迹后只保留有行为证据支持的改动；harnessing 级则在每个任务结束后由 reflector 把采纳的 harness 和一份 EXPERIENCE.md 经验文件存入改进库，指导后续任务的提案，但每个新任务仍从基线 harness 起步。研究团队在 WorkBuddy-Bench、JobBench 和 Harvey 的 LAB 三个基准上测试，执行器为 Gemini 3.5 Flash 与 GLM-5，分别跑在 OpenCode 和 Codex 下，默认编辑器是 Claude Opus 4.8，结果取 3 次运行均值。单步改进（k=1）在全部 4 种模型与 harness 组合、全部 3 个基准上都有提升：最好的是 GLM-5 在 OpenCode 下的 WorkBuddy-Bench，从 64.2 升到 75.7（+11.5 分）；最差的是 GLM-5 在 Codex 下的 JobBench，从 23.6 升到 24.8（+1.2 分）。较弱执行器收益更大，单步之后 GLM-5 在 WorkBuddy-Bench 上反超了基线 Gemini 3.5 Flash。k=5 的并行递归把 OpenCode 下的 Gemini 推到 WorkBuddy 的 80.8。代码以 Apache-2.0 许可开源，运行环境为 Linux、Python 3.12 或 3.13 加 uv，模型调用通过 Vertex AI。
关键事实
- Harness² 是框架而非模型，版本 0.1.0，训练参数为 0，暴露 8 个可编辑 harness 组件
- 8 个组件分别是 System prompt、Guardrails、Memory、Tool guidance、Subagents、Skills、Scripts、Plugins（middleware），比此前 Agentic Harness Engineering 的 7 文件划分多 1 个
- 单步改进（k=1）在 4 种模型与 harness 组合、3 个基准上全部提升
- 最佳结果：GLM-5 在 OpenCode 下 WorkBuddy-Bench 从 64.2 升至 75.7，+11.5 分
- 最差结果：GLM-5 在 Codex 下 JobBench 从 23.6 升至 24.8，仅 +1.2 分
- k=5 并行递归让 OpenCode 下的 Gemini 在 WorkBuddy 达到 80.8
本站视角
最直接的受益者是那些被锁定在某个闭源模型 API 上、又无法自己微调的中小团队和国内 Agent 开发者：如果 harness 层面的自动改写真能稳定带来 10 分左右的提升，那么「换更强的模型」就不再是提升产品体验的唯一路径，工程侧的投入回报被重新定价。对做 coding agent、法律与办公类垂直 agent 的团队，8 组件文件化的设计也提供了一个可复用的工程接口范式，比单纯追论文更有落地价值。我们的判断是：这是一次方法学上的实质进展，但不宜过度解读。理由有三。第一，提升幅度与执行器强弱强相关，GLM-5 涨 11.5 分而 Gemini 只涨 5.1 分，说明它很大程度上是在补 harness 与模型之间的错配，模型本身越强、基线 harness 越贴合，收益越薄。第二，跨方法对比里 Harness² 并非全面领先，LAB Partial 上 75.6 低于 Meta-Harness 的 76.5，而所有对比分数都是 Harness² 论文自己测的，其他方法并未在这些基准上自报成绩，这种单一来源的横评需要打折看待。第三，成本被轻描淡写：k=1 就要每任务多跑两次候选加一次最终执行，k=5 的 80.8 分背后是数倍推理开销，对按 token 计费的 API 用户，性价比是否成立要看具体业务。需要观察的是：这套递归改写在小任务、强时效场景下会不会因为多跑几轮而拖慢交付；以及 Google 以 Apache-2.0 开源、却把模型调用绑在 Vertex AI 上，这种「框架开源、算力导流」的组合会不会成为后续同类项目的默认姿势。
背景与影响
Agent 系统的能力长期被默认等同于底层模型的能力，harness（prompt、工具定义、记忆、编排）通常靠人工调参，换模型就得重调。Harness² 把 harness 本身当成可优化对象，且刻意避开需要标注数据或测试用例的自改进路线——多数此类方法依赖 verifier 判断答案对错，在开放世界任务里不成立。它用同一任务上不同 harness 变体的轨迹差异作为信号，属于「无标签自改进」这一研究方向。对使用闭源 API 的团队来说，这意味着不换模型、不加训练成本也可能拿到性能提升；对模型厂商而言，则说明「模型 + harness」的打包体验可能比裸模型分数更能决定实际表现。需要注意的是，这套方法每个任务要多跑基线、两个候选和最终执行，推理成本成倍上升，原文也明确提示要自行做沙箱隔离。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。