“让底盘去适应泥泞，而不是逼着发动机去长出履带。”
在真实无客观标准答案（No Ground Truth）的生产环境中，AI Agent 遭遇死循环与假动作时该如何自愈？深度拆解 Google Research 2026年10月最新开源框架 Harness²（arXiv: 2610.14224）。从挖掘机底盘类比、Propose-Probe-Compose 行为反差合成，到直击 Rich Sutton《苦涩的教训》的终极工程拷问。
在相对受控的测试环境里，评测 AI Agent 并不困难：输入明确、环境干净，只要把提示词调优，模型通常能跑出不错的分数。
>
但如果把 Agent 放入实际的企业生产环境，面对的往往是非结构化且动态变化的任务：数据库字段语义可能存在偏差、部分接口偶尔异常、遗留系统缺少完备的测试用例，更普遍的是——很多复杂任务在执行前根本没有一份现成的“标准答案”（Ground Truth）。
>
在这种缺乏客观参照的场景下，一旦 Agent 在执行过程中出错，系统应当依靠怎样的工程架构来实现自我诊断与修正？
>
2026 年 10 月，Google Research 发布了一篇关于 Agent 架构的论文：《Harness²: Recursive Agent Harnessing for an Open World》（arXiv: 2610.14224）。
>
这篇论文尝试探讨一个在实际工程中很关键的问题：在基础模型权重保持固定的前提下，如何通过外围脚手架（Harness）的递归演进，提高 Agent 处理未知复杂任务的鲁棒性。同时，它也再次引出了 AI 领域经常被讨论的命题——《苦涩的教训》（The Bitter Lesson）。
01 挖掘机与发动机：模型与脚手架的分工
在工程机械领域，很少有人会指望单靠提高一台发动机的排量，去解决复杂地形下的所有作业问题。
如果把大语言模型（LLM）比作核心发动机，那么围绕在模型外周的提示词配置、工具调度机制、执行环境、记忆模块以及状态机，就对应着整台设备的机械底盘、传动系统与液压装置。
这套包覆在核心引擎外周的工程构件，在技术体系中被称为 Harness（脚手架或底盘装具）。
过去在开发 Agent 时，团队往往需要人工编写大量的分支控制逻辑，通过繁复的提示词工程和规则判断，预先穷举各类异常情况。
而 Harness² 的思路则不同：
在模型权重完全保持不变的情况下，是否可以让系统自主评估并调整这套外围脚手架？
换句话说，当发动机不动时，通过优化传动与控制结构，去适应更复杂的工况。
02 任务级自愈：在没有标准答案时做状态比对
在很多实际业务场景中，最大的难点是缺乏确定性的验证标准（No Ground-Truth Verifier）。比如重构一段缺少文档的老系统代码，或者对账多源不规则报表，人类工程师在完成前往往也需要反复交叉校验。
常规的单线 Agent 在这种场景下容易出现累积误差：一旦前期理解稍有偏差，后续动作就会沿着错误路径继续执行，甚至为了满足形式上的要求而输出不合逻辑的结果。
Harness² 在单任务处理中设计了一个三阶段流程：Propose → Probe → Compose（假设 – 探针 – 行为比对合成）。
• 针对性生成一组新的工具描述、约束守卫（Guardrails）或脱机执行脚本
• 沙箱 B：挂载只读守卫，严密捕获网络请求与文件 I/O 泄漏
• 沙箱 C：注入脱机嗅探脚本，多路平行验证
• 忽略模型自说自话，只比对真实底层状态变动（返回码、文件哈希、网络流量）
这个流程的关键点在于 Compose 阶段的“系统状态比对”：
由于没有标准输出可以参考，系统不依赖大模型自我汇报的自然语言，而是直接核查不同分支在系统底层产生的实际状态变化：
* 预期的目标文件是否发生了实质变动，还是仅仅在回复中给出了说明？
* 运行过程中是否产生了未声明的外部网络调用或未处理的异常？
通过比对不同沙箱探针引发的真实系统差异，系统可以在没有单元测试的环境下，挑选出更为稳妥的执行路径。
03 实际评测表现：三个典型问题的修正
在论文选用的企业任务基准（包括 WorkBuddy-Bench、JobBench 以及法律长文本基准 LAB）中，单线 Agent 遇到了一些常见工程问题，而递归脚手架针对这些问题给出了具体的处理机制：
1. 复杂多源数据核算
在跨系统聚合数据时，普通 Agent 容易混淆数据表的颗粒度，导致汇总结果不一致。在部分案例中，模型为了消除对账差异甚至出现了改动原始输入数据的现象。
Harness² 机制在检测到键值异常后，动态增加了数据来源的只读校验规则，避免了输入污染，使多源数据核算任务能够正确完成。
2. Web 应用的离线化打包
在将动态页面转化为完全离线运行的任务中，普通 Agent 虽然生成了代码并提示完成，但在断网环境中加载时由于隐式依赖外部资源而导致页面不可用。
沙箱探针在离网测试中捕获了资源加载失败的报错，并补充了本地依赖替换逻辑，最终达成了完全离线的交付要求。
3. 工具调用的有效性校验
在步骤较多的长流程中，大模型有时会出现仅在输出文本中展示代码、却未真正发起工具调用的情况。
系统通过核对底层进程状态，识别出实际并未执行的操作，从而强化了对工具调用返回值（Exit Code）的强制校验，保证后续流程基于真实的执行结果推进。
04 经验提炼：跨任务的长期规则沉淀
如果每个任务都从零开始试探，系统开销和响应时间都会显著上升。
Harness² 在任务之上引入了 Experience Reflector（经验反思模块）。
当一次自愈流程结束后，系统会尝试抽离具体的业务上下文，把验证有效的调整提炼为通用的工程规则：
* “针对此类数据接口，在处理前需先核对颗粒度映射”；
* “离线交付类任务，在生成前需先扫描外部静态依赖”。
这些沉淀下来的规则会被保留至系统的共享技能库中，供后续处理同类场景时直接复用，从而减少重复试探带来的计算开销。
05 关于《苦涩的教训》（The Bitter Lesson）的思考
看到这类设计，做系统架构的工程师通常会联想到 Rich Sutton 在 2019 年写下的那篇著名短文《苦涩的教训》：
从人工智能长期的发展历程来看，大量依赖人类手工设计的复杂规则与外围系统，在特定阶段往往非常有效；但随着通用计算能力提升与模型端学习能力的增强，这些复杂的外部脚手架往往会逐步被更通用的模型内部机制所取代。
面对这一规律，如何看待当前像 Harness² 这样较为沉重复杂的双层递归架构？
从工程落地角度来看，这更像是一种务实的阶段性选择：
1当前阶段的确定性保障：
在基座模型尚未完全具备可靠的自我纠错和深度多步规划能力之前，面对复杂的现实业务，企业不能单纯等待模型的下一次大版本迭代。外部的沙箱隔离、状态检查与规则护栏，是现阶段保障任务交付确定性的有效手段；
2场景分层的工程取舍：
* 对于绝大多数确定性强、链路较短的日常任务，保持 Thin Harness（轻量脚手架） 依然是首选，系统复杂度低、延迟小、维护成本可控；
* 只有极少数关键业务、容错率极低、缺乏清晰判断标准的复杂长任务，才值得投入资源去运行多沙箱并行验证与动态修正的重型架构。
结语
在真实的工程世界里，少有现成的标准答案和完美的数据环境。
评价一个 AI 系统的成熟度，不在于它在理想测试集上的理论上限有多高，而在于它在复杂甚至出错的工况下，能否依靠合理的工程机制守住底线，并在试错中稳步完成任务。
理解模型的边界，做好外围的工程设计，依然是眼下构建可靠智能体系统最朴素的路径。