上下文窗口

构建上下文管理

上下文窗口

了解上下文窗口如何工作，以及管理长对话和代理工作流的策略

This feature is eligible for Zero Data Retention (ZDR). When your organization has a ZDR arrangement, data sent through this feature is not stored after the API response is returned.

随着对话的增长，你最终会接近上下文窗口限制。本指南解释了上下文窗口的工作原理，并介绍了有效管理它们的策略。

对于长时间运行的对话和代理工作流，服务器端压缩是上下文管理的主要策略。对于更专业的需求，上下文编辑提供了额外的策略，如工具结果清除和思考块清除。

理解上下文窗口

"上下文窗口"是指语言模型在生成响应时可以引用的所有文本，包括响应本身。这与语言模型训练所用的大量数据语料库不同，而是代表模型的"工作记忆"。更大的上下文窗口允许模型处理更复杂和更长的提示，但更多的上下文并不一定更好。随着令牌数量的增加，准确性和召回率会下降，这种现象被称为上下文衰退。这使得策划上下文中的内容与可用空间的大小同样重要。

Claude 在长上下文检索基准测试（如 MRCR 和 GraphWalks）上取得了最先进的成果，但这些成果取决于上下文中的内容，而不仅仅是适合多少。

有关为什么长上下文会衰退以及如何围绕它进行工程设计的深入探讨，请参阅有效的上下文工程。

下图说明了 API 请求的标准上下文窗口行为¹：

上下文窗口图

¹对于聊天界面，例如 claude.ai，上下文窗口也可以设置为滚动的"先进先出"系统。

渐进式令牌累积： 随着对话通过轮次推进，每条用户消息和助手响应都在上下文窗口内累积。之前的轮次完全保留。
线性增长模式： 上下文使用随着每一轮线性增长，之前的轮次完全保留。
上下文窗口容量： 总可用上下文窗口（最多 1M 令牌）代表存储对话历史和从 Claude 生成新输出的最大容量。
输入输出流： 每一轮包括：
- 输入阶段： 包含所有之前的对话历史加上当前用户消息
- 输出阶段： 生成成为未来输入一部分的文本响应

具有扩展思考的上下文窗口

使用扩展思考时，所有输入和输出令牌，包括用于思考的令牌，都计入上下文窗口限制，在多轮情况下有一些细微差别。

思考预算令牌是你的 max_tokens 参数的子集，作为输出令牌计费，并计入速率限制。使用自适应思考，Claude 动态决定其思考分配，因此实际思考令牌使用可能因请求而异。

但是，之前的思考块由 Claude API 自动从上下文窗口计算中剥离，不是模型在后续轮次"看到"的对话历史的一部分，为实际对话内容保留令牌容量。

下图演示了启用扩展思考时的专门令牌管理：

具有扩展思考的上下文窗口图

剥离扩展思考： 扩展思考块（以深灰色显示）在每一轮的输出阶段生成，但不会作为后续轮次的输入令牌向前传递。你不需要自己剥离思考块。Claude API 会自动为你执行此操作，如果你将它们传回。
技术实现细节：
- 当你将思考块作为对话历史的一部分传回时，API 会自动排除之前轮次的思考块。
- 扩展思考令牌仅在生成期间作为输出令牌计费一次。
- 有效上下文窗口计算变为：context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens。
- 思考令牌包括 thinking 块。

这种架构在令牌方面是高效的，允许进行广泛的推理而不浪费令牌，因为思考块的长度可能很大。

你可以在扩展思考指南中阅读更多关于上下文窗口和扩展思考的内容。

具有扩展思考和工具使用的上下文窗口

下图说明了结合扩展思考和工具使用时的上下文窗口令牌管理：

具有扩展思考和工具使用的上下文窗口图

第一轮架构
- 输入组件： 工具配置和用户消息
- 输出组件： 扩展思考 + 文本响应 + 工具使用请求
- 令牌计算： 所有输入和输出组件都计入上下文窗口，所有输出组件都作为输出令牌计费。
工具结果处理（第 2 轮）
- 输入组件： 第一轮中的每个块以及 tool_result。扩展思考块必须与相应的工具结果一起返回。这是你必须返回思考块的唯一情况。
- 输出组件： 工具结果传回 Claude 后，Claude 将仅以文本响应（在下一个 user 消息之前没有额外的扩展思考）。
- 令牌计算： 所有输入和输出组件都计入上下文窗口，所有输出组件都作为输出令牌计费。
第三步
- 输入组件： 所有输入和前一轮的输出都向前传递，除了思考块，现在可以删除它，因为 Claude 已完成整个工具使用周期。如果你传回思考块，API 将自动为你剥离它，或者你可以在此阶段自由地自己剥离它。这也是你添加下一个 User 轮次的地方。
- 输出组件： 由于在工具使用周期之外有新的 User 轮次，Claude 生成新的扩展思考块并从那里继续。
- 令牌计算： 之前的思考令牌自动从上下文窗口计算中剥离。所有其他之前的块仍然计为令牌窗口的一部分，当前 Assistant 轮次中的思考块计为上下文窗口的一部分。

工具使用与扩展思考的考虑事项：
- 发布工具结果时，必须包含伴随该特定工具请求的整个未修改的思考块（包括签名部分）。
- 扩展思考与工具使用的有效上下文窗口计算变为：context_window = input_tokens + current_turn_tokens。
- 系统使用密码签名来验证思考块的真实性。在工具使用期间未能保留思考块可能会破坏 Claude 的推理连续性。因此，如果你修改思考块，API 会返回错误。

Claude 4 模型支持交错思考，这使 Claude 能够在工具调用之间思考，并在接收工具结果后进行更复杂的推理。

Claude Sonnet 3.7 不支持交错思考，因此在没有非 tool_result 用户轮次的情况下，扩展思考和工具调用之间没有交错。

有关使用工具与扩展思考的更多信息，请参阅扩展思考指南。

Claude Mythos Preview、Claude Opus 4.7、Claude Opus 4.6 和 Claude Sonnet 4.6 具有 1M 令牌上下文窗口。其他 Claude 模型，包括 Claude Sonnet 4.5 和 Sonnet 4（已弃用），具有 200k 令牌上下文窗口。

单个请求最多可包含 600 张图像或 PDF 页面（对于具有 200k 令牌上下文窗口的模型为 100）。发送许多图像或大型文档时，你可能会在令牌限制之前接近请求大小限制。

Claude Sonnet 4.6、Sonnet 4.5 和 Haiku 4.5 中的上下文感知

Claude Sonnet 4.6、Claude Sonnet 4.5 和 Claude Haiku 4.5 具有上下文感知功能。这种能力让这些模型在整个对话中跟踪其剩余上下文窗口（即"令牌预算"）。这使 Claude 能够通过理解有多少空间可用来更有效地执行任务和管理上下文。Claude 经过训练可以精确使用此上下文，坚持任务直到最后，而不是猜测剩余多少令牌。对于模型来说，缺乏上下文感知就像在没有时钟的烹饪节目中竞争。Claude 4.5+ 模型通过明确告知模型其剩余上下文来改变这一点，以便它可以最大限度地利用可用令牌。

工作原理：

在对话开始时，Claude 会收到有关其总上下文窗口的信息：

<budget:token_budget>1000000</budget:token_budget>

预算设置为 1M 令牌（对于上下文窗口较小的模型为 200k）。

每次工具调用后，Claude 会收到剩余容量的更新：

<system_warning>Token usage: 35000/1000000; 965000 remaining</system_warning>

这种感知帮助 Claude 确定剩余多少容量用于工作，并在长时间运行的任务上实现更有效的执行。图像令牌包含在这些预算中。

优势：

上下文感知对以下方面特别有价值：

需要持续关注的长时间运行的代理会话
状态转换很重要的多上下文窗口工作流
需要仔细令牌管理的复杂任务

对于跨越多个会话的代理，设计你的状态工件，以便在新会话开始时上下文恢复很快。内存工具的多会话模式演示了一个具体的方法。另请参阅长时间运行代理的有效工具。

有关利用上下文感知的提示指导，请参阅提示最佳实践指南。

使用压缩管理上下文

如果你的对话经常接近上下文窗口限制，服务器端压缩是推荐的方法。压缩提供服务器端摘要，自动压缩对话的早期部分，使长时间运行的对话能够超越上下文限制，只需最少的集成工作。它目前在 Claude Opus 4.7、Claude Opus 4.6 和 Claude Sonnet 4.6 的测试版中可用。

对于更专业的需求，上下文编辑提供了额外的策略：

工具结果清除 - 在代理工作流中清除旧的工具结果
思考块清除 - 使用扩展思考管理思考块

使用较新 Claude 模型的上下文窗口管理

较新的 Claude 模型（从 Claude Sonnet 3.7 开始）在提示和输出令牌超过上下文窗口时返回验证错误，而不是静默截断。这种变化提供了更可预测的行为，但需要更仔细的令牌管理。

使用令牌计数 API在向 Claude 发送消息之前估计令牌使用情况。这有助于你规划并保持在上下文窗口限制内。

有关按模型的上下文窗口大小列表，请参阅模型比较表。

后续步骤

压缩

用于管理长时间运行对话中上下文的推荐策略。

上下文编辑

细粒度策略，如工具结果清除和思考块清除。

模型比较表

查看模型比较表，了解按模型的上下文窗口大小和输入/输出令牌定价列表。

扩展思考概览

了解更多关于扩展思考如何工作以及如何将其与工具使用和提示缓存等其他功能一起实现。

Was this page helpful?

构建上下文管理

上下文窗口

了解上下文窗口如何工作，以及管理长对话和代理工作流的策略

This feature is eligible for Zero Data Retention (ZDR). When your organization has a ZDR arrangement, data sent through this feature is not stored after the API response is returned.

随着对话的增长，你最终会接近上下文窗口限制。本指南解释了上下文窗口的工作原理，并介绍了有效管理它们的策略。

理解上下文窗口

Claude 在长上下文检索基准测试（如 MRCR 和 GraphWalks）上取得了最先进的成果，但这些成果取决于上下文中的内容，而不仅仅是适合多少。

有关为什么长上下文会衰退以及如何围绕它进行工程设计的深入探讨，请参阅有效的上下文工程。

下图说明了 API 请求的标准上下文窗口行为¹：

上下文窗口图

¹对于聊天界面，例如 claude.ai，上下文窗口也可以设置为滚动的"先进先出"系统。

渐进式令牌累积： 随着对话通过轮次推进，每条用户消息和助手响应都在上下文窗口内累积。之前的轮次完全保留。
线性增长模式： 上下文使用随着每一轮线性增长，之前的轮次完全保留。
上下文窗口容量： 总可用上下文窗口（最多 1M 令牌）代表存储对话历史和从 Claude 生成新输出的最大容量。
输入输出流： 每一轮包括：
- 输入阶段： 包含所有之前的对话历史加上当前用户消息
- 输出阶段： 生成成为未来输入一部分的文本响应

具有扩展思考的上下文窗口

使用扩展思考时，所有输入和输出令牌，包括用于思考的令牌，都计入上下文窗口限制，在多轮情况下有一些细微差别。

但是，之前的思考块由 Claude API 自动从上下文窗口计算中剥离，不是模型在后续轮次"看到"的对话历史的一部分，为实际对话内容保留令牌容量。

下图演示了启用扩展思考时的专门令牌管理：

具有扩展思考的上下文窗口图

剥离扩展思考： 扩展思考块（以深灰色显示）在每一轮的输出阶段生成，但不会作为后续轮次的输入令牌向前传递。你不需要自己剥离思考块。Claude API 会自动为你执行此操作，如果你将它们传回。
技术实现细节：
- 当你将思考块作为对话历史的一部分传回时，API 会自动排除之前轮次的思考块。
- 扩展思考令牌仅在生成期间作为输出令牌计费一次。
- 有效上下文窗口计算变为：context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens。
- 思考令牌包括 thinking 块。

这种架构在令牌方面是高效的，允许进行广泛的推理而不浪费令牌，因为思考块的长度可能很大。

你可以在扩展思考指南中阅读更多关于上下文窗口和扩展思考的内容。

具有扩展思考和工具使用的上下文窗口

下图说明了结合扩展思考和工具使用时的上下文窗口令牌管理：

具有扩展思考和工具使用的上下文窗口图

第一轮架构
- 输入组件： 工具配置和用户消息
- 输出组件： 扩展思考 + 文本响应 + 工具使用请求
- 令牌计算： 所有输入和输出组件都计入上下文窗口，所有输出组件都作为输出令牌计费。
工具结果处理（第 2 轮）
- 输入组件： 第一轮中的每个块以及 tool_result。扩展思考块必须与相应的工具结果一起返回。这是你必须返回思考块的唯一情况。
- 输出组件： 工具结果传回 Claude 后，Claude 将仅以文本响应（在下一个 user 消息之前没有额外的扩展思考）。
- 令牌计算： 所有输入和输出组件都计入上下文窗口，所有输出组件都作为输出令牌计费。
第三步
- 输入组件： 所有输入和前一轮的输出都向前传递，除了思考块，现在可以删除它，因为 Claude 已完成整个工具使用周期。如果你传回思考块，API 将自动为你剥离它，或者你可以在此阶段自由地自己剥离它。这也是你添加下一个 User 轮次的地方。
- 输出组件： 由于在工具使用周期之外有新的 User 轮次，Claude 生成新的扩展思考块并从那里继续。
- 令牌计算： 之前的思考令牌自动从上下文窗口计算中剥离。所有其他之前的块仍然计为令牌窗口的一部分，当前 Assistant 轮次中的思考块计为上下文窗口的一部分。

工具使用与扩展思考的考虑事项：
- 发布工具结果时，必须包含伴随该特定工具请求的整个未修改的思考块（包括签名部分）。
- 扩展思考与工具使用的有效上下文窗口计算变为：context_window = input_tokens + current_turn_tokens。
- 系统使用密码签名来验证思考块的真实性。在工具使用期间未能保留思考块可能会破坏 Claude 的推理连续性。因此，如果你修改思考块，API 会返回错误。

Claude 4 模型支持交错思考，这使 Claude 能够在工具调用之间思考，并在接收工具结果后进行更复杂的推理。

Claude Sonnet 3.7 不支持交错思考，因此在没有非 tool_result 用户轮次的情况下，扩展思考和工具调用之间没有交错。

有关使用工具与扩展思考的更多信息，请参阅扩展思考指南。

Claude Sonnet 4.6、Sonnet 4.5 和 Haiku 4.5 中的上下文感知

工作原理：

在对话开始时，Claude 会收到有关其总上下文窗口的信息：

<budget:token_budget>1000000</budget:token_budget>

预算设置为 1M 令牌（对于上下文窗口较小的模型为 200k）。

每次工具调用后，Claude 会收到剩余容量的更新：

<system_warning>Token usage: 35000/1000000; 965000 remaining</system_warning>

这种感知帮助 Claude 确定剩余多少容量用于工作，并在长时间运行的任务上实现更有效的执行。图像令牌包含在这些预算中。

优势：

上下文感知对以下方面特别有价值：

需要持续关注的长时间运行的代理会话
状态转换很重要的多上下文窗口工作流
需要仔细令牌管理的复杂任务

有关利用上下文感知的提示指导，请参阅提示最佳实践指南。

使用压缩管理上下文

对于更专业的需求，上下文编辑提供了额外的策略：

工具结果清除 - 在代理工作流中清除旧的工具结果
思考块清除 - 使用扩展思考管理思考块

使用较新 Claude 模型的上下文窗口管理

使用令牌计数 API在向 Claude 发送消息之前估计令牌使用情况。这有助于你规划并保持在上下文窗口限制内。

有关按模型的上下文窗口大小列表，请参阅模型比较表。

后续步骤

压缩

用于管理长时间运行对话中上下文的推荐策略。

上下文编辑

细粒度策略，如工具结果清除和思考块清除。

模型比较表

查看模型比较表，了解按模型的上下文窗口大小和输入/输出令牌定价列表。

扩展思考概览

了解更多关于扩展思考如何工作以及如何将其与工具使用和提示缓存等其他功能一起实现。

Was this page helpful?