谷歌研究团队对外开源Harness²递归智能体框架，项目以Apache 2.0协议托管于GitHub，支持OpenCode、Codex，默认启用OpenCode，可按需切换，官方明确该项目属于研究原型，并非面向生产的正式商用产品。

整套框架拆解为八大核心组件：系统提示词、护栏、记忆、工具指导、子智能体、Skills、脚本、插件。这些组件共同管控Agent上下文构建、工具调用、任务委派、多轮执行全流程。国内开发者将Harness²接入Jev 1.14后发现，不改动底层模型权重，就可以显著改善视觉任务的处理效果，框架能够自主迭代提示词、沉淀执行经验，拓展模型实际能力。

Harness²最大创新在于双层递归机制，适配开放世界大量无标准答案的真实业务场景。第一层为任务级递归，当Agent遭遇从未见过的全新任务，不会拘泥于预设固定策略，执行“提出—探测—组合”流程：生成多套Harness修改方案，让不同版本Agent并行执行同一任务，对比行为差异，筛选重组出适配当前任务的执行方案。不同于传统优化手段依赖标准答案、奖励信号做判断，Harness²依靠真实执行行为的差异作为优化依据，适配企业大量无标准答案的未知任务。

第二层是Harnessing级递归。框架设立持久化的Improvement Harness，任务结束后留存经过验证的优化方案与实践经验，沉淀为知识库反哺后续任务优化。由此形成完整闭环：接收任务→调整执行组件→实际运行验证改动效果→沉淀有效经验→指导下一轮迭代优化。

官方基于GLM‑5、Gemini 3.5 Flash等模型，在JobBench、LAB、WorkBuddy‑Bench三类基准上完成验证。仅一轮Harness²优化，WorkBuddy‑Bench最高提升11.5分，JobBench最高上涨4.5分，LAB任务通过率最高提升11.8个百分点；增加递归预算后性能还能继续走高。框架提供并行递归与顺序递归两种模式：并行模式同时探索多套方案，拓宽搜索范围；顺序模式继承上一轮执行证据，深度打磨单套策略。但性能提升存在代价，递归轮次越多，需要启动更多候选Agent、消耗更多模型调用，本质是以测试阶段计算资源换取任务成功率。同时官方提示，框架默认网络访问无限制，Codex执行器会关闭沙箱，正式评测需要做好网络限制，避免直接抓取公开题库答案干扰结果。

行业实践也点明，Harness工程本身具备极高复杂度，不存在脱离模型的通用最优解。业内提出“模型‑Harness‑任务匹配”理念：Harness的价值是约束模型行为、放大模型原生能力，提示词策略、工具调用逻辑、任务拆解方式高度绑定底层大模型。针对Claude调优的Harness策略，迁移到Gemini、GLM、Qwen未必生效。Harness本质是上下文工程的落地载体，核心工作之一就是维护干净可控的任务上下文窗口。

Harness的效果很难上线前预判，开发者不能仅凭主观经验调试。生产环境中，需要持续观测任务通过率、Token消耗、执行轨迹，定位Agent失败节点再针对性修改。评估Trace执行日志，已经成为Agent时代重要的“训练数据”。业内还形成一条循环思路：Harness工程→模型后训练→Harness再调优，借助Harness暴露真实业务缺陷，反馈给模型后训练环节，模型迭代完成之后再重新适配Harness组件。

为解决Harness迭代跟不上模型与业务变化的痛点，**AutoHarness（自动Harness工程）**成为重要研究方向。学术界衍生多条技术路线：Self‑Harness让Agent基于自身执行Trace识别失败，自主生成最小改动方案；Adaptive Auto‑Harness构建Harness Tree树结构，根据任务动态选用不同配置，规避单一Harness反复更新后性能退化的风险；Continual Harness支持Agent在持续运行过程中直接修改提示词、技能库，无需重置任务。而谷歌Harness²进一步拓展边界，在没有标准答案的开放任务下完成方案探测与经验沉淀。

不过AutoHarness落地生产，还要面对评估、回归、安全、成本四大现实难题。

第一是评估体系重构。只看最终输出对错已经远远不够，Agent可能输出正确结果，但内部执行路径低效，带来Token暴涨、延迟升高。因此工具调用轨迹、Token消耗、延迟、成本都需要纳入评估指标。

第二是回归校验。基准测试分数提升，不代表原有能力没有受损。开发者需要维护历史失败案例库，每次更新Harness或者模型，都要重跑历史用例，一旦旧问题复现就阻止版本上线，新能力增益不能掩盖能力倒退。

第三是安全风险。如果AutoHarness仅修改系统提示词风险有限，一旦开放工具、Shell、运行逻辑修改权限，Agent就能够生成执行新代码。现有项目已经暴露出沙箱校验不足的隐患，沙箱隔离、权限管控、代码审查是不可跳过的环节。

第四是成本约束。每生成一套候选Harness，都伴随模型调用、完整任务执行、回归测试开销。Benchmark上的性能提升，如果需要数十倍的Token消耗作为代价，在真实业务中就失去落地价值。社区也提出增加成本上限、引入人工参与方案筛选等诉求。

同时行业也开始反思Harness过度工程化问题：有开发者耗费8个月、883次提交迭代Agent框架，叠加大量组件之后，维护框架本身的工作量甚至超过使用Agent解决业务问题。新一代AutoHarness追求的不是无限堆叠组件，而是完整反馈闭环：识别失败、解析根因、尝试改动、验证效果，无收益的修改及时回滚删除。

目前整个赛道尚处于早期阶段，社区涌现多款开源项目。Prime Agent将自我改进能力内置Agent，依靠Continual Harness持久保存提示词、技能、子智能体，支持可追溯的小幅修改；auto‑harness读取失败样例自动优化提示词与工具，配套回归测试套件；kayba‑ai/autoharness不侵入原有Agent，接管候选方案管理、基准迭代，兼容多种代码生成器。整体来看，借助外围框架实现Agent能力增强已经成为重要方向，但距离大规模生产落地，仍要平衡性能、成本、安全三者之间的关系。