Context Degradation Zh

---
name: context-degradation-zh
description: 上下文退化诊断与缓解、中间迷失（lost in the middle）、上下文投毒、上下文干扰、上下文混淆、上下文冲突、长对话后 Agent 变笨、明明给了信息模型却无视、纠正后仍反复引用错误事实。当用户说「对话越长 Agent 越不听话」「我明明写了它为什么忽略」「它一直重复一个错的结论怎么纠正都没用」「RAG 检索了两份矛盾的文档」「多个任务混在一个会话里串了」时使用。五种退化模式各有信号与对策：中间迷失→关键信息放首尾；投毒→截断到投毒点之前重来而不是叠加纠正；干扰→单个无关文档就会显著拖累、加载前先过滤；混淆→任务隔离与显式上下文重置标记；冲突→事先定来源优先级并标注矛盾。附四桶缓解框架（写出 / 筛选 / 压缩 / 隔离）与阈值、恢复流程参考。也覆盖「忽略我一开始定的规则」「纠正了也没用」「说法矛盾」这类说法。改编自 Agent Skills for Context Engineering 的 context-degradation（MIT）。
author: Captain
version: 0.1.1
display_name: "上下文退化诊断"
display_name_en: "Context Degradation (zh)"
description_zh: "在级联之前诊断并修复上下文失效。退化不是二值而是连续体，表现为五种可预测模式：中间迷失、投毒、干扰、混淆、冲突。每种都有检测信号与缓解策略，把退化当成有可测阈值的工程问题。"
description_en: "Diagnose and fix context failures before they cascade. Degradation is a continuum with five predictable patterns: lost-in-middle, poisoning, distraction, confusion, clash. Each has detection signals and mitigations; treat it as an engineering problem with measurable thresholds."
tags:
  - "上下文退化"
  - "context degradation"
  - "中间迷失"
  - "上下文投毒"
  - "Agent 调试"
examples_zh:
  - "对话到后面 Agent 就开始忽略我一开始定的规则，怎么办"
  - "它一直引用一个错误的检索结果，纠正了也没用"
  - "两份文档说法矛盾，模型随机选了一个还不告诉我"
examples_en:
  - "The agent ignores rules I set at the start once the chat gets long"
  - "It keeps citing a wrong retrieved fact even after correction"
  - "Two docs disagree and the model silently picked one"
metadata:
  { "openclaw": { "requires": { "bins": [] }, "os": ["darwin", "linux", "windows"], "emoji": "📉" } }
---

# 上下文退化诊断

在级联之前诊断并修复上下文失效。退化不是二值的，而是通过五种独立、可预测的模式表现出来的连续体：**中间迷失、投毒、干扰、混淆、冲突**。每种模式都有特定的检测信号和缓解策略。把退化当作有可测阈值的工程问题，而不是不可预测的故障。

## 什么时候用

- 长对话中 Agent 表现意外下滑
- 调试 Agent 输出错误或无关内容的案例
- 设计必须可靠处理大上下文的系统
- 评估生产系统的上下文工程选择
- 排查「中间迷失」现象

相邻工作归别的技能：没有具体失效、只是解释机制→「上下文工程基础」；失效模式已知、要做 token 效率优化→压缩与遮蔽类技能；设计压缩或交接摘要→「上下文压缩」。

## 流程
监控上下文长度与表现的相关性，发现异常 → 对照五种模式详解定位是哪一种（或几种叠加）→ 按四桶缓解框架选策略并执行 → 在模型专属退化阈值之前重新设置压缩触发，不等症状复现。

## 核心概念

**围绕注意力 U 曲线安排位置。** 开头和结尾位置得到可靠的注意力，中间位置在长上下文实验中回忆准确率明显下降。这不是 bug，是注意力机制的结果：第一个 token 常充当「注意力汇」吸走不成比例的预算，上下文越长中间越被冷落。

**把投毒当断路器问题。** 幻觉、工具错误或错误的检索事实一旦进入上下文，就通过反复自引用复利放大。目标段被投毒，下游每个决策都在强化错误假设。检测要追踪主张来源；恢复要截断到投毒点之前，或只用已验证内容重启。

**加载前激进过滤。** 哪怕一份无关文档也会显著拖累相关任务。模型无法「跳过」无关内容，必须关注给它的一切，相关与无关内容争夺注意力。可能需要但当前不相关的信息放到工具调用后面，不预加载。

**隔离任务上下文防混淆。** 上下文含多种任务类型或目标切换时，模型会套用错误任务的约束、调用另一个语境的工具、混合多来源的需求。显式的任务分段 + 独立上下文窗口消除交叉污染。

**用优先级规则而不是堆积来解决冲突。** 多个各自正确却互相矛盾的来源（版本冲突、视角冲突、多源检索）同时在场时，模型无法判断哪个适用。显式标注矛盾、建立来源优先级、在进入上下文前过滤掉过期版本。

## 五种模式详解

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

关键信息放开头和结尾，永远不放中间。超过 4K token 的上下文这一效应就显著。用摘要结构把关键发现浮到注意力偏好的位置；加显式的章节标题和结构标记作为注意力锚点。必须完整包含某文档时，前面加要点摘要、后面加关键结论。

症状：正确信息就在上下文里但模型无视；回答与提供的数据矛盾；模型「忘了」长提示词前面给的指令。

### 投毒：预防与恢复

所有外部输入进入上下文前先验证。工具输出、检索文档、模型生成的摘要是三大投毒向量，各自引入被后续推理当作事实的未验证主张。

信号：之前成功的任务质量下滑；工具误用（错误的工具或参数）；显式纠正后仍持续的幻觉。这些聚在一起出现时，怀疑投毒而不是模型能力。

恢复靠**移除**被投毒内容，不靠在上面叠加纠正。截断到投毒点之前；或只保留已验证信息、用干净上下文重启；或显式标记被投毒段并要求从头重新评估。在被投毒的上下文上叠纠正很少奏效——原始错误仍保有注意力权重。

### 干扰：策展而非堆积

策展进入上下文的东西，不要指望模型忽略无关内容。研究表明单个干扰文档就触发可测的性能下降——效应是阶跃函数，不是线性曲线；多个干扰复利叠加。加载检索文档前做相关性过滤；用命名空间和结构让段边界清晰；参考资料放在检索工具后面，只在与当前推理步直接相关时进入上下文。

### 混淆：任务隔离

不同任务放到不同上下文窗口。混淆与干扰不同：它是模型把错误语境的约束套到当前任务上，而不只是注意力被稀释。迹象：回答针对了问题的错误方面；工具调用属于另一个任务；输出混合了多来源的需求。任务上下文之间做清晰的过渡；按任务隔离目标、约束和工具定义；单会话内不得不切换任务时，用显式的「上下文重置」标记声明当前段适用哪些约束。

### 冲突：解决协议

冲突发生前先定来源优先级规则。冲突与投毒不同：各条信息单独看都对，只是互相矛盾。做版本过滤，过期信息进不来。矛盾无法避免时，用结构化标注显式标出：什么冲突、各主张来自哪个来源、哪个来源优先。没有显式优先级，模型的解法不可预测。

```yaml
conflict:
  topic: 计费 API 版本
  source_a: docs/v1.md 说端点是 /charges
  source_b: docs/v2.md 说端点是 /payments
  precedence: docs/v2.md
  reason: 当前生产版本
```

## 经验阈值

用这些数字定设计约束，不当普适真理。RULER 类证据表明：宣称支持的长上下文不保证在该长度下的任务表现令人满意；近乎满分的「大海捞针」不能预测真实的长上下文性能。

- 复杂检索任务通常在广告窗口的 60–70% 开始退化（RULER 发现宣称 32K+ 的模型只有约一半在该长度保持满意表现）。
- 带扩展思考的模型通过逐步验证减少幻觉，代价是延迟和 token。
- 面向 Agent/编码优化的模型对工具输出密集的上下文注意力管理更好。
- 1M+ 窗口的模型能吃更多原始上下文，但仍遵循 U 形退化——更大的窗口推迟问题，不消灭问题。
- 处理 40 万 token 的成本相对 20 万不是线性翻倍而是指数级；很多应用因此在经济上不可行。
- 即便上下文无限，让一个模型同时维持几十个独立任务的质量也会退化，更多上下文解决不了；拆到子代理。

**反直觉发现：** 打乱顺序的上下文有时在检索任务上胜过连贯的（连贯性可能制造假关联；打乱迫使精确匹配）——两种排列都测。单个干扰项的冲击不成比例地大——干扰防护当二值处理：要么干净，要么接受显著退化。「针」与问题相似度低的推理任务随长度退化更快——让检索最大化查询与内容的语义重叠。

一律在自己的负载上做退化基准测试；模型专属阈值随每次模型更新而过期。

## 四桶缓解框架

按活跃的退化模式选策略：

- **写出（Write）**：用草稿文件、文件系统或外部存储把上下文保存到窗口之外。占用率超过 70% 时用。活跃上下文保持精简，信息通过工具调用仍可达。
- **筛选（Select）**：通过检索、过滤、排序只拉相关内容进窗口。出现干扰或混淆症状时用。加载前做相关性评分，低于阈值的排除，而不是有什么放什么。
- **压缩（Compress）**：通过摘要、抽象、观察遮蔽在保留信息的同时减 token。上下文在增长但内容都相关时用。冗长的工具输出换成紧凑的结构化摘要；重复模式抽象成单一引用。
- **隔离（Isolate）**：把上下文拆到子代理或多个会话，任何单一上下文都不越过退化阈值。出现混淆或冲突症状、或任务彼此独立时用。最激进，但对复杂多任务系统常常最有效。

架构层面：即时加载（当前推理步需要时才取）；观察遮蔽（处理完把冗长输出换成引用）；子代理各持任务相关的上下文；在模型专属退化阈值**之前**触发压缩，不等症状出现。

## 示例：投毒断路器

```text
症状：Agent 在纠正之后仍反复引用一个错误的检索主张
诊断：上下文投毒，不是缺指令
动作：
  1. 找到错误主张首次进入的那一轮
  2. 截断或从那之前重启
  3. 只重新加载已验证的来源
  4. 记录被拒绝的主张及其来源
```

## 准则

1. 开发期间监控上下文长度与表现的相关性
2. 关键信息放开头或结尾
3. 在退化严重之前设置压缩触发
4. 检索文档入库前验证准确性
5. 用版本管理防止过期信息造成冲突
6. 任务分段防止跨目标混淆
7. 为优雅退化而设计，不假设完美条件
8. 用逐步增大的上下文测试，找到退化阈值

## 坑

1. **正常波动看起来像退化。** 单次质量下滑是噪音；同样的下滑在 40K token 后持续出现才是信号。先建多次运行的基线。
2. **模型专属阈值会过期。** 厂商更新、微调、基础设施变化能让阈值双向移动 20–50%。每季度、以及每次重大模型更新后重测。
3. **大海捞针高分制造假信心。** 它测的是被动上下文中的单事实检索；真实负载需要多事实推理、指令遵循和全窗口综合。用镜像真实负载的任务基准。
4. **矛盾的检索文档悄悄投毒。** RAG 取回两份说法不一的文档，模型可能一声不吭选一个——看着像正确回答，实际是随机。在检索层做矛盾检测。
5. **提示词质量问题伪装成退化。** 模糊指令、缺约束、任务框定不清产生与退化相同的症状。先验证同一提示词在低上下文长度下是否正常；2K token 就失败的，问题在提示词。
6. **退化是带悬崖的非线性。** 性能稳定到某个阈值后骤降。按线性衰减设计的监控会漏掉它。压缩触发设在已知起点的 70% 处，不是起点本身。
7. **过度组织可能适得其反。** 打乱的干草堆有时胜过连贯的。针对具体任务测试重度结构化是否真的有帮助，不要假设。

## 参考

- [references/patterns.md](references/patterns.md)：注意力分布分析、投毒追踪、错误传播分析、相关性评分、上下文健康监控与告警阈值、恢复截断策略。
- 同系列：上下文工程基础（context-fundamentals-zh）、上下文压缩（context-compression-zh）、记忆系统（memory-systems-zh）。

---
改编自 [Agent Skills for Context Engineering](https://github.com/muratcankoylan/Agent-Skills-for-Context-Engineering) 的 `context-degradation`（MIT）。改动见 ATTRIBUTION.md。