上下文窗口是 LLM 一次能考虑的文本总量上限,按 token 计量——相当于它的工作记忆。所有东西共享这份预算:你的指令、之前的对话、贴进来的文档、工具的输出,以及模型正在写的回复。预算花完,就得有内容被丢弃、被摘要或被截断。
这些数字在实践中意味着什么
2026 年的前沿模型普遍提供 1M token 窗口——Claude Sonnet 5、Claude Opus 4.8、GLM-5.2 都在其列。一百万 token 约合 75 万英文单词:一整个代码库、好几本书、或数小时的会议转录,一次调用装下。仓库级代码推理和长时 agent 会话之所以可能,靠的就是这个。
三个坑
- **长上下文更烧钱。**输入 token 按百万计费,填满 1M 窗口的每次调用都是真金白银——部分厂商在超过某个阈值后还加收溢价(如超过 200K 或 272K token)。
- **标称 ≠ 有效。**埋在窗口中段的内容,模型的利用率可能下降(所谓 “lost in the middle” 效应);装得下 1M token 的模型未必用得好每一段。厂商越来越多地发布长上下文基准,正是因为光看标称数字说明不了问题。
- **窗口因平台而异。**同一个模型在不同云上限制可能不同——Opus 4.8 在 Claude API 上是 1M token,在 Microsoft Foundry 上是 200K。
怎么管好这份预算
提示词缓存(prompt caching)让重复使用的前缀(长 system prompt、共享文档)在后续调用里便宜得多;检索增强(RAG)只把相关片段塞进窗口而不是全量;发送前先用 Token 计算器算算你的文本到底要花多少钱。各模型的当前窗口规格见 LLM 模型目录。