context-degradation

上下文退化模式

在上下文问题连锁扩散之前，诊断并修复这些问题。上下文退化并非非黑即白，而是一个连续过程，会呈现五种不同且可预测的模式：中间遗失、污染、干扰、混淆和冲突。每种模式都有特定的检测信号和缓解策略。应将退化视为一个具有可测量阈值的工程问题，而不是不可预测的故障模式。

何时启用

在以下情况下启用此技能：

• Agent 在长时间对话中的表现意外下降
• 调试 Agent 产生错误或无关输出的情况
• 设计必须可靠处理大型上下文的系统
• 评估生产系统的上下文工程选择
• 调查 Agent 输出中的“中间遗失”现象
• 分析 Agent 行为中与上下文相关的故障

对于由其他技能负责的相关工作，请勿启用此技能：

• 在没有实际故障的情况下解释上下文基础机制：context-fundamentals。
• 已知故障模式后应用令牌效率技巧：context-optimization。
• 设计压缩或交接摘要策略：context-compression。
• 将大型输出、日志或临时状态持久化到提示词之外：filesystem-context。

核心概念

围绕注意力 U 形曲线安排上下文：在长上下文实验中，开头和结尾位置能得到可靠关注，而中间位置的回忆准确率会显著降低（claim-context-degradation-lost-middle-ruler）。这不是模型错误，而是注意力机制的结果——第一个令牌（通常是 BOS）充当“注意力汇”，吸收不成比例的注意力预算；随着上下文增长，中间令牌得到的关注则会减少。

将上下文污染视为断路器问题。一旦幻觉、工具错误或检索到的错误事实进入上下文，就会通过反复自我引用不断累积。被污染的目标部分会导致后续每个决策都强化错误假设。检测需要追踪声明来源；恢复则需要截断到污染点之前，或仅使用已验证的上下文重新开始。

在加载上下文之前积极过滤内容——即使只有一份无关文档，也会明显降低模型在相关任务上的表现。模型无法“跳过”无关上下文；它们必须关注提供的所有内容，从而导致相关内容与无关内容争夺注意力。将可能会用到但当前并不相关的信息放在工具调用之后，而不是预先加载。

隔离任务上下文以防止混淆。当上下文包含多种任务类型或在不同目标之间切换时，模型可能会采用错误任务的约束、调用适用于其他上下文的工具，或混合多个来源的要求。通过显式划分任务并使用独立的上下文窗口，可以消除交叉污染。

通过优先级规则而非累积内容来解决上下文冲突。当上下文中出现多个正确但相互矛盾的来源时（版本冲突、视角冲突、多来源检索），模型无法判断应以哪个来源为准。应明确标记矛盾、设定来源优先级，并在过时版本进入上下文之前将其过滤掉。

详细主题

中间迷失：检测与放置策略

将关键信息放在上下文的开头和结尾，绝不要放在中间。U 形注意力曲线意味着，位于中间的信息，其召回准确率会降低 10-40%。对于超过 4K 个令牌的上下文，这种影响会变得显著。

采用能在注意力偏好的位置呈现关键发现的摘要结构。添加明确的章节标题和结构标记——它们可以创建注意力锚点，帮助模型浏览较长的上下文。如果必须完整包含某份文档，请在前面附上要点摘要，并在末尾补充关键结论。

留意中间迷失的症状：上下文中存在正确信息，但模型忽略了它；回答与提供的数据相矛盾；或者模型“忘记”了较长提示词中早先给出的指令。

上下文污染：预防与恢复

所有外部输入进入上下文前都要进行验证。工具输出、检索到的文档和模型生成的摘要是三种主要的污染途径。每一种都会引入未经验证的说法，而后续推理会将其视为真实信息。

通过以下信号检测污染：此前能够成功完成的任务输出质量下降、工具调用不匹配（工具或参数错误），以及即使经过明确纠正仍持续出现的幻觉。当这些情况同时出现时，应怀疑是上下文污染，而不是模型能力问题。

恢复时应移除受污染的内容，而不是在其上叠加修正。截断到污染发生之前，使用仅保留已验证信息的干净上下文重新开始，或者明确标记受污染的部分并要求从头重新评估。在受污染的上下文上叠加修正通常无效——原始错误仍会保留注意力权重。

上下文干扰：筛选而非累积

筛选进入上下文的内容，不要指望模型自行忽略无关内容。研究表明，即使只有一份干扰文档，也会导致可测量的性能下降——这种影响呈阶跃函数，而非线性曲线。多个干扰项会进一步加剧问题。

在加载检索到的文档前进行相关性筛选。使用命名空间和结构化组织，让章节边界清晰明确。优先采用基于工具调用的访问方式，而不是预先加载：将参考资料存放在检索工具之后，使其仅在与当前推理步骤直接相关时才进入上下文。

上下文混淆：任务隔离

将不同任务分隔到单独的上下文窗口中。上下文混淆不同于上下文干扰——它指模型将错误上下文中的约束应用到当前任务，而不仅仅是注意力被稀释。其迹象包括：回答针对查询的错误方面、调用适用于其他任务的工具，以及输出混合了多个来源的要求。

在不同任务上下文之间实施明确的切换。采用状态管理，按任务隔离目标、约束和工具定义。如果无法避免在单次会话中切换任务，请使用明确的“上下文重置”标记，指出当前片段适用哪些约束。

上下文冲突：冲突解决协议

在冲突发生前建立来源优先级规则。上下文冲突不同于上下文污染——多个信息本身都正确，但彼此矛盾（版本冲突、视角差异、多个来源检索到的事实不一致）。

实施版本筛选，在过时信息进入上下文前将其排除。如果无法避免矛盾，请使用结构化冲突标注明确标记：说明冲突内容、各项说法分别来自哪个来源，以及哪个来源优先。没有明确的优先级规则，模型解决矛盾的方式就不可预测。

实证基准与阈值

使用这些基准来设定设计约束，而不要将其视为普遍真理。RULER 风格的证据表明，标称支持长上下文并不保证模型在该长度下能令人满意地完成任务（claim-context-degradation-lost-middle-ruler）。大海捞针测试接近完美的得分，并不能预测模型在真实场景中的长上下文表现。

特定模型的性能退化阈值

退化起点因模型系列和任务类型而异。一般来说，对于复杂检索任务，预计模型会在标称上下文窗口的 60–70% 处开始退化（RULER 基准发现，声称支持 32K 以上上下文的模型中，只有 50% 能在该长度下维持令人满意的性能）。主要规律如下：

• 具备扩展思考能力的模型通过逐步验证减少幻觉，但会增加延迟和 Token 成本
• 针对 Agent／编码优化的模型通常能更好地管理工具输出较多的上下文
• **上下文窗口非常大的模型（1M+）**能处理更多原始上下文，但仍呈现 U 形退化曲线——更大的窗口无法消除问题，只会推迟问题出现

务必针对自己的具体工作负载评测退化阈值，而不要依赖已发布的基准。随着每次模型更新，特定模型的阈值都会过时（参见陷阱 2）。

反直觉的发现

设计上下文策略时，请考虑以下有研究依据的意外发现：

打乱后的上下文可能优于连贯的上下文。 研究发现，对于某些检索任务，非连贯（打乱排列）的干草堆可能优于按逻辑顺序排列的干草堆（claim-context-degradation-distractor-shuffled）。连贯的上下文可能造成错误关联，干扰检索；非连贯的上下文则可能迫使模型进行精确匹配。不要认为组织得更好的上下文总会带来更好的结果——请测试这两种排列方式。

单个干扰项的影响格外显著。 与在第一个干扰项之后继续添加更多干扰项相比，单个无关文档造成的性能损失要大得多。应将干扰项预防视为非此即彼：要么保持上下文干净，要么接受显著的性能退化。

问题与目标内容的相似度低会加速退化。 需要跨不相似内容进行推理的任务，其性能随上下文长度增长而退化的速度，比表层相似度高的任务更快。设计检索时，应尽可能提高查询与检索内容之间的语义重合度。

更大的上下文何时会造成损害

不要认为更大的上下文窗口一定能提升性能。在特定模型的阈值以内，性能保持稳定；超过阈值后，性能会迅速退化——曲线并非平缓下滑，而是非线性的断崖式变化。对于许多模型，即使上下文窗口支持大得多的长度，显著退化也会在 8K–16K Token 时开始。

还要考虑成本：处理 400K Token 的上下文，在耗时和计算资源方面都比处理 200K Token 的成本高出成倍，而非线性增加。对于许多应用而言，这会使大上下文处理在经济上不切实际。

还要认识到认知瓶颈：即使上下文无限，让单个模型在数十个彼此独立的任务中始终保持高质量，也会造成无法通过增加上下文来解决的性能退化。应将任务拆分给多个子 Agent，而不是扩展上下文。

实用指南

四类缓解策略框架

根据当前出现的退化模式，应用以下四种策略：

写入 — 使用暂存区、文件系统或外部存储，在上下文窗口之外保存上下文。当上下文利用率超过窗口容量的 70% 时使用。这样可以保持活动上下文精简，同时通过工具调用保留信息访问能力。

筛选 — 通过检索、过滤和优先级排序，仅将相关上下文载入窗口。当出现分心或困惑症状时使用。载入前先进行相关性评分；低于阈值的内容应予以排除，而不是把所有可用内容都纳入。

压缩 — 通过总结、抽象和观察结果掩码，在保留信息的同时减少令牌数量。当上下文不断增长，但所有内容都相关时使用。将冗长的工具输出替换为简洁的结构化摘要；将重复模式抽象为单一引用。

隔离 — 将上下文拆分到子 Agent 或会话中，避免任何单一上下文超过其退化阈值。当出现困惑或冲突症状，或者任务彼此独立时使用。这是力度最大的一种策略，但对于复杂的多任务系统，往往也最有效。

增强韧性的架构模式

实施即时上下文载入：仅在当前推理步骤需要时检索信息，而非提前检索。处理完冗长的工具输出后，使用观察结果掩码将其替换为简洁的引用。采用子 Agent 架构，让每个 Agent 仅保留与任务相关的上下文。在上下文超过特定模型的退化起始阈值之前触发压缩，而不是等到症状出现后再处理。

示例

示例 1：检测退化

# Context grows during long conversation
turn_1: 1000 tokens
turn_5: 8000 tokens
turn_10: 25000 tokens
turn_20: 60000 tokens (degradation begins)
turn_30: 90000 tokens (significant degradation)

示例 2：缓解中间丢失问题

# Organize context with critical info at edges

[CURRENT TASK]                      # At start
- Goal: Generate quarterly report
- Deadline: End of week

[DETAILED CONTEXT]                  # Middle (less attention)
- 50 pages of data
- Multiple analysis sections
- Supporting evidence

[KEY FINDINGS]                     # At end
- Revenue up 15%
- Costs down 8%
- Growth in Region A

示例 3：上下文投毒断路器

symptom: agent keeps citing an incorrect retrieved claim after correction
diagnosis: poisoned context, not a missing-instruction problem
action:
  1. identify first turn where the bad claim entered
  2. truncate or restart from before that point
  3. reload only verified sources
  4. record the rejected claim and source provenance

示例 4：上下文冲突标注

conflict:
  topic: billing API version
  source_a: docs/v1.md says endpoint is /charges
  source_b: docs/v2.md says endpoint is /payments
  precedence: docs/v2.md
  reason: current production version

指南

1. 在开发过程中监测上下文长度与性能之间的关联
2. 将关键信息放在上下文的开头或结尾
3. 在退化变得严重之前实施压缩触发机制
4. 将检索到的文档加入上下文前，先验证其准确性
5. 使用版本控制，避免过时信息引发冲突
6. 对任务进行分段，避免不同目标之间出现上下文混淆
7. 针对平稳退化进行设计，而非假设条件始终完美
8. 使用逐渐增大的上下文进行测试，以找出退化阈值

常见陷阱

1. 正常波动看起来像性能退化：模型输出质量在不同运行中会自然波动。不要仅凭一次质量下降就诊断为性能退化——应通过多次运行建立基线，并观察是否存在与上下文增长相关的持续性下降。单次运行中质量下降 5-10% 属于噪声；如果每次都在 40K token 后出现同样的下降，就是信号。

2. 特定模型的阈值会过时：基准测试表中的性能退化起始值反映的是特定版本的模型。提供商更新、微调变更和基础设施调整都可能让阈值向任一方向移动 20-50%。应每季度重新进行基准测试，并在任何重大模型更新后重新测试，而不要把已发布的阈值视为永久不变。

3. 大海捞针测试分数会带来虚假的信心：模型在大海捞针测试中得分 99%，并不意味着它在生产环境中能良好处理 128K token。针尖测试衡量的是从被动上下文中检索单一事实的能力，而真实工作负载需要跨整个窗口进行多事实推理、遵循指令和综合信息。应使用贴近实际工作负载模式的任务专属基准测试。

4. 相互矛盾的检索文档会悄无声息地造成问题：当 RAG 流程检索到两份对某项事实说法不一的文档时，模型可能会悄悄选其中一份，而不指出冲突。这看起来像是正确回答，实则近乎随机。应在文档进入上下文前，在检索层实现矛盾检测。

5. 提示词质量问题会伪装成性能退化：提示词结构不佳（指令含糊、缺少约束、任务描述不清）会产生与上下文退化完全相同的症状——输出不一致、忽略指令、错误使用工具。在诊断性能退化之前，应验证相同提示词在较短上下文长度下能否正常工作。如果它在 2K token 时就失败，问题出在提示词，而非上下文。

6. 性能退化是非线性的，且会出现断崖式下降：性能不会逐渐退化——它会保持稳定，直到达到特定模型的阈值，然后急剧下降。采用“优雅降级”设计的系统往往会错过这种模式，因为监控检查假定性能会线性下降。应在断崖出现前（达到已知起始值的 70% 时）设置压缩触发条件，而不是等到起始值本身。

7. 过度整理上下文可能适得其反：直觉上，结构良好、连贯的上下文应优于杂乱无章的内容。研究表明，在检索任务中，打乱顺序的“干草堆”有时表现更好，因为连贯的上下文会造成错误关联。应针对具体任务测试重度结构化格式是否确实有帮助——不要想当然地认为它有用。

集成

此技能负责诊断和缓解正在发生的上下文故障。相邻技能负责在确定故障后实施相应策略：

• context-fundamentals：在故障发生前，对注意力机制和上下文窗口进行概念性说明。
• context-optimization：诊断后采用掩码、缓存、分区及其他提高 token 效率的策略。
• context-compression：在必须压缩累积上下文时，使用结构化摘要和交接机制。
• filesystem-context：将原始输出、日志和临时状态移出上下文，以便检查受污染或臃肿的上下文，而无需将其留在提示词中。
• multi-agent-patterns：将任务隔离到不同上下文中，以防止混淆和冲突。
• evaluation：性能退化测试和生产环境监控。

参考资料

内部参考：

• 退化模式参考 - 阅读时机：调试特定退化模式并需要实现级别的检测代码（注意力分析、投毒跟踪、相关性评分、恢复流程）

本系列中的相关技能：

• context-fundamentals - 阅读时机：缺乏关于上下文窗口、Token 预算或位置机制的基础知识
• context-optimization - 阅读时机：已诊断出退化问题，需要具体的缓解技术（压缩、压缩、屏蔽）
• evaluation - 阅读时机：设置生产监控，在退化影响用户之前将其检测出来

外部资源：

• Liu 等人，2023 年《迷失在中间》 - 阅读时机：需要为 U 形注意力的说法寻找一手研究依据，或设计感知位置的上下文布局
• RULER 基准测试文档 - 阅读时机：评估模型对长上下文支持的说法，或比较适用于上下文密集型工作负载的模型
• AI 实验室的生产工程指南 - 阅读时机：在生产基础设施中实现上下文管理

---

技能元数据

创建时间：2025-12-20 最后更新：2026-05-15 作者：Agent Skills for Context Engineering Contributors 版本：2.1.0