上下文狂奔：当"买得起"变成"用不好"
2026年，GPT-5.4发布100万token上下文窗口，开发者们欢呼雀跃。终于，可以让AI读完整本书、分析整个代码库、处理超长对话历史了！
但一个残酷的数据很快浇灭了热情：研究表明，当上下文从32k扩展到1M时，模型在信息检索任务上的准确率从97.2%暴跌到36.6%。这不是成本问题——是能力退化。
为什么会这样？答案藏在AI模型的工作原理中。
“迷失在中间”：上下文越多，效果越差
注意力稀释现象
大语言模型的注意力机制就像人类的"工作记忆"——容量有限，且对信息位置敏感。研究发现，模型对上下文两端的信息更敏感，而对中间部分存在"盲区"。
当Agent执行任务时，情况更糟：
- 读取文件：一个grep命令可能输出数千行
- 浏览网页：页面HTML包含大量噪声
- 执行代码：终端输出、错误日志不断堆积
这些信息源源不断地涌入上下文窗口，其中大部分是低价值的"噪声"。模型被迫在数百万token中寻找"信号"，如同大海捞针。
数据说话
| 上下文大小 | 信息检索准确率 | 相对下降 |
|---|---|---|
| 4K tokens | 98.5% | 基准 |
| 32K tokens | 97.2% | -1.3% |
| 128K tokens | 76.8% | -22% |
| 1M tokens | 36.6% | -62.7% |
这不仅是学术研究——在实际Agent应用中，开发者普遍反映"上下文越长，幻觉越多"。
三种解法：压缩的艺术
方案一：RAG（检索增强生成）
思路：不把所有信息塞进上下文，而是建立外部索引，按需检索。
优点：
- 理论上支持无限数据量
- 检索精度可控
缺点：
- 语义匹配有局限——关键词可能匹配不到
- 需要额外的向量数据库和维护成本
- 对于Agent动态生成的中间结果，索引成本高
适用场景：静态知识库、文档问答
方案二：滑动窗口
思路：只保留最近N个token，丢弃更早的内容。
优点：
- 实现简单，零成本
- 控制上下文大小精准
缺点：
- 丢失历史关联——“刚才说的那件事"可能已被清除
- 无法处理需要跨时间关联的任务
适用场景：简单对话、短期任务
方案三：智能压缩（Context Gateway）
思路：用小语言模型识别上下文中的"信号”，在工具输出进入窗口前进行智能压缩。
GitHub新星项目Context Gateway提出了这个思路：
原始工具输出 → 小模型筛选 → 压缩后的关键信息 → 进入主模型上下文
工作流程：
- Agent执行命令（如grep）
- 原始输出被发送到压缩器
- 小模型提取关键行、去除噪声
- 压缩后的摘要进入主上下文
优点：
- 保留关键信息，丢弃噪声
- 动态适应不同类型的工具输出
- 压缩比可达10:1甚至更高
缺点：
- 增加一次小模型调用（成本较低）
- 压缩可能丢失细节
适用场景：复杂Agent工作流、长任务执行
实战建议：构建"懂事"的Agent
1. 工具输出压缩
# 不要直接把grep结果塞进上下文
raw_output = execute_command("grep -r 'function' ./src")
# 压缩后使用
compressed = compress_tool_output(raw_output, max_lines=50)
2. 结构化存储
用数据库存储Agent需要"记住"的信息，而不是塞进上下文：
短期记忆 → 上下文窗口（快速访问）
长期记忆 → 向量数据库（按需检索）
工作记忆 → 结构化存储（任务状态）
3. 学会遗忘
让Agent定期"总结"并丢弃原始对话：
原始对话（100K tokens）
↓ 压缩
关键决策摘要（5K tokens）
↓ 进入上下文
本质思考：上下文不是"越大越好"
人类的工作记忆也有限——大约7±2个信息单元。但我们不会因此"失忆"，因为我们懂得：
- 忽略无关信息：不会记住路上的每块广告牌
- 压缩关键内容：把对话提炼成要点
- 外部化记忆：用笔记、日历、数据库
Agent也需要同样的"智慧"。100万token不是问题的答案，精准压缩才是。
行动清单
- 检查你的Agent上下文使用情况
- 评估是否需要引入压缩层
- 区分"必须记住"和"可以遗忘"的信息
- 考虑用结构化存储替代纯上下文记忆
上下文膨胀是Agent发展的必经之痛，但压缩技术的成熟将让AI代理真正"懂事"起来。下次当你为模型添加更多上下文时，先问一句：这些真的都需要吗？