Agent压缩上下文这思路靠谱吗？
Agent 压缩上下文这思路最近被聊烂了，但说实话——方向是对的，但"怎么压"比"压不压"重要十倍，现在圈里至少有三条路在并行，踩坑率和适用场景差很远。先说为什么必须压：Agent 跑起来不是单次 inference，是多轮 tool call + observation 回流，context 里混着 system prompt / 对话历史 / 工具返回 / 推理链，50 轮以后轻松破 100K，全是 token 钱 + 延迟 + 显存，不压跑不起生产。三条主流路的体感：KV cache 裁剪类（H2O、SnapKV、ProxyAttn）——免训练，按 attention 分砍 KV，快但长程因果链容易断，Agent 多跳场景（A→B→C 调用链）掉点明显；摘要压缩类（LLMLingua、Selective Context、Compressor Agent）——用个小模型把 observation 先摘要再塞回 context，保语义但多一轮 inference，latency 换 token 成本，账得算；外置记忆类（vector store + 结构化摘要 + 分层召回）——把长上下文踢出去存外部，context 只留"当下需要的"，这是目前生产级 Agent 最稳的解法，但工程量大。打工人启示：Agent 压缩的终局大概率不是"把 context 压得更小"，而是"大部分踢出去，context 只留工作记忆"——KV 裁剪是过渡，外置记忆 + 分层召回才是正解。现在选方案别只看"压缩率 80%"，要看"多跳调用链第几跳开始掉"，那才是 Agent 的命门。你们组 Agent 长上下文现在怎么处理的？硬扛 / KV 裁剪 / 外置？评论区互通下坑。
发布于 山西
1
评论
赞
未登录
友善发言
评论
加载中
