同一个 GPT-5.6在同一套 ARC-AGI-3 公开任务上一次得到 13.3%另一次得到 38.3%。变化不在模型权重而在模型外面的评测程序也就是 harness。OpenAI 2026 年 7 月 29 日公布的实验很适合用来检查一种常见误区只要模型名、数据集和分数单位相同两次结果就能直接比较。对于需要连续观察、采取动作并修正计划的智能体任务这个前提并不够。上下文怎样续接、旧记录何时被删除、模型是否能沿用之前形成的推理状态都会改变实际被测的系统。这并不等于“排行榜没有意义”也不能推出 GPT-5.6 在所有任务上都提升了三倍。更准确的结论是长时程评测必须把 harness 当作实验条件报告。否则一个看似属于模型的分数可能混入大量上下文工程差异。13.3% 和 38.3% 测到的系统并不完全相同ARC-AGI-3 不是静态问答。模型通过动作与游戏环境交互每次动作后收到当前画面和关卡的文本表示再决定下一步。模型在游戏中看不到自己的得分。官方采用的指标是 RHAE即 Relative Human Action Efficiency可理解为相对于人类行动效率衡量任务表现。OpenAI 根据官方游戏日志估算普通人类测试者的平均得分为 48%。OpenAI 先报告了两个较早结果GPT-5.6 Sol 为 7.8%GPT-5.5 为 0.4%。随后团队在同一公开任务集上比较了两种运行方式ARC Prize 的通用 harness 得到 13.3%使用 OpenAI Responses API、保留跨回合推理状态并启用 compaction 的 harness 得到 38.3%。后者约为前者的三倍同时输出 token 少了约六倍。这里容易出现一个错误读法把 38.3% 减去 13.3%全部算成“模型能力增长”。模型并没有变变化的是状态管理策略。13.3% 更接近“该模型在官方通用 harness 约束下的表现”38.3% 则是“该模型与另一套上下文管理方式组合后的表现”。两者都是真实结果但回答的问题不同。官方通用 harness 保持通用性有明确理由尽量让不同实验使用共同环境暴露模型自身局限方便公平比较。面向实际部署的 harness 则会利用特定 API 能力追求系统能做到的最好结果。前者偏向可比性后者偏向生产真实性不能拿一个替代另一个。第一处差异有历史消息不等于有推理连续性原 harness 在每个游戏动作后都会丢弃模型的私有推理。模型还能看到之前的动作和简短笔记却看不到此前形成计划与判断时使用的内部推理状态。对单步任务这种差异可能不明显对需要试探规则、排除错误路线、跨多个关卡复用发现的任务行动记录与推理连续性不是一回事。Responses API 的状态续接改变了这一点。通过previous_response_id后续请求可以接续先前响应对支持的模型持久化的 reasoning items 可以为下一次推理提供连续性。官方文档同时强调这些项目是不可见的API 不会把模型的原始私有推理文本返回给客户端。因此“保留推理”不能写成“应用可以查看模型思维链”。正确区分是可见对话或动作历史是调用方可以保存和检查的输入输出持久化推理状态是模型可在后续调用中利用的不可见状态previous_response_id是续接响应的一种方式不是读取私有推理的接口。评测程序如果只确认“历史消息还在”仍可能漏掉推理状态是否跨回合可用。比较两套 runner 时这一项需要单独记录。第二处差异滚动删除与压缩不是同一种上下文策略原 harness 还有一个更直接的断点历史超过 175,000 个字符后旧动作会被滚动删除。删除很容易实现却不知道最早的记录里哪些是无效试探哪些是后续关卡仍然需要的规则。智能体也许没有撞到模型上下文上限却会先因 runner 的清理策略失去关键线索。OpenAI 的实现改用 compaction并把阈值设为 175,000 tokens。文章解释在这个任务中动作网格的字符和 token 大致接近一比一所以两个阈值在量级上相近。这个细节很重要它降低了“新 harness 只是容纳了多得多原始文本”的可能性但不能把字符阈值与 token 阈值说成一般情况下完全等价。根据 OpenAI 开发者文档服务端 compaction 会在渲染后的 token 数跨过compact_threshold时触发产生一个加密的压缩项用更少 token 把此前的关键状态和推理带入后续调用。这个压缩项不供人阅读。若使用previous_response_id每轮只传新消息不应再手工修剪若调用方自行维护无状态输入数组则必须把输出中的压缩项继续传下去。compaction 也不等于原样保存完整对话。它保留的是后续所需状态不保证每个旧动作、每句话、每个中间细节都逐字存在。文章若把它描述成“无损记忆”或“完整历史永久保留”就越过了官方文档边界。为什么输出 token 更少得分反而更高“输出少六倍分数高三倍”乍看像矛盾前提是把输出长度当成推理质量的代理。这里更合理的解释是连续状态减少了重复恢复工作。如果每次动作后都丢弃此前的推理模型需要根据动作日志和短笔记重新理解局面。历史再被滚动截断后它还可能重复探索已经排除的路线。输出 token 增多并不表示有效计划更多也可能只是反复重建同一状态。状态续接和压缩让后续调用更容易沿用已经形成的计划因而可能用更少的外显输出完成更多有效动作。不过这只是与官方故障描述一致的机制解释不是 OpenAI 单独测出的因果占比。官方公开的是两个设置一起改变后的总结果没有给出“只保留推理”和“只使用 compaction”各自贡献多少的完整消融表。可以复现的四组 harness 对照如果团队正在比较两个模型或准备升级自己的 agent runner最实用的做法不是照抄 13.3% 和 38.3%而是为自己的任务做一个四格对照。下面是基于官方故障机制整理的实验设计不是 OpenAI 已发布的四组实验结果。组别跨回合推理状态长上下文处理A丢弃滚动删除旧记录B保留滚动删除旧记录C丢弃compactionD保留compaction四组实验需要固定这些条件模型快照、公开任务版本、系统指令、可用工具与动作、reasoning effort、停止条件、上下文阈值以及随机种子或重复运行次数。只换状态续接与长上下文策略才能观察二者是否分别造成差异。每次运行至少记录run_id: arc3-harness-D-03 model_snapshot: 精确模型版本 task_set: 公开集版本或提交哈希 reasoning_continuity: retained history_policy: compaction context_threshold_tokens: 175000 score_metric: RHAE score: 结果 levels_solved: 关卡数 actions: 动作总数 output_tokens: 输出 token compaction_events: 触发次数与位置 first_context_loss: 首次确认丢失旧信息的位置无则留空 failure_class: task_reasoning | state_loss | tool_error | timeout不要只保留最终总分。动作数能说明效率关卡数能避免平均分掩盖某个阶段的断崖压缩触发点和首次信息丢失位置有助于解释分数为什么变化。若条件允许再加总延迟与成本它们属于部署选择不属于模型能力本身。故障分类也需要证据。比如模型重复尝试一条旧路线不足以直接判定“失忆”。应回放触发点前后的可见历史、压缩项是否正确传递、有效 reasoning context以及工具返回是否完整。只有确认必要状态在 runner 层消失才能记为state_loss否则可能仍是任务推理失败。比模型之前先判断你要比较什么这组结果给出的不是一条“永远用生产 harness”的规则而是两种不同的比较口径。如果问题是“模型本身在共同约束下谁更强”应尽量使用同一个通用 harness统一提示、工具、状态策略和预算。做不到完全统一时至少把差异公开不能把一个模型的定制 runner 结果与另一个模型的通用 runner 结果直接排成能力名次。如果问题是“哪套系统能在业务里完成更多任务”就应该比较可部署的模型与 harness 组合。此时状态续接、压缩、工具适配和错误恢复本来就是系统能力的一部分但报告名称应写成“模型 runner 配置”而不是简称为模型分数。一个可执行的判断规则是做排行榜或模型研究优先报告通用 harness 结果并列出所有非等价设置做产品选型比较完整部署配置同时记录成本、延迟和失败恢复同时关心公平性与实际上限就并列报告通用 harness 和生产 harness 两组结果不把它们混成一个数字。OpenAI 还给出一个很具体的关卡案例在某个公开游戏中排行榜上的前沿模型都没有通过第一关之后的内容而采用新 harness 的 GPT-5.6 Sol 完成了全部六关。它说明上下文策略可能改变长时程任务的失败位置但仍只是 ARC-AGI-3 公开集中的一个游戏不能外推为所有 agent、所有游戏或所有软件任务都能获得同等幅度的改善。评测报告真正需要补上的往往不是更多小数位而是一张实验条件表。模型、任务集、提示、工具、推理连续性、历史清理、预算和停止条件共同定义了被测系统。只有这些条件足够接近横向分数才接近“比较模型”条件不一致时比较的是两套系统工程。官方来源How enabling two settings tripled our scores on the ARC-AGI-3 benchmarkOpenAIIlan Bigio、Ted Sanders2026-07-29Compaction 与 Reasoning modelsOpenAI 开发者文档访问于 2026-07-30。
