ACON：微软的 Agent 上下文压缩框架——从失败中学会"该记什么"
> 来源: arXiv:2510.00615
> 作者: Minki Kang 等（Microsoft Research / KAIST）
> 代码: github.com/microsoft/acon
> 发布时间: 2025-10-01（v2: 2025-10-17）
> 研究时间: 2026-03-30
🎯 一句话版本
ACON 是微软做的一个 Agent 上下文压缩框架——让 AI agent 在长任务中把历史和观察压缩成简报，减少 26-54% 的 token 消耗。核心巧思：对比"用全量上下文能成功、压缩后却失败"的案例，让大模型自己分析"压缩时丢了什么关键信息"，然后自动优化压缩策略。
🧨 问题：Agent 的上下文越跑越长
LLM agent 在执行长任务时（如操作 App、办公自动化），每一步都会产生新的 action + observation，上下文不断膨胀。
后果：
- 成本飙升：一个 AppWorld 任务平均 42.5 次 API 调用，peak token 接近 1 万
- 效率下降：长上下文里关键信息被淹没
- 小模型直接崩：上下文超出能力范围
现有方案（FIFO 截断、检索、LLMLingua 等）效果都不好——accuracy 从 56% 暴降到 27-45%。
🔧 ACON 的解法：从失败中学习压缩策略
核心思路
不是手写压缩规则，而是让大模型自己学会该保留什么。
Step 1: 同一批任务跑两遍
├── 全量上下文 → 成功 ✅
└── 压缩上下文 → 失败 ❌
Step 2: 对比分析——"失败是因为压缩丢了什么？"
→ 生成自然语言 Feedback
Step 3: 用 Feedback 更新压缩指南 P
→ 下次压缩时保留这些关键信息
Step 4: 蒸馏到小模型
→ 运行时开销大幅降低
两阶段优化
UT（Utility Maximization）：从压缩失败中学习
- 收集"全量成功 + 压缩失败"的对比案例
- 让 optimizer LLM（用的 o3）分析失败原因
- 生成更新后的压缩指南——比如"记录运行时变量"、"保留 email ID、token、文件路径"
CO（Compression Maximization）：从压缩成功中学习
- 收集"压缩后仍然成功"的案例
- 分析哪些压缩内容实际没被用到
- 进一步精简，减少不必要的保留
两步交替 → 既不丢关键信息，又不留冗余。
蒸馏到小模型
大模型压缩器（gpt-4.1）太贵，所以蒸馏到小模型：
| 设置 | 详情 |
|---|---|
| 学生模型 | Qwen3-14B / Qwen3-8B / Phi-4 |
| 方法 | LoRA fine-tune（rank=16, α=32） |
| 训练 | 3 epochs, lr=1e-4, AdamW |
| 硬件 | 1× A100 80GB |
| 效果 | 保留 >95% teacher 性能 |
📊 实验结果
AppWorld（9 个模拟 App，平均 42.5 次 API 调用/任务）
| 方法 | Accuracy | Peak Tokens | 变化 |
|---|---|---|---|
| **不压缩** | 56.0% | 9,930 | — |
| FIFO（截断旧的） | 45.8% | 6,730 | accuracy -18% |
| Retrieval（检索） | 27.4% | 8,390 | accuracy -51% |
| LLMLingua | 39.3% | 7,500 | accuracy -30% |
| **ACON UTCO** | **56.5%** | **7,330** | **accuracy +0.5%, tokens -26%** |
ACON 是唯一一个不降 accuracy 还减了 26% token 的方法。
OfficeBench（办公自动化）
| 方法 | Accuracy | Peak Tokens |
|---|---|---|
| 不压缩 | 76.84% | 7,270 |
| ACON UT | 74.74% | 4,930（-32%） |
8-objective QA（多目标问答）
| 方法 | EM | Peak Tokens |
|---|---|---|
| 不压缩 | 0.366 | 10,350 |
| ACON UTCO | 0.365 | 4,760（**-54%**） |
8-objective QA 上压缩效果最猛——token 砍掉一半多，EM 几乎不变。
蒸馏效果
| 压缩器 | AppWorld Acc | 相对 Teacher |
|---|---|---|
| gpt-4.1（teacher） | 56.5% | 100% |
| Qwen3-14B（student） | 54.2% | 96.2% |
| Qwen3-8B（student） | 53.1% | 94.0% |
14B 蒸馏模型保留了 96% 性能，可以本地跑，不需要调 API。
🏗️ 技术细节
压缩触发条件
| Benchmark | 历史阈值 Thist | 观察阈值 Tobs |
|---|---|---|
| AppWorld | 4,096 tokens | 1,024 tokens |
| OfficeBench | 4,096 tokens | 512 tokens |
| 8-obj QA | 2,048 tokens | 400 tokens |
超过阈值才触发压缩，避免短上下文的不必要开销。
优化器选择
论文测试了多个 LLM 作为 optimizer：
| Optimizer | AppWorld Acc |
|---|---|
| **o3** | **51.2%** |
| gpt-5 | 47.6% |
| gpt-4.1 | 45.2% |
o3 作为优化器效果最好——推理能力强的模型更擅长分析"失败原因"。
💡 与我们的关联
1. OpenClaw 的 context compaction 就是这个方向
OpenClaw 内置了 context compaction（当对话太长时自动压缩历史）。ACON 的方法比简单截断/摘要更科学——从失败中学习该保留什么。如果 OpenClaw 未来升级 compaction 策略，ACON 是很好的参考。
2. 我们的 Qwen3.5:27b 可以当蒸馏目标
ACON 蒸馏到 Qwen3-14B 就保留了 96% 性能。我们 ub2 上跑的 Qwen3.5:27b 参数量更大，理论上可以做更好的蒸馏压缩器。这给我们的本地模型增加了一个实用方向——不只是对话，还能做 context 压缩。
3. "对比失败"的方法论可以泛化
ACON 的核心思路——"对比成功和失败，分析差异，生成改进策略"——不只适用于上下文压缩。我们的 agent 工作流、prompt 优化、cron 任务设计都可以借鉴这种 failure-driven optimization。
4. witcheer 的本地压缩实践
之前调研的 witcheer 设置里，用 Qwen3.5:4b 做本地压缩（compression_threshold: 0.50）。ACON 提供了更系统化的方案——不是随便压，而是有指南的压。
📊 评分
| 维度 | 评分（/10） |
|---|---|
| 技术深度 | 9.0 — 完整的优化框架 + 蒸馏 pipeline + 3 个 benchmark |
| 创新性 | 8.5 — "从失败中学习压缩策略" + 自然语言空间优化 |
| 实用性 | 8.0 — 开源代码，可直接复现；但需要先跑对比轨迹 |
| 实验质量 | 9.0 — 3 个不同 benchmark、完整 ablation、蒸馏对比 |
| 与我们的相关度 | 7.5 — 方向一致（agent context 管理），但我们暂时没有这个级别的需求 |
| **综合** | **8.5** |
报告由深度研究助手自动生成 | 2026-03-30
来源: arXiv:2510.00615 / GitHub