上下文窗口详解

一个窗口，一切都在里面。

模型在 API 调用之间没有记忆。每个请求都是仅就你发送的那些令牌从零开始处理。上下文窗口是那条令牌序列的最大长度——输入加上模型正在生成的输出。"200K 上下文窗口"意味着输入和输出加在一起必须装进大约 200,000 个令牌。

关键在于，这个窗口是一个共享的单一预算。一切都在争抢同一片空间：

CONTEXT WINDOW  (e.g. 200,000 tokens total)
+--------------------------------------------------------------+
| system prompt        ~1,500 tok                              |
| tool definitions     ~2,000 tok                              |
| conversation history ~40,000 tok   (grows every turn)        |
| retrieved documents  ~8,000 tok                              |
| current user message ~500 tok                                |
| ............ remaining budget for the model's reply ........ |
+--------------------------------------------------------------+

回复必须装进剩下的部分。过长的历史会让模型没有空间作答——这个故障看起来像"模型被截断了"，实则是"你把预算花在了输入上"。

它以令牌计，不以单词或字符计。

按字符或单词做预算会误导你。粗略地说：典型英文每令牌约 4 个字符，因此每 1,000 令牌约 750 词——但代码、JSON、非英文文本和空白符都会改变这个比例（非英文每词常贵 2–4 倍；见《LLM 思维模型》）。永远别猜；去数。各服务商提供令牌计数端点和分词器库，让你在发送前就能给输入定大小，这在你必须为输出保证空间时至关重要。

到达上限时会发生什么。

三种各不相同、却常被混淆的故障形态：

• 硬拒绝。如果仅输入就超过窗口，API 会在生成任何东西之前返回错误。容易检测，但生产中未处理时很烦人。
• 输出截断。输入装下了但剩余空间很小；当合并长度触及上限或你的 max_tokens 上限时，模型在句子（或 JSON）中途停下。经典症状：因为生成在闭合大括号前被切断而导致 JSON 格式错误。
• 静默驱逐。许多聊天框架会自动裁掉旧消息，让长对话装得下。请求成功了，但模型确实再也看不到被丢弃的轮次。"机器人忘了我十分钟前说的话"通常是这个，而非模型缺陷。

大窗口不是免费空间。

"直接用 1M 令牌的模型，把一切都塞进去"在三个轴上失败：

• 成本。你每轮都为输入令牌付费。一个 10 万令牌的上下文在 20 轮对话中重放，就是为同一份材料计费 200 万输入令牌。上下文通常是智能体烧掉的最贵资源；提示词缓存能为稳定前缀缓解，但不能消除。
• 延迟。输入令牌越多，第一个输出令牌之前的计算越多。大上下文会增加首令牌时延数秒。
• 质量——"迷失在中间"。模型对上下文的开头和结尾关注得最可靠；埋在长上下文中间的信息被回忆得不那么可靠。较新模型会缓解但不会抹去这点。因此即便技术上装得下，更多上下文也可能降低答案质量。

最大窗口大小是天花板，不是目标。有效上下文——模型实际能用好的量——小于名义上限。

管理这个预算。

把上下文当作嵌入式系统里的内存：稀缺、刻意分配、过时即回收。

• 检索，别倾倒。与其粘贴整本 80 页手册，不如每次查询检索那几个相关片段。这正是 RAG 的动机，下一篇详述。
• 总结历史。用一段紧凑的滚动摘要替换 30 个旧轮次。为要点付令牌，而非为逐字记录。
• 刻意定位。把系统契约和最重要的文档放在边界处；在生成前紧挨着重述任何不可妥协的指令，那里近因权重最强。
• 预留输出空间。先决定答案的最大尺寸，从窗口减去它，然后才用输入填满其余。别通过被截断的回复才发现这个亏空。
• 隔离子任务。一个有干净最小窗口的聚焦子智能体，往往胜过一个携带庞大累积历史的——要关注的更少，可迷失的也更少。