Google Harness2 将智能体自我改进开源，但验证仍是考验
Google 在报告称通过改变智能体周边软件、而非模型本身可带来最高 11.5 分的提升后，开源了 Google Harness2。这一区别构成了核心张力。该框架让智能体能够修订提示词、工具、记忆及其他运行指令，但它必须在没有已知正确答案的情况下评判这些修订。
该项目被作者称为 Harness²，来自与 Google Cloud AI Research 和 Northwestern University 有关联的研究人员。其代码与一篇发布于 2026 年 10 月 9 日的研究论文同期亮相，并采用 Apache 2.0 许可证。这次发布将一种研究方法转化为开发者可以检查、运行和修改的软件。
该项目也挑战了一个关于 AI 智能体的常见假设：更好的结果并不总是需要更新或更大的模型。它们也可以来自对 harness 的调整，即将语言模型变成可执行系统的软件和指令。
这一观点给固定的智能体框架带来了压力。OpenCode、Codex、Claude Code 及类似系统将模型与提示词、工具、记忆和编排机制结合起来。Google Harness2 提出了一个问题：这些周边组件在部署后是否应当保持固定。
答案的重要性不止体现在基准排名上。一个可自我编辑的 harness 可以适应陌生的法律、办公、网页和编程任务；它也可能保留错误假设、选择较弱的修订方案，或为得出答案消耗显著更多算力。
Google Harness2 改变冻结模型周边的软件
此次发布将递归改进从模型训练转移到了智能体运行时的八个可编辑部分。
AI 智能体不只是响应提示词的语言模型。它还依赖指令、可用工具、存储的上下文、委派规则，以及控制每项操作的软件。这些组件共同构成智能体的 harness。
Google Harness2 开放了八个可供修订的组件：系统提示词、护栏、记忆、工具指引、子智能体、技能、脚本和中间件插件。每个组件均以挂载到运行时中的文件形式呈现。底层模型权重保持冻结。
这种分离很重要。训练或微调模型需要专业基础设施、准备好的数据以及独立的部署流程。编辑提示词、技能或工具指令，则可以在智能体执行任务期间完成。
开源仓库将该方法打包为面向 Linux 的 Python 项目。它支持 Python 3.12、并行和顺序优化，以及与 OpenCode 和 Codex 执行器的集成。随附演示使用确定性的编辑器和本地 Python 执行，因此开发者无需模型凭据即可检查工作流程。
依赖模型的评估则需要更多基础设施。仓库说明需要 Node.js、Google Cloud 身份验证、通过 Vertex AI 获得模型访问权限，以及针对不同基准的依赖项。WorkBuddy-Bench 需要 Docker，而法律基准需要文档处理工具。
这一配置表明了项目当前的目标受众。这是供准备开展受控评估的团队使用的研究软件，而非可悄然升级所有智能体的消费者功能。发布提供了实验所需的机制，但采用者仍需准备任务、执行环境、评判器和运行限制。
该框架会让每个传入任务从一个共同的基础 harness 开始。它不会简单地将最新的任务专属配置带入下一项任务，而是暂时优化当前 harness，并在独立的改进库中记录可复用的经验。
这一决定针对的是自适应系统中的一个常见失败模式。帮助合同分析的指令，可能会损害电子表格任务的表现。若直接累积每一项成功编辑，harness 会变得愈发专门化，也更难以理解。
Harness² 转而尝试保留有关某项编辑为何有效的证据。未来任务可借鉴这些经验，而无需继承整个早期执行配置。
因此，该项目体现了两种形式的软件：一个 harness 负责执行工作，另一个 harness 则改进执行该工作的系统。正因这一第二层，作者将其方法称为递归智能体 harnessing，而不是普通的提示词优化。
对于已经手动维护智能体指令的开发者而言，此次发布将一种熟悉的工作流正式化。团队检查失败、修订指令、重新运行任务，并保留有用的方法。Google Harness2 将这一循环的大部分工作交给智能体，并将由此产生的修改记录为结构化工件。
Google Harness2 如何在没有正确答案的情况下优化智能体
其核心机制是在匹配条件下比较行为，而不是要求完美验证器识别正确输出。
该框架将其主要的任务级流程称为 Propose-Probe-Compose。提议者首先研究原始执行过程，并提出有针对性的 harness 修改。探针会使用这些候选修改重新运行同一任务。随后，组合器根据所得轨迹之间的差异所支持的证据来合并改动。
轨迹是模型响应、工具调用、观察结果和生成文件的记录序列。它为系统提供了比最终答案本身更多的证据。编辑器可以看到，某项修订是否找到了缺失输入、调用了合适工具，或在提交前验证了文档。
系统将提议分为两个范围。不变量编辑器关注通用执行行为，例如在写入输出后检查结果。领域编辑器则关注任务特定的知识、格式或流程。
这种分离降低了每个问题都获得同一种通用修复的可能性。当两者都带来有益的行为变化时，它也使组合器能够将广泛适用的流程规则与专门指引结合起来。
关键在于，在线流程无法获得基准的答案键。研究论文描述了一种开放世界设定：任务会在 harness 设计完成后到来。执行期间可能没有可靠的真实答案验证器可用。
系统并非宣称某个候选方案正确，而是在寻找对比。假设基础智能体遗漏了若干源文件。一项修订会盘点每项输入，另一项则加入电子表格核对指引。它们的轨迹能够揭示这些干预是否改变了智能体的流程。
组合器利用这些证据构建另一个 harness，并再次运行任务。这种方法并未消除判断，而是将判断从拿输出与已知答案比较，转移为比较不同执行过程中的可观察行为。
开发者可以通过两种方式投入额外的测试时算力。并行递归会同时探索多个候选修订，然后汇总这些尝试的证据。顺序递归则会在每次此前修订后再进行一次优化。
变量 k 控制这种探索预算。更大的值给予系统更多发现和测试编辑的机会，但每个机会都会增加模型调用、工具使用和执行时间。
任务结束后，第二层递归会更新持续改进 harness。反思器会存储被采用的 harness，以及一份描述干预、证据和结果的经验文件。后续提议可查阅该库。
这种设计使经验比完成后的提示词更具可移植性。存储的经验可能指出，文档生成任务适合重新打开最终文件并检查必需章节。即使具体文档不同，这一流程也可跨领域适用。
这种区别也将该框架与日常知识工作联系起来。智能体可能需要在生成决策备忘录前，整合会议纪要、电子表格、政策文件和项目文档。困难之处通常在于跨来源追溯主张，而非生成流畅文稿。
团队已经可以通过构建可搜索的知识库来减轻这一负担。Harness² 将这一理念延伸到执行策略：智能体可以针对特定任务，修订其收集、检查和使用这些材料的方式。
不过，该机制仍处于实验阶段。行为对比是证据，而非真相。两个候选方案可能共享同一错误前提，而看似完善的轨迹仍可能导向糟糕的交付成果。
基准测试提升让固定智能体 Harness 面临压力
报告结果表明，harness 设计对性能的影响可能与更换模型相当，尤其对于起点较弱的系统。
研究人员在三个专业基准上评估了 Harness²。WorkBuddy-Bench 涵盖编程、网页和办公任务。JobBench 测试专业工作能力，而 Harvey’s Legal Agent Benchmark 衡量法律任务表现。
测试覆盖两种模型与两种初始 harness 的四种组合。模型为 Gemini 3.5 Flash 和 GLM-5。初始执行 harness 为 OpenCode 和 Codex，而 Claude Opus 4.8 在主要实验中担任默认编辑器。
作者称，单次优化步骤在全部三个基准上提升了每种受测模型和 harness 组合。报告中的最大提升在 WorkBuddy-Bench 上达到 11.5 分、在 JobBench 上达到 4.5 分，并在法律基准的部分通过率上达到 11.8 个百分点。
WorkBuddy-Bench 上最大的变化出现在 OpenCode 下运行的 GLM-5。其平均分在一步优化后从 64.2 上升至 75.7。OpenCode 下的 Gemini 3.5 Flash 则从 72.4 升至 77.5。
这些数字支持一项实际推断：harness 可以通过纠正原始模型能力无法解决的执行行为，缩小部分模型间的差距。
结果因配置而异。Codex 下的 GLM-5 在 JobBench 上仅增加 1.2 分，从 23.6 升至 24.8。同一基准上，OpenCode 下的 Gemini 提升了 4.5 分。
这种差异比最高的标题数字更重要。该方法并未在每种模型、harness 和任务中产生统一提升。其价值取决于起始系统和领域。
研究人员还提高了递归预算。对于 OpenCode 下的 Gemini，从一次优化转向 k=5 的并行递归，进一步提升了 WorkBuddy-Bench 的表现。编程达到 80.8，网页达到 81.7，办公达到 83.4。
论文报告称，在选定的 WorkBuddy-Bench 领域中，当预算从一提升至五时，并行和顺序得分均有所增长。竞争方法在这些测试中显示出较小或不那么一致的变化。
更多探索并非全部解释。在一项消融研究中，移除改进库使 WorkBuddy-Bench 的平均表现下降 3.1 分。移除按范围划分的编辑器角色损失 2.9 分，而跳过组合则损失 1.6 分。
JobBench 呈现出类似模式。移除该库使其得分下降 1.8 分，通用编辑器损失 3.7 分，省略组合则损失 1.9 分。这些结果表明，保留的经验、专门化提议和基于证据的组合均有所贡献。
JobBench 的一个案例说明了其机制。基础智能体未能整合源文件间的信息，也没有重新打开最终输出进行核验，得分为 43.1。
一项拟议干预要求清点每一项输入并明确追溯来源。另一项则增加了针对日程、场地、劳动力和预算核对的领域指导。合成器保留了这两项干预引入的全部四处修改，重新运行后的得分为 77.8。
该案例进一步支持了改进智能体 harness 的论点，因为问题出在流程上。模型并不缺乏基本的语言能力，也并非无法访问文件；它缺少的是可靠的工作方法。
即使是固定 harness，在不同领域中的表现也仍有差异。论文的比较发现，Claude Code 在固定系统中领跑代码和办公任务，而 Codex 在网页任务中领先。没有任何未改动的 harness 能在所有领域占优。
以拥有更大递归预算的 OpenCode 为起点，Harness² 在代码任务上比最强固定替代方案高出 4.6 分，网页任务高出 5.8 分，办公任务高出 4.9 分。作者明确指出，这一自适应结果使用了额外的测试时计算资源。
因此，竞争压力指向的是固定 harness 的方法，而非某一款具体产品。供应商可以改进模型，但如果周边指令和工具无法适应变化，用户仍可能获得不一致的结果。
自我改进型智能体 Harness 仍需独立核验
Harness² 可以改进智能体的流程，但其自身证据显示，递归修改有时会选择更差的行为，或传播错误假设。
基准测试结果来自项目作者，尚未在独立部署中确立跨生产环境的可靠性。论文报告了三次运行的平均值，这有助于衡量波动性，但不能替代外部复现。
该方法在交付最终输出前也会消耗额外计算资源。每一次提案、探测、合成和重新运行都会消耗 token 和执行时间。在有足够容量时，并行处理可以缩短耗时，但无法消除底层资源成本。
论文将已评估配置置于 JobBench 和 WorkBuddy-Bench 的经验性计算性能前沿上。这一结果意味着，测得的收益相较于已测试替代方案更具竞争力；但并不代表递归对每一种生产工作负载都具备经济性。
低价值任务未必值得多次模型执行。法律备忘录或运营决策或许值得进行更多核查，但这些领域也要求比基准测试运行器更严格的控制措施。
最重要的警示来自作者自身的失败分析。他们审查了九次性能回退，并将其归类为候选选择失败、共享错误前提，以及评估或执行不确定性。
在一个编程案例中，该框架选择了得分 55 的输出，而非得分 95 的替代方案。在一项法律任务中，范围更窄的修订降低了覆盖度，得分从 54 降至 26。
其他失败则源于候选方案共享的错误假设。这些错误导致了 2 至 11 分不等的损失。如果每一项拟议修改都接受相同的错误前提，比较其行为也无法揭示最初的错误。
论文还将缺失的评审决策和正常的逐次运行波动视为归因难题。得分变化可能源自修改、随机执行，或评估噪声。更多探测会有所帮助，但也会增加成本。
代码库活动同样暴露了实施风险。一项公开的缓存身份问题报告称，当任务指令或源文件发生变化、但任务标识符保持不变时，恢复的实验可能会复用此前输出。
该问题作者在不调用模型的情况下复现了这一行为，并指出输入内容未被纳入已保存运行身份的部分构成。该报告未量化其对已发布基准分数的影响，审阅时也尚未附有维护者的解决方案。
不过，该问题说明了更广泛的运营挑战。递归系统需要为任务、源材料、harness 修订、缓存输出和评估设置建立可靠的溯源关系。否则，表面上的改进可能反映的只是过时证据。
安全性带来了另一项担忧。八个可编辑组件包括护栏、脚本、插件和工具指令。这些文件能够影响智能体访问的内容及其执行的操作。
自主编辑器不应拥有无限制的权限去削弱访问控制、执行未经审查的脚本，或持久保存敏感任务细节。生产使用需要组件级权限、不可变的安全边界、审计日志和回滚机制。
持久化经验同样值得谨慎对待。来自某位客户、部门或法律事务的有益经验，在被用于另一项任务时可能泄露机密信息。因此，改进库不仅需要语义相关性，还需要数据隔离和保留政策。
团队还应区分性能优化与安全验证。基准分数奖励的是在其评估器条件下完成任务，并不会自动衡量隐私、授权、事实准确性或对恶意输入的抵抗力。
Google Harness2 本身就展示了这一区别为何重要。它的合成器可能偏好一个在行为上看似可信、但客观上更弱的候选方案。缺乏真值正是该框架试图处理的问题，但这仍是它无法消除的限制。
合理的生产设计应允许系统修改低风险指导，同时保护核心政策。提示词表述和工作流检查清单可以编辑；凭据规则、网络边界、审批关卡和破坏性操作限制则应置于智能体权限之外。
对于跨任务持续生效的拟议修改，人工审查依然很有价值。该框架可以生成证据，解释为何采纳某项修改。运营人员可在其进入共享库前，利用该记录批准、拒绝或限制该变更。
递归式智能体 Harness 正在改变智能体工程路线图
下一项检验在于：组织能否在控制计算成本、性能回退和持久记忆的同时复现这些收益。
第一个值得关注的信号是独立基准复现。该代码库公开了代码、配置、提示词和评估命令，为外部团队提供了实际起点。复现工作应同时报告最终得分和总模型使用量。
若不同供应商环境中都能成功复现，将强化核心主张。这将表明，自适应 harness 并未与所测试的模型、编辑器或 Google Cloud 环境紧密绑定。
若无法复现这些收益，则会削弱其普适性论据。研究人员需要识别差异究竟来自模型行为、基准版本、执行环境还是评估设置。
第二个信号是真实任务流中的表现，而非孤立的基准运行。harness 层面的递归承诺带来累积价值，因为早期任务的经验会引导后续提案。
论文为这种迁移提供了初步证据。基于 JobBench 构建的经验库，在 WorkBuddy-Bench 上将一步优化提升了：代码任务 0.6 分、网页任务 0.5 分、办公任务 2.9 分。
这些增益小于最强的任务级结果，且其中一项分析是回顾性地使用了后续任务经验。实际部署应证明，有用经验会按时间顺序积累，且不会导入未来信息。
运营人员应在衡量平均性能的同时衡量性能回退率，还应跟踪干预频率、延迟、模型消耗，以及通过人工审查的持久修改比例。
第三个信号是更强的验证与治理层。作者建议采用挑战共享假设的探测、多次执行以区分修改效果与波动性，以及在覆盖度与精确度之间取得平衡的更佳选择方法。
代码库修复可以提供另一个指标。具备内容感知能力的缓存身份、固定的基准修订版本和可靠的失效机制，将使实验更容易复现。为可编辑组件设定清晰的安全边界，则会使部署更安全。
更广泛的研究领域也将测试其他形式的 harness 自适应。Meta-Harness 在部署前搜索配置。ReasoningBank 检索有用的推理经验，同时保持 harness 固定。Harness Scaling 则为单个任务修订 harness。
Harness² 将在线任务自适应与持久化改进机制结合起来。这种组合是其主要特点，但也集中了风险。糟糕的任务级修订只会影响一个结果，而糟糕的保留经验可能影响后续任务。
对开发者而言，实际信息并不是每个智能体都应立即重写自身，而是提示词、记忆、工具和编排值得作为一个相连系统进行评估。
团队可以从受限实验开始。他们可以选择有代表性的任务，保留不可变的基础 harness，只允许在沙盒中修订，并将输出质量与总计算成本进行比较。每一项持久变更都应保持可追溯和可逆。
知识工作者也应关注，因为 harness 质量塑造了可见的智能体行为。当工具指令薄弱、记忆嘈杂，或工作流遗漏验证环节时，模型可能显得不可靠。反过来，更好的流程可以在不改变模型的前提下改善结果。
开源发布使这些假设能够被检验。它为研究人员提供了一个通用实现，用于研究智能体如何诊断失败、修订操作指令并保留经验。
Google Harness2 最终将自我改进的讨论从抽象的模型智能转向可检查的软件制品。这是一个有益转变，因为团队可以审查文件、追溯修订并衡量执行情况。
它并未解决最困难的问题：在不存在答案键时，谁来验证改进者？该框架以结构化的行为证据取代盲目编辑，但证据仍可能具有误导性。
在未来几个月中，应关注独立复现、真实跨任务结果，以及围绕可编辑组件的更严格控制。这些信号将决定递归式智能体 harness 会成为可靠的工程层，还是仍停留在前景可期的研究工作流。
对于当前正在评估 AI 智能体的团队而言，立即行动很直接：将模型和其 harness 分开测试，记录每一项变更，并在保留自动化修订前要求明确证据。Google Harness2 为这项实验提供了具体框架，而其报告的失败也表明监督为何依然重要。
