过去，开发者改进 Agent 的常见路径是更换模型或微调权重。Google Research 近期开源的 Harness² 提供另一种思路：在模型权重保持不变的情况下，通过递归优化围绕模型运行的“外壳”来提升任务表现。该项目在掘金“每日一个开源项目”系列第258期中被介绍，采用 Apache-2.0 协议，创建时间为 2026 年 10 月 6 日，目前已有 23,451 颗 Star 和 2,354 个 Fork。
把 Agent 外壳变成可编辑对象
所谓 Harness，是模型周边的一整套运行系统，包括提示词、工具、记忆、技能与编排逻辑等。Harness² 的出发点是：同一个模型放在不同外壳中，表现可能存在明显差异。过去这些外壳多依赖人工试错，而该项目试图把“改 Agent”变成对明确组件的编辑操作。
按照项目说明，模型外围被拆成八个可编辑组件，并按运行时角色分组。提示词、护栏、记忆、工具说明、子 Agent、技能、脚本、插件等都可以成为优化对象。这样一来，优化器修改的不是模型参数，而是这些可保存、可审阅、可复用的外部组件。对于无法微调的闭源模型，这种方式也具有现实意义。
没有标准答案，也能自我改进
Harness² 面向的是开放世界任务，即 Agent 可能遇到设计 Harness 时没有预料到的新任务。它的核心流程是 Propose–Probe–Compose：先提出改进方案，再在真实任务中执行探测，最后基于同一任务上不同执行结果的差异合成新的 Harness。
这一设计的关键在于，它不依赖标准答案，而是通过不同执行过程的对比来判断哪些变化值得保留。这使它更接近开放环境中的真实使用场景。但代价也很清楚：每一次探测都是一次真实 Agent 执行，费用与耗时都会随递归预算增加。
项目还提供了任务级递归机制。每个任务结束后，被采纳的 Harness 以及“有证据支持的经验教训”会写入持久的改进 Harness，用于指导后续任务。流程中的“经验反思器”负责完成这一步。与每个任务从零调整相比，这种机制试图让改进逐步累积。
对于想先理解流程的开发者，项目提供无需模型调用的演示命令 harness2-demo --output runs/demo --k 2。该演示会使用确定性的编辑器和真实的 Python 执行跑完两种递归模式。完整运行则要求更高，素材提到需要 Linux、Python 3.12 和 uv；涉及模型评测时，还需要 Node.js 20+、Google Cloud CLI 以及相关基准依赖。
效果、成本与安全边界同样重要
项目 README 称，在三个专业基准、四种模型—Harness 配置上，单个 Harness² 步骤就能让 GLM-5 和 Gemini 3.5 Flash 超过各自的基础 Harness，并说明增加任务级递归预算会带来进一步提升。支持的基准包括 JobBench、LAB 和 WorkBuddy-Bench，执行器支持 OpenCode 和 Codex，递归模式支持并行与顺序。
需要注意的是，评测强调可复现与防泄漏：评判和报告需要使用与优化运行相同的基准、执行器、子集、--k、--mode 和随机种子；基于模型的运行会产生 API 费用，建议从很小的任务选择开始。
项目也直接提示了风险：执行器网络访问默认不受限制，Codex 运行时沙箱关闭。公开基准的评分标准可能在网上查到，因此评测前需要按文档配置网络限制，避免 Agent 接触到基准答案和评分标准。对于一个会修改自身提示词、护栏、脚本和工具的 Agent，这些限制在真实环境中尤为关键。README 也声明这是研究代码，不是官方支持的产品，仓库有 163 个未关闭 Issue。
- 优化对象是 Agent 外壳，而不是模型权重。
- 改进依据来自同一任务上的执行对比，而非标准答案。
- 真实执行会带来 API 成本，网络与沙箱配置需要提前审视。
Harness² 的价值，不在于证明某一次评测提升有多高，而在于它把 Agent 优化从人工试错推向一种可记录、可重复的过程。对开发者来说，这提供了一个新的判断维度：在换模型、微调模型之外，系统性地优化外壳，可能同样是提高 Agent 能力的可行路径。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/google-research-kai-yuan-harness-bu-peng-mo-xing-quan-zhong
