Agent 处理长任务时，容易碰到上下文膨胀的问题。随着搜索结果、工具输出和推理过程的累积，真正重要的信息会被淹没，难以快速找到。即便现在的模型拥有 1M、10M 的上下文窗口，长轨迹依然会带来注意力和推理上的成本。

作者提出了一种 Agent 主动管理上下文的机制。在需要时，Agent 会压缩当前的历史信息，并把原始内容保存到外部存储上。后续任务如果缺少细节信息，可以按需回查。

## 固定压缩的局限

传统的 ReAct Agent 会不断把 action、observation 和推理内容追加到历史中，直到给出答案或是触达上下文窗口的上限。

常见的上下文压缩方式是在 token 使用量达到某个阈值后，强制触发摘要。论文的 Figure 1（下图）以窗口占用达到 90% 为例：触达阈值时，Summary Agent 的外部模块会将此前的消息压缩成一段摘要，再由 Agent 带着摘要继续执行任务。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/bccb7605d896b337773cc4a1d209197b.png)

图 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 近似。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/6ad0f1e26ecfe53bb1afcc614a2de8e8.png)

图 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 上下文上限的一致，以尽量减少模型规模和实验设置带来的干扰。不过作者指出，这些基线此前并没有在完全相同的任务设置下进行评估，因此重新实现可能会带来一定差异。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/1cc3762756279e0f772318e7a70b47fa.png)

图 3：ACM 与不同上下文管理方法在三类长任务上的性能对比

## 性能与计算成本

与 ReAct 相比，只加入 ACM 工具、不进行后训练的 Qwen3.5-9B 在三项任务上就已经取得提升；经过专门的上下文管理训练后，这个模型的性能结果得到了进一步的提高。

此外，上下文峰值也有所下降。BrowseComp-Plus 从 63K 降到 54K，DeepSearchQA 从 46K 降到 41K，SWE-Bench Verified 从 59K 降到 50K。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/51b33edc6ec23be12d53e52e95e75473.png)

图 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⁴ 则要求四次全部成功，用来衡量模型是否能稳定完成同一任务。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/2c997d93b7cd6d756f75b5972842620d.png)

图 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。

  

![](https://developer.qcloudimg.com/http-save/yehe-12464096/95f813476ba9b2f93b6de9906d6b3cc3.png)

图 6：完整轨迹、原始上下文与实际上下文曲线

上图的蓝色折线展示了 ACM 管理下的实际上下文变化。模型压缩早期历史后，后续又多次调用 `query_memory` 回查原始记录，再根据找回的线索继续搜索和验证。在整个过程中，Agent 会在搜索、读取、整理、回查和提交答案之间不断切换，使一条原始长度已经超过模型窗口的任务轨迹能够继续执行。单个成功案例无法代表所有压缩和召回都有效，但它很直观地展示了 ACM 在长任务中的运行方式。

## 工程意义与边界

ACM 的核心思路，是把上下文作为 Agent 执行过程中需要主动维护的运行时资源。压缩、持久化和回查被做成显式工具，再通过后训练让模型学习调用时机。对于深度搜索、代码修复这类长任务，这种设计可以让有限的工作上下文支撑更长的执行轨迹。

这套机制也有明确前提：基础模型需要具备足够强的长程推理和工具使用能力，否则任务还没进入需要管理上下文的阶段就已经结束。论文中的 ReSum、ACON 和 ACE 等基线也由作者重新实现，因此仍可能存在一定实现差异。

落到真实的系统中，还得考虑外部记忆如何组织、敏感数据如何留存、查询失败如何恢复，以及压缩和回查带来的延迟与成本。整体来看，ACM 更适合作为长程 Agent 的一层运行时内存机制：当任务持续几十轮甚至上百轮时，让 Agent 主动管理不断增长的历史，避免上下文逐渐成为后续推理的负担。

Agent 处理长任务时，容易碰到上下文膨胀的问题。随着搜索结果、工具输出和推理过程的累积，真正重要的信息会被淹没，难以快速找到。即便现在的模型拥有 1M、10M 的上下文窗口，长轨迹依然会带来注意力和推理上的成本。

让 Agent 自己管理 Context：长任务如何主动压缩与召回信息

ACM 让 Agent 主动压缩上下文并按需回查，提升长任务执行稳定性。

人工智能

架构设计

算法

ACM机制让Agent自主决定何时压缩上下文，将原始信息存入外部存储，支持按需回查。相比固定阈值摘要，ACM在BrowseComp-Plus、DeepSearchQA和SWE-BenchVerified上均提升性能，上下文峰值降低约15%，Pass@4从73.5%升至82.0%，Pass⁴从34.1%升至59.3%。该设计将上下文管理纳入Agent动作空间，通过双约束训练优化压缩时机，支撑更长执行轨迹。

敏感数据

Agent

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ACM机制让Agent自主决定何时压缩上下文，将原始信息存入外部存储，支持按需回查。相比固定阈值摘要，ACM在BrowseComp-Plus、DeepSearchQA和SWE-BenchVerified上均提升性能，上下文峰值降低约15%，Pass@4从73.5%升至82.0%，Pass⁴从34.1%升至59.3%。该...

让 Agent 自己管理 Context：长任务如何主动压缩与召回信息-腾讯云开发者社区-腾讯云

让 Agent 自己管理 Context：长任务如何主动压缩与召回信息

让 Agent 自己管理 Context：长任务如何主动压缩与召回信息

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐