概念Context Rot长上下文上下文工程LLMAgent

Context Rot（上下文腐烂）

随着输入 token 增多，LLM 输出质量会持续下降——即便远没到上下文窗口上限。Chroma 实测 18 个前沿模型无一幸免。对编码 agent 而言，这是首要失败模式，比模型能力更关键。

什么是 Context Rot

Context Rot（上下文腐烂）指随着输入 token 增多，LLM 输出质量持续下降的现象——而且是在远没到上下文窗口上限时就开始下降。这个词由 Chroma 在 2025 年的技术报告中提出并系统验证：他们测了 18 个前沿模型（含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3），没有一个例外，全都随输入变长而变差。

关键区分：Context Rot 不是上下文溢出。

	上下文溢出	Context Rot
触发	超过模型最大 token 上限	远未到上限就发生
表现	截断/拒绝，二元失败	渐进式质量下降
例子	200K 窗口塞 210K	200K 窗口塞 50K 就开始退化

一个 200K 窗口的模型，可能在 50K token 时就出现明显退化。下降是连续的，不是悬崖式的。

为什么重要

很多团队的误区是「我选了 128K / 1M 上下文的模型，应该够用了」，然后塞满上下文却纳闷质量为什么变差。Context Rot 的核心洞察是：

容量是错误的指标，信噪比才决定输出质量。

对编码 agent 来说这尤其致命——Context Rot 是 agent 的首要失败模式，比模型能力、推理能力更关键。模型本身够聪明能解决问题，前提是上下文保持干净。但 agent 在搜索、探索、回溯过程中会不断累积噪声，这些噪声直接拖垮后续每一步的输出。

表现形式

Chroma 的研究揭示了几个非均匀退化的维度：

needle-question 相似度：问题和目标信息的语义匹配度越低，越长的上下文越捞不出来（经典 NIAH 测的是字面匹配，掩盖了这个问题）
干扰项（distractors）：上下文里有相似但无关的内容时，越长越容易被带偏
lost-in-the-middle：信息放在长上下文中间时最容易被忽略，准确率可掉 30%+
噪声类型有别：互相抵消的操作（如成对的增删）比单纯的无关文本（如 print 语句）更严重地拖垮性能

社区的真实观察也印证这点：Claude Code 在多次 compaction 后会越来越差；与其让模型在长上下文里硬找，不如先让它总结、再基于总结提问、需要时再喂原文（RAG 式或简单 agent 循环）效果更好。

怎么缓解

Context Rot 是「上下文工程」存在的根本原因。常见手段：

控制信噪比：只放当前任务真正需要的内容，无关历史及时清掉
RAG 检索：用 RAG 按需取相关片段，而不是一股脑全塞进去
总结压缩：长对话/长文档先总结，基于总结工作，需要细节时再拉原文
分而治之：把大任务拆成多个干净上下文的子任务（多 agent 编排实测比单 agent 提升显著）
主动清理：agent 探索产生的噪声（失败的尝试、无关的文件内容）用完就清，别让它留在上下文里腐烂

这些都属于 Context Engineering 的范畴。

对模型选型的启示

别只看上下文窗口大小：1M 窗口不等于能有效用满 1M。看的是模型在长上下文下的实际保持能力。
长上下文 ≠ 不需要 RAG：「长上下文会杀死 RAG」是误解。恰恰相反，Context Rot 证明了即便有大窗口，按需检索 + 控制信噪比仍是刚需。
compaction 不是免费的：Claude Opus 4.5、GPT-5.1-Codex-Max 的 compaction 机制能延长工作时长，但每次压缩都可能损失信息，长任务质量仍会缓慢下滑。

常见误区

「上下文没满就没事」：错。退化在远未满时就开始，容量充足不代表质量稳定。
「换个更大窗口的模型就行」：错。Chroma 测的 18 个模型全部退化，换大窗口治标不治本，得做上下文工程。
「RAG 过时了」：错。Context Rot 反而强化了 RAG 和上下文工程的价值。
「把所有文档一次喂进去最省事」：短期省事，长期质量差。先总结后按需取原文通常更准。