什么是 AI 模型的上下文窗口
上下文窗口是语言模型在单次请求中「看到」的文本量：你的提示词、对话历史、上传的文档以及模型的回复。一次 API 调用能否容纳整个代码库、长合同或仅一段短对话，取决于窗口大小。下文说明什么是上下文窗口、如何用 token 衡量，以及为何它是选模型时的关键参数之一。
通俗定义
上下文窗口（context window）是模型在一次请求中能处理的最大 token 数量。token 既不是词也不是字符：它是分词后的文本片段。在俄语和英语中，一个 token 大约对应 3-4 个字符或词的一部分；「programming」可能占 2-3 个 token。
模型不会自行「记住」过去的会话。它在回答时所知的一切，都是你在当前请求中、在窗口限制内传入的内容。若对话或文档超过上限，较早部分会被截断，或需用单独技术压缩（RAG、摘要、分块）。
实际上下文如何构成
典型 API 请求中的上下文包括：
- System prompt - 给模型的指令（角色、回复格式、约束）。
- 消息历史 - 聊天中先前的 user 与 assistant 轮次。
- 附件 - PDF 文本、仓库代码、知识库片段。
- 模型输出 - 许多模型中，回复也计入单次调用的总上限。
逻辑很简单：input + output ≤ 上下文窗口大小（部分模型分别限制 input 与 output，但本质相同 - 每次调用有上限）。
128K 窗口示例：
| 组成部分 | 大约体量 |
|---|---|
| System prompt | 500-2,000 token |
| 对话历史（20 条消息） | 5,000-15,000 |
| 上传文档 | 80,000 |
| 模型回复 | 最多 8,000-16,000 |
若总和超限，API 会报错，或平台自动截断历史开头 - 取决于客户端。
输入上下文与输出上下文
开发者常混淆两个概念：
- Input context - 模型接受的 token 数（提示词 + 历史 + 文件）。
- Max output tokens - 单次调用回复长度的上限（独立 API 参数，如
max_tokens）。
1M 窗口的模型 input 可接近百万 token，但单次回复仍可能限制在例如 8K-64K token。生成长报告有时需要多次顺序请求或流式续写。
部分定价档对 long-context 请求（超过阈值，如 200K input）收费更高 - 反映更大的推理负载。
为何需要大上下文窗口
当单次请求需承载大量相关信息时，大上下文很有用：
- 文档分析 - 合同、报告、数十页研究，无需事先压缩。
- 代码工作 - 多个项目文件、堆栈跟踪与修改历史放在同一提示中。
- 长对话 - 支持与咨询场景需要完整线程，而非仅最近 10 条消息。
- Agentic 场景 - 智能体在单会话中累积观察、工具调用与中间结果。
小窗口（4K-32K）足以应对短任务：分类、表单字段抽取、段落翻译、简单聊天机器人。涉及文档与代码的企业场景通常瞄准 128K 及以上。
2026 年的典型规模
到 2026 年中，市场分为几档：
| 档位 | 窗口大小 | 示例模型 | 典型任务 |
|---|---|---|---|
| 紧凑 | 8K-32K | 轻量本地模型、旧 API | 聊天、分类 |
| 标准 | 128K-200K | GPT-5.5、Claude Sonnet 5、Gemini 3.1 Pro | 代码、文档、智能体 |
| 扩展 | 1M-2M | GPT-5.6、Claude Fable 5、Gemini 3.5 Flash | 大型仓库、语料 |
上下文增长快于「有效」长度：模型技术上可接受百万 token，但在最长尾部质量可能下降（「lost in the middle」效应 - 模型对长上下文中间部分的信息利用较差）。大窗口不能替代良好架构，而是扩展能力。
限制与变通
即便 2M 窗口，也不应把所有内容塞进一个提示：
- 成本 - input 按 token 计费；每次请求百万 token 会迅速抬高生产费用。
- 延迟 - 长上下文在 GPU 上处理更久。
- 质量 - 相关事实应明确提供，而非「埋」在 500 页中间。
窗口不足或需省钱时的实用模式：
- RAG（检索增强生成）- 在向量库中检索相关片段，仅注入提示。
- 摘要 - 用单独模型调用压缩旧消息或文档章节。
- 分块 - 将文本切块并聚合结果。
- 滑动窗口 - 历史中仅保留最近 N 条消息加简短过往摘要。
生产中常组合：知识库事实用 RAG + 适度对话历史 + 128K-1M 模型处理「重」请求。
如何按任务选择窗口大小
| 任务 | 建议下限 | 说明 |
|---|---|---|
| FAQ 机器人、意图分类 | 8K-16K | 历史短，文档走 RAG |
| 单仓库 Copilot | 128K-1M | 取决于代码库大小 |
| 法律 / 合规审查 | 200K+ | 长 PDF、交叉引用 |
| 多模态文档 | 1M+ | 文本 + 图像消耗更多 token |
选模型前先估算 真实 input 体量：统计典型请求的 token（tiktoken、API 分词器或提供商的 count_tokens），并为回复与历史增长预留 20-30% 余量。
总结
上下文窗口是语言模型在单次请求中的「工作记忆」。以 token 计量，包含提示词、历史、附件，通常还包括回复空间。大窗口（128K-2M）可在不频繁截断的情况下分析长文档与代码库，但不能替代 RAG、摘要与成本控制。选模型时不仅看规格数字，还要看长上下文质量、long-context 定价以及典型请求的真实大小。
常见问题
token 与词有何不同？
Token 是模型分词后的文本单位。一个词可能是一个或多个 token；标点与空格也计入。俄语与英语平均 1000 token ≈ 750-900 词 或 3000-4000 字符，具体因语言与模型而异。估算请用具体提供商的分词器，而非 Word 词数。
文本超过上下文窗口会怎样？
取决于平台：API 可能返回「context length exceeded」、截断历史 开头（最早消息先丢）或提供压缩。模型不会「读到」窗口之外 - 超限信息对它不存在。对策：RAG、摘要、分块或更大窗口的模型。
上下文越大回答越好吗？
不一定。大窗口提供传递更多数据的 能力，不保证同等利用好全部内容。极长输入时，中间事实的准确度常下降，成本与延迟上升。更好是传递相关上下文（检索或结构化提示），而非「以防万一」塞入整个语料。
如何估算文档占多少 token？
使用官方工具：OpenAI 兼容模型用 tiktoken，Anthropic tokenizer，Gemini 用 Google AI Studio，或提供商 SDK 的 count_tokens。粗算：1 页文本（约 500 词）约 650-800 token；代码与表格因特殊符号可能每字符产生更多 token。
普通聊天机器人需要 1M token 模型吗？
典型短回复与 FAQ 的聊天机器人 - 不需要，32K-128K 加知识库 RAG 即可。1M+ 适用于大型 PDF 分析、整个仓库、长 agentic 会话，或无法在不损连贯性的前提下预先切分数据。先在生产中测量真实请求大小 - 往往 128K 加合适架构已足够。