我如何理解 Context Rot

关于上下文管理,最常见的比喻是容量:窗口是一个容器,装到百分之八十就该清理了。这个比喻统治了绝大多数 Agent 的上下文策略,也误导了它们。

我的观察是:Agent 在真实代码库任务上的退化,很少发生在窗口将满时,而是发生在某个看起来还很宽裕的中间点。退化之前,窗口里通常已经堆了十几轮工具输出,其中大部分是正确但无关的信息。

浓度视角改变了什么

容量视角下,管理策略是”什么时候删”。浓度视角下,问题变成了”删什么、留什么、按什么顺序留”。这两者的差异在实践里非常大:

• 容量策略会保留最新的内容,因为它假设旧的先过期。浓度策略发现:二十轮前那条确立任务边界的用户指令,浓度高于刚刚那一大段测试日志。
• 容量策略倾向于摘要压缩。但摘要有自己的稀释成本——压缩后的内容浓度上限变低了,因为细节被磨平。

还没想清楚的部分

另一个疑点:稀释是不是严格单调的?直觉上,一次精准的纠错反而能”唤醒”被稀释的早期信息。如果成立,那上下文管理就不只是删除,还包括周期性地重述核心约束——用新的 token 重新激活旧的语义。

这篇先到这里。观点还会改,但”浓度优于容量”这个判断,目前在我的实验里没有反例。