上下文窗口 128K 和 128K 不一样：为什么"越大越好"是个误区

上周有个开发者朋友问我："我的模型支持 200K 上下文，是不是把整个代码仓库塞进去就行？"

我告诉他：不行。

不是模型撑不住，而是**塞进去的东西越多，模型找重点的能力越差**。这就像你让一个实习生读 500 页文档然后回答一个问题——他确实能读完，但大概率会漏掉关键信息。

上下文窗口的真相

上下文窗口（Context Window）是模型一次能"看到"的 token 数量上限。2026 年主流模型普遍支持 128K 到 200K，听起来很厉害。但这里有个关键区别：**能装下，不等于能记住**。

模型处理长文本的方式不是"逐字阅读"，而是通过注意力机制（Attention）在输入的所有 token 之间建立关联。当输入很长时，注意力权重会被稀释——模型需要同时关注几千个 token，每个 token 分到的注意力就变少了。

我们做了一个简单的对比实验。给同一个模型输入不同长度的文本，然后问同一个问题：

- **10K token 输入**：模型准确找到了答案所在段落，引用了原文。

- **50K token 输入**：模型找到了答案，但混入了无关信息。

- **100K token 输入**：模型给出了看似合理但部分错误的答案，因为它把两段相似内容搞混了。

这不是模型"变笨了"，而是**信息密度下降**导致的。就像在一堆书里找一句话，书越多，找得越慢，错得越多。

不要直接把 10 万字的文档丢给模型。先用模型自己做一个摘要（控制在 2K token 以内），然后在摘要基础上提问。两步走比一步到位准确得多。

模型对输入开头和结尾的信息记忆最强，中间部分最容易遗忘——这就是所谓的"中间丢失"（Lost in the Middle）现象。所以，把你的核心问题放在 prompt 的第一行，参考资料放在后面。

如果必须处理超长文本，把它切成 4K-8K token 的段落，逐段让模型提取关键信息，最后把各段结果汇总。这比一次性塞进去效果好得多，而且成本更低——因为模型不需要在每次推理时处理全部 token。

因为营销需要。"200K 上下文"听起来比"4K 上下文"高级得多。但实际使用中，超过 32K 的场景并不多。大多数对话、代码审查、文档问答，16K-32K 已经绰绰有余。

更大的上下文窗口还有一个隐藏成本：**推理延迟和费用**。token 越多，模型需要计算的注意力矩阵越大，响应时间呈非线性增长。

在我们 SFD 实验室的 15 个 Agent 日常工作中，我们给每个 Agent 的上下文窗口设了硬上限——通常不超过 16K。超过的部分要么被截断，要么先做摘要。

结果是什么？Agent 的响应速度提升了 40%，错误率下降了 25%。

**少即是多，在 AI 系统里同样适用。**

上下文窗口不是越大越好，而是越精准越好。与其追求"能装多少"，不如花心思在"怎么装"上。好的 prompt 工程师不是会写长 prompt 的人，而是知道什么时候该删掉一半内容的人。