上下文腐化（Context Rot）
也叫： 上下文退化
上下文腐化指的是一个观察到的现象：随着输入里文字量增加，语言模型的可靠性会下降——不只是在上下文窗口快满时，而是随 token 累积逐步下降，哪怕是模型在短输入下轻松就能做对的任务。
大的上下文窗口容易让人产生一个诱人的假设：既然模型能接收一百万 token，那就把所有东西都倒进去，让它自己挑重点。上下文腐化——这个说法因 Chroma 2025 年一篇研究报告而流行——指的正是这个假设站不住脚。模型表现不会随输入变长而保持平稳，而是往下滑，而且早在窗口填满之前就开始滑了。
那项研究让许多当前模型在刻意设计得很简单的任务上（找一个事实、复述一段文字）跑不同的输入长度，发现每往上加一档长度，可靠性就下降一点，不是只在接近上限时。一个宣称窗口很大的模型，在比如几万 token 时也可能变得明显更不靠谱。任务是简单的，是长度本身在拖后腿。
实用结论和 context-engineering 的出发点一致：更多上下文不是免费的，也不总是更好。把窗口塞满松散相关的材料，会让模型更不擅长用其中真正重要的那部分。这就是为什么 Agent 运行框架会对旧对话做摘要、做窄范围检索而不是整篇文档倒进去、并裁剪工具输出——它们都在管理上下文腐化，不管叫不叫这个名字。
怎么运作
这背后不是单一 bug，而是几件事叠加：注意力在更多 token 上如何摊薄、训练数据里非常长且连贯的输入占比偏低、以及干扰性或近乎重复的内容如何和相关片段争夺注意力。位置也有影响——相关的『中间迷失（lost in the middle）』效应表明，埋在上下文中段的内容比开头结尾的更难被回忆——但上下文腐化是更宽的论断：不管关键信息放哪，总长度都会拉低可靠性。因为下降是渐进的，它常常不被察觉，直到一个在测试时（短提示）好用的任务，在生产中（长的、累积起来的上下文）开始出错。
举个例子
只给 Agent 相关的 3 段话时，它能答对某个问题。给同样这 3 段话、外加『为了完整』粘进来的 40 页松散相关文档后，它开始漏掉原本那 3 段话里明明写着的细节。问题本身没有变难，是多出来的 token 让模型对重点部分的处理退化了。
和相关概念的区别
上下文腐化与中间迷失：『中间迷失』是一个具体的位置效应——放在长上下文中段的事实，比放在开头或结尾的更难被检索到。上下文腐化是更宽的观察：不管关键内容放在哪，整体可靠性都随总输入长度增加而下降。
常见误解
常见问题
上下文腐化是什么？
换更大的上下文窗口能解决上下文腐化吗？
在 Agent 里怎么应对上下文腐化？
最近核实： 2026-08-30