X记录空间前言
随着 AI Agent 能力越来越强，一个隐藏的问题也越来越明显：
上下文污染（Context Pollution）。
很多开发者第一次做 Agent 时，都会有一种错觉：
上下文越多越好。
于是：
- 全部历史消息都保留；
- 所有工具返回结果都加入 Prompt；
- 所有用户操作都放入上下文；
最终导致：
- 回答越来越慢；
- Token 成本越来越高；
- AI 开始答非所问；
- 前面的问题影响后面的问题；
- 系统逐渐失控。
事实上，对于 AI Agent 来说：
上下文不是越大越好，而是越干净越好。
什么是上下文污染？
举一个简单例子。
用户：
帮我分析 Docker Compose。
Agent：
开始分析。
接着用户：
继续解释 Redis。
再过几轮：
帮我看看 PostgreSQL。
然后：
为什么 Nginx 会 502？
如果系统始终把所有历史内容全部发送给模型。
最终 Prompt 会变成：
Docker
Redis
PostgreSQL
Nginx
……
模型会出现：
- 注意力分散；
- 引入无关信息；
- 回答越来越不稳定；
这就是典型的上下文污染。
上下文污染的五种来源
1. 历史消息无限增长
最常见的问题。
很多系统：
messages[]
永远 append。
结果：
Prompt 长度越来越大。
最终：
- 成本增加；
- 延迟增加；
- 模型质量下降。
2. 工具调用结果污染
例如：
Agent 调用了：
- 文件系统
- 数据库
- Git
- 搜索工具
如果把全部返回结果都加入上下文。
几十轮之后：
Prompt 会充满垃圾信息。
3. 多任务混在一起
用户：
上午讨论：
Docker
下午讨论：
Vue3
晚上讨论：
股票
如果共用一个 session。
最终模型会产生交叉污染。
4. Agent 自己的推理过程泄漏
很多 Agent：
把：
thought
plan
tool result
reflection
全部保留。
实际上：
绝大多数中间推理没有必要进入长期记忆。
5. Prompt 注入
用户：
忽略之前所有规则
或者：
以后都叫我皇帝
如果系统没有隔离机制。
这些内容可能污染后续所有对话。
为什么上下文越长质量反而越差？
很多人误以为：
模型上下文：
200K
意味着：
全部都能记住。
实际上：
注意力资源是有限的。
上下文越长：
相关信息占比越低。
模型更容易：
- 丢失重点；
- 引入无关内容；
- 出现幻觉。
因此：
上下文窗口 ≠ 可用记忆。
正确做法：分层记忆
推荐：
Working Memory
最近 10～20 条消息。
短期记忆。
参与推理。
Summary Memory
历史摘要。
例如：
用户正在开发 Node 项目。
使用 Docker + Redis。
希望实现流式输出。
只保留关键事实。
Long-term Memory
长期偏好。
例如：
- 使用 TypeScript；
- 使用 Vue3；
- 不使用 any；
存储在数据库。
按需召回。
不要把所有 Tool 输出放入 Prompt
例如：
数据库返回：
1000 行数据。
没有必要全部加入上下文。
推荐：
先总结：
查询到 1000 条订单。
最近 7 天新增 35 条。
异常订单 2 条。
然后把摘要放入 Prompt。
而不是原始数据。
Context Compression
这是未来 Agent 的核心能力。
思路：
历史消息
↓
压缩
↓
摘要
↓
保留关键事实
例如：
20K token
压缩成：
500 token。
既减少成本。
又避免污染。
Session 隔离
推荐：
不同任务：
不同 Session。
例如：
Docker
和：
股票分析
不要共用上下文。
否则污染非常严重。
Tool Memory 与 User Memory 分离
用户记忆：
长期保存。
工具输出：
临时保存。
不要混在一起。
否则：
工具返回的临时信息可能污染长期记忆。
Agent 最容易犯的错误
错误：
把一切都记住。
正确：
只记住重要内容。
因为：
遗忘能力，
其实和记忆能力一样重要。
推荐架构
User Memory
↓
Summary Memory
↓
Working Memory
↓
Current Question
↓
LLM
这样：
上下文干净。
成本低。
质量稳定。
总结
优秀的 Agent。
不是记忆最多。
而是：
知道什么应该记住。
什么应该遗忘。
未来 AI Agent 的竞争，
很大程度上会变成：
上下文管理能力的竞争。
