论文：ICML 2026 / PMLR 306
arXiv：https://arxiv.org/abs/2510.00615
代码：https://github.com/microsoft/acon
作者：Minki Kang（KAIST，工作完成于 Microsoft 实习期间）、Wei-Ning Chen、Dongge Han、Huseyin A. Inan、Lukas Wutschitz、Yanzhi Chen、Robert Sim、Saravan Rajmohan（Microsoft；Yanzhi Chen 同时来自 University of Cambridge）

如果你在做 LLM Agent / Harness / 长程任务上下文管理，这篇论文很值得读：它不改智能体参数，而是在自然语言空间里优化「压缩指南」，同时压缩 交互历史（history） 与 环境观察（observation），再把优化后的压缩器蒸馏到小模型。

一句话概括：ACON = Agent Context OptimizatioN——根据智能体失败分析，迭代改写压缩指南，在峰值 token 与任务成功率之间拿到更好的折中，并且对专有 API 模型同样适用。

---

1. 背景与动机：长程智能体的上下文会「无限膨胀」

大模型正越来越多地作为智能体部署在动态环境中：规划、选工具、执行动作，再根据反馈修正策略。和「一遍出答案」的聊天或解题不同，长程任务往往会展开几十甚至上百步，并跨多个应用协同。成功高度依赖精确记录动作与观察——丢一个文件路径、API 参数或登录 token，整条流水线就可能失败。

问题在于：交互一积累，上下文就会不受限制地增长，带来两个硬瓶颈。

1. 推理显存 / 计算成本：Transformer 的 KV cache 随上下文变长，长程推理很快变得难以承受。
2. 上下文干扰（distraction）：过长上下文会稀释关键信息，过时或无关细节拖累决策质量。

图：智能体与环境持续交互，动作、观察与思考不断写入上下文，形成不断增长的原始历史（红线：高内存占用）。压缩后用精简历史替换（蓝线），希望在降低峰值 token 的同时保留决策所需信息。

论文特别强调生产力场景（邮件管理、工作流自动化、跨工具协同）。这里的智能体上下文，实际上是环境的 world model：既要保留事实历史，也要保留动作–结果关系、前置条件（例如必须先登录），以及后续决策线索（例如截止日期）。简单截断或通用摘要很容易把这些信号丢掉。

由此引出两个研究问题：

• RQ1：如何优化压缩器，使压缩后仍保留准确决策所需的信息？
• RQ2：如何降低压缩器本身的成本——能否用小模型代替大模型做压缩？

---

2. 核心问题：现有压缩为何不够用？

管理不断增长的上下文并不是新问题，但已有方法大多不是为「多步、异构、状态敏感」的智能体设计的。

• 对话记忆 / 会话摘要（如 MemGPT 一类工作）更强调会话连贯，而非多步状态追踪。
• 文档 / 检索式压缩（如 LLMLingua、LongLLMLingua）常假设单步推理，上下文用完即可丢弃。
• 启发式规则（截断、检索最近 k 轮、固定摘要模板）换环境后容易失效。
• 与策略耦合的模型优化 / RL（如 MEM1、Context-Folding 等）把压缩当作智能体动作的一部分，通常需要更新权重，难用于专有 API 模型；智能体与压缩器也往往绑在同一个可训练模型上。

ACON 走第三条路：不改智能体参数 $\theta$，只在自然语言空间优化压缩指南 $P$。Harness 里的压缩流程通常是「压缩提示词 + 压缩器模型 → 摘要」。记压缩器为 $f(\cdot ;\varphi ,P)$，$\varphi$ 是压缩器权重，$P$ 是自然语言形式的压缩指南。ACON 把 $P$ 当作优化对象，用失败反馈把 $P^{(0)}$ 更新为更好的 $P^{\star }$，而 $\varphi$ 保持不变；必要时再把压缩器蒸馏到小模型。

实验上，论文强调应同时看 任务精度 与 峰值 token（peak tokens），而不是只压长度。Peak tokens 指轨迹中单步上下文的最大长度（不含 system prompt），可近似看成推理时内存峰值。

图：AppWorld 上平均准确率 vs 历史压缩的峰值 token。对 gpt-4.1，ACON 相对朴素提示压缩能在控制 token 成本的同时保住准确率；对蒸馏后的 Qwen3-14B，压缩还能通过减轻干扰提高准确率。

---

3. 方法：历史压缩 + 观察压缩，再用 UT / CO 优化指南

图：ACON 框架概览——同时做历史压缩与观察压缩，并分为「指南优化」与「压缩器蒸馏」两阶段。

3.1 问题形式化

任务建模为 POMDP。智能体 $M$ 的参数 $\theta$ 与系统提示 $P_{\text{agent}}$ 固定，每一步根据历史 $h_{t-1}$ 与最新观察 $o_t$ 生成动作：

$$M(o_t,h_{t-1};\theta ,P_{\text{agent}})\mapsto a_t\text{\hspace{1em}(1)}$$

动态上下文代价定义为各步代价之和，通常与 token 长度成正比：

$$C(H)=\sum _{t=1}^{T}C(h_{t-1},o_t)$$

系统提示的成本是静态的，真正「无界增长」的是交互历史。压缩器 $f(\cdot ;\varphi ,P)$ 只在超阈值时启用，以避免不必要的额外调用：

$$h_t^{\prime }=f(h_t;\varphi ,P_{\text{hist}})\text{if }|h_t|>T_{\text{hist}},\text{else }{h}_t\text{\hspace{1em}(3)}$$

$$o_t^{\prime }=f(o_t,h_{t-1};\varphi ,P_{\text{obs}})\text{if }|o_t|>T_{\text{obs}},\text{else }{o}_t\text{\hspace{1em}(4)}$$

压缩后的 $h_t^{\prime }$ / $o_t^{\prime }$ 会替换原始内容，再进入下一步决策并写入后续历史。实现上，论文还保留最近一对 action–observation，以免丢掉当前状态。

在智能体固定时，目标是最大化任务奖励、最小化上下文代价：

$$\underset{\psi }{\max }\mathbb{E}[R(s_T(\psi ))]-\lambda \mathbb{E}[C(H^{\prime }(\psi ))],\lambda \ge 0\text{\hspace{1em}(7)}$$

其中 $\psi \in (\varphi ,P)$。直接优化很困难：没有压缩金标准、奖励稀疏且只在轨迹结束才出现；若用 RL 更新 $\varphi$，成本高、方差大（压缩质量只能通过最终成败间接评估），也不适用于 API 模型。

因此 ACON 不微调 $\varphi$，只优化自然语言指南 $P$。

3.2 压缩指南优化：对比失败轨迹，做文本空间「梯度」

核心观察是：压缩后的轨迹本身就带着比二值奖励更密的信号。如果同一任务「无压缩成功、有压缩失败」，往往说明压缩丢掉了关键信息。

于是在训练集 $D_{\text{train}}$ 上分别跑无压缩与有压缩轨迹，收集对比子集 $D_{\text{cont}}$。优化器 LLM 对比压缩前后上下文 $H$ 与 $H^{\prime }$，生成自然语言反馈（丢失变量/状态、摘要错误、缺失事实等）：

$$\text{Feedback}=\text{LLM}(\text{Feedback Instruction},H,H^{\prime })\text{\hspace{1em}(8)}$$

再聚合多任务反馈，更新指南（相当于文本空间里的一次 batch 更新）：

$$P^{(1)}=\text{LLM}(\text{Update Inst.},P^{(0)},{\Vert }_{i=1}^n{\text{Feedback}}_i)\text{\hspace{1em}(9)}$$

这个过程分两步，分别对应式 (7) 的两项目标：

• UT（utility maximization）：聚合对比反馈，生成多个候选 $P^{(1)}$ 并选出奖励更好的指南，主要提升任务成功率。
• CO（compression maximization）：只看压缩后仍成功的轨迹，追问「哪些信息真正被用到」，把 $P^{(1)}$ 再写成更短但足够的 $P^{(2)}$，以压低上下文代价。

实验中默认用 o3 做优化器，通常只跑 一轮 UT + 一轮 CO；更新阶段会采样 5 个候选指南，并在训练子集上择优。指南优化本身很轻（论文报告每个 benchmark 通常 不到 2 美元），主要成本仍在收集训练轨迹（例如 AppWorld 训练集上用 gpt-4.1 各跑一遍有/无压缩，约 20 美元，且可摊销或复用已有日志）。

3.3 蒸馏：把优化后的压缩器搬到小模型

大模型反复做压缩仍然贵。ACON 用带 $P^{\star }$ 的教师压缩器，在「压缩后仍成功」的样本上，以交叉熵监督学生模型 ${\varphi }_S$（LoRA），推理时由学生替代教师：

$$f(\cdot ;{\varphi }_T,P)\stackrel{\text{prompt optim.}}{\to }f(\cdot ;{\varphi }_T,P^{\star })\stackrel{\text{distill}}{\to }f(\cdot ;{\varphi }_S,P^{\star })\text{\hspace{1em}(11)}$$

这样决策与压缩可以解耦：大模型当智能体，小模型当压缩器。论文用 LoRA（rank 16）在 Qwen3-14B、Qwen3-8B、Phi-4 等模型上做蒸馏，训练与推理均可在单张 A100 80GB 上完成。

---

4. 实验与结果

4.1 设置速览

基准（平均都需 10+ 步交互；引言也写到各基准通常要 15+ 步）：

• AppWorld：9 个模拟 App（Spotify、Venmo、SimpleNote、Gmail 等）与约 100 个模拟用户，主指标为任务完成准确率；官方划分 90 条训练、168 条 test-normal。
• OfficeBench：Word / Excel / Email 等办公自动化，按涉及 1/2/3 个应用分难度；论文使用 92 条训练、95 条测试（排除需 OCR 的任务）。
• Multi-objective QA（8-objective QA）：一次任务要回答 8 个问题并汇总输出，指标为平均 EM / F1。

效率指标：Steps、Peak Tokens、Dependency（对历史上下文的累积依赖，近似生成动作的累计计算成本）。智能体统一为 ReAct。

基线：No compression、FIFO（保留最近若干轮）、Retrieval（按相似度检索历史）、LLMLingua（抽取式压缩）、Naive Prompting（通用压缩指令）。
ACON 变体：仅 UT；以及 UT 后再做 CO 的 UTCO。默认阈值例如 AppWorld 上 $T_{\text{hist}}=4096$、$T_{\text{obs}}=1024$（OfficeBench / QA 会再下调）。

4.2 大模型智能体：降峰值 token，同时保住甚至抬升成功率

主实验以 gpt-4.1 同时担任 agent 与 compressor。AppWorld 历史压缩的一组关键数字如下（Peak 单位为 $\times 10^3$）：

方法	Acc. ↑	Peak ↓	备注
No compression	56.0	9.93	无压缩上界
FIFO / Retrieval / LLMLingua / Prompting	45.8 / 27.4 / 39.3 / 43.5	6.73–8.39	中等与困难任务掉点更明显
ACON UT	51.2	7.17	先抬成功率
ACON UTCO	56.5	7.33	接近并略超无压缩准确率

对应地，峰值 token 约降 26%（9.93→7.33）。观察压缩上，ACON UTCO 的平均准确率为 53.6，同样优于各压缩基线。

在另外两个基准上：

• OfficeBench：ACON 可将峰值上下文规模降低约 近 30%，准确率仍保持在 74%+（历史压缩 UT 为 74.74，无压缩 76.84）。按难度拆分时，收益在更具挑战的 3-app 任务上更明显。
• 8-objective QA：历史压缩的 ACON UT 在 EM/F1 上超过无压缩（0.373 / 0.494 vs 0.366 / 0.488），同时把 peak tokens 从 10.35 降到 4.71（约 54.5%），dependency 也从 3.32 降到 1.57。

综合三个基准，论文给出的总括是：峰值 token 降低 26–54%，任务成功率优于已有压缩基线。

UT vs UTCO 怎么选？ 这是很有工程味道的一条结论：

• 环境嘈杂、observation 冗余多（如 AppWorld 的冗长 API 输出）→ UTCO 往往更合适，更激进剪枝可能同时提升效率与专注度。
• 高保真信息检索 / 事实敏感任务（如 OfficeBench、8-objective QA）→ UT 更稳妥，过度压缩可能丢掉最终决策所需的细粒度事实。

另外，附录还试过把历史与观察同时压缩：峰值和 dependency 会降得更多，但相对单独压缩更容易伤准确率，需要更谨慎。

4.3 压缩器蒸馏：小模型能顶上

把 UT 后的教师压缩器蒸馏到 Qwen3-14B / Qwen3-8B / Phi-4 等，学生可保留教师 超过 95% 的表现，同时显著降低压缩开销。论文还观察到：即使不做蒸馏，gpt-4.1-mini 在优化指南下也能在 OfficeBench 与 QA 上充当有效轻量压缩器——说明「优化后的指南」本身就很值钱。

成本侧对比更直观（以 API 定价为代理）：gpt-4.1 教师压缩器约 $0.045 / example；换成 gpt-4.1-mini 约 $0.014（降 69.2%）；蒸馏后的 Qwen3-14B 约 $0.0004，相对教师降低约 99.1%。于是昂贵的大模型可以主要留给智能体决策。

也要看到 trade-off：压缩会引入额外调用。AppWorld 上，用 gpt-4.1 agent + Qwen3-14B compressor 时，端到端 API 成本可从约 $0.331/任务降到 $0.285（历史）或 $0.272（观察）；但在本地 A100 上测 wall-clock latency（Qwen3-14B agent + 同尺寸 compressor），中位数会从 73.24s 升到 87.68s / 101.92s。省内存与 token，不等于一定更「快」。

4.4 小模型智能体：压缩也能「治干扰」

小模型对长上下文更脆弱，没有压缩时，Qwen3-14B 一类模型常在中等和困难任务上失败。ACON 在这里的角色更像「均衡器」：给小模型更短但足够的上下文，让它少被干扰，从而更接近大模型的表现。

论文报告，在蒸馏后的 Qwen3-14B agent 上：

• AppWorld：准确率 25.6% → 33.9%，相对提升约 32.4%
• 8-objective QA：EM 0.158 → 0.23，相对提升约 45.6%
• 引言汇总：小 LM 作为长程智能体，AppWorld / OfficeBench / Multi-objective QA 上分别约有 32% / 20% / 46% 的性能提升

一个定性案例也说明「压缩不等于丢信息」。未压缩时，gpt-4.1-mini 反复调用文件系统 API 却不管认证，一直拿到 401；压缩后的历史反而更清楚地保留了关键依赖：需要同时提供用户名和密码、要把返回的 access_token 传入后续调用、supervisor 应用里没有代理 API。于是智能体直接走到正确流程，完成了此前失败的删文件任务。

4.5 若干消融与细节

• 阈值：太小会频繁压缩、伤准确率；太大则省不了多少 token。AppWorld 上中等阈值（历史 4096、观察 1024）折中最好。
• 优化器：默认 o3 + 对比失败反馈 最好（AppWorld 历史压缩平均 Acc. 51.2）；去掉对比反馈为 50.6，换成 gpt-4.1 / gpt-5 分别为 47.6 / 50.6。较弱优化器仍能改进基线指南，只是不如 o3。
• 多轮优化：在 UT+CO 之后再额外跑一轮 UT，附录中出现了性能下降，说明单轮通常已够用。
• 额外 WebVoyager：在网页 AXTree 这类冗长、动态变化的观察上，ACON 相对朴素 prompting 仍能提准（历史压缩 42.9→48.6，观察压缩 45.7→47.1），并明显低于无压缩的峰值 token。指南优化不限于模拟办公场景。
• 与 MEM1 类方法的差异：ACON 不训练智能体、不需要权重与梯度，允许「大模型 agent + 小模型 compressor」，指南优化也不依赖 GPU 上的 RL；代价是自然语言优化缺少严格收敛保证。

---

5. 小结：给 Harness 构建者的启发

ACON 的贡献可以收成四条：统一压缩 history 与 observation；用失败驱动的指南优化（UT / CO），模型无关，可直接用于 API 智能体；再通过蒸馏把压缩模块低成本部署；在 AppWorld、OfficeBench 与 Multi-objective QA 上，峰值 token 降 26–54%，并优于多种压缩基线，对小模型智能体减干扰的收益尤其明显。

若你正在搭自己的 agent harness，比较落地的启发是：

1. 把压缩指南 $P$ 当成一等公民的可优化对象，而不是写死一次的 prompt。用「无压缩成功 vs 有压缩失败」做对比反馈，比只盯二值 reward 信息密度更高。
2. 分开优化「有用」与「更短」：先 UT 保任务，再 CO 压长度；按环境噪声程度在 UT / UTCO 之间切换，不要默认越短越好。
3. 阈值触发 + 保留最近一步：只在超阈值时压缩，并保留最新 action–observation，避免丢掉当前状态。阈值本身也是精度–成本旋钮。
4. agent 与 compressor 解耦：大模型决策、小模型压缩；先优化指南再蒸馏，压缩成本可以降到几乎可忽略。
5. 同时盯 peak tokens、任务成功率，以及压缩引入的延迟 / API 成本。省上下文不等于端到端更快，生成式压缩会多一次模型调用，历史压缩还常常让已有 KV cache 失效。
6. 压缩的目标是澄清依赖，而不只是缩短文本。登录凭证、token、文件路径、前置条件这类「丢了就会翻车」的状态，应该在指南里被显式保护。

局限也说得诚实：实证主要集中在 GPT 系列；自然语言空间优化缺少严格收敛保证；蒸馏与教师仍有差距（论文猜测与每域约 100 条样本的规模有关）；压缩会增加延迟。但对「长程 harness 里怎么系统化地压上下文」这一问题，ACON 给出了一条清晰、可复用、且对 API 模型友好的路径。

---

参考
Kang et al., ACON: Optimizing Context Compression for Long-horizon LLM Agents, Proceedings of the 43rd International Conference on Machine Learning, Seoul, PMLR 306, 2026. arXiv: 2510.00615. Code: https://github.com/microsoft/acon