在使用大语言模型（LLM）进行问答、推理或多轮对话任务时，我们常常遇到“上下文窗口”这个概念。它决定了模型一次性可以“处理”和“记住”的 token 总量，是理解模型能力边界和优化提示工程的基础。
本文将通过三张图，分别剖析claude 三类典型上下文场景：标准对话模式、扩展思考模式、扩展思考 + 工具调用模式，帮助读者全面理解上下文窗口的结构、演变和使用策略。
标准上下文窗口 ——多轮会话 线性累积
在最基本的对话场景中，模型的上下文窗口以线性方式增长。每轮用户输入与模型输出都会完整地加入到上下文中，并在后续被再次“读取”，用于生成新的响应。
特点包括：
上下文窗口是一个固定容量的滑动窗口（如 200K token）。
内容以“先进先出”方式更新，超出容量的最早内容将被截断。
每一轮输入输出都会被完整记录，使对话保持连贯性。
适用场景：标准多轮对话助手、问答任务等。
限制点：在长对话或内容密集型任务中容易触及 token 上限，导致上下文截断，影响模型表现。
启用扩展思考 —— 推理能力增强，token 使用量提升
在某些高级模型架构中，引入了“扩展思考（Extended Thinking）”机制，允许模型在生成最终输出前先进行一次内部推理或规划（即“思考块”）。
技术上，该机制在每轮对话的输出阶段，会额外生成一段思考文本块（thinking block），用于模型内部结构化思考。在Claude的设计中这段内容虽然计入输出 token，但不会在后续对话中继续保留在上下文中。
关键特性：
思考块仅计费一次，在下一轮中自动从上下文中剔除，释放上下文空间。
提高模型复杂推理时的 token 利用率。
上下文计算公式被优化为：
context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens
适用场景：涉及复杂逻辑链、规划、多轮分析任务等。
技术注意：使用该机制时，无需手动管理思考块的移除，一般模型API 自动处理。
扩展思考 + 工具调用 —— 多阶段推理与信息获取协同
第三种更复杂的场景结合了“扩展思考”与“外部工具调用”。该模式常用于模型需要借助外部工具调用获取信息后，再进行推理生成的任务中。
处理流程如下：
第一轮：用户输入 → 模型生成扩展思考 + 工具调用请求。
第二轮：将上一轮工具结果和原始思考块一并带入，模型基于工具结果输出最终响应。
第三轮起：清除前一次的思考块，继续下一个对话或任务回合。
上下文处理规则：
工具调用阶段必须保留对应的思考块，以保持推理一致性。
API 使用签名机制验证思考块的完整性；若修改，将导致响应错误。
思考块完成任务后即可自动剔除，恢复常规上下文结构。
适用场景：外部知识调用、代码执行等工具调用的 LLM 应用。
实际价值：该机制实现了深度推理与外部操作的无缝协作，同时保持上下文高效利用。
总结
“上下文窗口”不仅仅是模型可见的输入历史，更是一种资源调度机制，决定了模型能处理的内容广度和深度。理解并善用它，是构建高质量 LLM 应用的关键。
在实际使用中，合理配置上下文管理策略，不仅可以提高模型响应质量，也能显著降低 token 成本与出错概率。如果正在构建自己的 RAG 系统、多轮对话 agent 或 AI Copilot，不妨从上下文管理策略开始优化，提升模型的“记忆力”与“推理力”。
本文参考Claude官方上下文窗口说明
