Agent 上下文压缩：从「背不动」到「拎得清」

>一句话导读：你的 Agent 越跑越慢、越跑越蠢？大概率不是模型变菜了，而是它「背了太多不该背的东西」。本文用三张图，讲清楚为什么需要压缩、怎么压缩、什么时候用什么招。

一、Agent 的「上下文困境」

想象你是一个 Agent（智能体），你的工作是陪用户聊天、查资料、写代码、做分析。

第 1 轮对话，用户问你「今天天气怎么样」。你脑子里只有一句话，轻如鸿毛，健步如飞。

第 10 轮对话，你们已经聊了需求分析、技术选型、代码 review。你脑子里塞了 8K token，开始有点喘了。

第 50 轮对话，加上搜索结果 10 页、代码输出 500 行、中间推理 20 步……你的上下文膨胀到 50K+ token，直接被压垮在地：

这三个痛点，刀刀致命

结论：上下文不是「越多越好」，而是「越精越好」。

二、四大压缩门派，各显神通

面对膨胀的上下文，江湖上形成了四大门派。没有银弹，只有最适合场景的招式。

门派一：摘要法（Summarization）

核心思想：把 50 轮对话「写读后感」，只保留核心结论和关键事件。

怎么实现：

• 每 N 轮对话后，让模型生成一段摘要，替代原始对话
• 可以分层：近期保留原文，中期保留摘要，远期保留「摘要的摘要」

优点：

• 保留语义连贯性，读起来还是「人话」
• 实现简单，几行代码就能跑

缺点：

• 生成摘要本身也要耗 token（虽然比原文少得多）
• 可能丢失细节，比如用户说「不要红色」这种精确偏好

适合场景：对话轮次多、但单轮信息密度中等的场景，比如客服、教育辅导。

门派二：RAG 检索法（Retrieval-Augmented）

核心思想：像图书馆管理员——用户问啥，只找相关的书；不相关的历史，统统留在书架上。

怎么实现：

• 把所有历史对话、文档切分成块，存入向量数据库
• 用户提问时，先把问题向量化，去库里「搜相似」
• 只把最相关的 Top-K 片段塞进上下文

优点：

• 精准命中，噪音极少
• 理论上支持无限长的历史（只要硬盘够大）

缺点：

• 检索质量决定上限，「搜不到」比「没压缩」更致命
• 需要额外维护向量数据库，架构复杂度上升

适合场景：研究分析、知识问答、需要查阅大量资料的场景。

门派三：结构化记忆（Structured Memory）

核心思想：把聊天历史「翻译」成键值对、图谱、待办清单，像给 Agent 装了一个「记事本」。

怎么实现：

{"用户偏好":{"回答风格":"简洁","编程语言":"Python"},"当前任务":"写一个爬虫脚本","已尝试方案":["方案A: requests (失败-被封IP)","方案B: selenium (进行中)"],"待办事项":["1. 加代理池","2. 加随机延迟"]}