上下文退化诊断

长对话里的 Agent 为什么会突然"失灵"

Agent 在长对话中逐渐表现不佳时,常见的归因是"上下文太长了"。这个说法不算错,但无法指导修复。真正要回答的是:到底丢了什么、何时开始坏、该动哪个环节。可能是中部的关键指令被忽略(lost-in-middle),可能是一条幻觉经反复自我引用被固化(poisoning),也可能是无关文档混入抢走了注意力(distraction)、多类任务约束互相污染(confusion),或多条各自正确的信息彼此冲突(clash)。

先量化,再定位模式

技能的工作流从基线开始:先用多次低上下文运行确认正常质量,只有当下跌持续且与 token 增长相关(常见在超过 40K token 后反复出现)才判定为退化,排除自然波动。随后对照五种模式的典型信号:正确信息明明在上下文里却被无视、纠正后仍坚持错误、调用了别的任务的工具、回答了问题的错误面向等。

修复走四桶法,不靠叠加更正

• Write:利用率超 70% 时把信息存到草稿或文件,靠工具按需取回
• Select:出现干扰/混淆时做相关性过滤,低于阈值不加载
• Compress:内容都相关但仍在增长时,用摘要与观察遮蔽降 token
• Isolate:任务彼此独立时拆到子 Agent 或独立会话

一个关键判断:中毒要靠截断到中毒点之前重启,而不是往上叠加更正——原错误仍占注意力权重,叠加几乎无效。

输出与边界

产出 DegradationDiagnosis 工件:模式、信号、严重度、四桶法方向、操作步骤。注意它只负责"诊断 + 选定修复方向",具体的压缩、交接、持久化手法要交给下游技能。复杂检索任务的退化常在名义窗口 60-70% 处开始,大窗口只是延迟而非消除退化。