如果智能体反复犯同样的错误，应该先换模型吗？

编程智能体修复了测试失败，却又把修复改回去。研究智能体再次查找已经确认过的资料，文档智能体则在漫长任务结束时忘记了之前确定的条件。这样的情形反复出现时，接入更强大的模型看起来像是最快的解决方案。

但如果失败的原因不是知识或推理能力不足，而是任务状态丢失、缺少完成判定、失败后的恢复规则存在空白，即使更换模型，同样的问题仍会存在。NVIDIA 的 AVO 案例之所以有趣，也不只是因为 Claude Opus 5 本身，而是因为围绕模型、让它持续处理长任务的 Harness 成为了焦点。

不过，不能把标题中的约30分和100分简单理解为前后的成绩。两次运行并不是只改变 Harness 的对照实验。这个案例真正值得借鉴的不是“提升70个百分点”这个数字，而是评估智能体时，将模型与执行系统分开比较的方法。

这不是从30分升到100分的对照实验

AVO 不是一个新的语言模型，而是面向长期自主任务的智能体系统。主智能体反复进行情境调查、规划、实现和评估，持久记忆会将先前的尝试和评估结果保留到下一次运行中。独立的监督者会在探索停滞或陷入低效重复时介入。

25个
ARC-AGI-3 公开环境
183个
完成的总关卡数
6,624次
在环境中采取的行动

基于 Claude Opus 5 的 AVO 完成了 ARC-AGI-3 公开集的25个环境、183个关卡，取得了 100.00 RHAE。在环境中采取了6,624次行动。 RHAE 同时反映关卡是否完成，以及相对人类首次尝试基准的环境行动效率。内部推理或工具调用只要不改变环境状态，就不会计入行动次数。

NVIDIA 同时提到的约30%来自 ARC Prize 对 Claude Opus 5 的另一项评估。它与 AVO 运行在推理设置、智能体系统和评估配置上均不相同。NVIDIA 也说明，这种差异并不能直接衡量 AVO 单独的贡献。因此，不能计算出“Harness 精确带来了70个百分点”，也不能说它“将性能提高了3.3倍”。

100分并不意味着实现了 AGI，也不代表实际工作中的成功率为100%。

该结果来自问题公开的集合。ARC Prize 技术报告解释说，针对公开环境调整的 Harness 可能会过拟合，因此不将公开集得分视为衡量 AGI 进展的有效指标。同时，报告也区分指出，这类 Harness 研究可能对工作自动化具有经济价值。

Harness 管理的不是答案，而是任务的连续性

Harness 的作用不只是给模型套上长提示词。它在模型调用之间管理要记住什么、执行哪些工具、由谁判定结果，以及失败后是继续还是停止。

反复出现的失败 应先检查的 Harness 要素 要比较的记录
重复已做过的调查或修改 保留目标、已确认事实和先前尝试的持久状态 重复工具调用与重复失败次数
将错误结果声明为完成 测试、模式、静态分析等外部判定器 声明完成后的验证失败率
失败后只重复同一种策略 失败记录与恢复策略 失败后的恢复率与人工介入次数
在长时间运行中丢失目标 查看进度和预算的监督层 目标偏离、中止时点、每项完成任务的成本

其他实验也表明，Harness 配置的影响不小。OpenAI 报告称，GPT-5.6 Sol 在官方 Harness 中的公开集得分为13.3%，但在同时采用推理状态保持和上下文压缩的 Responses API Harness 中取得了38.3%，输出 Token 则降至六分之一。由于两项设置是同时应用的，无法分离各自的贡献；但这个案例表明，同一模型处理执行状态的方式不同，结果和成本也可能不同。

输入表示也没有唯一正确答案。VISTA 为同一个 Claude Opus 5 使用512×512渲染图像和可再次检索的圆形视觉记忆，在公开的25个环境中取得了100.00。行动次数为7,542次。AVO 使用64×64文本网格报告了6,624次，但两者的后端和记忆结构不同，不能仅凭这一差异判断优劣。

今天就把失败案例分为校准集和保留集

第一步不是新建一个多智能体系统。请从过往运行日志中收集可复现的失败案例，先分为修改 Harness 时会查看的校准集和在修改完成前不会查看的保留集。反复修正同一个案例后又在该案例中成功，并不是泛化的证据。这与 ARC Prize 的警告是同一个问题：针对公开、已观察环境设计的 Harness，未必能迁移到初次遇到的环境。

  1. 创建工作类型和判定标准相同的一组案例。 如果是修复支付 Bug，请设定适用于每个案例的完成条件，例如通过回归测试、遵守修改文件范围、重复扣费为0。将用于 Harness 设计的校准案例与仅用于最终评估的保留案例分开，并记录每个案例属于哪一组。
  2. 在校准集上运行当前配置，作为基线。 固定模型、推理设置、输入和工具权限。如果可以控制种子或温度等波动，请使用相同值。如果无法固定，就在相同案例上多次运行每种配置，避免一次成功或失败左右结论。
  3. 建立分母可见的基线表。 不要只写“完成率60%”，还要记录任务数和重复次数，例如“10个案例完成6个”，或“5个案例各运行3次，15次中完成9次”。以同一运行单位记录重复失败、失败后恢复、人工介入、模型调用量、Token、运行时间和成本。ARC-AGI-3 的行动效率并未包含所有内部推理和工具调用成本，因此实际成本必须另行测量。
  4. 从持久状态开始逐项添加。 将目标、已确认事实、尝试过的方法、评估结果和剩余工作传递到下一次运行，然后在相同条件下重新评估同一校准集。接着一次只加入一个外部判定器、失败后恢复策略或监督层，并与前一项配置比较。
  5. 确定配置后，首次打开保留集。 不再继续调整校准案例中表现最好的配置，直接将其应用到保留案例。也在相同的保留集和运行条件下评估基线，比较完成案例数、恢复案例数和成本。如果看到保留结果后再次修改了 Harness，这些案例就已经变成校准案例，因此最终验证需要新的保留集。
  6. 最后才只更换模型。 在保持已确定的 Harness、同一案例集、同一权限和判定标准的前提下更换模型。这样才能分离模型变更与 Harness 变更的效果。

校准用的任务状态不必很复杂。可以先像下面这样记录可判定的信息和数据划分。

{
  "task_id": "bugfix-017",
  "split": "calibration",
  "goal": "修复支付失败后的重试，使其不会重复扣费",
  "expected_checks": [
    "通过回归测试",
    "遵守修改文件范围",
    "重复扣费为0"
  ],
  "prior_attempts": [],
  "budget": {"max_model_calls": 20}
}

成功标准需要分母和保留集结果。

例如，若将10个校准案例各运行3次，请记录完成率和恢复率在总计30次运行中各是多少次。添加一项 Harness 要素时，观察这些比例是否改善，以及重复失败、人工介入、每项完成任务的 Token、时间和成本是否也一同改善。最后，只有在设计过程中未查看的保留案例中也出现同方向的变化，才有理由扩展到下一类工作。如果案例数量很少，请如实报告运行次数和观察结果，而不是声称确定的改进率。

接入工具并不意味着长期任务就安全了

长期任务中的错误可能不是一次错误回答，而是累积的状态损坏。DELEGATE-52 研究评估了19个 LLM 在52个专业领域中的长期文档编辑表现，并报告即使是前沿模型，在任务结束时也平均损坏了25%的文档内容。仅增加工具使用并未改善性能；随着文档规模、交互长度和干扰文件增加，损坏会加重。

不能将这一结果直接套用为编程或游戏智能体的错误率。但实务中需要确认的警示很明确：不能把工具调用成功等同于工作完成。外部判定器必须验证结果，并且失败状态应能在进入下一阶段前得到恢复或中止。

下一份智能体评估表中，不要只写模型名称。 还要写明所用记忆、完成判定器、恢复策略、监督条件和执行预算，才能再次比较同一个系统。NVIDIA 的100分带来的最实用改变，不是如何选择最强模型，而是将评估单位从模型扩展到完整执行系统。

如果想进一步深入

NVIDIA AVO Reaches 100% on ARC-AGI-3 — 可同时了解 AVO 的结构、公开集结果，以及与约30%基线比较的局限。 developer.nvidia.com

ARC-AGI-3 Scoring Methodology — 可了解 RHAE 如何计算完成情况和环境行动效率，以及哪些内容未计入成本。 docs.arcprize.org

How enabling two settings tripled our scores on the ARC-AGI-3 benchmark — 说明同时应用推理状态保持和上下文压缩后，得分和输出 Token 如何变化。 openai.com

LLMs Corrupt Your Documents When You Delegate — 可了解一个反例：长期文档工作中损坏会累积，单靠接入工具无法解决。 arxiv.org