本文来自微信公众号： InfoQ ，作者：褚杏娟，原文标题：《谷歌开源Harness，支持 OpenCode 和 Codex：国内开发者接入Jev实测“真行”》
谷歌研究团队开源了一套名为Harness²的智能体框架，试图让AI Agent在不修改模型权重的情况下，通过持续调整系统提示词、记忆、工具指导、skill、子智能体等外部组件，实现递归式能力提升。
目前，Harness²已在GitHub以Apache 2.0协议开源，支持OpenCode和Codex，默认使用OpenCode，也可以切换至Codex。Google Research同时强调，Harness²仍属于研究项目，并非谷歌官方支持的产品。
GitHub地址：https://github.com/google-research/harness2
团队将这套可修改的Harness拆成8类组件，包括系统提示词、护栏、记忆、工具指导、子智能体、Skills、脚本和插件。这些组件共同决定Agent如何构建上下文、调用工具、委派任务，以及如何在多轮工具调用中完成工作。
国内开发者Joseph Zhou称，将Harness²接入Jev 1.14后，在不调整模型权重的情况下大幅提升了视觉任务表现。按照其说法，底层系统会调整自身提示词、构建执行能力并提炼经验。
不知道标准答案，也要改进自己
Harness²全称为“面向开放世界的递归智能体Harness（Recursive Agent Harnessing for an Open World）”。
它最核心的设计，是两层递归机制。第一层发生在单个任务内的“任务级递归”。当Agent遇到一个Harness设计阶段没有见过的新任务时，系统不会完全依赖预先写好的固定策略，而是执行一轮“提出—探测—组合”：先生成多个Harness修改方案，让不同版本实际执行同一个任务，再观察它们产生的行为差异，最后重新组合出一套更合适的Harness。
特别的是，Harness²并不要求任务一定存在明确的标准答案。
许多自动优化方法依赖评测集、奖励信号或真实标准验证器来判断一次修改是否更好。但真实企业环境中的大量任务并不存在唯一答案，甚至可能在Agent上线之前从未出现过。Harness²因此更多通过实际执行观察修改带来的行为差异，采用有执行证据支持的修改，再将经验用于后续任务。
第二层则发生在任务之间的“Harnessing级递归”。
Harness²不会在一个任务结束后把刚刚得到的经验全部丢掉，而是维护一个持续存在的Improvement Harness，将此前采用过的Harness方案以及有执行证据支持的经验保存下来，用于指导之后的优化。
由此，可以形成一个闭环：Agent面对任务、修改执行方式、实际运行验证修改结果、保留有效经验，再利用这些经验指导下一轮Harness调整。
Google Research已经在JobBench、LAB和WorkBuddy-Bench三类专业任务Benchmark，以及4种“模型—Harness”配置上测试Harness²，使用的基础模型包括GLM-5和Gemini 3.5 Flash。
结果显示，仅进行一步Harness²优化，在模型权重保持不变的情况下，WorkBuddy-Bench成绩最高提升11.5分，JobBench最高提升4.5分，LAB部分通过率最高提高11.8个百分点。继续增加任务级递归预算后，性能还会进一步提升。
Harness²同时提供并行和顺序两种递归方式。前者同时探索多套Harness，更偏向“搜索得更宽”；后者把上一轮优化结果和执行证据带入下一轮，更偏向“优化得更深”。
但这种提升并不是免费的。每增加一轮递归，都意味着为同一个任务运行更多候选Agent和模型调用，本质上是在用更多测试时计算换取更高成功率。
另外，Harness²当前executor默认网络访问不受限制，而且Codex executor会关闭sandbox。官方提醒，公开Benchmark的评分细则或答案可能通过互联网获取，因此正式评测需要另外限制网络访问。
“Harness真的很难做！”
“Harness真的很难做！”长期参与Harness开发、并与多支生产团队合作的工程师Viv感叹道。
Harness并不是一层可以脱离模型单独设计的通用软件。Viv将这一点概括为“模型-Harness-任务匹配”。
在他看来，Harness的作用既是控制模型行为，也是放大模型已有能力。钩子、控制提示词、自动上下文管理等机制，本质上都在帮助模型把原生能力更稳定地用于某类具体任务。
不同模型适合的工具形态、提示词方式以及问题拆解方式也并不相同。一套针对Claude优化的上下文管理和工具策略，未必适合Gemini；Codex中有效的Agent Loop，也未必可以直接迁移到GLM或Qwen。这使Harness很难出现完全独立于模型的“统一最优解”。
此外，Harness很大程度上是上下文工程的交付机制。对于大模型而言，上下文窗口就是计算边界，因此Harness最重要的职责之一，就是让每个子任务能够方便地建立并维持一个干净的上下文。
与此同时，Harness的实际效果又很难在上线之前准确预测。“凭感觉当然很好，但如果你只是‘凭感觉’做Harness，那基本等于主动放弃了一部分性能。”
在生产环境中，开发者需要持续观察任务通过率、Token消耗和执行轨迹，定位Agent究竟在哪里失败，再针对具体组件进行修改。Viv将Eval视为当前Agent时代的一种“训练数据”：Harness构建本身就是不断收集Trace、建立评估目标和实验的过程。
Viv目前尤其关注一条循环路径：Harness Engineering→Post-Training→Harness Engineering，即先通过Harness找到模型在真实任务中的缺陷，再由后训练吸收一部分能力，模型升级后又重新调整Harness。
而今年业内还越来越多地开始探索AutoHarness，即把Harness工程本身的迭代交给Agent，要解决的本质上是Harness工程无法跟上模型和任务变化的问题。
学术届在这一方向上有了不少成果。比如，Self-Harness，把优化者收回到Agent自身：不再依赖一个更强的外部模型，而是让Agent从自己的执行Trace中识别失败模式，提出最小化Harness修改，再通过回归测试决定是否接受。
Adaptive Auto-Harness则针对真实任务不断变化的问题，不再维护一个持续被反复修改的唯一Harness，而是建立Harness Tree，根据任务动态选择不同Harness，并保留人工干预入口。研究团队指出，在开放任务流中，单一Harness反复更新后可能反而出现性能下降。
另一条Continual Harness路线，则尝试让Agent在一次持续运行过程中直接修改自己的提示词、子智能体、Skills和记忆，而不需要重置任务。它最初来自长期游戏Agent的实践，随后进一步发展出模型和Harness相互改进的闭环。
谷歌开源的Harness²则把问题推进到更为开放的层面：系统不要求任务一定存在标准答案，而是通过不同Harness执行同一个任务产生的行为差异进行“提出—探测—组合”，再把有证据支持的经验写入长期Improvement Harness。
Eval、回滚和成本问题
但是现实问题是：如果Agent可以自动修改AGENTS.md、Skills、Tools甚至整个执行逻辑，它怎么证明自己真的变好了？
一种正在形成的工程思路，是把代码仓库中的真实任务、PR和故障变成可评分任务，让Agent完成任务后回看失败的工具调用、模糊文档、Prompt和缺失Skill，再提出Harness修改。
随之而来的问题是Eval应该评估什么？显然，只看最终答案是否正确已经不够。Agent可能仍然得到正确答案，但内部执行方式已经从高效文件检索退化成大规模递归扫描，带来更多Token、更高延迟和更高成本。因此，工具调用、Trace、Token消耗、延迟和成本都开始被纳入Harness Eval。
回归问题也因此变得重要。一次Benchmark平均成绩提升，并不能证明某些关键能力没有倒退。一些开发者开始维护专门的历史失败案例集，每次Harness或模型更新都首先重新运行这些任务，只要过去已经解决的问题再次出现，就阻止更新上线。新能力提升，并不一定等于系统整体进步。
安全边界则是另一个现实问题。如果AutoHarness只能修改System Prompt，风险还相对有限；如果允许它修改Tool、中间件、Shell、记忆和运行时逻辑，就意味着Agent实际上开始生成并执行新的程序。
A-Evolve的GitHub Issues中已经有开发者指出，由Proposer产生的harness.py可能在加载阶段直接执行模块级代码，而候选Harness的前置Gate仅进行compile()检查。这使沙箱、权限控制和代码审查成为AutoHarness必须面对的问题。
成本也是一个很大的问题。Harness²开源后，社区很快提出支持本地Benchmark、增加--max-usd成本上限，以及允许人工参与Harness选择和经验总结等需求。
原因并不复杂：每生成一个候选Harness，都可能意味着额外模型调用、完整任务执行以及回归测试。如果为了提高几个百分点的成功率，需要付出数十倍Token的搜索成本，“自我进化”在Benchmark上有效，并不代表生产环境一定划算。
与此同时，开发者们也开始反思Harness工程是否正在变得“过度”。
一名开发者曾分享自己用8个月、883次提交构建一套Agent Harness的经历。系统不断加入代码图、RAG、确定性编排、隔离Worker、崩溃恢复、模型路由、Replay、验证Gate、自我改进实验和Dashboard，最终维护Harness本身消耗的时间甚至超过了真正使用Agent。
因此，当前AutoHarness的演化方向并不只是不断给Agent增加组件，而是试图形成一套更完整的反馈循环：发现失败、理解失败、尝试修改、验证修改，并在修改没有收益时重新删除。
结束语
这个方向目前还很早期，社区也开源了一些相关软件。
比如，Prime Intellect在8月采用MIT协议开源的Prime Agent则进一步把“自我改进Harness”直接做进Agent产品。Prime Agent使用Continual Harness保存提示词、记忆、Skill和可复用子智能体等持久状态，Agent可以根据实际执行经验，对这些组件进行小幅、可追踪的修改。
还有NeoSigma开源的auto-harness，开发者给它一个Agent文件和Benchmark，Coding Agent会读取失败案例，自动修改System Prompt和Tools，再用自己维护的Eval Suite做回归检查。另一个开源项目kayba-ai/autoharness则不会要求开发者更换原来的Agent，而是接管候选修改、Benchmark、迭代和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/