上下文压缩：让 AI 智能体该忘就忘，又不丢失关键信息
大家好，我是 Rijul。我正开发 git-lrc —— 一个微型的 AI 代码审查工具，每次提交代码时自动运行。它完全免费，源码在 GitHub 上开放。如果觉得有用，请给 git-lrc 点个 Star，帮助更多开发者发现这个项目。欢迎试用并反馈意见。
假设你让 AI 智能体帮你修复一个 API，只给了它一条简单指令：修复 API 500 错误。这个智能体可能会经历这样的工作流程：
Agent：
→ 读取日志
→ 搜索代码库
→ 检查数据库
→ 查看最近的提交记录
→ 运行测试
→ 尝试修复
30 次工具调用之后，智能体的上下文已经变得非常庞大。但其中大部分信息可能已经没用了。智能体不需要一直保留调查中的每一个细节。它不需要：
- 每条日志的每一行
- 所有失败的搜索
- 重复的信息
- 旧的工具输出
- 那些已经不再相关的中间步骤
它真正需要的是 当前的调查状态。
上下文问题
想象一下，智能体在调查过程中累积了 40,000 个 token 的上下文。这些上下文占用了宝贵的空间。随着智能体继续工作，上下文窗口逐渐被填满。最终，智能体可能没有多余空间容纳新信息，进而导致：
- 成本更高
- 处理变慢
- 留给后续工具调用的空间变小
- 重要信息被挤出了上下文
所以，与其把整个历史记录一直带着走，不如对它进行压缩。原本 40,000 个 token 可能变成这样：
目标：
修复 API 500 错误。
已发现：
- 错误在部署 v1.4 后出现。
- 数据库正常。
- 支付服务缺少 PAYMENT_API_KEY。
已尝试：
- 重启服务，没有效果。
下一步：
修复环境配置并重新测试。这就是上下文压缩。
什么是上下文压缩？
上下文压缩不是简单地把内容变短。它的目标是：移除不再有用的信息，同时保留智能体继续工作所需的关键内容。智能体不需要记住每一步做了什么，它只需要记住那些步骤得出的重要结论。
三种基本的上下文压缩技术
1. 剪枝（Pruning）
最简单的技术就是剪枝——移除不再有用的信息。比如：
Agent：→ 搜索 config.yaml → 没找到
Agent：→ 搜索 settings.yaml → 没找到
Agent：→ 搜索环境变量 → 发现 PAYMENT_API_KEY 缺失
一旦智能体找到了真正的原因，那些失败的搜索记录可能就没用了，可以从当前上下文中删除。重要的信息是：PAYMENT_API_KEY 缺失。剪枝的本质就是：移除智能体不再需要的内容。
2. 提炼（Distillation）
与其保留整个对话，不如把它转换成结构化的摘要。例如：
目标： 修复 API 500 错误
事实：
- 数据库正常
- 错误在部署 v1.4 之后开始出现
- PAYMENT_API_KEY 缺失
决策：
- 不要修改数据库
- 修复环境配置
已完成：
- 检查了日志
- 验证了数据库连接
- 检查了环境变量
下一步：
- 添加 PAYMENT_API_KEY
- 重启服务
- 重新测试 API
原本的调查可能耗费了几千个 token，但提炼后的状态包含了智能体继续工作所需的信息。一个有用的结构可以是：目标 → 事实 → 决策 → 已完成工作 → 下一步操作。提炼的本质就是：将长历史转化为结构化状态。
3. 泛化（Generalisation）
有时调查中包含了可以在未来场景中复用的知识。例如：
具体经验：缺少 API 密钥导致支付 API 失败。
↓
可复用知识：
上下文压缩：让AI代理忘掉不重要的信息，同时保留关键脉络
当API集成失败时，检查环境变量。代理不再只记住某次具体事件中发生了什么，而是从这次经验中提炼出一条通用规则。这可以用于：
- 未来的排查工作
- 运维手册
- 代理技能
- 长期记忆
泛化本质上就是：把一次具体的经验变成可复用的知识。
核心思路
AI代理不需要永远携带全部历史记录。它只需要保留那些仍然有用的部分。一个长链条的排查过程可能长这样：
40,000 token 的原始历史
↓
上下文压缩
↓
目标 + 事实 + 决策
↓
下一步行动
代理随后可以在更小的上下文窗口中继续工作，同时保留真正重要的信息。上下文压缩不是让你忘掉一切，而是让你忘掉该忘的东西。