论文标题	ACON: Optimizing Context Compression for Long-horizon LLM Agents
作者	Minki Kang, Wei-Ning Chen, Dongge Han, Huseyin A. Inan, Lukas Wutschitz, Yanzhi Chen, Robert Sim, Saravan Rajmohan
机构	KAIST, Microsoft, University of Cambridge
发表信息	arXiv preprint, arXiv:2510.00615v2, 17 Oct 2025。PDF 中未看到正式期刊/会议录信息。
代码	https://github.com/microsoft/acon

论文的背景很明确：LLM Agent 在多步任务中会持续积累工具调用、环境返回、历史动作、失败尝试和中间状态，context 会随着交互轮次不断变长。

长上下文带来的问题不只是成本升高。对 Agent 来说，history 和 observation 往往承担“工作记忆”的作用，里面可能包含账号状态、API 参数、文件路径、已完成步骤、错误反馈等关键信息。直接截断会丢状态，普通摘要又可能保留了流畅文本却删掉了后续动作真正需要的变量。

ACON 试图把历史压缩成较短但仍含关键信息的 summary，从而让后续步骤在更小上下文中继续执行。这个图证明的是问题存在的结构性原因：长程任务天然会产生“越做越长”的上下文，而不是某个单一 prompt 写得太长。

长程 Agent 为什么会越跑越长

论文解决的具体问题是：在长程 Agent 中，如何压缩 history 和 observation，使输入上下文变短，同时不破坏完成任务所需的状态信息。

作者把目标写成一个带成本惩罚的优化问题：既要最大化任务成功带来的 reward，也要降低上下文成本。这个设定比“把 token 压得越少越好”更合理，因为对 Agent 来说，压缩如果导致任务失败，节省的 token 没有实际价值。

因此 ACON 的工作目标可以概括为三点：第一，找出 Agent 上下文中可以压缩的部分；第二，学习一种不会轻易丢关键状态的压缩规则；第三，降低 compressor 本身的调用成本，使它有机会用于实际系统。

三个目标分别解决什么问题

ACON 的核心思想是：把“上下文压缩”从普通摘要问题，改造成一个围绕任务成功率优化的 Agent 状态保留问题。它不是一次性写一个“请总结历史”的 prompt，而是比较“完整上下文成功”和“压缩上下文失败”的轨迹，让强 LLM 分析压缩到底漏掉了什么，再把这些失败原因转化为新的 compression guideline。

从建模上看，Agent 在第 t 步并不是只看当前用户问题，而是根据历史 h_{t-1} 和当前环境返回 o_t 生成动作 a_t：

随着工具调用和环境反馈不断加入，h_t 会越来越长。ACON 优化的目标可以理解为：

这个公式背后的意思很关键：压缩不是越短越好，而是要在“还能完成任务”和“上下文更短”之间找平衡。对长程 Agent 来说，一个短但丢失状态的 summary 可能比完整历史更危险，因为它会让模型基于错误或不完整的世界状态继续行动。

Figure 3 展示了 ACON guideline optimization 的三层机制。第一层是“对比轨迹”：同一个训练任务分别用无压缩 Agent 和压缩 Agent 跑一遍，真正有价值的样本不是所有失败任务，而是无压缩能成功、压缩后失败的任务。因为这说明任务本身可完成，问题更可能出在压缩丢失了关键上下文。第二层是“自然语言反馈”：强 LLM 不只是给一个成功/失败分数，而是阅读两条轨迹，指出压缩版本少了什么、错了什么、在哪一步开始偏离。第三层是“guideline 更新”：这些失败诊断会变成新的压缩规则，再用于下一轮 compressor。也就是说，Figure 3 展示的是一个把压缩失败转化为 prompt 规则的闭环。

方法上，ACON 先区分两个压缩对象：history compression 和 observation compression。history 是跨步骤记忆，里面包含已经做过的动作、工具返回、错误反馈、变量值、文件或对象 ID、用户目标、待完成子任务等；它的问题是越积越长，但风险是压缩后丢掉状态。observation 是当前环境或工具刚返回的大段内容，例如搜索结果、API 返回、表格、文档片段；它的问题是信息过载，但风险是删掉后来才会用到的细节。因此论文没有把所有 context 当作一整块文本处理，而是分别设置 history threshold 和 observation threshold，在超过阈值时触发对应 compressor。

两个压缩对象的区别

guideline optimization 如何从失败中迭代

UT 与 CO 的目标差异

这个算法也解释了为什么作者没有直接用 RL 训练 compressor。论文指出这里没有标准压缩答案，任务 reward 只有执行结束后才知道，环境 rollout 又很贵，而且 token cost 是离散量，不容易直接做梯度优化。所以 ACON 选择优化自然语言 guideline，而不是直接更新大模型参数。

原论文的 Splitwise 例子展示了 history compression 的状态保留方式：普通 prompting baseline 能说清楚“已经登录、查找了 Splitwise 消息、下一步要检查联系人”，但它偏叙述；ACON-UT 会显式保留 access token、page index/page limit、目标日期、邀请消息 ID、发送者手机号等可执行状态；ACON-UTCO 则把这些状态进一步压缩成更短的变量列表。这个例子证明 ACON 压缩出来的不是“更漂亮的摘要”，而是“下一轮 Agent 可以继续执行的状态包”。

原论文的 Spotify API 例子能很好地解释 observation compression 的风险：任务是播放一个已下载歌曲足够多的专辑，普通压缩只保留了查询专辑库、下载歌曲和专辑详情相关 API，却漏掉了真正执行播放需要的 play_music。ACON 优化后会把 play_music 也保留下来，因为后续动作最终必须调用它。这个例子说明 observation compression 不能只判断“当前看起来相关的信息”，还要判断“完成任务最终必需的行动接口”。

最后是 compressor distillation。直接让 gpt-4.1 这类强模型在每一步都做压缩，会引入新的推理开销，所以 ACON 把优化后的强模型 compressor 当成 teacher，让它生成大量“原始上下文 -> 压缩上下文”的训练样本，再用 LoRA 微调较小的 student compressor。推理时可以用小模型负责压缩，强模型主要负责 Agent 决策。这个环节解决的是部署可行性问题：如果 compressor 自身太贵，那么 peak tokens 虽然降了，系统总成本仍可能不划算。

论文在 AppWorld、OfficeBench 和 8-objective QA 三类长程 Agent benchmark 上实验。指标包括任务表现（accuracy、EM、F1）、交互步数、peak tokens 和 dependency。对比方法包括无压缩、FIFO、retrieval、LLMLingua、普通 LLM prompting，以及 ACON 的 UT / UTCO 版本。

ACON 的核心贡献有三点。第一，它把长程 Agent 的上下文压缩对象明确分成 history 和 observation，比只做通用 prompt compression 更贴近 Agent 工作流。第二，它提出用“完整上下文成功、压缩上下文失败”的对比轨迹来优化自然语言压缩规则，使压缩器学会保留任务关键状态。第三，它通过 distillation 降低 compressor 成本，并展示了小模型 Agent 可以从结构化压缩上下文中受益。