上下文窗口不是免费存储：显式驱逐策略的必要性

大多数工程团队对待 LLM 上下文窗口的方式，就像早期 Web 开发者对待全局变量：先塞进去，问题以后再说。上下文里堆满了最近 40 轮对话、仓库里的三个完整文件、十几份检索到的文档，以及一个经过六个月集体修改、越来越臃肿的系统提示词。一切看起来都能运行——直到某天突然不行了，而那时已经很难判断究竟是哪里出了问题。

上下文窗口不是堆内存。它更接近于 CPU 寄存器文件：容量有限、单位成本高昂，且其内容直接影响模型执行的每一次计算。当你把寄存器当成草稿纸随意使用而忘记管理时，程序会以各种匪夷所思的方式崩溃。当你把上下文窗口当成草稿纸时，LLM 会以悄无声息且代价高昂的方式退化。

为何"塞满一切"的直觉看似正确

上下文填充背后的直觉乍看合理：信息越多，答案越好；模型看不到的内容就无法利用；检索有延迟，不如把所有东西都留在上下文里。当上下文窗口还只有 4K Token、稀缺性强制约束行为时，这些论点有一定道理。随着窗口扩展到 128K、200K 乃至更大，稀缺压力消失了——约束意识也随之消失了。

取而代之的是另一种直觉：越大越安全。200K Token 的窗口可以容纳整个代码库，为什么不用呢？模型自己会判断什么内容相关。

然而事实并非如此，而且后果会以大多数团队从未度量过的三种方式复合叠加。

成本是二次方增长，而非线性增长。 Transformer 注意力机制的复杂度相对于序列长度是 O(n²)。将上下文加倍，计算量不是翻倍——而是翻四倍。一个传入 8,000 Token 文件内容的系统，处理成本是传入 1,000 Token 以回答相同问题的系统的 64 倍。那些看到账单飙升却归因于"用量增长"的团队，往往面对的其实是披着规模问题外衣的上下文膨胀问题。

质量在触及上限之前就已开始下降。 Chroma 在 2025 年针对"上下文衰退"（context rot）的研究——覆盖了 18 个前沿模型，包括 GPT-4.1、Claude Opus 4 和 Gemini 2.5 Pro——表明输出质量在上下文窗口填满之前就已出现明显退化。退化并不均匀：它遵循 U 形注意力曲线——位于上下文开头和结尾的 Token 获得的关注不成比例地多，而中间的 Token 则被部分忽略。针对多文档问答的研究发现，当相关文档从 20 个文档列表的第 1 位移到第 10 位时，准确率下降超过 30%。GPT-3.5-Turbo 有时在添加额外上下文后，表现反而比没有上下文时更差。

有效容量低于宣传值。 一个声称支持 200K Token 的模型，实际可靠的工作范围更接近 120K–140K。在宣传窗口的 60–70% 处，准确率就开始退化，而这种退化很难在聚合指标中发现，因为错误答案看起来和正确答案一样。

这些问题不会出现在请求延迟仪表盘或错误率监控中。它们表现为细微的质量漂移——输出在技术上逻辑通顺，但缺少关键细节、做出错误权衡，或自信地忽略了埋藏在检索文档第三页的相关约束。

度量缺口

大多数团队默默承受这些成本却浑然不觉，原因在于上下文利用率几乎从未被监控。团队会跟踪 Token 数量（通常作为成本信号而非质量信号），也会记录延迟。但几乎没有人追踪：

• 上下文利用效率：上下文中有多少比例的 Token 被模型输出实际引用？如果传入了 20K Token，而答案只用到了其中 500 Token 的信息，那么你为 97.5% 的浪费买了单。
• 相关内容的上下文位置：模型实际使用的信息出现在上下文窗口的什么位置？如果总是在中间，这就是一个警示信号。
• 质量与上下文大小的相关性：随着上下文增大，输出质量（通过评估而非感觉来衡量）是否下降？这是上下文衰退最直接的信号，但几乎没有团队做这个实验。
• 单次查询的上下文构成：系统提示词、对话历史、检索文档、工具调用结果各占多少 Token？这些数字自上个季度以来如何变化？

没有这些监控，上下文填充就是隐形的。账单上涨，质量下降，诊断结果是"模型变差了"或"用户变了"，而不是"我们开始在每次调用中传入完整聊天记录加三份支持文档"。

上下文预算：一种工程实践

操作系统应对寄存器稀缺的方式不是购买更多寄存器——而是通过纪律和工具显式管理寄存器分配。同样的方法适用于上下文窗口。

上下文预算是按请求分配的 Token 容量，按来源细分。以下是一个处理编程任务的 Agent 的具体示例：

• 系统提示词：2,000 Token（固定，每季度审查）
• 任务描述和当前意图：500 Token
• 对话历史（摘要版）：1,500 Token
• 检索到的代码上下文：4,000 Token
• 本轮工具调用结果：2,000 Token

加载中…