上下文窗口有多大才够用？读懂 token 限制与长上下文

上下文窗口是大语言模型（LLM）处理一次请求时可用的 token 总空间，既包括读入的内容，也包括生成的内容。在 1M token 的窗口内，指令、文档和对话记录要与模型的回答共用这份空间；如果模型会进行思考，思考过程也要占用其中的容量。把窗口填满，并不意味着模型就能准确利用里面的每个细节。

AI 的上下文窗口是什么？

可以把上下文窗口想象成一张工作台。文档、指令和待完成的工作都要摆在台面上。台面越大，能铺开的材料越多，但操作本身也需要空间；即使把所有文档都摊开，也不代表你一定能注意到关键条款。

token 是模型处理信息的单位，通常是词语的一部分，而非一个完整的词。文本、代码等输入会按模型自身的规则转换成 token。因此，应当计算实际请求包含多少 token，而不是根据页数或文件大小估算容量。Google 的 token 指南解释了这一区别。

输入中还可能包含你从未在聊天框里输入过的内容：

• 规定助手行为的系统指令。
• 当前消息，以及保留下来的对话历史。
• 描述模型可执行操作的工具定义。
• 工具返回结果、检索到的段落、图片和文档。

Anthropic 在上下文计算规则中明确将这些内容纳入统计。因此，用户的问题即使很短，完整请求也可能非常大。

上下文窗口和 token 限制有什么区别？

上下文窗口约束的是整个请求，输出上限约束的则是生成的部分。推理模型可能会先用掉一部分生成预算进行思考，再给出可见的答案。OpenAI 的文档说明了输入、输出和推理如何占用同一个窗口。

对于输入与输出共享窗口的模型，规划时应遵循这条规则：

输入 token 数 + 为生成预留的 token 数，不得超过上下文窗口。

如果模型将推理计入生成部分，预留空间时也要把它算进去。同时，还要遵守模型单独规定的最大输出限制。把输出上限设得更高，并不会凭空增加空间。

AI 工具的上下文窗口究竟决定了什么？

它决定模型在当前请求中能同时考虑多少材料，却不能说明模型能否准确运用这些材料、应用会在会话之间保存什么，或下次请求时会把哪些已保存的内容重新发送给模型。

对客服人员来说，这一区别很实际：工单仍然保存在客服系统中，却可能根本不在助手当前的输入里。对开发者来说，保存对话记录和组装下一次模型请求，是两项不同的工作。

Claude、GPT-6 和 Gemini 4 的上下文窗口有多大？

下表中的主要 API 模型都提供了约百万 token 的上下文窗口，但除了醒目的容量数字，输出规则同样关键。**以下规格已于 2026 年 10 月 16 日根据各厂商当时在线的模型页面核实。**每一行都附有厂商页面链接；这些是 API 规格，并不代表面向个人用户的聊天套餐或具体应用也提供相同额度。

Claude 当前的模型页面显示，上表中各款 Claude 模型的窗口大小和输出上限相同。因此，上下文窗口大小不适合作为它们之间的主要选型依据，更应该比较它们在你的任务中的回答表现。

GPT-6 Astra、GPT-6.1 Sol 和 GPT-6 Luna 的上述容量也相同。不过，即使窗口一样大，模型在信息提取、规划或编程任务上的表现仍可能不同。规格只能说明装得下多少内容，不能据此给质量排名。

Gemini 4 Argon 的长解码额度也属于这个共享窗口。Google 表示，API 会将请求的输出量限制在扣除输入后的剩余空间内，思考过程同样消耗这份预算。不能先把输入窗口填满，再在其上叠加一份高额输出额度。Gemini 的 token 计算规则对此有明确说明。

算一笔账：提示词放得下，回答却未必

一份百万 token 的提示词，留给回答的空间可能比模型标称的最大输出少得多。

以 GPT-6 Astra 文档中的限制为例。假设组装后的请求包含 1,000,000 个输入 token，涵盖指令、工具、历史记录和源文档。这只是用于演示的预算，并非实测工作负载。你希望为生成预留模型允许的全部 128,000 个 token。

计算如下：

• 上下文窗口：1,050,000 tokens。
• 扣除输入后的剩余空间：1,050,000 − 1,000,000 = 50,000 tokens。
• 计划中的输入加输出：1,000,000 + 128,000 = 1,128,000 tokens。
• 缺口：78,000 tokens。

输入放得下，计划中的回答预算却放不下。而且，剩余空间还需要同时容纳推理过程和可见答案。

若要预留完整的最大输出额度，输入最多只能占 922,000 tokens，也就是 1,050,000 − 128,000。这还没有扣除工作流需要的额外余量。当然，并非每个任务都要预留最大输出；应根据任务实际需要的输出量来分配空间。

为什么上下文窗口更大，信息召回却未必更好？

请求没有超出容量，模型的回答仍可能漏掉其中的证据。即使 API 接受了提示词，这也属于质量问题。

Anthropic 在上下文工程指南中指出，上下文增长时，信息召回能力可能下降。问题不一定表现为明显的拒绝回答：助手可能忽略某项例外，把旧政策和替代它的新政策混为一谈，或者根据附近一段看似相关的文字作答。

Nelson F. Liu 等人的论文 Lost in the Middle发现，文档问答和键值检索的表现，会受到相关信息所在位置的影响。相比靠近开头或结尾的证据，中间位置的证据可能更难被有效利用。这是一项既有研究，并不是针对上表当前模型的基准测试。

**长上下文质量，应当用你自己的工作负载来衡量。**这里不存在一个通用的 token 数字，超过它，所有模型就会突然变得不可靠。

对于客服助手，可以围绕政策中的例外条款建立一组小型评测集，并确保正确答案已知。先只提供适用政策，再加入无关政策构成长请求，对比两种输入下的表现。把决定答案的关键段落分别放在靠前、中间和靠后的位置，检查回答是否采用了正确的例外条款，以及是否引用了正确来源。

对于编程助手，可以提出一个需要结合实现文件及其调用方才能回答的问题。先确认模型在聚焦输入下的答案，再加入无关文件。如果输入变长后效果反而下降，购买更大的容量并不能帮你查明错误原因。

成功找到一句有明显特征的话，可以说明模型具备相应的检索能力，但不能证明它能协调相互冲突的文档，也不能证明它在长任务中始终遵守每一项约束。

遇到上下文超长或 token 限制，该怎么办？

**开发者应检查组装后的完整请求，使用者则应先保存当前任务状态，再继续会话。**无论哪一种情况，都要分清：是输入被拒绝，还是回答因没有剩余空间而中途停止。

按照 Anthropic 对当前 Claude 模型的说明，仅输入就超出窗口时，会报提示词过长错误。如果输入没有超限，但生成过程触及窗口边界，响应则可能以 model_context_window_exceeded 为停止原因。应检查实际报错或停止原因，而不是默认系统已经悄悄丢弃了旧消息。参见 Claude 的上下文溢出处理规则。

1. 1

   统计应用实际发送的全部内容

   把指令、对话消息、工具定义、检索段落和工具结果放在一起检查。如果厂商的 token 计数功能支持你的请求格式，就先用它估算，再与响应中的实际用量对照。Anthropic 的 token 计数接口支持结构化消息和多种输入类型，但对服务端工具及部分文件来源有限制。

2. 2

   为生成内容预留空间

   记录模型的窗口大小、输出上限，以及当前任务需要预留的输出量。适用时也要计入思考过程，再相应缩减输入预算；不要把每一个剩余 token 都当成继续塞文档的空间。

3. 3

   找出不断膨胀的内容

   重点检查重复的搜索结果、完整日志、重复文档，以及已放弃的对话分支。编程智能体可能需要失败的测试和相关函数，但通常不需要在每一轮都带上此前所有成功命令的完整输出。保留能帮助验证下一步操作的证据即可。

4. 4

   留下接续任务的记录

   重启或压缩上下文之前，保存目标、已经确认的决策、尚未解决的问题、相关来源的位置，以及下一步操作。处理客户问题时，应保留当前诉求和适用的政策例外。只要精确措辞会影响判断，就重新打开原始来源核对。

5. 5

   调整后再次检查答案是否正确

   用缩小后的请求重做此前失败的任务，确认必需的证据仍然存在，答案也正确。如果提示词已经能放下，模型却依然漏掉决定性细节，就应排查材料选择和信息召回，而不是继续盲目删减。

如果一个简短、稳定的工作流已经能正确回答，而且始终没有超限，就无需调整模型选择。仅凭宣传中的窗口更大，不足以成为迁移理由。

检索、摘要、上下文压缩和缓存，分别该在什么时候用？

先看是什么内容占据了空间，再选择处理方式。这些技术解决的问题各不相同，也可以配合使用。

**当资料总量远大于回答问题所需的证据量时，使用检索。**检索增强生成（RAG）会在模型作答前提供筛选后的来源材料。客服助手应获取适用的退货政策和订单记录，而不是通读整个知识库。Agentic RAG 指南介绍了智能体如何在首轮证据不足时继续搜索。

检索的局限在于筛选：如果遗漏了决定答案的例外条款，模型就无从利用它。如果任务确实需要持续比较多份文档的细节，可以把数量受控的完整文档放进上下文，并评估缩小范围后是否丢失了必要证据。

**当旧细节可以转化为长期保留的任务状态时，使用摘要。**摘要应保留已经作出的决定、仍未确定的事项，以及支撑材料的位置。对于一次代码修改，这可能包括选定的方案、当前失败表现和相关文件路径。如果下一步判断依赖具体措辞，就不要用笼统转述替代准确的合同条款或错误信息。

**当对话历史本身占据了大部分空间时，使用上下文压缩。**上下文压缩会把累积的历史替换为更精简、可供继续工作的上下文。Anthropic 提醒，压缩过于激进可能丢失重要细节，因此要检查哪些信息被保留下来，不能把压缩后的对话当作无损档案。Anthropic 对上下文压缩的讨论解释了其中的取舍。

更完整的上下文工程指南介绍了如何在智能体工作的过程中选择和维护这些内容。

**当有用的输入反复出现时，使用提示词缓存。**它会复用匹配的提示词前缀所对应的处理结果，也就是请求开头保持不变的那部分内容。把稳定的指令和共用材料放在变化的内容之前，并遵循模型的缓存规则。OpenAI 当前的指南包含显式缓存断点的行为说明，而 Gemini 4 Argon 的模型页面只列出了隐式缓存。参见 OpenAI 缓存指南和 Gemini 缓存支持情况。

长提示词会增加计费的输入 token。缓存命中可以降低重复输入的费用，具体仍取决于缓存写入规则，但这些 token 依然占据上下文窗口。缓存机制另有专文介绍。

压缩或重写提示词的开头，可能降低缓存复用率。有用的稳定前缀应尽量保留；无关历史如果已经影响请求质量，就应删除。缓存命中率高，并不能证明答案质量好。

长上下文有哪些被夸大的能力？

**人们常常让容量数字去证明它根本没有衡量过的能力。**上下文窗口再大，也不能据此认定模型具有完美的信息召回能力、永久记忆，或能用更长的提示词替代所有检索工作流。

真正需要更大窗口的情况很具体：任务要求同时处理更多相关证据，较小的请求会丢失关键关联，而更大的请求在你的评测中确实能得出正确结果。这才是使用更大容量的理由。

如果日志、历史记录或来源资料正在挤占回答空间，就应着手处理。先改进进入请求的内容；若相关材料仍然放不下，再考虑窗口更大的模型。如果现有工作流已经可靠，只是规格表上出现了更大的数字，就不必急着更换。

关于上下文窗口的常见问题

AI 语言模型的上下文窗口是什么？

它是模型在单次请求中可用的 token 容量，涵盖模型处理的输入和生成的输出。对于推理模型，还要按照厂商的规则计入思考过程。

200K 上下文长度到底有多长？

200K 表示 200,000 tokens，并不对应固定的字数或页数；输入与输出共享的窗口还必须容纳生成内容。应使用所选模型的分词器或它支持的计数接口，统计你的实际材料。

编程中的上下文是什么意思？

上下文是某项操作可以利用的周边信息。在 LLM 应用中，它指为当前模型请求组装的指令、消息和辅助材料。

上下文工程有什么具体例子？

客服助手收到当前工单、适用政策，以及此前决策的简要记录。需要时再检索补充证据，而不是直接接收全部工单档案。

上下文工程师的薪资有多高？

上下文窗口规格无法说明一个岗位的薪资。招聘时，应先明确工作内容涉及检索、应用工程、评测还是基础设施，再比较所在地区职责范围相近的岗位。

如何学习上下文工程？

从一个小型应用的完整请求入手，分别调整指令、检索证据或保留的历史，并用已知正确答案对比结果。要学会解释一次调整为什么提升了正确性，而不只是为什么让提示词变短了。

上下文工程和提示词工程有什么区别？

提示词工程关注提供给模型的指令和示例。上下文工程还涵盖证据筛选、工具提供，以及在工作推进过程中保留合适的状态。

上下文工程有哪些最佳实践？

为完整请求做好预算，预留输出空间，保留相关证据，并在摘要中留下来源位置。删减内容或压缩上下文之后，要检查回答是否仍然正确。

做上下文工程时，智能体最需要哪些技能？

让智能体能够有针对性地查找来源、查看相关段落和保存任务状态。判断这些工具是否有效，要看它们的结果能否帮助下一步决策，同时避免把大量无关材料塞进请求。

下周一就做一次请求瘦身

找出一次失败或漏掉重要细节的请求。统计完整输入，为预期输出预留空间，再找出占用空间最多、却无助于回答问题的那块内容。用筛选后的证据或任务接续记录替换它，然后重做任务，与已知正确答案核对。只有在证据和结果都得到保留时，才采用这个更小的请求。

想了解更多构建可靠 AI 工作流的实用指南，欢迎订阅通讯。