Context Rot：AI Agent 为何在长对话中质量下降

Context rot 是 LLM 输出质量随上下文增长而逐渐退化的现象——模型开始遗漏、误读或忽略窗口中明明存在的信息。它在窗口填满之前很久就开始显现，这也是为什么一个在前一小时表现出色的 Agent 会在第二小时开始出纰漏。没有任何东西损坏，也没有数据丢失——模型只是比会话开始时更差地利用自己的上下文。

TL;DR：LLM 的输出质量随上下文窗口填满而下降，尽管它所需的信息仍然存在于窗口之中。原因在于有限的注意力预算，而非有限的记忆：窗口中的每个 token 都在争夺模型的注意力。解决方法是管理进入上下文的内容，而非扩大窗口。

什么是 Context Rot？

Context rot 是模型在其上下文窗口中准确使用已有信息的能力随 token 数量增长而衰退的现象。指令被丢弃，记忆变得模糊，尽管每个相关 token 在技术上仍然可供模型使用。

这个术语源于长上下文 recall 研究，如今已成为标准的工程词汇；Anthropic 自己的模型文档现在也以其名称来定义它。它与幻觉（hallucination）不同——幻觉是捏造，可以在任何上下文长度下发生；也与模型老化（model staleness）不同——后者关乎训练数据截止于某个日期。Rot 特指单一增长会话内部发生的事情。

它之所以重要，是因为退化的输出有人力代价。在 Sonar 2026 年针对超过 1100 名开发者的代码状态调查中，96% 表示他们不完全信任 AI 生成的代码，仅有 48% 在提交前始终验证。一个腐化的会话产生的输出恰恰加深了这种验证负担。

为什么 Context Rot 会发生？

注意力是一个预算。Transformer 将窗口中的每个 token 与其他所有 token 建立关联，而任何一个事实获得的注意力随池子增长而减少。Anthropic 的上下文窗口文档对此后果直言不讳：更多上下文并非自动更好，因为准确率和 recall 随 token 数量攀升而退化。窗口是工作记忆，而工作记忆会变得拥挤。

位置也很重要。模型的训练主要在较短的序列上，因此它们更可靠地加权窗口的开头和结尾，而非中间部分。埋在窗口中段的内容——比如四十分钟前的设计决策，或者在一次长文件转储中只陈述过一次的限制——最先衰退。同样，OpenAI 的提示工程指南也建议将与跨请求重用相关的内容放在提示的开头。

然后是噪声。一个长的 Agent 会话积累了过时的工具输出和已放弃的方案，所有这些都与真正重要的 token 争夺注意力。

Context Rot 在 Agent 会话中是什么样子？

一旦将症状映射到原因，就很容易识别：

被遗忘的指令。 来自指令文件的规则在会话中途停止应用。这是中间窗口损失：规则仍然存在，但注意力已转移到别处。

被推翻的决策。 Agent 一小时前同意了一个方案，现在却争论相反的方向，因为最初的讨论已经淡去。

重复工作。 它重新读取文件或重新运行已完成的检查，这表明其会话历史 recall 已退化。

自信的错误引用。 它描述之前读取过的函数或配置，却说错了内容，同时听起来很确定。

试错漂移。 精确的、有理有据的编辑被猜测和检查循环所取代，因为推理质量下降。

臃肿的指令文件加速了这一切，因为每个预加载的规则都在真正工作开始之前就消耗了注意力预算。负担落在人身上：《The Register》对 Sonar 调查的报道指出，95% 的开发者至少花费一些精力审查 AI 输出，59% 将该努力评为中等或大量。

常见问题

为什么我的 Agent 运行时间越长表现越差？

因为每次对话都会以工具输出、diff 和日志的形式添加 token，而每个添加的 token 都会稀释分配给其他一切的注意力。小的每步错误会累积而非相互抵消，这就是为什么 2026 年 AI Agent 可靠性科学研究工作提议在衡量 Agent 时，除了单次尝试成功率外，还要衡量跨运行的一致性和鲁棒性。会话长度本身就是风险因素。

更大的上下文窗口能解决问题吗？

不能。更大的窗口提高了可以加载的上限，但退化在任何广告限制之前很早就开始了，所以额外的容量大多只是给衰减更多的运行空间。更完整的答案在下一节。

Context Rot 和幻觉一样吗？

不一样。幻觉是捏造：模型发明了它从未拥有的信息，可以在十行提示中发生。Rot 退化的是模型对它实际拥有的信息的处理能力，且随长度恶化。两者确实相互作用：腐化的会话会产生更多幻觉，因为弱的 recall 用看似合理的虚构来掩盖。

通过重启会话能修复吗？

部分可以。新会话会丢弃累积的噪声，但也会丢弃合法上下文，包括你一路建立的决策和约束。团队通过按需检索来解决这个问题，使用像 Unblocked 这样的上下文引擎，在需要时将相关历史拉回，而不是寄希望于窗口仍然保留它。

更大的上下文窗口能修复 Context Rot 吗？

广告宣传的窗口不断增长；Anthropic 当前的模型接受多达一百万个 token。有效上下文并没有跟上。输出质量在广告限制之前很久就开始退化，这就是为什么从业者将有效上下文视为规格上数字的一个分数，而非数字本身。

对于 Agent 来说，问题会复合。假设退化将 Agent 从接近完美拉到每个单独步骤 85% 的可靠性。运行十个依赖步骤，干净端到端运行的概率是 0.85 的十次方，大约 20%。这只是算术，但它解释了为什么长会话会以慢动作失败。这也解释了为什么 2026 年评估研究认为单次尝试基准隐藏了 Agent 跨长时域的衰减方式。

更大的窗口让你可以加载更多，也仅此而已。窗口里装了什么和模型实际能用什么是两个不同的问题。

Context Rot 和用完上下文一样吗？

不一样，词汇表经常模糊两者。用完上下文是溢出：会话达到窗口的硬限制，发生了一些可见的事情，比如截断、压缩传递或错误。Rot 更安静。它发生在窗口中间，有多余的余地，每个 token 仍然存在；模型只是更差地使用它们。

这个区别改变了补救方法。溢出是你可以围绕它安排日程的容量问题。Rot 是质量开始于窗口开始填充的时刻的问题，这就是为什么下面的修复专注于管理而非压缩。

Context Rot 在哪里影响最大？

长时域编码 Agent，影响最大。Agent 循环将工具输出堆叠在工具输出上：文件读取、diff、测试日志、shell 结果。其中大部分在步骤完成的那一刻就成为一次性噪声，然而所有这些都留在窗口中。运行数小时的会话恰好积累了 rot 所需的条件。

工具开销使其更糟。连接少数 MCP 服务器，它们的模式（schema）可以在第一个真实任务 token 到达之前就消耗窗口的有意义部分。预算花在了管道上。

这与更广泛的可靠性图景一致：2026 年国际 AI 安全报告将通用 AI 系统可依赖行为的处理视为一个开放的科学问题。如果你运行 Claude Code，我们有一份针对 Claude Code 中 Context Rot 的现场指南，包括它在会话中倾向于咬人的位置。

团队如何防止它？

四类缓解措施在各种工具中都经受住了考验：

管理进入的内容。 将指令文件精简到 Agent 实际上没有它们就会违反的规则。精简工具清单和模式。将每个预加载的 token 视为已花费的注意力。

在阶段边界重置。 完成规划，然后在携带简短摘要而非完整记录的新会话中开始实现。你保留了结论，丢弃了噪声。

隔离旁路任务。 将研究和探索性工作发送到单独会话或子 Agent，这样它的中间输出永远不会污染主线程。只有提炼后的答案才会回来。

按需检索。 不是预加载 Agent 可能需要的所有东西，而是在它需要的时刻获取它需要的东西。这正是上下文引擎的用武之地：Unblocked，工程用的上下文引擎，在问题出现时解析相关的 PR 线程、文档或过去的决策，这样窗口携带的是答案而非档案。

让 Agent 自己管理这个预算是一个活跃的研究领域；2026 年的 Self-GC 让 Agent 在长时域任务中管理自己的上下文。

如何在自己的会话中发现它

在任何运行了一段时间的会话上做一个快速的三项自检：

1. Agent 重新问你已经回答过的问题。
2. 它推翻了你俩之前解决的一个决策。
3. 在一段长长的工具输出或文件转储之后，输出质量急剧下降。

任何一个都意味着窗口在与你作对，答案很少是更大的模型或更大的窗口。Rot 是一个管理问题，不是容量问题：当上下文包含当前步骤需要的东西且别无其他时，会话保持敏锐。这种纪律可以是手动的，也可以来自按需检索上下文的工具——这是我们构建 Unblocked 要做的事情。