Agent 上下文压缩从「背不动」到「拎得清」一句话导读你的 Agent 越跑越慢、越跑越蠢大概率不是模型变菜了而是它「背了太多不该背的东西」。本文用三张图讲清楚为什么需要压缩、怎么压缩、什么时候用什么招。一、Agent 的「上下文困境」想象你是一个 Agent智能体你的工作是陪用户聊天、查资料、写代码、做分析。第 1 轮对话用户问你「今天天气怎么样」。你脑子里只有一句话轻如鸿毛健步如飞。第 10 轮对话你们已经聊了需求分析、技术选型、代码 review。你脑子里塞了 8K token开始有点喘了。第 50 轮对话加上搜索结果 10 页、代码输出 500 行、中间推理 20 步……你的上下文膨胀到 50K token直接被压垮在地这三个痛点刀刀致命痛点通俗解释技术真相钱包在哭泣每多 1K tokenAPI 账单上就得多掏一次钱输入 token 按量计费50K 上下文 ≈ 5K 的 10 倍成本用户等到怀疑人生模型读长文本像读字典越读越慢长序列注意力计算复杂度 O(n²)推理时间指数级增长注意力「失忆」信息淹没在噪音里关键指令被忽略LLM 的「有效上下文」远小于理论值中间内容最易被遗忘结论上下文不是「越多越好」而是「越精越好」。二、四大压缩门派各显神通面对膨胀的上下文江湖上形成了四大门派。没有银弹只有最适合场景的招式。门派一摘要法Summarization核心思想把 50 轮对话「写读后感」只保留核心结论和关键事件。怎么实现每 N 轮对话后让模型生成一段摘要替代原始对话可以分层近期保留原文中期保留摘要远期保留「摘要的摘要」优点保留语义连贯性读起来还是「人话」实现简单几行代码就能跑缺点生成摘要本身也要耗 token虽然比原文少得多可能丢失细节比如用户说「不要红色」这种精确偏好适合场景对话轮次多、但单轮信息密度中等的场景比如客服、教育辅导。门派二RAG 检索法Retrieval-Augmented核心思想像图书馆管理员——用户问啥只找相关的书不相关的历史统统留在书架上。怎么实现把所有历史对话、文档切分成块存入向量数据库用户提问时先把问题向量化去库里「搜相似」只把最相关的 Top-K 片段塞进上下文优点精准命中噪音极少理论上支持无限长的历史只要硬盘够大缺点检索质量决定上限「搜不到」比「没压缩」更致命需要额外维护向量数据库架构复杂度上升适合场景研究分析、知识问答、需要查阅大量资料的场景。门派三结构化记忆Structured Memory核心思想把聊天历史「翻译」成键值对、图谱、待办清单像给 Agent 装了一个「记事本」。怎么实现{用户偏好:{回答风格:简洁,编程语言:Python},当前任务:写一个爬虫脚本,已尝试方案:[方案A: requests (失败-被封IP),方案B: selenium (进行中)],待办事项:[1. 加代理池,2. 加随机延迟]}