AGENT

AI代理的智能上下文管理

代理生成的上下文实际上很快变成噪音而不是有用的信息。另一种看法是：代理的上下文增长如此迅速，以至于它们变得非常昂贵，但并没有显著提高下游任务的性能。

admin

• 19 min read
AI代理的智能上下文管理

想象一下，你正在做一个项目，把每一个想法、实验和失败都记下来。一段时间后，你的笔记堆积如山，找到有用的信息需要的时间和精力超过了工作本身。软件工程（SE）代理也面临类似的问题：代理“记笔记”每生成一个输出，就会逐步将信息添加到他们的上下文中；这会导致巨大的——而且昂贵的——内存日志。

巨大的上下文可能会带来一些问题。首先，AI模型是按字数（token）计价的，随着上下文的增加，所花费的token数量急剧增加。如果不加干预地允许上下文增长，就有可能很快超过现代大语言模型（LLM）的上下文窗口。此外，代理的有效上下文大小实际上相当小（参见这篇论文和这篇论文）。

这意味着代理生成的上下文实际上很快变成噪音而不是有用的信息。另一种看法是：代理的上下文增长如此迅速，以至于它们变得非常昂贵，但并没有显著提高下游任务的性能。目前，我们正在为次优的投资回报率浪费资源。

如果增长的上下文是有问题的，那么采取了哪些措施来管理它们？令人惊讶的是，考虑到后果，目前的措施很少。迄今为止，重点一直放在通过策略增强代理的规划能力上，例如扩展训练数据和环境（例如论文1和2），以及增强的规划和搜索效率策略（例如论文1和2）。

然而，在基于效率的上下文管理方面的研究仍存在显著空白。我们的研究人员通过一项实证研究填补了这一空白，该研究探讨了主要的基于效率的上下文管理方法，并提出了一种新颖的混合方法，实现了显著的成本降低。这项研究是Tobias Lindenbauer在慕尼黑工业大学的软件工程与人工智能实验室的硕士论文的一部分。我们将在深度学习代码研讨会上展示我们的见解，这是NeurIPS 2025会议的一部分，将于2025年12月6日在圣地亚哥举行。

在这篇文章中，我们将描述：

  • 上下文管理的两种主要方法：观察掩码和LLM摘要。
  • 我们的实验及其结果，比较这两种方法与基线。
  • 我们的混合解决方案以及我们研究的广泛应用。

1、上下文管理方法

当AI代理处理复杂的编码任务时，它们需要记住之前做过什么，比如读过哪些文件，测试过哪些代码，以及如何推理错误。这种“记忆”也被称为上下文，它帮助代理更有效地进行推理。然而，高效管理这种记忆是一个平衡行为，既要给AI足够的思考空间，又不能让它被不必要的杂乱信息淹没。

最近，一些研究更仔细地审视了AI的上下文窗口大小对其性能的影响（例如这篇2024年研究和这篇2025年研究）。这些论文一致表明，随着上下文的增长，语言模型往往难以充分利用它们所获得的所有信息。尽管上下文管理在代理的性能和运行成本方面起着至关重要的作用，但大多数研究仍然将其视为一种工程细节，而不是核心研究问题。

在当前最先进的技术中，有以下两种主要的上下文管理方法。请注意，第一种方法既较新又更复杂；OpenHands最初提出了它，并且目前在Cursor和Warp的（专有的）SE代理解决方案中使用。第二种方法稍旧一些，也是两者中较为简单的。

  • LLM摘要：另一个AI模型生成简短的摘要
  • 观察掩码：较旧、不重要的信息被隐藏

这两种方法都保留了重要的上下文，因此从根本上说它们都是有效的。关键区别在于它们是如何做到这一点的。下图展示了差异，然后文本进一步详细说明。

基于Lindenbauer等人（2025）：4。

在图像的左侧，我们可以看到默认过程，即原始代理，为了简单起见省略了提示。每次轮次，表示为 T1 和 T2 在左侧边距中，包括三个部分：推理、动作和观察。

在上图的中间，是LLM摘要。它通过将生成的长历史（换句话说，轨迹）压缩成一个紧凑的形式，降低了所有三个部分的分辨率。黄色框代表前两个轮次T1和T2的摘要。

在图像的右侧，我们可以看到观察掩码只针对环境观察，同时保留动作和推理的历史完整。只有第三部分被掩码隐藏，这里用绿色表示。考虑到典型的SE代理的轮次严重偏向于观察，这种方法只减少这个特定轮次元素的分辨率是合理的。并且，代理仍然可以访问其过去的推理和决策，但不再重新处理早期轮次中的大量冗长文本，例如测试日志或完整的文件读取。

这两种方法之间还有一个额外的区别涉及无限上下文。具体来说，LLM摘要理论上允许无限扩展轮次而不会导致上下文无限扩大，因为重复摘要的结果是大型上下文窗口不会被超出。另一方面，观察掩码显著降低了上下文增长的范围，但如果轮次数量也被允许无限增长，上下文也可以无限增长。

下表展示了每种方法的优缺点。

最近，一些其他研究人员开发了上下文管理工具，并分析了它们在效率方面的表现。该领域的最新研究包括以下内容：

  1. MEM1，探索了多跳问答和网络导航等任务的动态状态管理。然而，这项工作没有与更简单的排除方法如观察掩码进行比较，他们使用的基准相对较短且轻量级（仅几百个token），不像SE代理中看到的那样长轨迹。请注意，这种方法涉及训练模型。
  2. 一种变体的LLM摘要方法，旨在帮助SE代理更高效地管理其上下文。然而，他们没有与更简单的观察掩码方法进行比较。他们最接近的替代方案称为Delete基线，删除整个对话轮次而不是对其进行摘要。这听起来可能很高效，但由于这些代理主要与环境互动，删除整个轮次可能会中断它们的推理并影响性能。
  3. 一种方法使用观察掩码在深度研究和计算机使用代理的强化学习和推理中表现出色。请注意，这种方法涉及训练模型。

注意：虽然第一种方法早于我们的研究，但后两种是在我们的研究完成后发表的。

尽管上述研究在高效的上下文管理方面提供了有趣的结果，但仍有大量关于代理高效管理上下文的最佳策略需要学习。在我们的研究中，我们质疑复杂的摘要策略是否真的有必要保持效率。为了探索这一点，我们使用SWE-agent和OpenHands进行了实验，看看更简单的技术如何，我们将在下一节讨论。

2、我们对当前上下文管理方法的实证研究

实验测试了三种记忆策略。这些策略如下，其中第一个是基线，后两个是主要的研究对象。

  1. 让记忆无限制增长 - 原始代理
  2. 用占位符修剪旧的观察 - 观察掩码
  3. 使用另一个AI来总结过去步骤 - LLM摘要

作为实验的基线，我们研究了原始代理的结构，使用ReAct或CodeAct。在这些框架中，代理的轨迹是一系列与环境的交互，上下文是无界的。

对于我们研究的两个主要对象，我们通过以下代表性的开源实现分析了流行的方法：

  • 通过滚动窗口的环境观察掩码(SWE-agent)，它：
  • 保持代理的推理和行动完整。
  • 一旦观察超出固定窗口，就用占位符替换旧的观察，本质上告诉模型，“一些细节被省略以简洁。”
  • 基于提示的LLM摘要(OpenHands)，它：
  • 使用单独的摘要器语言模型将较旧的交互（即观察、动作和推理）压缩成摘要。
  • 不改变最新的轮次。

根据初步实验，我们了解到为了公平比较LLM摘要的有限属性与观察掩码的缓慢但无限制的增长，我们需要使用长周期任务轨迹（在我们的论文的附录中描述）。对于这里报告的实验，我们让代理运行最多250轮。当涉及到观察掩码时，我们发现保持最新10轮的窗口在性能和效率之间提供了最佳平衡。对于LLM摘要，我们一次摘要21轮，始终保留最新的10轮。

此外，我们使用了最先进的模型，包括开放权重(Qwen3)和专有(Gemini 2.5 Flash)模型，从32B到480B不等；我们还涵盖了思考和非思考模式。所有实验都在SWE-bench Verified上运行，每个实例有500个。有关配置的更多细节，请参阅论文的第3节。

2.1 观察掩码简单但有效

正如前一节所述，我们的实验研究了三种记忆策略：第一种是基线，后两种是主要研究对象。我们实验的主要结果是观察掩码在整体效率和可靠性方面优于LLM摘要。

  1. 让记忆无限制增长 - 原始代理
  2. 用占位符修剪旧的观察 - 观察掩码
  3. 使用另一个AI来总结过去步骤 - LLM摘要

这两种方法（2）和（3）相比（1）节省了超过50%的成本，后者让代理的记忆不受管理。这些以效率为导向的上下文管理方法大幅减少了上下文增长，而不会损害代理解决问题的能力。

令人惊讶的是，简单的观察掩码方法不仅更便宜；它在解决基准任务时通常匹配甚至略微优于LLM摘要。在五个测试设置中的四个中，使用观察掩码的代理支付的费用更低，而且表现更好。

例如，使用强大的Qwen3-Coder 480B模型，观察掩码使解决率提高了2.6%，而平均成本降低了52%。在其他情况下，LLM摘要达到了这些结果，但很少超越它们。即使是微小的差异——比如每个问题三美分——在大规模AI部署中也会累积起来。

2.2 代理特定的性能差异

我们还想了解上述实验的见解是否可以推广到不同的代理，使用相同的参数但较小的子集。为了调查，我们在OpenHands代理上分别使用了两种上下文管理方法，在SWE-bench Verified基准的一个子集上（即50个实例而不是500个）。此外，代理被限制为Gemini 2.5 Flash，且不进行思考。

额外的测试包括实施SWE-Agent的最佳值与OpenHands代理，观察到性能有显著差异，然后改变参数，使性能恢复到标准水平。我们发现，观察掩码在成本节约和解决问题能力方面与LLM摘要相当——但仅在为每个代理模板调整了掩码“窗口”超参数之后。

什么是“调整掩码窗口超参数”？每个代理保存其对话历史的方式不同。在我们研究的工具中，SWE-agent（使用观察掩码）跳过了失败的重试轮次，而OpenHands（使用LLM摘要）包含了所有轮次。

考虑到参数，即上下文窗口仅限于最后10轮，对话历史的差异可能是巨大的。换句话说，如果代理连续10轮都失败，OpenHands代理的上下文窗口中的观察只会是错误的。这可能会造成很大的问题，可能会使代理偏离轨道。

因此，对于像OpenHands这样的代理，需要更大的窗口尺寸，以免负面影响性能。通过调整窗口大小，可以考虑这种代理特定的超参数差异，并在必要时增加窗口，例如在OpenHands的情况下。

2.3 LLM摘要和轨迹延长

我们真正想知道的一件事是，为什么LLM摘要，尽管是更复杂的解决方案，却经常比普通的观察掩码更不经济。结果发现，有一个有趣的转折：当代理使用摘要方法时，它们往往会运行更多的步骤，这意味着账单更大，最终效率更低。

当我们深入数据时，我们发现对于像Gemini 2.5 Flash这样的模型，使用LLM摘要导致代理平均运行52轮，比使用观察掩码多了15%。同样的情况也发生在Qwen3-Coder 480B上：摘要将流程延长了约15%，与让代理处理其原始历史相比，延长了13%。

为什么？似乎LLM生成的摘要实际上可能会平滑或隐藏表明代理应该停止尝试解决问题的迹象。这意味着它通常会继续运行到正常停止点之后，甚至是合理停止点（参见这篇论文关于解决率的平台）。

因此，尽管摘要旨在让事情更整洁，但它们可能会适得其反，鼓励代理继续运行，消耗更多资源却没有更好地解决问题。这是一个很好的提醒，有时保持简单不仅有效，而且更高效。

更重要的是，每次代理请求LLM生成摘要时，都会发出一个昂贵的API调用来处理轨迹的一长段，产生额外的费用。这些摘要生成调用并不便宜，有时占每个实例总成本的7%以上，尤其是对于最大的模型。由于每个LLM摘要API调用必须处理代理历史的独特切片，几乎没有缓存重用。当这些摘要成本被扣除后，LLM摘要和观察掩码之间的效率差距在大多数情况下大幅缩小。

聪明和简单的策略相对于什么都不做，成本减半，但简单性通常在总效率和可靠性上胜出。 所以，尽管摘要听起来很聪明，但实际上代价高昂，而且并不能可靠地胜过简单的掩码方法。这表明，许多当前的AI代理如果减少对摘要调用的依赖，或者开发创造性的混合策略，有效地结合这两种方法，就可以降低成本。

3、混合解决方案以实现更高的效率

在看到观察掩码和LLM摘要各自的表现后，掩码通常与摘要相当（或更好），我们想看看结合两者的最佳部分是否能带来更大的节省。如上表所示，这两种方法具有互补的优势，这是进一步合并它们优势的另一个论据。

我们的混合方法依靠观察掩码作为代理对抗上下文膨胀的第一道防线。我们这样设计是因为观察掩码速度快且成本低：它用占位符隐藏旧的、嘈杂的工具输出，只保留代理向前推进时最有相关性的部分。

但是，而不是完全忽略摘要，混合系统偶尔使用LLM摘要作为最后的手段，当上下文开始变得真正难以管理时，创建一个简短的AI生成的摘要。在我们的设置中，代理让掩码处理大部分步骤，但在收集了一大堆轮次后才会触发LLM摘要。在这些情况下，摘要由调整后的超参数触发。

我们新颖的混合方法的优势包括：

  1. 它让代理从观察掩码中快速节省成本，尤其是在新问题刚开始时，上下文还不是问题的时候。
  2. 它确保即使对于超级长或复杂的任务，偶尔的LLM摘要步骤也能防止内存失控，而无需在简单任务上额外花费摘要生成的费用。
  3. 因为我们的方法不涉及训练模型（即改变权重），我们可以为任何现有模型（包括GPT-5和Claude）添加此方法。这等于立即节省成本，即使在无法训练模型的情况下也是如此。据我们所知，同时期的方法缺乏这种应用。

正如我们所知道的上面，超参数调整很重要，这同样适用于我们的混合方法。具体来说，我们调整了掩码的窗口和摘要前的轮次数，为每种特定类型的代理或任务调整了这两个参数。当我们在一个代理上使用的设置用于另一个设置时，我们并不总是得到最佳结果。

除了调整之外，我们严格测试了我们的方法，数字支持我们的主张。在具有挑战性的SWE-bench-Verified基准和超大的Qwen3-Coder 480B模型的测试中，混合技术相比纯观察掩码节省了7%，相比仅使用LLM摘要节省了11%。它还推动了成功答案的比例增加了约2.6%，同时节省了相当大的一笔钱，整个基准最高可达35美元，当代理大规模运行时，这确实积累起来。

4、高效的上下文管理

这项研究深入探讨了AI代理处理不断增长的上下文的不同方式，在各种模型和代理框架中进行了测试。此外，鉴于轨迹足够长，并特别关注参数调整，我们能够一致地重现这些发现。

我们研究的主要结论是：

  • 忽视基于效率的上下文管理意味着忽视重要的成本节约策略。
  • 如果你想拥有既敏锐又节俭的AI代理，不要只依赖一种上下文管理策略——我们的混合方法结合了观察掩码和LLM摘要的优势。

除了论文外，我们还在线提供了我们的代码。查看它并看看上下文管理的差异。

原文链接：Cutting Through the Noise: Smarter Context Management for LLM-Powered Agents

汇智网翻译整理，转载请标明出处