ACON: Optimizing Context Compression for Long-horizon LLM Agents¶

会议: ICML2026
arXiv: 2510.00615
代码: https://github.com/microsoft/acon
领域: LLM Agent / 上下文压缩 / 长程任务
关键词: LLM Agent、上下文压缩、Prompt优化、轨迹对比、压缩蒸馏

一句话总结¶

Acon 用失败轨迹对比来优化自然语言压缩指南，同时压缩 agent 的历史和观察上下文，在 AppWorld、OfficeBench 和多目标 QA 上把峰值 token 降低 26% 到 54%，并保持或提升长程任务成功率。

研究背景与动机¶

领域现状：LLM agent 已经被用于办公自动化、应用操作、搜索问答等多步任务。与单轮问答不同，agent 需要持续保存观察、动作、工具输出和中间状态，后续每一步决策都依赖这些交互历史。

现有痛点：长程 agent 的上下文会不断增长，带来两类问题。第一，Transformer 推理和 KV cache 成本随上下文变长而上升，内存和延迟都不可控。第二，长上下文里混入大量过时或无关信息后，模型更容易被噪声分散注意力，尤其是较小模型会明显掉任务成功率。

核心矛盾：上下文压缩必须同时“狠”和“准”。如果只截断或泛泛总结，文件路径、API 参数、账户状态、工具返回中的约束等关键状态很容易丢失；如果保留太多，又不能真正降低成本。更难的是，很多 proprietary LLM 不能做梯度更新，RL 式压缩策略也需要昂贵 rollout。

本文目标：作者希望构造一个模型无关的压缩框架，在不改 agent 权重的前提下，自动学习不同环境中的压缩规则，使压缩后的上下文既短又保留完成任务所需状态，并且能把压缩器蒸馏到小模型以降低额外开销。

切入角度：论文的观察是，压缩失败会在轨迹层面留下很强的诊断信号：同一个任务在完整上下文下成功、压缩上下文下失败，说明压缩器漏掉了某些关键状态。把这种前后上下文对比交给 LLM 分析，可以生成自然语言反馈，用来更新压缩 prompt。

核心 idea：不用微调 agent，而是在自然语言空间里迭代优化“应该保留什么、删掉什么”的压缩指南，再用成功轨迹蒸馏小型压缩器。

方法详解¶

Acon 可以看成一个插在 agent 与环境之间的上下文管理层。Agent 仍然用原始 ReAct 或 benchmark 指定的工具格式决策；Acon 只在历史或观察超过阈值时调用压缩器，把长文本改写成更短但信息密度更高的状态摘要。关键不在于手写一个通用总结 prompt，而是用训练任务中的成功/失败轨迹自动改进这个 prompt。

整体框架¶

输入是一个长程 agent benchmark、固定的 agent LLM、固定系统 prompt、以及一批训练任务。每个时间步，agent 会看到历史 $h_{t-1}$ 和最新观察 $o_t$。如果历史长度超过阈值 $T_{hist}$，Acon 用压缩器 $f(h_t;\phi,P_{hist})$ 生成压缩历史；如果观察超过阈值 $T_{obs}$，则用 $f(o_t,h_{t-1};\phi,P_{obs})$ 生成压缩观察。压缩后的上下文替换原上下文进入下一步决策。

训练阶段先用初始压缩指南跑任务，收集“完整上下文成功、压缩上下文失败”的 contrastive subset。优化器 LLM 阅读原始上下文、压缩上下文和失败信息，写出压缩遗漏了什么、哪些状态应该保留。随后另一个 update prompt 汇总多条反馈，更新压缩指南。第一轮主要最大化任务成功率，论文称为 utility maximization；第二轮只在压缩后成功的任务上分析哪些信息实际被用到，进一步压短上下文，称为 compression maximization。最后，作者用优化后的大模型压缩器产生输入输出对，LoRA 微调 Qwen3/Phi 等小模型作为压缩器。

关键设计¶

历史与观察的分离式压缩:
- 功能：同时处理 agent 历史增长和单步环境观察过长这两种上下文来源。
- 核心思路：历史压缩只在 $|h_t|>T_{hist}$ 时触发，观察压缩只在 $|o_t|>T_{obs}$ 时触发。历史压缩关注跨步状态、动作结果和未来约束；观察压缩关注当前工具返回中的有效字段，并可参考过去历史判断哪些字段相关。
- 设计动机：长程 agent 的 token 爆炸不只来自历史，也来自一次工具调用返回的大表格、邮件、网页或文件内容。把两类压缩分开优化，比一个泛化 summary prompt 更能适配任务结构。
基于失败对比的压缩指南优化:
- 功能：把稀疏的任务成败奖励转成可读的自然语言优化信号。
- 核心思路：对于完整上下文成功但压缩上下文失败的任务，让 LLM 对比 $H$ 和 $H'$，指出压缩版本丢失了哪些必要信息。多条反馈被聚合成新的压缩指南 $P^{(1)}$。论文还生成多个候选 prompt，在 contrastive tasks 上评估后选择最好者。
- 设计动机：直接用 RL 优化压缩策略需要大量 rollout，且无法更新 API LLM。自然语言 prompt 优化把“压缩错在哪里”显式写出来，可在少量训练任务上快速迭代，并且对任意 agent 模型可用。
压缩最大化与压缩器蒸馏:
- 功能：在保留任务成功率的同时进一步降低上下文长度和压缩器调用成本。
- 核心思路：utility step 先确保不丢关键状态；compression step 再从已经成功的压缩轨迹里分析哪些内容真正被使用，要求 LLM 删除冗余描述。随后用优化指南下的大模型压缩输出作为教师数据，微调小模型压缩器，目标是最小化生成压缩文本的交叉熵。
- 设计动机：只追求成功率容易产生保守摘要，token 降幅有限；只追求短又会丢状态。两阶段优化把 reward 和 cost 分开处理，蒸馏则避免每一步都调用昂贵大模型做压缩。

损失函数 / 训练策略¶

方法的目标可写成 $\max_\psi E[R(s_T(\psi))]-\lambda E[C(H'(\psi))]$，其中 $R$ 是任务终止奖励，$C$ 是动态上下文成本。实际优化不对 LLM 权重做梯度更新，而是用文本反馈更新压缩指南。蒸馏阶段使用教师压缩器生成 $(x,y)$ 对，对学生压缩模型做标准 next-token cross-entropy 训练；历史压缩时 $x=h_t,y=h'_t$，观察压缩时 $x=(h_{t-1},o_t),y=o'_t$。

实验关键数据¶

主实验¶

主结果覆盖 AppWorld、OfficeBench 和 8-objective QA。下面选取核心表格中的代表性数字，重点看任务性能与峰值 token 的权衡。

Benchmark / 设置	方法	任务指标	Steps	Peak tokens	Dependency	说明
AppWorld / history / gpt-4.1	No compression	56.0 Acc	16.14	9.93K	5.96M	完整上下文上界，成本最高
AppWorld / history / gpt-4.1	Prompting	43.5 Acc	24.01	6.93K	5.29M	普通压缩显著掉成功率
AppWorld / history / gpt-4.1	Acon UT	51.2 Acc	20.92	7.17K	4.49M	token 降低且中等难度任务更稳
AppWorld / history / gpt-4.1	Acon UT+CO	56.5 Acc	22.82	7.33K	4.69M	达到或略超完整上下文，同时峰值 token 降约 26%
AppWorld / observation / gpt-4.1	Prompting	42.3 Acc	17.38	6.58K	4.09M	普通 observation 压缩仍丢关键信息
AppWorld / observation / gpt-4.1	Acon UT+CO	53.6 Acc	18.12	7.43K	4.93M	比 baseline 压缩更高成功率

OfficeBench 与 8-objective QA 上，Acon 同样改善准确率/效率权衡。

Benchmark	方法类别	主要结果	论文结论
OfficeBench	history compression	Acon 将 peak context 降近 30%，准确率保持 74% 以上	办公任务需要精确信息，UT 通常比过度压缩更稳
8-objective QA	history compression	Acon 在 EM/F1 上超过 no compression，同时 peak tokens 和 dependency 分别降 54.5% 和 61.5%	检索问答中去掉冗余上下文可提升事实聚焦
小 agent Qwen3-14B	distilled compressor + compressed trajectories	AppWorld 从 25.6% 到 33.9%，8-objective QA EM 从 0.158 到 0.23	压缩能缓解小模型的长上下文干扰
压缩器成本	gpt-4.1-mini / Qwen3-14B distill	成本从 gpt-4.1 的 $0.045 降到 $0.014 或 $0.0004	蒸馏显著降低压缩模块开销

消融实验¶

论文主要分析 compression threshold、prompt optimizer 和实际 API/延迟成本。

消融维度	配置	AppWorld 平均 Acc	结论
Prompt optimizer	o3 + contrastive feedback	51.2	默认设置最好
Prompt optimizer	o3，无 contrastive	50.6 (-0.6)	只看失败轨迹不如成功/失败对比
Prompt optimizer	gpt-4.1 + contrastive	47.6 (-3.6)	优化器模型弱一些仍可用，但指南质量下降
Prompt optimizer	gpt-5 + contrastive	50.6 (-0.6)	不同强模型差距小于是否有对比反馈

实际效率设置	API cost / task	Latency / task	说明
No Compression	$0.331	73.24s	无压缩器调用，token 成本高
Acon history	$0.285	87.68s	降低 API 成本，但多一次压缩调用带来延迟
Acon observation	$0.272	101.92s	成本最低，延迟最高

阈值分析	观察	启示
阈值过小	token 更少，但压缩调用更频繁且准确率下降	过早压缩会把仍有用的信息改写掉
阈值过大	准确率更接近 no compression，但成本较高	压缩收益不足
中等阈值	history 4096、observation 1024 效果最好	作为默认部署折中

关键发现¶

Acon 最重要的收益不是单纯省 token，而是把上下文变得更“任务相关”。在 AppWorld hard/medium 等长轨迹上，普通压缩会严重掉分，Acon 能保留关键状态。
UT 和 CO 是可选择的 trade-off。AppWorld 这类工具输出冗余多的环境适合 UT+CO；OfficeBench 和 QA 这种细节敏感任务中，UT 往往更稳。
压缩器可以小模型化。蒸馏后的小压缩器保留超过 95% 教师表现，把压缩成本降到接近可忽略，但仍会引入额外延迟。
小 agent 受益尤其明显。压缩后的轨迹减少 distractor，让 Qwen3-14B 这类较小模型在长程任务中更容易做对决策。

亮点与洞察¶

这篇论文把“压缩 prompt 怎么写”从手工规则变成了可优化对象，而且优化信号来自 agent 真正失败的轨迹，比泛泛总结更贴近任务。
失败对比的设计很实用。完整上下文成功、压缩上下文失败时，差异几乎就是压缩器的错误定位，这比只看最终 reward 更容易转成自然语言反馈。
Acon 不是和 agent 绑死的模型优化方法。它不要求访问 agent 权重，因此对 API LLM、闭源模型和已经部署的 agent 系统都更现实。
压缩在这里还有“去噪”作用。实验中部分压缩设置超过 no compression，说明长上下文并不总是信息越多越好，保留合适状态有时比保留全部上下文更利于推理。

局限与展望¶

Acon 需要训练任务 rollout 来收集成功/失败对比，虽然比 RL 轻，但仍依赖 benchmark 或可重复环境。
压缩引入额外延迟。即使 API 成本下降，真实交互系统可能更在意 wall-clock latency，需要异步压缩、缓存或更小压缩器进一步优化。
指南优化依赖强 LLM 作为 optimizer。论文显示 gpt-4.1 可替代 o3 但性能下降，说明优化器质量仍是瓶颈。
目前实验主要是文本工具环境，尚未覆盖更复杂的多模态 agent、浏览器 GUI、大规模代码仓库等上下文结构。
压缩错误很难完全避免。高保真任务中 CO 可能删掉细微事实，因此部署时需要根据任务风险选择保守或激进压缩策略。

评分¶

新颖性: ⭐⭐⭐⭐☆ 用轨迹对比做自然语言压缩指南优化，切中长程 agent 的真实痛点。
实验充分度: ⭐⭐⭐⭐☆ 覆盖三个长程 benchmark、两类压缩、小模型蒸馏和成本分析；真实开放环境仍可更多。
写作质量: ⭐⭐⭐⭐☆ 问题、方法和实验都比较清楚，附录表格丰富；个别符号和 prompt 优化流程读起来略密。
价值: ⭐⭐⭐⭐⭐ 对长程 LLM agent 的部署成本、上下文干扰和小模型可用性都有直接帮助。