name: context-degradation description: 识别、诊断和缓解智能体系统中的上下文退化模式。当上下文变得庞大、智能体性能意外下降或调试智能体故障时使用。
上下文退化模式
随着上下文长度增加，语言模型会表现出可预测的退化模式。理解这些模式对于诊断故障和设计弹性系统至关重要。上下文退化不是一种二元状态，而是一种性能下降的连续体，以几种不同的方式表现出来。
何时激活
在以下情况下激活此技能：
- 智能体在长对话中性能意外下降
- 调试智能体产生错误或不相关输出的情况
- 设计必须可靠处理大上下文的系统
- 评估生产系统的上下文工程选择
- 调查智能体输出中的“中间迷失”现象
- 分析智能体行为中与上下文相关的故障
核心概念
上下文退化通过几种不同的模式表现出来。中间迷失现象导致上下文中间的信息获得较少的关注。上下文污染发生在错误通过重复引用而累积时。上下文分心发生在不相关信息淹没相关内容时。上下文混淆发生在模型无法确定哪个上下文适用时。上下文冲突在累积的信息直接矛盾时产生。
这些模式是可预测的，可以通过压缩、掩码、分区和隔离等架构模式来缓解。
详细主题
中间迷失现象
最广为人知的退化模式是“中间迷失”效应，模型表现出U形注意力曲线。上下文开头和结尾的信息获得可靠的关注，而埋在中间的信息则召回准确性显著降低。
实证证据 研究表明，放置在上下文中间的相关信息，其召回准确性比放置在开头或结尾的相同信息低10-40%。这不是模型的失败，而是注意力机制和训练数据分布的结果。
模型将大量注意力分配给第一个token（通常是BOS token）以稳定内部状态。这创建了一个“注意力沉没点”，消耗了注意力预算。随着上下文增长，有限的预算被摊薄，中间token无法获得足够的注意力权重以实现可靠检索。
实际影响 设计上下文放置时要考虑注意力模式。将关键信息放在上下文的开头或结尾。考虑信息是会被直接查询还是需要支持推理——如果是后者，放置位置不那么重要，但整体信号质量更重要。
对于长文档或对话，使用摘要结构，在注意力偏好的位置呈现关键信息。使用明确的章节标题和过渡来帮助模型导航结构。
上下文污染
上下文污染发生在幻觉、错误或不正确信息进入上下文并通过重复引用而累积时。一旦被污染，上下文会创建反馈循环，强化错误的信念。
污染如何发生 污染通常通过三种途径进入。首先，工具输出可能包含错误或意外格式，模型将其接受为事实。其次，检索到的文档可能包含不正确或过时的信息，模型将其纳入推理。第三，模型生成的摘要或中间输出可能引入持续存在于上下文中的幻觉。
累积效应是严重的。如果智能体的目标部分被污染，它会制定出需要大量努力才能撤销的策略。每个后续决策都会引用被污染的内容，强化错误的假设。
检测与恢复 注意以下症状：先前成功的任务输出质量下降，工具错位（智能体调用错误的工具或参数），以及尽管尝试纠正但幻觉仍然存在。当这些症状出现时，考虑上下文污染。
恢复需要移除或替换被污染的内容。这可能涉及将上下文截断到污染点之前，在上下文中明确标注污染并要求重新评估，或者重新开始使用干净的上下文，仅保留已验证的信息。
上下文分心
当上下文变得如此之长，以至于模型过度关注所提供的信息，而牺牲了其训练知识时，就会出现上下文分心。模型会关注上下文中的所有内容，无论其相关性如何，这会产生压力，迫使模型使用所提供的信息，即使内部知识更准确。
分心效应 研究表明，即使上下文中只有一个不相关的文档，也会降低涉及相关文档的任务的性能。多个分心因素会加剧退化。这种效应不是关于绝对意义上的噪音，而是关于注意力分配——不相关信息与相关信息竞争有限的注意力预算。
模型没有“跳过”不相关上下文的机制。它们必须关注所提供的所有内容，这种义务即使在无关信息明显无用的情况下也会造成分心。
缓解策略 通过仔细筛选进入上下文的内容来缓解分心。在加载检索到的文档之前应用相关性过滤。使用命名空间和组织结构，使不相关的部分在结构上容易被忽略。考虑信息是否真的需要放在上下文中，或者可以通过工具调用访问。
上下文混淆
当不相关信息以降低质量的方式影响响应时，就会出现上下文混淆。这与分心有关但不同——混淆关注的是上下文对模型行为的影响，而不是注意力分配。
如果你把某些东西放在上下文中，模型就必须关注它。模型可能会合并不相关的信息，使用不恰当的工具定义，或应用来自不同上下文的约束。当上下文包含多种任务类型或在单个会话中切换任务时，混淆尤其成问题。
混淆的迹象 注意以下情况：响应处理了查询的错误方面，工具调用似乎适用于不同的任务，或者输出混合了来自多个来源的需求。这些表明对当前情况适用哪个上下文感到困惑。
架构解决方案 架构解决方案包括明确的任务分割（不同任务获得不同的上下文窗口），任务上下文之间的清晰过渡，以及隔离不同目标上下文的状态管理。
上下文冲突
当累积的信息直接冲突，产生矛盾的指导并破坏推理时，就会产生上下文冲突。这与污染不同，在污染中，一条信息是错误的——在冲突中，多条正确的信息相互矛盾。
冲突的来源 冲突通常源于多源检索（不同来源有矛盾信息）、版本冲突（过时和当前信息同时出现在上下文中）以及观点冲突（不同观点有效但不兼容）。
解决方法 解决方法包括：明确标记冲突，识别矛盾并要求澄清；优先级规则，确定哪个来源优先；版本过滤，从上下文中排除过时信息。
实证基准与阈值
研究提供了关于退化模式的具体数据，为设计决策提供信息。
RULER基准测试结果 RULER基准测试给出了令人清醒的发现：只有50%声称具有32K+上下文的模型在32K token时能保持令人满意的性能。GPT-5.2在当前模型中退化最少，而许多模型在扩展上下文下仍下降30+分。在简单的“大海捞针”测试中获得接近完美的分数，并不能转化为真正的长上下文理解。
模型特定的退化阈值
| 模型 | 退化开始 | 严重退化 | 备注 |
|---|---|---|---|
| GPT-5.2 | ~64K token | ~200K token | 整体退化抵抗力最佳，带有思考模式 |
| Claude Opus 4.5 | ~100K token | ~180K token | 200K上下文窗口，强大的注意力管理 |
| Claude Sonnet 4.5 | ~80K token | ~150K token | 针对智能体和编码任务优化 |
| Gemini 3 Pro | ~500K token | ~800K token | 1M上下文窗口，原生多模态 |
| Gemini 3 Flash | ~300K token | ~600K token | 速度是Gemini 2.5的3倍，MMMU-Pro得分81.2% |
模型特定的行为模式 不同模型在上下文压力下表现出不同的故障模式：
- Claude 4.5系列：校准不确定性下的最低幻觉率。Claude Opus 4.5在SWE-bench Verified上达到80.9%。倾向于拒绝或要求澄清，而不是捏造。
- GPT-5.2：提供两种模式——即时（快速）和思考（推理）。思考模式通过逐步验证减少幻觉，但增加了延迟。
- Gemini 3 Pro/Flash：具有1M上下文窗口的原生多模态。Gemini 3 Flash比上一代速度提升3倍。在跨文本、代码、图像、音频和视频的多模态推理方面表现出色。
这些模式为不同用例的模型选择提供信息。高风险任务受益于Claude 4.5的保守方法或GPT-5.2的思考模式；速度关键型任务可以使用即时模式。
反直觉的发现
研究揭示了几种挑战上下文管理假设的反直觉模式。
打乱的“干草堆”优于连贯的“干草堆” 研究发现，打乱的（不连贯的）“干草堆”比逻辑连贯的“干草堆”产生更好的性能。这表明连贯的上下文可能会创建混淆检索的虚假关联，而不连贯的上下文迫使模型依赖精确匹配。
单个分心因素具有不成比例的影响 即使是一个不相关的文档也会显著降低性能。这种效应与噪音量不成比例，而是遵循一个阶跃函数，即任何分心因素的存在都会触发退化。
“针-问题”相似性相关性 “针”和问题对之间的相似性越低，随着上下文长度的增加，退化速度越快。需要跨不相似内容进行推理的任务尤其脆弱。
何时更大的上下文反而有害
更大的上下文窗口并不总是能提高性能。在许多情况下，更大的上下文会带来新的问题，其弊端超过了益处。
性能退化曲线 模型表现出随上下文长度变化的非线性退化。性能在达到阈值之前保持稳定，然后迅速下降。阈值因模型和任务复杂性而异。对于许多模型，即使上下文窗口支持更大的尺寸，有意义的退化大约在8,000-16,000 token左右开始。
成本影响 处理成本随上下文长度不成比例地增长。处理400K token上下文的成本不是处理200K的两倍——它在时间和计算资源上都呈指数级增长。对于许多应用来说，这使得大上下文处理在经济上不切实际。
认知负荷隐喻 即使拥有无限的上下文，要求单个模型在数十个独立任务中保持一致的品质也会产生认知瓶颈。模型必须不断在项目之间切换上下文，维护比较框架，并确保风格一致性。这不是一个通过更多上下文就能解决的问题。
实践指导
四桶方法
四种策略解决上下文退化的不同方面：
写入：使用草稿纸、文件系统或外部存储将上下文保存在窗口之外。这使活动上下文保持精简，同时保留信息访问。
选择：通过检索、过滤和优先级排序将相关上下文拉入窗口。这通过排除不相关信息来解决分心问题。
压缩：通过摘要、抽象和观察掩码减少token，同时保留信息。这扩展了有效的上下文容量。
隔离：将上下文分割到子智能体或会话中，以防止任何单个上下文变得大到足以退化。这是最激进的策略，但通常也是最有效的。
架构模式
通过特定的架构模式实施这些策略。使用即时上下文加载，仅在需要时检索信息。使用观察掩码，用紧凑的引用替换冗长的工具输出。使用子智能体架构来隔离不同任务的上下文。使用压缩在上下文超过限制之前总结不断增长的上下文。
示例
示例1：检测退化
# 上下文在长对话中增长
turn_1: 1000 token
turn_5: 8000 token
turn_10: 25000 token
turn_20: 60000 token (开始退化)
turn_30: 90000 token (显著退化)
示例2：缓解中间迷失
# 将关键信息组织在边缘的上下文
[当前任务] # 在开头
- 目标：生成季度报告
- 截止日期：本周末
[详细上下文] # 中间（较少关注）
- 50页数据
- 多个分析部分
- 支持证据
[关键发现] # 在末尾
- 收入增长15%
- 成本下降8%
- A区增长
指南
- 在开发过程中监控上下文长度与性能的相关性
- 将关键信息放在上下文的开头或结尾
- 在退化变得严重之前实施压缩触发器
- 在将检索到的文档添加到上下文之前验证其准确性
- 使用版本控制防止过时信息导致冲突
- 分割任务以防止跨不同目标的上下文混淆
- 为优雅降级而设计，而不是假设完美条件
- 使用逐渐增大的上下文进行测试，以找到退化阈值
集成
此技能建立在上下文基础知识之上，应在理解基本上下文概念后学习。它与以下内容相关：
- context-optimization - 缓解退化的技术
- multi-agent-patterns - 使用隔离防止退化
- evaluation - 在生产中测量和检测退化
参考文献
内部参考：
- 退化模式参考 - 详细技术参考
本集合中的相关技能：
- context-fundamentals - 上下文基础
- context-optimization - 缓解技术
- evaluation - 检测与测量
外部资源：
- 关于注意力机制和上下文窗口限制的研究
- 关于“中间迷失”现象的研究
- AI实验室的生产工程指南
技能元数据
创建日期: 2025-12-20 最后更新: 2025-12-20 作者: Agent Skills for Context Engineering Contributors 版本: 1.0.0