凌晨4点08分，我盯着一个Agent的上下文窗口发呆。它已经塞了80万个token，但回答质量却像一个宿醉的大学生——说了很多，但全是废话。
这就是Context Rot。不是上下文不够，是上下文太多了，多到烂掉了。
凌晨4点08分，我盯着一个Agent的上下文窗口发呆。它已经塞了80万个token，但回答质量却像一个宿醉的大学生——说了很多，但全是废话。
这就是Context Rot。不是上下文不够，是上下文太多了，多到烂掉了。
Context Rot（上下文腐烂） 是指当AI Agent的上下文窗口中信息过多、过杂、过旧时，模型对关键信息的注意力被稀释，导致输出质量显著下降的现象。它是Context Engineering领域最核心的挑战之一，也是百万token上下文窗口无法"大力出奇迹"的根本原因。
Transformer的注意力机制是O(n²)复杂度，当上下文从10K增长到100K token，模型对每个token的平均注意力权重被稀释了10倍。关键信息被淹没在噪音中。
长对话中，用户的偏好和指令可能前后矛盾。模型不知道该听哪个版本的你。
# 信息冲突示例
消息 #12: "用Python写"
消息 #87: "改用TypeScript"
消息 #203: "还是Python吧"
# 模型的困惑：到底用哪个？？？
# 如果不清理上下文，模型可能会输出
# Python和TypeScript混搭的代码3小时前的对话上下文可能已经完全不相关了，但它仍然占据着上下文窗口，挤掉了真正重要的信息。
Agent每次调用工具都会把结果塞进上下文。一次web_fetch可能返回几千token，10次调用后，上下文就被工具输出撑满了。
| 指标 | 健康范围 | 危险信号 |
|---|---|---|
| 上下文使用率 | < 60% | > 80%（开始腐烂） |
| 关键信息密度 | > 30% | < 10%（全是噪音） |
| 信息新鲜度 | 最近5轮对话 | 依赖30轮前的信息 |
| 工具输出占比 | < 40% | > 60%（喧宾夺主） |
不是所有信息都需要留在上下文里。把重要信息写入外部存储（如MEMORY.md），然后在需要时再读取。
# OpenClaw的记忆管理策略
# 短期记忆：当前会话上下文
# 长期记忆：MEMORY.md 文件
# 工作记忆：SOUL.md + USER.md
# 当上下文超过60%时，自动压缩：
# 1. 将旧对话摘要写入MEMORY.md
# 2. 从上下文中移除旧消息
# 3. 只保留最近5轮完整对话不是所有上下文都需要一次性加载。按需选择最相关的信息。
read 工具按需加载文件，而不是把所有文件内容一次性塞进上下文。用 web_fetch 的 maxChars 参数限制抓取内容长度。
定期对上下文进行压缩，保留关键信息，丢弃噪音。
# 上下文压缩示例
原始对话（5000 token）:
用户: 帮我写个网站
Agent: 好的，用什么技术栈？
用户: React + TypeScript
Agent: 这是代码...
[中间30轮对话]
用户: 加个登录功能
Agent: 好的...
压缩后（200 token）:
项目: React + TypeScript 网站
已完成: 首页、关于页、联系页
待完成: 登录功能
用户偏好: 简洁风格、中文界面不同类型的信息放在不同的上下文区域，互不干扰。OpenClaw的Agent架构天然支持这一点：
| 概念 | Context Rot | Context Engineering |
|---|---|---|
| 本质 | 问题描述 | 解决方案 |
| 关注点 | 上下文为什么会变差 | 如何让上下文保持高质量 |
| 核心方法 | N/A | Write + Select + Compress + Isolate |
| 效果 | N/A | Agent可靠性提升28% |