近期AI热点007｜ARC-AGI-3 得分为何提高到近三倍：模型之外，Agent Harness 也是变量

近期AI热点007｜ARC-AGI-3 得分为何提高到近三倍：模型之外，Agent Harness 也是变量

主要信息源：OpenAI ARC-AGI-3 官方实验文章、Responses API 官方介绍、Compaction 官方指南、ARC Prize 方法说明
关键词：ARC-AGI-3、Agent Harness、Responses API、Compaction、上下文管理、AI Agent、模型评测

OpenAI 实验原文：https://openai.com/index/how-two-settings-tripled-our-arc-agi-3-scores/
Responses API：https://developers.openai.com/blog/responses-api
Compaction 指南：https://developers.openai.com/api/docs/guides/compaction

2026 年 7 月 29 日，OpenAI 公布了一组容易被误读的数据：在 ARC-AGI-3 公开任务集上，GPT-5.6 Sol 使用通用 Harness 时得分为 13.3%；保留推理状态并启用上下文压缩后，得分提高到 38.3%，同时输出 Token 约降至原来的六分之一。

模型没有更换，权重没有更新，主要变化发生在模型外部的运行系统。

这项实验真正值得开发者关注的，不是“某个模型又刷新了榜单”，而是一个更接近工程现实的问题：我们通常说自己在评测模型，实际评测到的往往是模型、API 设置、上下文管理、工具接口和任务循环的组合。

ARC-AGI-3 测试的是什么

ARC-AGI-3 使用陌生的二维游戏测试 Agent 的学习和推理能力。模型不会获得完整规则，需要根据连续画面和操作反馈推断：

• 哪些对象可以交互；
• 一个动作会怎样改变环境；
• 当前关卡的目标是什么；
• 过去失败的尝试说明了什么；
• 下一步应该探索还是执行计划。

这类任务和静态问答不同。模型不是读完一道题后一次输出答案，而是在一个循环里不断行动：

观察环境
↓
形成假设与计划
↓
执行一个动作
↓
读取新的环境状态
↓
修正假设并继续

如果每轮结束后都丢掉上一次推理，Agent 就需要反复重新理解规则；如果上下文过长时直接删除最早记录，它还会逐渐忘记已经验证过的结论。

两套 Harness 的差异

OpenAI 在文章中指出，最初使用的通用 Harness 存在两个关键行为。

第一，每次游戏操作后，模型的私有推理状态都会被丢弃。下一轮虽然还能看到部分操作记录，却看不到产生这些操作的计划和中间判断。

第二，Harness 使用滚动截断控制上下文。记录超过限制后，最早的观察和动作会被直接移除。

OpenAI 随后用更接近 ChatGPT 与 Codex 生产环境的方式重新实现 Harness：

官方根据公开游戏记录估计，人类测试者在同一指标上的平均得分约为 48%。因此，38.3% 仍不代表 Agent 已经达到稳定的人类水平，但足以说明 Harness 会显著影响结果。

保留推理状态为什么有用

长程 Agent 的难点不是每一步都需要重新做一道难题，而是需要在几十甚至几百轮操作中保持同一个计划。

假设模型已经通过前五轮操作发现：

蓝色方块可以推动；
红色区域会重置关卡；
右上角的门只有在两个开关同时激活后才会打开。

如果第六轮开始时这些判断不再存在，模型只能从动作日志中重新推导。重复推导会增加输出 Token，也更容易让策略发生漂移。

Responses API 支持通过上一轮响应 ID 延续任务状态。下面是一个精简的 Agent 循环示例，重点展示 previous_response_id 的使用方式：

import json
import os

from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
model = "gpt-5.6-sol"

def build_observation(step: int, frame: dict) –> str:
return json.dumps(
{
"step": step,
"observation": frame,
"instruction": (
"根据当前画面选择下一步动作。"
"输出一个 JSON 对象，包含 action 和简短的可验证依据。"
),
},
ensure_ascii=False,
)

response = client.responses.create(
model=model,
input=build_observation(
0,
{"player": [1, 1], "objects": [[2, 1, "blue_block"]]},
),
)

for step in range(1, 20):
# 实际项目中应校验模型动作，再交给环境执行。
action_text = response.output_text
next_frame = environment_step(action_text) # 由你的环境实现

response = client.responses.create(
model=model,
previous_response_id=response.id,
input=build_observation(step, next_frame),
)

print(response.output_text)

这里的关键不是把完整历史手动拼回 input，而是让后续请求引用上一轮响应。官方实验称，对于 GPT-5.6，这种方式可以在工具调用和多轮对话之间自动保留推理状态。

示例中的 environment_step() 是占位函数。生产环境必须在它前面增加动作 Schema 校验、权限控制、超时、幂等键和失败恢复，不能直接把模型输出当作可信命令执行。

Compaction 与粗暴截断有什么不同

滚动截断的逻辑很简单：上下文超过限制后，从最早的消息开始删除。

while estimate_tokens(history) > context_limit:
history.pop(0)

这种方式容易实现，却不知道被删除的信息是否重要。最早的内容可能只是寒暄，也可能是任务目标、已经验证的规则或一次关键失败。

Compaction 的目标是把较长历史压缩成更紧凑的状态，再让任务继续运行。概念上更接近下面的过程：

if estimate_tokens(history) > compact_threshold:
history = compact(
history,
preserve=[
"任务目标",
"已验证规则",
"失败尝试",
"未解决问题",
"外部工具返回的关键事实",
],
)

这段代码是机制示意，不是 OpenAI SDK 的参数格式。具体 Compaction 配置应以文章开头链接的当前官方指南为准。

压缩也不是无损存储。摘要可能遗漏精确数值、代码片段、对象 ID 或边界条件。因此，生产系统不应只保留压缩后的自然语言，还应把不可丢失的状态放在结构化存储中：

{
"goal": "通过第 4 关",
"verified_rules": [
"blue_block_pushable",
"red_tile_resets_level"
],
"completed_steps": [1, 2, 3],
"open_questions": [
"whether_both_switches_must_remain_active"
]
}

模型上下文适合保存工作记忆，数据库或状态机适合保存不能丢失的事实。两者不是互相替代的关系。

如何给自己的 Agent 做 Harness A/B 测试

仅比较最终成功率通常不够。一个 Harness 可能分数更高，但消耗更多 Token、延迟更长，或者依赖更多重试。

建议至少记录以下字段：

run_id
task_id
harness
success
score
input_tokens
output_tokens
latency_seconds
tool_calls
retries
compaction_events

可以把每次运行保存为 results.csv，再用下面的 Python 脚本做基础汇总：

from collections import defaultdict
import csv

groups = defaultdict(list)

with open("results.csv", encoding="utf-8", newline="") as file:
for row in csv.DictReader(file):
groups[row["harness"]].append(
{
"success": int(row["success"]),
"score": float(row["score"]),
"input_tokens": int(row["input_tokens"]),
"output_tokens": int(row["output_tokens"]),
"latency": float(row["latency_seconds"]),
"retries": int(row["retries"]),
}
)

for harness, runs in sorted(groups.items()):
count = len(runs)
total_tokens = sum(
run["input_tokens"] + run["output_tokens"] for run in runs
)

print(
{
"harness": harness,
"runs": count,
"success_rate": sum(r["success"] for r in runs) / count,
"avg_score": sum(r["score"] for r in runs) / count,
"avg_tokens": total_tokens / count,
"avg_latency_s": sum(r["latency"] for r in runs) / count,
"avg_retries": sum(r["retries"] for r in runs) / count,
}
)

测试时应保证两组使用相同的任务、模型版本、推理强度、工具权限和最大运行步数。若一组启用了状态延续，另一组没有，那么测试问题应明确写成“哪套 Agent 系统完成任务更好”，而不是“哪个模型更强”。

公平评测与真实产品评测并不完全相同

ARC-AGI-3 采用通用 Harness 有合理目的：减少针对特定模型的适配，让不同模型在更一致的条件下比较。OpenAI 使用生产化 Harness 也有合理目的：测量模型在实际 API 能力被正确使用时可以做到什么。

两种评测回答的是不同问题：

因此，看到“开启两个设置后得分接近三倍”时，不能直接得出原榜单无效，也不能把 38.3% 当作所有 Agent 任务都会获得的固定提升。

更稳妥的做法是同时报告：模型名称、API 版本、推理设置、上下文策略、工具集合、停止条件、Token 使用量和失败样本。缺少这些信息，单独一个分数很难复现。

生产 Agent 还需要哪些保护

保留推理和压缩主要解决记忆连续性，不会自动解决工具安全和结果正确性。长程 Agent 至少还需要：

• 给工具调用定义严格 Schema，拒绝未知字段和越界参数；
• 对写文件、发消息、付款和删除操作增加人工确认；
• 给外部动作设置幂等键，避免网络重试造成重复执行；
• 分别记录模型失败、工具失败和业务验收失败；
• 保存环境中的权威状态，而不是只依赖对话历史；
• 对压缩前后的关键事实做一致性检查；
• 设置 Token、时间、步骤数和费用预算；
• 保留完整运行轨迹，便于定位某一步为什么偏离目标。

上下文管理做得更好，Agent 通常能运行得更久；运行时间更长，也意味着错误可能传播得更远。因此，记忆能力与权限控制需要一起设计。

这项实验给开发者的实际启发

ARC-AGI-3 实验说明，模型能力只是 Agent 系统的一部分。对于需要连续工具调用、代码修改、游戏操作、网页研究或科学计算的长任务，Harness 至少承担四项职责：

OpenAI 的结果来自官方实验，尚不能替代不同模型、不同工具和真实业务上的独立复现。但它提供了一个值得采用的评测习惯：模型升级前，先把 Harness 配置、上下文策略和工具权限写进实验记录；看到异常低分时，也先检查状态是否在轮次间被意外丢弃。

Agent 时代的模型评测，正在从“给模型一张试卷”变成“给系统一项连续任务”。这两种测试都重要，只是不能混为一谈。

参考资料

• OpenAI：How enabling two settings tripled our scores on the ARC-AGI-3 benchmark，2026-07-29
  https://openai.com/index/how-two-settings-tripled-our-arc-agi-3-scores/
• OpenAI Developers：Responses API
  https://developers.openai.com/blog/responses-api
• OpenAI Developers：Compaction
  https://developers.openai.com/api/docs/guides/compaction
• ARC Prize：ARC-AGI-3
  https://arcprize.org/arc-agi/3
• ARC Prize Docs：RHAE Methodology
  https://docs.arcprize.org/methodology