LLM Agent 在应对长周期任务时，真正的挑战往往并非模型缺乏推理能力，而是上下文开始失控：前几步还能保持清晰，后续却逐渐遗忘约束、丢失状态、重复试错，最终让任务演变成一场事故现场。来自自动化所、上海交通大学、UCSD 与合肥工业大学联合团队的最新综述《Context Compression for LLM Agents》系统梳理了 Agent 上下文压缩的方法、失败模式与评估体系，明确指出 Agent 的核心瓶颈正在从“模型是否能思考”转向“上下文是否能够被可靠地管理”。

最近在与从事 LLM Agent 的朋友交流时，大家普遍存在一个共同的焦虑：模型明明在前期步骤中表现正确，但后续却开始遗忘任务、丢失约束、反复横跳，最终将一个本来能够顺利完成的长任务，硬生生拖成了事故现场。

很多人第一反应是模型还不够强大。然而，自动化所、上交大、UCSD 与合工大联合团队发布的这篇综述，真正深入剖析问题后会发现，Agent 的麻烦往往不在于“会不会推理”，而在于“上下文能否被可靠地管理”。

换句话说，Agent 真正的瓶颈很多时候并非推理能力，而是上下文管理。

这篇综述研究的不是长文本，而是长任务

其讨论对象并非普通的静态长文档，而是 LLM Agent 在执行长周期任务过程中不断累积的 unbounded agentic trajectory（无界智能体轨迹）。这个轨迹中混杂着 Actions、Thoughts 和 Observations，也就是大家熟悉的 A-T-O 序列。

这种上下文最棘手的地方在于，它并非“字数过多”，而是“状态过多”。每执行一步，环境就会发生变化；每记录一次，依赖关系就会重新排列；每重试一次，后续策略就可能被改写。于是，上下文窗口越来越紧张，关键信息也越来越容易被挤出。

因此，这篇综述从一开始就将问题定得很明确：上下文管理绝非可有可无的优化，而是 Agent 能否持续运行的基础设施。

这件事为什么比普通长上下文更具挑战

普通长文档压缩主要处理一段静态材料；而 Agent 的上下文压缩面对的却是一个不断变化的执行过程。这里的每一个 token 都不仅仅是文本，它还承载着时序、状态、约束和动作的后果。

这也正是作者强调的原因：Agent context compression 不能仅仅追求“压短”，还必须保留 temporal dependencies（时序依赖）、actionable states（可执行状态）和 structural fidelity（结构保真度）。如果压短后无法继续执行，那就不算压缩成功，而是把系统变瘦了，同时也变残了。

论文给出的主框架很清楚：Select / Compress / Store / Recover

作者将整个上下文管理过程整理成一条完整的管线：先 Select（选择），决定哪些内容值得处理；再 Compress（压缩），将其转化为更紧凑的表示；然后 Store（存储），把关键状态保留下来；最后在需要时 Recover（恢复），重新将它们提取出来。

这个框架的价值不仅在于讲清概念，更在于它将研究对象从“一个压缩算法”升级为“一个可执行的系统”。真正应该比较的不仅仅是压缩率，还包括保存了什么、丢失了什么、以后是否还能找回。

这篇综述最重要的三条主线：压什么、怎么压、谁来决定

第一条是 compression target（压缩目标），即压什么。作者将现有方法分为几类：有的压缩 observation（观察），有的压缩 trajectory（轨迹），有的压缩 plan and reasoning（规划与推理），有的压缩 memory state（记忆状态），还有的直接压缩 representation（表示）。

第二条是 compression mechanism（压缩机制），即怎么压。这包括 masking/truncation（遮蔽/截断）、summarization/abstraction（摘要/抽象）、pruning/reduction（剪枝/缩减）、externalization/retrieval（外化/检索），以及更底层的 representation compression（表示压缩）。

第三条是 control policy（控制策略），即谁来决定何时压缩。可以是系统的固定规则，也可以是外部控制器，还可以由 Agent 自行决定，甚至可以通过学习策略进行优化。

这三条线分别对应工程中最容易出问题的三个层面：压错对象、压坏内容、压错时机。只要其中一条链路不稳，Agent 就很容易从“看起来很聪明”变成“看起来很忙”。

不是所有压缩都叫“省”，有些只是把风险往后挪

作者对不同机制的态度也很鲜明。截断和遮盖最廉价，但一旦删除就很难恢复；总结压缩能保留语义，但容易引入遗漏和过度概括；剪枝可以保留结构，却不一定压得足够狠；外化和检索最像真正可恢复的系统，但代价是把问题从“压缩”转变为“是否能找回”。

读完这段会发现一个很现实的结论：许多系统表面上做了压缩，实际上只是把上下文问题从当前轮次推迟到了下一轮次。token 省了，风险却没减少，只是换了一个地方爆发。

三类失败，几乎就是 Agent 工程事故现场

论文将 failure modes（失败模式）整理成三个层次。第一层是 F1：压缩前就选错了对象、时机或粒度，本不该压缩的内容被提前压缩了。第二层是 F2：在压缩过程中破坏了关键语义、结构关系或约束条件。第三层是 F3：信息其实仍然存在，但后续无法找回、恢复不准，或者无法正确使用。

这三种失败非常像真实工程中的事故链：先是判断错误，再是处理损坏，最后是恢复失败。表面上是一个问题，实际上是三次失误的层层叠加。

尤其是 F3，最容易被忽视。因为它看起来最像“信息还在”，但对 Agent 来说，信息只要不能在需要的时候准确提取出来，就等于不存在。

不同领域里，什么是“重要信息”完全不一样

论文还专门进行了 domain-specific analysis（领域特定分析），讨论了软件工程、Web 导航和深度研究这三类场景。它们对上下文的要求根本不是一套标准。

在软件工程中，最重要的是代码依赖、错误链和状态约束；在 Web/GUI 导航中，关键的是页面结构、可点击对象和交互反馈；在深度研究中，关键的是证据链、来源和推理路径。

也就是说，Agent context compression 根本不存在一个“万能模板”。同样的压缩策略，在不同任务中可能在一个场景中救命，在另一个场景中翻车。

评估也不能只看最后成没成

综述对评估部分的批评很直接：仅仅看 end-task success（最终任务成功）是不够的。因为有些方法表面上完成了任务，但中间状态已经损坏，后续的可恢复性也随之丧失。

作者更希望看到的是一套更接近系统真实运行方式的指标体系，比如信息密度、时间一致性、错误传播，以及压缩后状态是否还能稳定支撑后续决策。对于 Agent 来说，过程可靠性本身就是性能的一部分。

这篇综述真正给行业提供的，是一把新尺子

它并不是在说“上下文越短越好”，而是在说：Agent 的上下文应该被当作一种可管理、可恢复、可控制的执行资产。谁能把 Select、Compress、Store、Recover 这条链路做稳，谁就更有机会将长任务真正跑完。

这也是这篇综述最值得被记住的地方。LLM Agent 的上限，越来越接近于上下文管理能力的上限。不是单纯看模型有多大，而是看它能否将长期轨迹压得住、存得住、取回。

写在最后

如果说长上下文模型解决的是“能装多少”，那么 agent context compression 解决的就是“装进去以后还能不能持续用好”。它面对的并非一次性输入，而是长程执行；不是静态文本，而是动态轨迹；不是简单截断，而是可恢复的结构化状态。

当任务越来越长、工具越来越多、状态越来越复杂时，真正决定系统上限的，往往不是再多给一点上下文，而是将上下文压缩成一套真正可靠的执行资产。