Context Rot（上下文腐烂）
上下文腐烂（Context Rot） 指 LLM 随上下文长度增加而出现的性能非线性退化现象。Hong et al.（2025）在 18 个前沿模型（含 GPT-4.1、Claude Opus 4、Gemini 2.5、Qwen3）上的受控实验证实：所有模型在输入增长时都退化，且退化在窗口远未满时即已开始——宣称支持 200K token 的模型可能在 50K 时已出现显著性能损失。退化是连续的，不是到达某个硬上限时的断崖式下跌。
Chroma 在更大规模的测评中评估了 18 个前沿模型（GPT-4.1、Claude 4、Gemini 2.5、Qwen3 等），同样得出相同结论：所有模型性能随输入长度增加而退化。Claude Code 的用户实践也发现：输出质量在上下文容量达到 40–60% 时即开始明显退化——远早于任何硬性上限。
这是任何跨多步累积工具结果、中间推理和文件内容的 Agent 的正常运行条件，而非边缘情况。
两个基础约束
二次注意力成本（Quadratic Attention Cost）：Transformer 的自注意力机制对 n 个 token 计算 n² 对权重。上下文加倍，计算量翻四倍。FlashAttention 等技术优化常数因子，但二次结构是架构性的。这使上下文窗口成为稀缺资源，而非可随意扩充的容器。
U 型注意力曲线（U-Shaped Attention Curve）：Liu et al.（2024）的关键实证——在 20 文档多文档问答中，当相关文档处于上下文中间位置时，准确率比放在开头或末尾低 30% 以上。这一"中间迷失（Lost in the Middle）“效应跨模型、跨任务、跨上下文长度成立，包括专门在长上下文上训练的模型。
实践含义：信息在上下文中的位置与信息存在本身同等重要。一个检索到正确内容但位置放置不当的 Agent，收益接近于零。
上下文腐烂 vs 上下文漂移
两个概念都源于相同的架构约束，但发生在不同时间尺度：
| 维度 | 上下文腐烂 | 上下文漂移（Context Drift） |
|---|---|---|
| 范围 | 单次推理步骤 | 扩展的多轮轨迹 |
| 机制 | 上下文增长 → 检索/推理质量下降 | 压缩摘要引入微小不准确性 → 随轮次复合累积 |
| 症状 | 找不到相关文件；忽略已给出的约束 | 重复已完成的工作；与早期决策矛盾；遗忘动机目标 |
| 检测 | 可在单次运行内测量 | 需要 100+ 轮次的评测（MemBench、MemoryArena） |
| 缓解 | 压缩、检索、渐进披露 | 任何技术都能减慢但无法停止 |
上下文漂移是Context Engineering（上下文工程）单独无法解决的问题，需要 ETCLOVG Taxonomy（ETCLOVG 分类法） 的 O 层（可观测性）和 G 层（治理）提供验证循环和人工检查点作为补充。
缓解技术
上下文压缩（Context Compaction）：当上下文窗口接近上限时，用压缩表示重新初始化。Anthropic Applied AI Team（2025）描述了调优挑战：摘要必须保留架构决策、未解决 bug 和实现细节，同时丢弃工具输出和已合并的中间推理。推荐从最大化召回开始，迭代提高精度——反向操作（从精度开始删除）会导致 Agent 丢失后续需要的上下文且无法恢复。Codex CLI 早期允许用户手动触发 /compact，后来改为在 auto_compact_limit 超过阈值时调用 Responses API（响应 API） 的 compact 端点，用更短的项目列表替换旧输入。
工具结果清除（Tool Result Clearing）：最轻量的压缩形式——Agent 处理后，用紧凑的引用替换完整工具输出。可以持续应用，现为 Anthropic 开发者平台的产品级功能。
子 Agent 上下文隔离：当任务需要深度子话题探索时，将子任务分配给独立的子智能体，让搜索记录、测试日志和详细分析留在子线程，只向编排者返回浓缩结论。编排者因此能把主上下文用于保存需求、约束和决策。摘要长度需要按任务设计，不存在适用于所有工作流的固定 Token 数。
渐进披露（Progressive Disclosure）：不预先加载所有潜在相关信息，而是维护轻量标识符（文件路径、存储查询、链接），在任务展开时按需加载。Claude Code 的混合策略：CLAUDE.md 在会话启动时加载提供项目上下文，glob 和 grep 命令让 Agent 按需加载特定文件内容。
KV-cache 感知设计：Manus 团队将 KV-cache 命中率识别为"生产 AI Agent 最重要的指标”——命中的 token 成本（$0.30/MTok）约为未命中的十分之一（$3.00/MTok）。三条设计规则：保持 prompt 前缀稳定（前缀的单 token 差异会使后续所有内容的缓存失效）；将上下文视为仅追加（修改过去的动作或观察会破坏缓存复用）；使用确定性序列化（JSON 键排序不稳定会静默地使缓存失效）。详见 Prompt Caching（提示缓存）。
为何更大的上下文窗口不能解决问题
上下文腐烂框架解释了为何扩大窗口不是根本解决方案：
- U 型曲线是架构性的：更长的窗口只是把中间位置信息退化的问题推后，而不是消除
- 成本是二次方的：窗口加倍，成本翻四倍，延迟显著增加
- 漂移在压缩时引入：更长的窗口意味着更多轮次才触发压缩，但每次压缩引入的不准确性仍然存在
真正的解决方案是把上下文管理视为状态估计问题：量化每次压缩/检索/遗忘步骤中损失的任务相关信息，并界定 Agent 内部状态与实际任务状态之间的散度。这是Context Engineering（上下文工程）当前研究的前沿开放问题。
相关词条
- Context Engineering（上下文工程） — 管理上下文腐烂的工程方法论
- Agent Memory（Agent 记忆） — 上下文腐烂在长运行循环中演化为细节丢失、目标漂移等遗忘性失效，记忆层是对应的解法
- Prompt Caching（提示缓存） — 长对话中降低重复推理成本的缓存机制
- ETCLOVG Taxonomy（ETCLOVG 分类法） — C 层（上下文管理）和 O 层（可观测性）共同应对上下文腐烂
- Harness Engineering（驾驭工程） — harness 的上下文管理职责
- AI Agent（智能体） — 上下文腐烂对长视野 Agent 的影响
- Subagent（子智能体） — 通过独立线程隔离探索噪声，并向主线程返回蒸馏结果