Agent 处理长任务时，容易碰到上下文膨胀的问题。随着搜索结果、工具输出和推理过程的累积，真正重要的信息会被淹没，难以快速找到。即便现在的模型拥有 1M、10M 的上下文窗口，长轨迹依然会带来注意力和推理上的成本。
在论文中，作者提出了一种 Agent 主动管理上下文的机制。在需要时，Agent 会压缩当前的历史信息，并把原始内容保存到外部存储上。后续任务如果缺少细节信息，可以按需回查。
固定压缩的局限
传统的 ReAct Agent 会不断把 action、observation 和推理内容追加到历史中，直到给出答案或是触达上下文窗口的上限。
常见的上下文压缩方式是在 token 使用量达到某个阈值后，强制触发摘要。论文的 Figure 1（下图）以窗口占用达到 90% 为例：触达阈值时，Summary Agent 的外部模块会将此前的消息压缩成一段摘要，再由 Agent 带着摘要继续执行任务。
图 1：ReAct、固定阈值 Summary Agent 与 ACM Agent 的差异
这种方法可以延缓上下文溢出的时间，但压缩时机主要由 token 数决定，很难反映 Agent 当前所处的任务阶段。可能模型刚完成一轮探索，积累了大量的重复信息，刚好适合整理上下文；也有可能正处于连续验证几条关键证据的阶段，突然压缩反而会打断当前信息的组织。对于长任务来说，什么时候压缩本身就是一个决策问题，固定阈值很难处理这种差异。
另一个问题主要来自摘要带来的信息折损。传统 Summary Agent 压缩后，会用摘要替换先前的原始内容，缺少后续任务回查原始内容的通道。一旦摘要遗漏某个实体、数字或证据链，就很难重新找回这些细节信息。此外，长任务中的信息价值还会随着任务的推进发生变化，当前看似无关的结果，可能十几轮之后才成为关键的线索。
针对上述两个问题，ACM 做了机制调整。上下文的压缩时机交由 Agent 自己判断，被移出工作上下文的原始内容则继续保存在外部存储中。这样一来，上下文管理也成为了 Agent action space 的一部分。
工作记忆与长期记忆
ACM 的运行机制并不复杂，核心只有两个工具：manage_context 和 query_memory（参考图 1）。
manage_context 负责整理当前工作的上下文。当 Agent 判断历史内容需要被压缩时，系统会调用 summarizer LLM，将当前尚未压缩的一段消息整理成更短的摘要，同时把对应的原始消息写入外部存储。每段摘要都会获得一个唯一标识，用来关联摘要与原始记录。
query_memory 负责回查。当 Agent 发现摘要中缺少某个细节时，可以带着摘要标识和具体问题向外部存储发起查询。querier LLM 会读取对应的原始消息，从中提取与当前问题相关的信息，再返回给 Agent。这样，模型眼前保留的是更短、更集中的工作记忆，外部存储则保存可以重新查询的历史记录。随着任务的推进，工作上下文可以主动收缩，也能在需要时重新获取早期信息。
论文把这套设计称为“无损上下文管理”。这里的“无损”，指的是原始消息在系统层面没有被永久丢弃，后续需要可以重新读取。由于摘要本身依然可能会遗漏信息，query_memory 的效果也会受到查询表达和 querier LLM 提取能力的影响。所以，实际系统还是会面临查询不准、信息遗漏和额外延迟等问题。
从工程结构上看，这相当于给 Agent 增加了一组显式的内存操作：上下文窗口是当前推理需要的工作区，外部存储保存更完整的历史数据，摘要标识则用来连接两者。这样一来，“整理”和“回忆”也被纳入 Agent 的任务执行过程。
上下文管理时机
只把上面这两个工具塞进工具列表还不够。论文发现，只给模型提供 ACM 工具，未经专门训练的模型也不知道什么时候该用工具。有的模型几乎不主动调用 ACM，有的模型还会过早压缩上下文，还有的模型明明收集到足够的证据，却一直在整理上下文，没有及时提交答案。因此，论文把训练重点放在“什么时候管理 Context”上。
为此，ACM 设计了一套双约束的教师引导数据生成的流程。第一条路径从“不提供 ACM 工具”的学生轨迹开始。学生模型照常完成任务后，教师模型会检查它的执行过程，当模型开始重复搜索、陷入无效循环，或是积累了足够多的信息、适合整理时，教师会在相应位置插入一次上下文管理动作。这条路径提供了“什么时候应该压缩”的示范。
第二条路径从“提供 ACM 工具”的学生轨迹开始，主要暴露模型未经训练时的工具使用习惯。教师找到过早或不必要的上下文管理调用，把它替换成更合适的动作，例如继续定向搜索、打开关键的文档，或者在信息充足时直接提交答案。这条路径提供“什么时候应该继续任务”的示范。
教师修改动作后，学生会从这个位置继续 rollout，因此训练数据保留了这次动作调整对后续轨迹的影响。数据还经过两类过滤：排除学生多次尝试都能成功完成的简单样本；检查教师推理是否泄漏参考答案。最后再混入一部分学生的原始轨迹，以降低训练的不稳定性。
模型训练采用软标签蒸馏。论文使用 Qwen3.5-397B-A17B 为学生轨迹生成 token 级概率分布，每个位置保留 top-20 候选，Qwen3.5-9B 会学习如何匹配这些分布，并连续训练三个 epoch。公开的实现进一步说明，轨迹 annotation 使用 GPT-5，后续再由 Qwen3.5-397B-A17B 生成 top-K logprobs；受 GPU 资源限制，实际流水线会先缓存教师 logprobs，再加载缓存来训练学生。学生参数更新之后，由于缓存轨迹来自旧策略，代码实现严格来说属于分阶段的 off-policy 近似。
图 2：“无 ACM 工具轨迹中插入动作”和“有 ACM 工具轨迹中移除错误动作”的双约束流程
长任务基准与对照方法
论文的实验部分覆盖了三类长任务：深度网页搜索的 BrowseComp-Plus、面向真实网络搜索的 DeepSearchQA，以及代码修复基准 SWE-Bench Verified。其中，BrowseComp-Plus 使用 680 条训练样本和 150 条评估样本，DeepSearchQA 仅用于域外评估，SWE-Bench Verified 的训练数据则来自 SWE-Gym。
学生模型、summarizer 和 querier 均使用 Qwen3.5-9B 模型。这里有一个前提：ACM 要发挥作用，模型首先需要具备持续执行长任务的能力。论文附录中的 Qwen3-4B-Thinking 平均只运行约 2 轮、调用约 1.2 次搜索，准确率只有 3.4%。任务轨迹还没有长到出现明显的 Context 压力，上下文管理自然也很难发挥作用。
实验的主要基线包括不做上下文管理的 ReAct、固定阈值摘要方法 ReSum 和 ACON，以及跨轨迹积累经验、但不动态压缩单次轨迹的 ACE。论文将这些方法统一复现在 Qwen3.5-9B 上，并保持搜索工具、解码配置和 128K 上下文上限的一致，以尽量减少模型规模和实验设置带来的干扰。不过作者指出，这些基线此前并没有在完全相同的任务设置下进行评估，因此重新实现可能会带来一定差异。
图 3：ACM 与不同上下文管理方法在三类长任务上的性能对比
性能与计算成本
与 ReAct 相比，只加入 ACM 工具、不进行后训练的 Qwen3.5-9B 在三项任务上就已经取得提升；经过专门的上下文管理训练后，这个模型的性能结果得到了进一步的提高。
此外，上下文峰值也有所下降。BrowseComp-Plus 从 63K 降到 54K，DeepSearchQA 从 46K 降到 41K，SWE-Bench Verified 从 59K 降到 50K。
图 4：ACM 与 ReAct 在长任务中的上下文增长对比
上图的上下文曲线呈现出明显的锯齿状，Agent 在触及 128K 上下文窗口的上限前主动整理了上下文，压缩后继续探索，说明上下文管理确实释放出了一部分工作空间。
不过，这组结果还需要结合工具调用次数来看。BrowseComp-Plus 上，ReAct 平均调用 19.5 次工具，ACM 后训练模型增加到 46.2 次；DeepSearchQA 从 47.4 次增加到 58.8 次；SWE-Bench Verified 从 74.7 次增加到 79.3 次。
论文的行为分析也显示，经过后训练的模型会进行更多搜索和文档读取。这说明 ACM 的收益与探索过程的长度密切相关。它降低了单条轨迹的上下文峰值压力，同时让 Agent 能够继续执行更多轮、调用更多工具。
论文没有提供严格控制工具调用次数、总输入 token 或端到端成本的对照，因此现有结果不足以说明 ACM 在相同推理成本下仍能获得同等幅度的质量提升。
在固定的上下文上限下，Agent 可以通过主动整理历史，把更多计算继续用于搜索和验证。
执行稳定性的变化
论文还通过四次独立运行来观察模型的执行稳定性。
Pass@4 表示四次运行中至少成功一次，接近模型能够触及的能力边界；Pass⁴ 则要求四次全部成功，用来衡量模型是否能稳定完成同一任务。
图 5：Pass@4、Pass@1 与 Pass⁴ 的三轮训练结果
如图所示，ReAct 的 Pass@4 为 73.5%，Pass⁴ 只有 34.1%；加入 ACM 工具后，两项指标分别提升到 78.8% 和 44.0%。经过三个 epoch 的 ACM 后训练，Pass@4 进一步提升到 82.0%，Pass⁴ 达到 59.3%，Pass@1 也从 57.0% 提升到 72.7%。
相比之下，Pass@4 的增幅相对有限，Pass⁴ 的提升会更明显。这说明上下文管理在扩展模型解题能力的同时，也降低了同一道长任务多次运行之间的波动。
对于需要持续搜索和反复验证的 Agent 来说，上下文中积累的噪声越多，后续的决策就越容易受到早期轨迹的干扰；经过 Agent 主动整理上下文后，模型能够维持更清晰的工作上下文，执行结果也会更加稳定。
222K 长轨迹案例
论文给出了一条包含五个约束的多跳搜索案例。
后训练模型在该案例中共运行了 83 轮，其中包括 63 次搜索、9 次文档读取、7 次 manage_context 和 5 次 query_memory。如果完整地保留所有历史，这条轨迹最终会增长到 222K token，并在第 47 轮超过 128K 的上下文上限。实际上，通过多次主动压缩，ACM 将实际工作上下文峰值控制在 98K。
图 6：完整轨迹、原始上下文与实际上下文曲线
上图的蓝色折线展示了 ACM 管理下的实际上下文变化。模型压缩早期历史后，后续又多次调用 query_memory 回查原始记录，再根据找回的线索继续搜索和验证。在整个过程中，Agent 会在搜索、读取、整理、回查和提交答案之间不断切换，使一条原始长度已经超过模型窗口的任务轨迹能够继续执行。单个成功案例无法代表所有压缩和召回都有效，但它很直观地展示了 ACM 在长任务中的运行方式。
工程意义与边界
ACM 的核心思路，是把上下文作为 Agent 执行过程中需要主动维护的运行时资源。压缩、持久化和回查被做成显式工具，再通过后训练让模型学习调用时机。对于深度搜索、代码修复这类长任务，这种设计可以让有限的工作上下文支撑更长的执行轨迹。
这套机制也有明确前提：基础模型需要具备足够强的长程推理和工具使用能力，否则任务还没进入需要管理上下文的阶段就已经结束。论文中的 ReSum、ACON 和 ACE 等基线也由作者重新实现，因此仍可能存在一定实现差异。
落到真实的系统中，还得考虑外部记忆如何组织、敏感数据如何留存、查询失败如何恢复，以及压缩和回查带来的延迟与成本。整体来看，ACM 更适合作为长程 Agent 的一层运行时内存机制：当任务持续几十轮甚至上百轮时，让 Agent 主动管理不断增长的历史，避免上下文逐渐成为后续推理的负担。
