谷歌开源Harness²框架支持OpenCode与Codex

谷歌研究团队开源了智能体框架Harness²，目标是在不改变模型权重的情况下，让Agent持续调整系统提示词、记忆、工具指导、Skills和子智能体等外部组件，逐步提升任务执行能力。项目采用Apache 2.0协议，默认使用OpenCode，也支持切换Codex；官方明确表示它目前仍是研究原型，并非面向生产环境的正式产品。

Harness²将可修改的Harness拆分为系统提示词、护栏、记忆、工具指导、子智能体、Skills、脚本和插件八类组件，分别参与上下文构建、工具调用、任务委派及多轮执行。国内开发者Joseph Zhou称，接入Jev 1.14后，视觉任务表现明显提升，系统能够自行调整提示词、组织执行能力并沉淀经验。

该框架包含两层递归机制。任务级递归会针对陌生任务提出多套Harness方案，实际运行后比较行为差异，再组合出更合适的方案，即使任务没有标准答案也能依据执行证据进行筛选。跨任务的Harnessing级递归则通过持续存在的Improvement Harness保存有效方案和经验，形成“修改—执行—验证—积累—再优化”的循环，并支持并行探索或顺序深化，但代价是更多模型调用和测试时计算。

Google Research在JobBench、LAB和WorkBuddy-Bench三类专业基准上，使用GLM-5与Gemini 3.5 Flash等模型测试了四种“模型—Harness”配置。仅进行一次优化，WorkBuddy-Bench最高提升11.5分，JobBench最高提升4.5分，LAB通过率最高增加11.8个百分点，增加任务级递归预算后仍可能继续提高。当前执行器默认不限制网络，Codex执行器还会关闭sandbox，因此评测时需要额外隔离网络，避免公开答案或评分规则被获取。

实践者指出，Harness不存在脱离模型和任务的统一最优解，适用于Claude的工具策略未必适合Gemini，Codex的Agent Loop也未必能直接迁移到GLM或Qwen。生产环境应持续观察通过率、Token消耗、延迟、成本和执行Trace，把Eval视为类似训练数据的反馈，并在Harness Engineering、Post-Training之间反复迭代。Self-Harness、Adaptive Auto-Harness和Continual Harness等研究也在探索让系统自我修改、按任务选择Harness或持续更新提示词与记忆。

自动修改AGENTS.md、工具、Shell、中间件或运行时逻辑会带来安全风险，因为Agent可能实际生成并执行新程序。相关实践已暴露模块加载阶段执行代码、仅用compile()做前置检查等问题，沙箱、权限管理和代码审查不可或缺。同时，候选Harness、完整任务执行和回归测试都会增加成本，社区因此建议加入本地Benchmark、--max-usd预算上限及人工选择机制。平均成绩提升也不能掩盖历史能力倒退，开发者需要维护失败案例集；如何避免Harness工程过度复杂，仍是落地前必须解决的问题。