上下文腐化：AI 为什么越聊越不准，怎样修复？

上下文腐化（context rot）会让 AI 智能体的回答变得不准确，即便输入还在标称的上下文窗口范围内。Chroma 对 18 个语言模型的研究发现，模型的可靠性会随输入长度变化。应对这一问题，关键是保留下一步行动所需的证据，同时减少无关的历史信息。

什么是 AI 的上下文腐化？

上下文腐化，是指随着提供给语言模型的信息增多，模型的可靠性逐渐下降。 具体表现可能是漏掉事实、建立错误关联，或在回答时不再遵守已经确定的决策。模型仍然能接收一段很长的对话，却未必能准确利用其中的信息。

上下文窗口是模型处理单次请求时可用的工作空间，里面可以包含指令、对话历史、文档和工具结果。token 是模型处理内容的单位，通常相当于单词的一个片段。哪些内容会占用这个空间，可以参阅上下文窗口指南。

可以把它想象成故障处置室里的一面墙：当前方案、已放弃的假设、过时的时间线和旧日志都贴在上面。把墙扩大，确实能贴下更多材料，却不会自动告诉接手的人，眼下究竟该按哪项决策执行。

排查智能体问题时，这个区别很关键。如果所需事实在请求送达模型前就被删掉了，应检查截断或检索环节。如果事实就在输入中，回答却遗漏或误用了它，就应检查模型如何处理这些上下文。仅凭其中任何一种表现，都不能认定问题由输入过长导致。

文档核查日期：2026 年 10 月 24 日。 下文引用的厂商建议已对照 Anthropic 当时在线的文档核实。文中的工作流示例是设计建议，并非已报告的生产环境成果。

Context Rot 研究：证据究竟说明了什么？

Chroma 于 2025 年 7 月 14 日发布的报告发现，当语义匹配更难，或出现看似相关的干扰信息时，长输入中的信息检索会变得更不可靠。这些受控任务提供了有用证据，但不能当作你的智能体的性能基准。参见原始研究。

在清理后的 LongMemEval 对话基准中，Chroma 将 306 条提示词的完整输入与只保留相关内容的精简版本进行比较：前者平均约 113,000 tokens，后者平均约 300 tokens。所有参评模型在精简输入下的得分都更高。但这里有个关键前提：这些短输入来自已标注的相关段落，并经过人工调整，并不是由一套接受自动评估的检索系统生成的。参见研究方法与结果。

Chroma 的研究结论有哪些边界？

这份报告没有确定背后的作用机制，也没有给出通用的安全 token 数上限。此外，在重复文本实验中，输出长度会随输入一同增长，这与要求简短回答的检索测试不同。参见研究局限与任务说明。

对开发者而言，更有用的问题是：系统能否找到并保留必需的证据？一张把精心筛选的证据与完整历史进行比较的图表，并不能说明你的搜索索引、过滤器或摘要工具能否正确选出这些证据。信息筛选本身也需要单独评估。

为什么上下文越长，越难用好？

模型必须能把相关材料与周围的信息区分开。 一份旧部署方案，可能比一份毫不相干的文档更像当前方案。风险不只是找不到某句话，还包括把不适用的那句话用到了当前情境中。

Anthropic 的上下文工程指南将架构限制，以及训练主要采用较短序列，列为长上下文难以处理的部分原因。它描述的是精确度逐步下降，而不是跨过某个边界后能力突然消失。这些解释可用于分析问题，但还不足以证明一套完整的因果机制。

假设一个客服智能体的历史记录里，既有最初的诊断，也有失败的临时解决办法，还有后来确认有效的修复方案。此时，如果一次工具调用又返回了旧版排障指南，下一次回答就必须同时理清时间先后和信息权威性。用户的问题没有变，增加的文字却让判断更复杂了。

应当把这种判断明确写出来：说明当前状态，将早期诊断标记为已否定，并保留支持已采纳修复方案的来源。目标是让证据充分、状态清晰，而不是一味把提示词压到最短。

开发者和运维人员应先检查什么？

先用不同上下文重放同一个决策，再判断是否是模型的问题。 对开发者来说，这意味着要记录应用实际组装并发送的请求。界面上可见的聊天记录，可能没有包含模型收到的系统指令、检索结果或工具响应。

对运维人员来说，要先指出具体漏掉了哪项要求，或执行了什么错误操作。“越聊感觉越差”很难排查；“它推荐了故障记录中已经否决的临时方案”，才是可以重放验证的问题。

对一个已保存的案例，可以按以下顺序诊断：

1. 1

   固定决策条件

   保持问题、模型配置和预期达成的目标不变，保存原始输入与权威证据。重放时不执行外部操作，避免比较过程改变案例本身。

2. 2

   确认模型收到了证据

   在实际请求中查找必需的段落。如果没有找到，先修复检索、截断或状态加载。如果送进去的是过时来源，先修复来源选择与时效性问题。

3. 3

   构造精简输入进行对照

   保留相同的任务指令及回答所需的全部证据，移除无关历史和过时的工具结果。不要把标准答案塞进输入，也不要降低任务难度。在有代表性的重放案例中，对比正确性、来源使用情况和约束遵守情况。

4. 4

   根据失败原因选择修复办法

   如果精简输入有效，就检查上下文的筛选与组织方式。如果两种输入都失败，就检查任务、指令、证据质量和模型能力。如果问题从生成摘要之后才开始，就检查摘要丢掉了什么。

这组对照只能用于诊断，不能证明错误完全由长度引起，因为删减材料也改变了内容构成。要更严格地检验长度的影响，应控制相关证据及其位置，再加入无关材料。不要从一次碰巧成功的重跑中得出普遍结论。

如果历史信息不断增长，并反复伴随本可避免的错误，团队就应着手处理。对于简短、范围明确，而且能通过正确性检查的工作流，保留简单设计即可。只有当具体故障需要编排机制来解决时，再引入它。

如何缓解智能体的上下文退化？

先看是哪类材料引发了问题，再选择对应的处理办法。 上下文压缩用于管理不断累积的历史，检索用于筛选证据，子智能体用于隔离探索过程，调整顺序用于讲清任务，精简工具响应则能减少不必要的输入。这些手段可以配合使用，也各有失效方式。

压缩历史，但要保住工作状态

上下文压缩，是用更短的续接记录替换较早的对话内容。 Anthropic 在线的上下文压缩文档解释了为何需要控制活跃上下文的大小：“随着对话增长，响应质量会下降。” 其 API 既支持应用主动请求压缩，也支持达到配置的 token 阈值后触发压缩。

交接记录应围绕下一步行动所需的信息来设计。以故障处置为例，要保留当前目标、已确认的原因、被否决的临时方案及否决理由、尚未消除的不确定性、来源位置和下一步行动。如果正确执行依赖精确的标识符或原文，就必须原样保留。

“已调查问题并取得进展”是一条无效的交接记录。更有用的写法是：“该临时方案因破坏必需行为而被否决；已采纳的修复方案记录在故障文档中；验证尚未完成。” 后者能让工作继续，无需再讲一遍调查过程。

局限： 摘要可能删掉后来才变得重要的细节。因此要保留访问原始记录的途径，并评估接续工作的智能体是否仍能回答依赖这些细节的问题。持久化保存状态与决定重新加载什么，是两项不同的工作，详见智能体记忆详解。

任务需要什么证据，就检索什么

保存大型资料的引用，按需加载相关部分。 Anthropic 将这种方式称为即时上下文：智能体可以保留文件路径、查询语句或链接，需要时再取回材料。参见上下文检索指南。

对于故障处置智能体，先加载当前故障记录和适用的服务文档。只有诊断需要时，再调取历史故障。返回每段内容时，应尽可能附上来源、版本或日期，并保留足够的前后文，让模型能理解其中的例外条件。

局限： 检索可能漏掉起决定作用的条款，也可能返回看似匹配、实际已经过时的内容。衡量回答质量之前，先检查必需的证据是否在输入中。如果摘录不足以下判断，智能体应能扩大搜索范围或阅读完整来源。

结果集更小，只有在保留了决策所需信息的前提下才有意义。“用检索代替一股脑塞入上下文”是一种筛选策略，不是让系统藏起那些不便处理的信息。

给子智能体明确的任务边界和干净的上下文

如果主智能体不需要探索过程中的全部原始结果，就让这项探索在独立上下文中进行。 Anthropic 的Claude Code 子智能体文档介绍了这样的执行单元：它们在各自的上下文窗口内工作，再将结果返回主对话。

负责检查日志的子智能体，可以只接收具体问题、相关服务信息和日志位置。要求它返回发现、证据所在位置、不确定性，以及尚未解决的依赖问题。主智能体便能利用这些结果，无需带着完整的搜索过程继续工作。

局限： 隔离上下文也会隔离共享知识。要提供子智能体所需的约束，并要求结论附带证据。同时检查编排框架究竟向它传递了什么：如果把父级的整段历史都复制过去，就失去了隔离的意义。而把每个子智能体的完整对话再粘回主对话，又会让主上下文重新堆满杂乱信息。

这种模式适合可以拆开的调查任务。如果一项决策高度依赖同一份共享记录，各部分难以分离，那么留在主上下文中配合定向检索，可能更容易处理。

有意识地安排文档与当前问题的顺序

让当前任务与辅助材料容易区分。 Anthropic 的长上下文提示词指南建议，将长文档放在提示词靠前的位置，区分各自来源，再把问题放在文档之后。对于文档问答，它还建议先找出相关引文，再作答。

在应用中，应把支配任务的指令保留在对应的指令通道。任务输入内部，则将当前故障记录与历史笔记分别标注，再清楚说明问题和输出要求。不要因为调整了位置，就把检索到的文字当成支配任务的指令。

局限： 调整顺序无法找回从未加载的证据，也没有一种排列能保证对所有模型和任务都有效。要用自己的案例比较不同布局。如果简洁、反映当前情况的任务说明已经足够，就不必每一轮都重复整本规则手册。

精选工具输出，并保留取回全文的途径

返回下一次决策需要的结果，同时提供访问完整产物的路径。 Anthropic 的工具设计指南建议提供有意义的响应，并使用过滤、分页和截断等控制手段。其上下文编辑文档则另外介绍了如何从对话历史中清除较早的工具结果。

检查失败时，返回失败情况、相关错误摘录，以及已保存报告的位置。搜索时，返回相关段落及其来源。操作成功时，返回状态和继续执行所需的标识符。不要仅仅因为工具生成了整份报告，就把它全部嵌入上下文。

局限： 盲目截断可能删掉关键错误或限定条件。应明确标示省略之处，并允许智能体请求更多内容。对于后续需要检查的完整输出，应将其保存在活跃上下文之外。

这些选择应在请求组装层落实。关于指令、记忆、工具和检索材料如何配合，可以阅读更完整的上下文工程指南。

关于上下文腐化，哪些说法被夸大了？

不存在一个通用的消息条数或窗口占用比例，能告诉所有智能体何时该重置。 防止请求超出上限的阈值，是容量配置。某个工作流从哪里开始变得不可靠，必须结合它实际执行的任务来衡量。

长对话中的每个错误回答，也不都能证明发生了上下文腐化。证据缺失、指令冲突、工具故障，或任务超出能力范围，都可能造成类似表现。一份有用的故障报告，应说明失败的是哪项决策，并记录模型当时收到了什么。

上下文压缩并非无损，外部记忆也不会自动保证相关性。 两者都是需要检查输出的组件。如果只是更高效地保留了错误结论，反而可能让工作流稳定地犯错。

最后，缓存解决的是另一类问题。KV cache复用的是注意力计算，既不判断哪份文档重要，也不清理过时历史。即使请求充分命中了缓存，其中仍可能装着不适合下一步决策的材料。

本周可以落实的检查清单

找一个反复出错的智能体，按下面的清单处理：

• 记录出错决策发生时的实际输入，明确它需要哪些证据。
• 在要求不变的前提下，用精简且相关的证据重放任务，并在有代表性的案例中比较正确性。
• 将噪声最多的工具响应替换为相关摘录，并附上完整产物的位置。
• 定义压缩后的交接记录，保留决策、被否决的方案、约束、来源和未完成的工作。
• 如果杂乱信息来自探索过程，就把一项可以拆开的调查移到独立、干净的子智能体上下文中。
• 只有接续后的工作流仍保留必需事实，并改善了目标故障，才发布改动；同时保留恢复原有行为的途径。

从可以复现的故障入手。这样才能给改动设定明确的验收标准，而不是把“上下文更少”本身当作成功指标。

上下文腐化常见问题

上下文腐化现在仍然存在吗？

Anthropic 当前的上下文压缩文档仍明确说明，随着对话增长，响应质量会下降。这支持我们继续做好上下文管理，但不能据此判断每个现有模型的表现。应评估自己实际部署的模型和工作流。

如何避免上下文腐化？

保留当前有效的指令和必需证据，移除过时或重复的材料，谨慎压缩历史，并按需检索细节。适合时，将噪声较多的辅助任务隔离出去。每次改动后，都要确认下一步行动所需的事实仍被保留。

上下文腐化是什么原因造成的？

上下文长度、周围材料的相关性，以及信息的呈现方式，都可能影响可靠性。原始研究并未确定单一的底层机制。对于智能体，应先检查实际提供的证据和工作状态，再选择修复办法。

订阅邮件通讯，获取构建和运营 AI 工作流的实用指南。