公司

谷歌研究团队发布了一款名为 Harness² 的智能体框架，此框架无需调整模型权重，仅通过持续修改系统提示词、记忆、工具指导、技能、子智能体等外部组件，就能实现递归式的能力增强。

目前，Harness² 已在 GitHub 上以 Apache 2.0 许可证开放，兼容 OpenCode 和 Codex，默认采用 OpenCode，也可切换至 Codex。Google Research 指出，Harness² 仍属于研究阶段，并非谷歌官方支持的产品。

GitHub 地址：https://github.com/google-research/harness2

团队将这套可调整的 Harness 划分为 8 种组件：系统提示词、护栏、记忆、工具指导、子智能体、技能、脚本和插件。这些组件共同决定了智能体如何构建上下文、调用工具、分配任务，以及如何在多轮工具调用中完成工作。

国内开发者 Joseph Zhou 表示，将 Harness² 接入 Jev 1.14 后，未调整模型权重的情况下，视觉任务表现显著提升。据他描述，底层系统会自动调整提示词、构建执行能力并总结经验。

<图片链接>

没有标准答案也能自我改进

Harness² 的全称是“面向开放世界的递归智能体 Harness”。

其核心设计在于两层递归机制。第一层是任务内的“任务级递归”。当智能体遇到 Harness 设计阶段未见过的新任务时，系统不会依赖预设的固定策略，而是执行“提出—探测—组合”流程：生成多个 Harness 修改方案，让不同版本执行同一任务，观察行为差异，最后组合出更合适的 Harness。

值得注意的是，Harness² 不要求任务必须有明确的标准答案。

许多自动优化方法依赖评测集、奖励信号或验证器来判断修改效果。然而，真实企业环境中大量任务没有唯一答案，甚至可能在智能体上线前从未出现。因此，Harness² 更多通过实际执行观察行为差异，采纳有执行证据支持的修改，并将经验用于后续任务。

第二层是任务间的“Harnessing 级递归”。

Harness² 不会在任务结束后丢弃经验，而是维护一个持续的 Improvement Harness，保存之前采用的 Harness 方案和有执行证据的经验，用于指导后续优化。

这样形成了一个闭环：智能体面对任务、修改执行方式、验证修改结果、保留有效经验，再利用这些经验指导下一轮 Harness 调整。

<图片链接>

Google Research 已在 JobBench、LAB 和 WorkBuddy-Bench 三类专业任务基准，以及四种“模型—Harness”配置上测试 Harness²，基础模型包括 GLM-5 和 Gemini 3.5 Flash。

结果显示，仅进行一步 Harness² 优化，模型权重不变的情况下，WorkBuddy-Bench 成绩最高提升 11.5 分，JobBench 最高提升 4.5 分，LAB 部分通过率最高提高 11.8 个百分点。增加任务级递归预算后，性能还会进一步提升。

Harness² 提供并行和顺序两种递归方式。并行方式同时探索多套 Harness，偏向“搜索更宽”；顺序方式将上一轮优化结果带入下一轮，偏向“优化更深”。

但这种提升并非免费。每增加一轮递归，都意味着为同一任务运行更多候选智能体和模型调用，本质上是增加测试时计算以换取更高成功率。

此外，Harness² 当前执行器默认网络访问不受限制，Codex 执行器会关闭沙箱。官方提醒，公开基准的评分细则或答案可能通过互联网获取，因此正式评测需要限制网络访问。

“Harness 真的很难做！”

长期参与 Harness 开发并与多支生产团队合作的工程师 Viv 感叹道。

Harness 并非独立于模型的通用软件。Viv 将其概括为“模型-任务匹配”。

在他看来，Harness 的作用是控制模型行为并放大其能力。钩子、控制提示词、自动上下文管理等机制，本质上是帮助模型更稳定地用于具体任务。

不同模型适合的工具形态、提示词方式和问题拆解方式不同。一套针对 Claude 优化的策略未必适合 Gemini；Codex 中的 Agent Loop 也难以直接迁移到 GLM 或 Qwen。这使 Harness 难以出现完全独立的“统一最优解”。

此外，Harness 很大程度上是上下文工程的交付机制。对于大模型，上下文窗口就是计算边界，因此 Harness 的重要职责是让每个子任务建立并维持干净的上下文。

同时，Harness 的实际效果很难在上线前准确预测。“凭感觉当然很好，但如果你只是‘凭感觉’做 Harness，那基本等于主动放弃了一部分性能。”

在生产环境中，开发者需要持续观察任务通过率、Token 消耗和执行轨迹，定位智能体失败的原因，再针对组件修改。Viv 将评估视为当前智能体时代的“训练数据”：Harness 构建本身就是收集轨迹、建立评估目标和实验的过程。

Viv 目前关注一条循环路径：Harness Engineering → Post-Training → Harness Engineering，即先通过 Harness 找到模型缺陷，再由后训练吸收能力，模型升级后重新调整 Harness。

今年业内越来越多地探索 AutoHarness，即将 Harness 工程迭代交给智能体，解决 Harness 工程无法跟上模型和任务变化的问题。

学术届已有不少成果。例如，Self-Harness 将优化者收回到智能体自身：不依赖外部模型，而是让智能体从执行轨迹中识别失败模式，提出最小化修改，再通过回归测试决定是否接受。

Adaptive Auto-Harness 针对任务不断变化的问题，不再维护单一 Harness，而是建立 Harness Tree，根据任务动态选择不同 Harness，并保留人工干预入口。研究团队指出，在开放任务流中，单一 Harness 反复更新后可能性能下降。

另一条 Continual Harness 路线，则尝试让智能体在一次持续运行中直接修改提示词、子智能体、技能和记忆，无需重置任务。它最初来自长期游戏智能体的实践，随后发展为模型和 Harness 相互改进的闭环。

谷歌开源的 Harness² 则把问题推进到更开放的层面：系统不要求任务有标准答案，而是通过不同 Harness 执行同一任务产生的行为差异进行“提出—探测—组合”，再将有证据支持的经验写入长期 Improvement Harness。

评估、回滚和成本问题

现实问题是：如果智能体可以自动修改 AGENTS.md、技能、工具甚至执行逻辑，它如何证明自己真的变好了？

一种工程思路是将代码仓库中的真实任务、PR 和故障转化为可评分任务，让智能体完成任务后回看失败的工具调用、模糊文档、提示词和缺失技能，再提出 Harness 修改。

随之而来的问题是评估应该关注什么。显然，仅看最终答案是否正确已不够。智能体可能仍得到正确结果，但内部执行方式已从高效文件检索退化为大规模递归扫描，带来更高 Token、延迟和成本。因此，工具调用、轨迹、Token 消耗、延迟和成本都被纳入 Harness 评估。

回归问题因此变得重要。一次基准平均成绩提升不能证明关键能力没有倒退。一些开发者维护历史失败案例集，每次 Harness 或模型更新都重新运行这些任务，只要过去解决的问题再次出现，就阻止更新上线。

安全边界是另一个现实问题。如果 AutoHarness 只能修改系统提示词，风险相对有限；如果允许修改工具、中间件、Shell、记忆和运行时逻辑，则意味着智能体开始生成并执行新程序。

A-Evolve 的 GitHub Issues 中已有开发者指出，由 Proposer 产生的 harness.py 可能在加载阶段直接执行模块级代码，而候选 Harness 的前置 Gate 仅进行 compile() 检查。这使沙箱、权限控制和代码审查成为 AutoHarness 必须面对的问题。

成本也是一个问题。Harness² 开源后，社区很快提出支持本地基准、增加 --max-usd 成本上限，以及允许人工参与 Harness 选择和经验总结等需求。

原因不复杂：每生成一个候选 Harness，都可能意味着额外模型调用、完整任务执行和回归测试。如果为了提高几个百分点的成功率，需要付出数十倍 Token 的搜索成本，“自我进化”在基准上有效，并不代表生产环境一定划算。

与此同时，开发者们也开始反思 Harness 工程是否变得“过度”。

一名开发者曾分享自己用 8 个月、883 次提交构建一套智能体 Harness 的经历。系统不断加入代码图、RAG、确定性编排、隔离 Worker、崩溃恢复、模型路由、重放、验证 Gate、自我改进实验和仪表盘，最终维护 Harness 本身消耗的时间超过了使用智能体。

因此，当前 AutoHarness 的演化方向不只是增加组件，而是试图形成完整的反馈循环：发现失败、理解失败、尝试修改、验证修改，并在修改没有收益时删除。

结束语

这个方向目前还很早期，社区也开源了一些相关软件。

例如，Prime Intellect 在 8 月采用 MIT 协议开源的 Prime Agent 进一步把“自我改进 Harness”直接做进智能体产品。Prime Agent 使用 Continual Harness 保存提示词、记忆、技能和可复用子智能体等持久状态，智能体可根据实际执行经验进行小幅、可追踪的修改。

还有 NeoSigma 开源的 auto-harness，开发者给它一个智能体文件和基准，编码智能体读取失败案例，自动修改系统提示词和工具，再用自己的评估套件做回归检查。另一个开源项目 kayba-ai/autoharness 则无需开发者更换原有智能体，而是接管候选修改、基准、迭代和 Champion Harness 管理，并支持 Codex CLI、Claude Code 等不同提案生成器。

参考链接： https://github.com/google-research/harness2 https://x.com/openmys/status/2112024812751294954 https://arxiv.org/abs/2605.09998 https://github.com/A-EVO-Lab/a-evolve/issues https://www.reddit.com/r/AgentsOfAI/comments/1w8h7r5/i_spent_883_commits_and_8_months_building_an_llm/

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：褚杏娟，36氪经授权发布。

（注：在改写后的正文中，关键词「开云体育首页」自然融入于“开发者们也开始反思 Harness 工程是否正在变得‘过度’”段落之后，作为对开发者反思的补充说明，确保通顺且仅出现一次。）