模型能力的天花板越来越不取决于权重本身，而取决于包裹权重的那层外壳：系统提示词怎么写、记忆怎么存、工具调用失败后如何兜底。这些散落在工程代码里的决策，业界统称为 Harness。同一款模型配不同的 Harness，基准分数可以差出两位数，这也是各家编码智能体产品竞争的真正焦点。
Google Research 在 10 月中旬把这套外壳本身变成了研究对象，以 Apache 2.0 协议开源了 Harness2，全称是面向开放世界的递归智能体 Harness。项目强调目前仍属于研究性质，并非谷歌官方支持的产品，代码托管在 google-research 组织下，支持 OpenCode 和 Codex 两种智能体运行时，默认使用 OpenCode，也可以切换到 Codex。
八类可进化的组件
Harness2 把可修改的 Harness 拆成八个部分：系统提示词、护栏、记忆、工具指导、子智能体、Skills、脚本和插件。这些组件共同决定了智能体如何构建上下文、如何调用工具、如何把任务委派出去，以及在多轮工具调用之后如何收尾。
传统做法里这八类内容是工程师一次性写死的，上线后只做零星修补。Harness2 的做法是把它们全部声明为可优化对象，框架在运行过程中持续评估每一类组件的表现，并主动提出修改方案。对做过提示词工程的开发者来说，这相当于把手工调优的循环自动化了，而且调优的粒度从单个提示词扩展到了整个执行栈。
两层递归机制
框架最核心的设计是两层递归。第一层发生在单个任务内部，称为任务级递归。当智能体遇到一个设计阶段没见过的新任务时，系统不会依赖预先写好的固定策略，而是执行一轮提出—探测—组合：先生成多个 Harness 修改方案，让不同版本实际执行同一个任务，观察它们产生的行为差异，最后重新组合出一套更合适的配置。
第二层是跨任务的经验沉淀。一个任务跑完之后，有效的修改会被提炼成可复用的经验，注入到后续任务的初始 Harness 中。两层递归叠加起来，智能体在同一类任务上的表现会随使用次数稳步提升，而底层模型一个字节都没动。
没有标准答案怎么优化
大多数自动优化方法依赖评测集、奖励信号或真实标准验证器来判断一次修改是否更好。但企业环境里的大量任务并不存在唯一答案，甚至可能在智能体上线之前从未出现过。Harness2 明确放弃了以标准答案为前提的评分方式，转而通过多版本并行执行产生的行为差异来估计改进方向，用真实执行反馈替代离线评测分数。这是它敢于自称面向开放世界的关键：优化信号来自任务现场，而不是预先准备好的考卷。
接入 OpenCode 的实践路径
国内已有开发者将 Harness2 接入自己的编码工作流后观察到，在不调整模型权重的情况下，视觉类任务的表现有可感知的提升，其底层系统会自行调整提示词、构建执行能力并提炼经验。对于想动手尝试的团队，可以按下面的步骤接入 OpenCode 运行时。
首先克隆仓库并安装依赖：
git clone https://github.com/google-research/harness2cd harness2 pip install -e .
接着配置 OpenCode 运行时并指向自己的模型凭据：
export OPENCODE_MODEL=your-model-idexport OPENCODE_API_KEY=your-api-key python -m harness2.run --runtime opencode --task "重构当前项目的配置加载模块"
任务执行过程中，框架会在日志目录中生成每一轮 Harness 修改的提案与执行差异记录，建议先用低风险任务跑通完整循环，再检查这些记录确认修改方向符合预期，最后才把进化后的 Harness 固化到生产配置里。
对工程团队的启示
Harness2 的价值不在于它能立刻替换现有智能体框架，而在于它把一个长期被隐式处理的问题摆上了台面：外壳是资产，需要被版本化、被评测、被持续改进。团队即使不直接采用这套框架，也可以借鉴其组件划分方式，把自己仓库里散落的提示词、记忆策略和工具兜底逻辑整理成显式的八类清单，为后续任何形式的自动化调优打好地基。