30 秒快速回答

Agent 上下文压缩（Agentic Context Compression）是一套在 LLM 接收输入之前，自动删减、提炼、结构化上下文的工程手段，让 AI Agent 在长任务中既不”跑偏”也不”烧钱”。 它解决的核心问题叫”上下文通胀”（Context Inflation）：一次复杂的 Agent 会话，输入给模型的 Token 可能膨胀到 6 万以上，而其中真正有价值的信息往往不到 15%。压缩技术用一句话概括就是——同样的答案，花更少的 Token，注意力更集中。

为什么长任务会”上下文通胀”？

一个典型的 Coding Agent 单次任务轨迹是这样的：

用户提问 → RAG 检索返回 5000 tokens
        → 工具调用返回 100 条结果（JSON）
        → 日志输出 8000 tokens
        → 读取代码文件 3000 tokens
        → 再次工具调用 → …… → Token 预算爆炸

真实案例中，一个 SRE 故障排查会话的上下文膨胀到了 65,694 tokens。而里面有信息量的部分可能不到 15%——剩下的全是：JSON 数组里 90% 的无关数据、日志里 472 行 “PASS”、Git Diff 中未变更的上下文行。

维度 不压缩（65K tokens） 压缩后（5K tokens）
单次请求成本 高（Claude Sonnet 输入 $3/M） 约降 60-95%
首 Token 延迟 ~8 秒 ~2 秒
注意力质量 关键信息被”噪声淹没” 目标清晰、不易跑偏
上下文窗口 200K 也可能溢出 长期够用

更隐蔽的问题是 Context Poisoning（上下文中毒）：把整个历史全部喂给模型，早期失败的日志和无关的报错会持续干扰模型的判断。2026 年 1 月的 Focus Agent 论文（arXiv:2601.07190）用 SWE-bench Lite 实测证明：在保持同等成功率的前提下，通过主动压缩可减少 22.7% 的总 Token 处理量——说明 Agent 循环中大部分上下文其实是阻碍解题的噪声。

四种主流压缩策略

按”激进程度”从低到高排列，你可以根据场景组合使用：

策略 做法 压缩率 优点 缺点
截断 保留 System Prompt + 最近 N 轮，删掉最早消息 30-50% 简单、零额外调用 早期重要决策会丢失
摘要 用 LLM 把长对话提炼成要点 80-90% 信息密度高 摘要模型可能删错重点
结构化 把对话转成 State（目标/决策/约束/待办） 90%+ 稳定、可存库、可追溯 需要设计 Schema
工具结果压缩 对 API/DB/日志返回做精简后再入上下文 60-95% 直击最大 Token 源头 需按内容类型定制

1. 截断：最简单但最危险

messages = messages[-20:]   # 只保留最近 20 轮

如果用户在第 2 轮说过”数据库必须用 PostgreSQL”，到第 40 轮讨论细节时这段约束已被截掉，Agent 就可能重新推荐 MySQL——这是典型的上下文丢失。

2. 摘要：不能只让模型”随便总结”

直接让模型”总结一下对话”很危险，它可能把”看起来不重要”的信息删掉。正确做法是指定摘要 Schema：

{
  "goal": "设计电商系统",
  "constraints": ["后端Go", "数据库MySQL", "支持微信/支付宝支付"],
  "decisions": ["订单表按用户ID分片"],
  "open_questions": ["支付回调重试策略待定"],
  "tool_results": [],
  "next_action": "设计订单状态机"
}

结构化摘要比自由文本更适合 Agent——它保留了约束和决策，压缩后几百 Token 就能顶几千 Token 的原始对话。

3. 状态化压缩：让 State 取代对话历史

与其保留 100 轮对话，不如把关键信息提取为结构化状态存到 Redis/数据库。Agent 的上下文只保留”当前 State + 最近对话”，而不是整个 Conversation。成熟的 Agent 应该从 “Conversation as State” 升级为 “State + Conversation”——不要让聊天记录承担数据库的职责。

4. 工具结果压缩：最大、也最容易被忽视的 Token 黑洞

Agent 最爆 Token 的地方往往不是聊天，而是工具返回。例如：

# 错误示范：把 DB 返回的 10000 行原样塞给 LLM
result = db.query("SELECT * FROM orders")
context += str(result)   # 灾难

# 正确示范：先聚合，再入上下文
summary = {
    "total": 10000,
    "status_distribution": {"paid": 7820, "pending": 1210, "refunded": 970},
    "top_orders": top_n(result, 5)
}
context += json.dumps(summary)   # 几百 Token 搞定

2026 年最新进展：从工具到新范式

上下文压缩正在从”手动工程”演变成”自主架构”：

  • Focus Agent（2026 年 1 月新论文）：受黏菌生物启发，把上下文 Token 视为稀缺代谢资源，Agent 自主决定何时 Compress（总结关键学习）何时 Withdraw（删除原始日志）。在 SWE-bench Lite 上减少 22.7% Token 且成功率不降。
  • Headroom（GitHub 26K+ Stars）：本地优先的压缩层，内置 6 种自适应压缩器——SmartCrusher（JSON 压缩 70-95%）、CodeCompressor（AST 感知代码折叠）、Kompress（语义压缩）等，配合 CCR 可逆缓存机制，压缩后仍可通过 headroom_retrieve 按需取回原始数据，做到”压缩不丢信息”。
  • MemLayer 等开源记忆库：作为”知识块”把摘要后的上下文推入长期存储，保持活跃窗口精简。

总结

Agent 上下文压缩的三个核心洞察：

  1. 长上下文 ≠ 高效上下文：上下文窗口应被视为”有限预算”而不是”无限仓库”，塞满历史只会稀释注意力、烧掉 Token。
  2. 四类压缩按需组合：截断最省事但有损，摘要和结构化压得狠，工具结果压缩回报最高——先处理工具返回，再谈其他。
  3. 2026 年趋势是”自主压缩”：Focus Agent 证明 Agent 可以自己决定忘什么、留什么；Headroom 等工具把压缩做成标准件，压缩正成为生产级 Agent 的标配能力。

延伸阅读