Signal #23：同一个模型，为什么会变成完全不同的 Agent

2026 年 7 月 29 日，OpenAI 公布了一项关于 Agent 上下文的对照实验。

实验围绕 ARC-AGI-3 展开。这是一套面向 Agent 的交互式推理基准，由一系列陌生的二维游戏环境组成。Agent 不会提前获得完整的操作规则和任务说明，只能不断尝试动作、观察环境变化，逐步推断游戏机制，找到关卡目标并形成后续策略。

它的评分不只看 Agent 是否完成关卡，也会比较 Agent 与人类完成任务时使用的动作数量，因此不是普通意义上的准确率。

在公开任务集上，同一个 GPT-5.6 Sol 使用 ARC-AGI-3 官方 Harness 时得分为 13.3%。在对照实验中，OpenAI 使用 Responses API 重新实现了一套 Harness，保留模型在前序步骤中产生的推理消息，并用 Compaction，也就是上下文压缩，替代滚动截断。调整之后，得分提高到了 38.3%，输出 Token 同时减少约六倍。

模型没有变，任务也没有变。变化的是模型能否延续此前形成的判断，以及不断增长的上下文如何被处理。

这组实验很容易被概括成“Harness 很重要”，但这个判断已经不新鲜了。真正值得追问的是：为什么上下文组织方式的变化，能够产生如此大的能力差异？

当前很多 Agent 仍然沿用一种从聊天产品继承而来的上下文机制：消息持续追加，内容过长以后再截断或压缩。但长程任务需要的，可能并不是一份越来越长的对话历史，而是系统围绕当前目标和任务阶段，持续组织模型此刻真正需要的信息。

ARC-AGI-3 考验的不只是模型能否完成某一次推理，还要求它持续保留探索过程中形成的认识：哪些动作已经尝试过，哪些假设被证伪，当前正在验证什么，以及下一步为什么应该这样行动。

官方 Harness 为了保持通用性，没有针对具体模型加入特殊工具和能力，但它的上下文处理方式带来了两个问题。

首先，每次游戏动作结束后，模型此前产生的推理消息都会被丢弃。模型仍然能够看到过去的动作和少量伴随记录，却无法继续使用当时形成的计划、洞察和中间判断。

其次，随着交互历史增长，官方 Harness 会通过滚动截断删除最早的内容。模型不仅无法保留过去的推理过程，连早期执行过的动作和环境反馈也会逐渐消失。

结果是，模型需要在每一轮重新理解游戏。它可能已经发现了一条重要规律，却无法稳定延续这个判断；也可能重新尝试此前失败过的路径，因为相关信息已经离开当前上下文。

在 OpenAI 重新实现的 Harness 中，前序步骤中的推理消息可以继续保留。模型能够利用已经形成的认识，不再需要每执行一个动作，就重新推导游戏规则。当上下文接近上限时，系统也不再滚动删除最早的消息，而是通过 Compaction 压缩已有历史后继续执行。

数字差异是最直观的结果，它背后更值得关注的是一种长期存在的归因偏差。

当 Agent 重复尝试、忘记目标或无法长期维持策略时，我们经常认为模型缺乏规划和推理能力。但在这个案例中，相当一部分混乱并非来自模型不会推理，而是系统不断让模型失去此前的推理结果。

一种运行方式要求模型先恢复历史、重新建立目标、判断当前进度，再解决下一步问题；另一种运行方式则允许模型直接在已经形成的认识上继续推进。模型能力没有变化，但它每一步拿到的上下文已经不同，最终表现得像两个完全不同的 Agent，也就不令人意外了。

很多 Agent 的上下文，大致遵循同一种结构：

这种方式实现简单，也与模型的对话接口天然兼容。在较短的交互中，它通常能够正常工作；问题主要出现在长程任务中。

一个开发任务可能先经历需求分析，再进入代码检索、方案设计、修改实现、测试失败、问题定位和最终验收。一个研究任务也可能经历资料收集、假设形成、证据冲突、方向调整和结论修正。随着任务推进，每个阶段所需要的信息都在发生变化。

持续追加的消息历史，却主要按照信息发生的时间组织，而不是按照信息对当前任务的价值组织。

最近产生的大量终端日志、搜索结果和失败输出会不断进入上下文。更早形成的任务目标、关键决策和约束虽然仍然重要，却逐渐被推到上下文深处，甚至在达到长度上限后被删除。

例如，一个 Coding Agent 可能已经在需求分析阶段确认“不能修改现有接口”。但经过数十轮代码检索、终端输出和测试失败以后，这条约束逐渐远离当前上下文。进入修复阶段时，Agent 又提出了修改接口的方案。表面上看，这是模型没有理解或遵守需求；实际也可能是系统没有继续突出这条仍然有效的约束。

这条不断增长的消息序列中，至少混合了三种性质不同的信息：

它们有不同的生命周期，也承担着不同职责，却经常被统一塞进上下文窗口，交给模型自行分辨。

模型因此不只是在解决任务，还要持续从混杂的历史中判断：哪些信息仍然有效，哪些已经过时，哪些只是一条失败路径留下的噪声，哪些结论需要回到原始证据重新确认。

更长的上下文窗口能够延缓信息被删除，却没有消除这项工作。窗口越大，模型能够接收的信息越多，需要处理的历史和噪声也可能越多。

因此，长程 Agent 面临的不只是上下文“装不下”的问题，还包括模型此刻看到的信息，是否仍然与当前任务相关。

上下文达到上限以后进行摘要或压缩，是目前常见的处理方式。OpenAI 的实验也证明，相比直接删除早期内容，保留推理消息并进行 Compaction，能够显著改善长程任务中的连续性。

但压缩仍然面临一个更深的问题：系统在压缩发生时，必须提前判断哪些信息将来仍然重要，而这种判断很难在一次压缩中准确完成。

一段信息在需求分析阶段可能显得无关，进入代码实现后却可能成为关键约束。某次失败的尝试当时没有产生结果，后续出现相似问题时却可能帮助 Agent 避免再次走入同一条路径。一个被摘要为“接口调用失败”的结果，在重新定位问题时，可能需要查看具体错误码、请求参数和完整响应。

如果摘要直接替代了原始内容，这种信息选择通常是不可逆的。后续任务方向一旦发生变化，被删除的细节便无法重新进入上下文。

压缩的触发时机也经常由固定阈值决定。系统在上下文使用达到某个比例后开始整理历史，但 Token 数量并不知道任务是否刚刚完成一个阶段，也不知道 Agent 是否正处在需要连续保留细节的关键推理过程中。

2026 年 7 月 26 日发布的论文 ACM：Agentic Context Management for Long Horizon Tasks，开始尝试将上下文管理变成 Agent 执行过程中的主动动作。

ACM 为 Agent 提供了两类上下文工具：一类用于压缩当前历史，并将原始消息转移到外部存储；另一类允许 Agent 在后续需要时，重新查询被移出的原始内容。

上下文管理不再只由固定长度阈值触发，Agent 可以根据当前推理状态和任务进度，决定何时整理自己的工作空间。被移出的原始消息也不会被直接删除，摘要会通过唯一标识与对应的原始内容关联，使 Agent 后续仍然能够重新获取需要的细节。

论文基于 Qwen3.5-9B 进行了后训练。相较普通 ReAct 基线，论文报告 ACM 在 BrowseComp-Plus、DeepSearchQA 和 SWE-Bench Verified 上分别获得了 27%、16% 和 8% 的提升，同时将峰值 Token 使用量降低约 20%。研究还观察到，经过上下文管理后，Agent 能够进行更长时间的探索，不同运行之间的结果也更加稳定。

需要注意的是，ACM 主要处理的是单次任务内部的上下文管理。这里的外部存储用于保存被移出当前窗口的原始消息，并不等同于跨任务、跨 Session 持续积累的长期记忆。

ACM 没有彻底解决上下文相关性问题，但它推进了一个重要变化：上下文不再只是一段被动增长、达到阈值后统一处理的历史。在 ACM 中，Agent 开始参与决定哪些信息应该留在当前工作区，哪些信息可以暂时移出，以及什么时候需要重新找回。

上下文由“只能持续追加的记录”，向“可以被主动管理的工作空间”前进了一步。

但主动决定何时压缩，仍然主要是在管理已经产生的历史。更进一步的问题是：模型每一步看到的内容，是否必须由历史压缩而来？

如果沿着 OpenAI 和 ACM 的结果继续推演，长程 Agent 真正需要的可能并不是保存全部历史，也不只是找到更聪明的压缩方法。

本文将一种可能的方向称为动态上下文构造：将任务状态和原始信息保存在上下文之外，再根据当前目标和任务阶段，重新选择并组织模型此刻需要看到的内容。

不同任务需要的结构不会完全相同，但一份面向当前阶段的上下文，至少可能包含：

这些内容不是完整历史本身，而是从完整任务状态中生成的一份工作视图。

任务执行轨迹仍然可以被完整保存，用于回放、审计和复盘；原始代码、文档、日志和工具输出继续作为证据存在；当前阶段暂时不需要的信息，也可以保存在外部，需要时再重新加载。

例如，Agent 从需求分析进入代码实现时，当前上下文可以减少早期的发散讨论，突出已经确认的接口、修改范围和验收条件；进入测试与修复阶段后，则可以进一步突出失败用例、实际输出、最近修改和仍未通过的验证项。

任务阶段发生变化时，系统也不必继续沿用上一阶段形成的摘要，而可以重新从任务状态、执行轨迹和原始证据中，构造一份更符合新目标的上下文。

如果进一步扩展到跨任务场景，长期记忆还可以作为另一类外部信息源，保存跨任务仍然有效的事实、规则和经验。它是否进入当前上下文，同样需要根据当前目标、任务阶段和证据需求决定。

这里关于动态上下文构造和长期记忆的讨论，是本文沿着已有实验进一步提出的工程推演，并不是 OpenAI 或 ACM 已经直接验证的结论。

这套设想仍然需要更多实验。动态构造是否一定优于持续追加，任务状态应该由模型还是外部系统维护，错误的状态判断是否会把真正重要的信息排除在上下文之外，目前都没有确定答案。

但它会改变我们评价和构建 Agent 的方式。

仅记录模型、Prompt 和最终得分已经不够。上下文中保留了什么、删除了什么，任务状态如何维护，原始证据能否被重新获取，都应当成为可观察、可比较的系统变量。否则，我们仍然可能把上下文机制带来的收益或缺陷，简单归因到模型本身。

OpenAI 的实验已经给出了一个清晰的起点：仅仅改变推理消息的保留方式和上下文压缩策略，同一个模型就可能出现接近三倍的表现差异。ACM 则进一步说明，上下文管理可以从固定阈值触发的被动处理，转变为与任务进度相关的主动过程。

今天很多 Agent 的上下文，仍然主要是一段持续增长、定期压缩的历史。但长程任务真正需要的，可能是系统基于当前工作状态，为模型动态生成的一份任务视图。

同一个模型放进不同的上下文机制里，就可能表现成不同的 Agent。真正拉开差异的，可能不只是模型知道多少，还包括系统在每一步让它看见什么、记住什么，以及暂时忽略什么。