先看证据

可编辑8类脚手架组件关键事实
+11.5分单步最大提升
GLM-5+OpenCode 64.2→75.7WorkBuddy
+1.2分JobBench最小提升
k=5并行使WorkBuddy再升2.9–3.9分关键事实
主结果覆盖3基准、4种配置,均值为3次运行关键事实

把机制串起来

输入先把素材压到可处理的规模

Agent的表现不只取决于模型权重,还取决于提示词、工具、记忆和编排等外围“脚手架”。测试时适应是模型在推理阶段调整行为;Harness²进一步让外部编辑器修改这些脚手架文件,但执行模型权重保持冻结。所谓“无验证器”指运行时不靠标准答案筛选修改,不代表论文评测时没有基准评分。

机制再把计算集中到关键步骤

每个新任务先由基础脚手架执行一次;编辑器再提出通用能力改动和领域专用改动两类候选,并在同一任务上试跑。合成器将候选轨迹与参考轨迹及产物对照,只采纳有行为证据支持的改动,也可以不改;这能减少纯凭编辑器直觉改配置,但轨迹更好不等于答案正确。任务结束后,反思器保存被采纳的脚手架和 EXPERIENCE.md 经验,供后续提案参考,而非把前题配置原样套给新题。并行预算 k 会扩展候选和合成次数,顺序预算 k 则连续迭代;调用成本随搜索增加,结果也可能受执行随机性影响。实验中执行模型与

结果最后落到可验证的工作结果

['适合任务重复出现、允许编辑器试跑的专业Agent', '先审查脚本与插件改动,再授予生产环境权限', '不要把轨迹变好当成正确性证明,仍需独立评测', '迁移到新领域前验证经验库,别直接复用旧配置']

优化对象从模型转向模型周围的系统

Google Cloud AI Research 开源了 Harness²,一套在部署时递归改进智能体运行脚手架的框架。它面向一种常见但棘手的情形:任务会在设计阶段之后才出现,运行时又没有标准答案可以直接告诉系统做得对不对。框架不训练模型,也不改权重,而是编辑提示词、工具和编排等外围文件。

这次变化值得技术负责人读,不是因为它证明模型可以靠自己变聪明,而是因为它把优化责任从单一模型扩展到了整套运行环境。很多智能体问题看起来像模型能力不足,实际也可能来自工具说明含糊、任务规划不稳,或交接流程设计不当。Harness²试图把这些因素变成可被修改、试跑和比较的对象。

把改动拆成提出、试跑与合成

Harness²把可编辑范围拆成八类组件:系统提示词、护栏、记忆、技能、工具指导、脚本、子智能体和中间件插件。它们覆盖了上下文如何构造、工具如何使用、任务如何委派,以及工具循环中的行为。这个拆分的工程含义是,改进不必被压缩成一段越来越长的系统提示词,而可以落到具体文件和职责上。

单个任务内部采用 Propose–Probe–Compose,也就是提出、试跑、合成。编辑器针对观察到的问题提出通用改动和领域专用改动,再让候选脚手架在同一任务上运行,最后比较执行轨迹与产物,只保留有行为证据支持的修改;如果没有足够依据,也可以保留原方案。这里的比较能帮助判断改动是否影响了行为,但不能证明结果正确。

分数上升是真实信号,但不是普遍承诺

论文在 WorkBuddy-Bench、JobBench 和法律任务基准 Harvey’s LAB 上测试了四种执行模型与脚手架组合,主要结果是单步递归,并报告三次运行的均值和标准差。读数里最醒目的是 GLM-5 配合 OpenCode:WorkBuddy-Bench 从 64.2 到 75.7,增加 11.5 分;在 LAB 的 Partial 指标上,则从 59.6 到 71.4,增加 11.8 个百分点。Gemini 3.5 Flash 配合 OpenCode 在 JobBench 上从 31.5 到 36.0,增加 4.5 分。

这些结果并非只挑出了一个成功组合:材料显示,四种配置在三项基准上的单步结果都改善了。但幅度差异提醒团队不要把“能优化”理解成“必然大幅提升”:GLM-5 配合 Codex 在 JobBench 上只从 23.6 到 24.8,增加 1.2 分。更弱的执行器有时获益更多,GLM-5 经一次改进后也超过了基线 Gemini 3.5 Flash 在 WorkBuddy-Bench 上的分数,但这仍是特定基准和配置下的观察。

跨任务积累经验,也引入新的成本

框架不只在一题里反复尝试。每个任务完成后,它会把采用过的脚手架和经验写入改进库,记录哪些做法曾在什么条件下有证据支持,供后续任务提出新候选时参考。关键区别在于,下一题仍从基础脚手架开始,而不是把上一题的定制版本原封不动套过去。这种设计试图积累经验,同时避免把一次性的改动误当成通用规则。

递归预算决定搜索规模。并行模式会同时探测多组通用和领域候选,再进行合成;顺序模式则连续执行多轮改进。论文报告,WorkBuddy-Bench 上把预算扩展到 k=5,相比单步还增加 2.9–3.9 分;JobBench 增加 3.0–4.2 分,LAB Partial 增加 2.6–6.7 个百分点。这些提升来自特定实验设置,预算变大也意味着更多模型调用和推理成本,不能据此推断每种工作负载都应使用最大搜索。

部署前先把证据边界和角色分清

一个容易混淆的地方是“没有标准答案”不等于“实验没有评分”。论文的目标是在运行时修改脚手架时不依赖标准答案或带标签的验证反馈;最终评估仍使用基准评分。另一个关键条件是角色分工:主实验里的 GLM-5 和 Gemini 3.5 Flash 是冻结权重的执行模型,默认由 Claude Opus 4.8 担任脚手架编辑器。因此,GLM-5 的分数提升不能被描述成 GLM-5 独自完成了整套自我改写。

研究团队也明确指出,执行随机性和模型共同偏差会影响轨迹比较,行为证据不能保证修改正确,更不能保证迁移到新任务。项目代码采用 Apache-2.0,但这不代表第三方代码、基准和数据集也都使用相同许可;仓库还对 WorkBuddy-Bench 的定制许可及欧盟使用地域限制作了说明。此外,仓库声明项目并非 Google 官方支持的产品。对技术负责人而言,较稳妥的做法是把 Harness²当作受控的脚手架搜索工具:在有明确成本预算、可审计改动和独立任务评估的范围内试用,而不是把它当作免验证的在线自我进化机制。