一个代理探索 500 文件的代码库 60 分钟。开始时，它引用 src/auth/jwt.ts:12 → verifyJWT() 和精确的函数签名。到第 45 分钟，它描述的是”典型的 JWT 验证模式”——泛化的、无出处的、换到任何代码库都成立的。会话早期发现的具体细节随着后续信息的积累被稀释和挤走了。
这就是上下文退化：一种与会话时长相关而非与任务复杂度相关的渐进式具体性丧失。
具体性衰减
一个探索代理 60 分钟内的输出度量：
| 时间 | 具体引用（file:line、函数名） |
|---|---|
| 0-15 分钟 | 92% |
| 15-30 分钟 | 74% |
| 30-45 分钟 | 48% |
| 45-60 分钟 | 23% |
衰减是稳定的，与正在探索的内容无关。它与时间（累积的上下文）相关，而不是代码特征。
受控证据：复杂度不是原因
客服准确率按对话长度追踪，控制了案例复杂度：
| 短对话（5-10 条消息） | 长对话（25+ 条消息） | |
|---|---|---|
| 简单案例 | 98% | 91% |
| 复杂案例 | 94% | 82% |
每增加 10 条消息，准确率下降 3%，不管复杂度如何。 衰减是均匀的——对简单和复杂案例的影响一样。错误类型：金额错误、政策引用错误、订单详情张冠李戴。这些是上下文退化导致的具体性丧失，不是推理失败。
自我矛盾信号
检查了 80 多个文件后，代理开始与自己早期的发现矛盾——对它之前认定结构良好的代码建议重构。代理失去了对自己先前评估的访问，因为那个评估已经被后续信息稀释了。
这是最清晰的诊断信号：当代理当前的输出与其早期输出冲突时，上下文退化就是原因。
缓解策略
对于独立项目（发票提取、批处理）： 每个项目在自己的会话中用新鲜上下文处理。发票 #47 和发票 #46 没有依赖关系——共享会话只会引入退化。每个项目的准确率保持在 97% 而不是到第 50 个时降到 89%。
对于持续探索（代码库映射、研究）： 把关键发现写到 scratchpad 文件。上下文填满时压缩对话历史——代理引用外部文件而不是退化的上下文。这把关键知识外部化，使其免受退化影响。
对于大型代码审查（CI 中 20+ 文件）： 拆分为独立上下文的单文件审查轮次。每个文件获得全部注意力。最终集成轮次检查跨文件交互。这是 K4.6.3 多轮模式应用于退化预防。
对于多模块安全审计（400+ 文件）： 每个模块在独立的子代理会话中扫描。每个模块的发现写到一个文件。一个新鲜的协调器从所有发现文件中编译报告。没有单个会话处理超过一个模块的上下文量。
什么不管用
更大的上下文窗口。 延迟退化但不能防止它。即使在大窗口内，连续处理数百个文件时注意力质量仍然会退化。问题是注意力稀释，不是原始容量。
“要准确”指令。 无法恢复已经从上下文中丢失的信息。如果订单号在摘要中被稀释了，任何指令都无法让代理引用它。
重新读取早期输出。 消耗额外上下文空间，加速耗尽问题。信息应该被外部化到文件，而不是重新注入已经紧张的上下文。
会话中途转移到更大的模型。 保留的是退化后的状态。已经被摘要的早期发现在新上下文中仍然是模糊的。
一句话总结： 上下文退化导致每增加 10 条消息准确率稳定下降 3%，不管复杂度如何——用 scratchpad 缓解持续会话，用独立会话处理独立任务，用按模块的子代理处理大代码库。