背景：Agent 卡在外部组件，不是只缺模型
团队做专业任务 Agent 时，常见困境是：模型权重不能动，提示词、记忆、工具指导、子智能体却互相耦合，改一处就影响整条执行链。结果不是“模型不会”，而是上下文构建、工具调度、任务委派没有可复用调优机制。InfoQ 的报道 给出了一个可操作样本：谷歌研究团队把可修改的 Harness 拆成 8 类组件，并以 Apache 2.0 协议在 Harness² 仓库 开源。
量级上，公开测试显示：仅进行一步 Harness² 优化、模型权重保持不变，WorkBuddy-Bench 成绩最高提升 11.5 分，JobBench 最高提升 4.5 分，LAB 部分通过率最高提高 11.8 个百分点。这不是换模型的收益，而是改外部 Harness 的收益。另有社交平台 X 的博主 Josephzhou@openmys 称，将 Harness² 接入 Jev 1.14 后，在不调整模型权重的情况下，视觉任务表现大幅提升。
方案：拆组件、双后端、用执行证据递归
Harness² 的架构选择很明确：不做“一个大提示词包打天下”，而是把 Harness 拆成系统提示词、护栏、记忆、工具指导、子智能体、Skills、脚本和插件 8 类组件，分别控制上下文构建、工具调用和任务委派。这样做的取舍是：前期要维护更多组件，但定位失败点时不必在一整段提示词里猜。
后端上，它支持 OpenCode 和 Codex，默认使用 OpenCode，也可以切换至 Codex。为什么不一上来锁死单后端？因为不同模型适合的工具形态、提示词方式和任务拆解不同；一套针对某模型优化的工具策略，未必适合另一模型。Codex 中有效的 Agent Loop，也未必能直接迁移到 GLM 或 Qwen。先保留双后端，是为了做“模型—Harness—任务”匹配测试。
递归机制分任务内和任务间。任务内遇到新任务时，先生成多个 Harness 修改方案，让不同版本执行同一任务，观察行为差异，再组合出更合适的 Harness；任务间则保留 Improvement Harness，把有执行证据支持的方案和经验带入后续任务。它不要求任务一定有标准答案，而是用实际执行差异做判断。代价是测试时计算增加：每轮递归都意味着更多候选 Agent 和模型调用。
实现要点：先拉仓库，再跑基线与对照
不要先猜配置。先把仓库拉到本地，定位 OpenCode、Codex、executor、sandbox 和 Jev 相关文档与配置入口：
git clone https://github.com/google-research/harness2.git
cd harness2
git log --oneline | head
grep -RInE "OpenCode|Codex|executor|sandbox|Jev" . --exclude-dir=.git | head
接着按仓库说明先跑默认 OpenCode 基线，记录任务通过率、Token 消耗和执行轨迹；再切换 Codex 做对照，且一次只改 8 类组件中的一类。接入 Jev 1.14 时，按仓库 executor 文档配置模型服务，不改模型权重；公开信息只给到“视觉任务提升”，没有给出完整参数，不要照抄网上环境变量。
正式评测前先做隔离：Harness² 当前 executor 默认网络访问不受限制，Codex executor 会关闭 sandbox；公开 Benchmark 的评分细则或答案可能通过互联网获取。正式跑分必须限制网络访问，并在隔离环境中执行。递归预算从小开始：并行递归用于扩大搜索面，顺序递归用于把上一轮执行证据带入下一轮。
效果：公开数据与边界
| 测试项 | 改动前 | 一步 Harness² 优化后 |
|---|---|---|
| WorkBuddy-Bench | 原配置，模型权重不变 | 最高提升 11.5 分 |
| JobBench | 原配置，模型权重不变 | 最高提升 4.5 分 |
| LAB 部分通过率 | 原配置，模型权重不变 | 最高提高 11.8 个百分点 |
| Jev 1.14 视觉任务 | 接入前 | 公开称大幅提升，未给具体数值 |
这些结果来自 JobBench、LAB 和 WorkBuddy-Bench 三类专业任务 Benchmark，以及 4 种“模型—Harness”配置，基础模型包括 GLM-5 和 Gemini 3.5 Flash。注意“最高提升”不是平均值，也不是生产环境承诺；继续增加任务级递归预算后性能还会提升，但模型调用次数和 Token 消耗也会上升。Jev 1.14 的视觉任务收益目前只有定性说法，不能当成可复现分数。
复盘：最贵的教训是评测隔离
最贵的教训不是调参，而是沙箱和网络。Harness² 定位为研究原型而非生产产品；默认网络不受限、Codex executor 关闭 sandbox，会让公开评测存在答案泄漏风险。没有限网和隔离，分数再高也不能信。
第二个教训是别把 Harness 当通用层。Harness 的实际效果很难在上线前准确预测，生产里要持续看任务通过率、Token 消耗和执行轨迹，定位失败发生在哪个组件，再改对应组件。还能怎么改：把 Trace 和 Eval 当作迭代依据；在 8 类组件中优先改最影响失败的一类；用顺序递归保留执行证据，用并行递归扩大搜索；关注 Harness Engineering 到 Post-Training 再回到 Harness Engineering 的循环，以及 AutoHarness 的探索，但不要绕开隔离评测。