上下文視窗

建構上下文管理

上下文窗口

了解上下文窗口如何運作，以及管理長對話和代理工作流程的策略。

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 輪次的地方。
- 由於在工具使用週期之外有新的輪次，Claude 生成新的擴展思考塊並從那裡繼續。

工具使用與擴展思考的考慮事項：
- 發佈工具結果時，必須包含伴隨該特定工具請求的整個未修改的思考塊（包括簽名部分）。
- 工具使用擴展思考的有效上下文窗口計算變為：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 會在您將其作為對話歷史的一部分傳回時自動執行此操作。
技術實現細節：
- 當您將思考塊作為對話歷史的一部分傳回時，API 會自動排除先前輪次的思考塊。
- 擴展思考令牌僅在生成期間作為輸出令牌計費一次。
- 有效上下文窗口計算變為：context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens。
- 思考令牌包括 thinking 塊。

此架構在令牌效率上很高，允許進行廣泛的推理而不浪費令牌，因為思考塊的長度可能很大。

您可以在擴展思考指南中閱讀有關上下文窗口和擴展思考的更多信息。

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

下圖說明了結合擴展思考和工具使用時的上下文窗口令牌管理：

具有擴展思考和工具使用的上下文窗口圖表

第一輪架構
- 輸入組件： 工具配置和用戶消息
- 輸出組件： 擴展思考 + 文本回應 + 工具使用請求
- 令牌計算： 所有輸入和輸出組件都計入上下文窗口，所有輸出組件都作為輸出令牌計費。
工具結果處理（第 2 輪）
- 輸入組件： 第一輪中的每個塊以及 tool_result。擴展思考塊必須與相應的工具結果一起返回。這是您必須返回思考塊的唯一情況。
- 輸出組件： 工具結果傳回給 Claude 後，Claude 將僅以文本回應（在下一個 user 消息之前沒有額外的擴展思考）。
- 令牌計算： 所有輸入和輸出組件都計入上下文窗口，所有輸出組件都作為輸出令牌計費。
第三步
- 輸入組件： 所有輸入和前一輪的輸出都被轉發，除了思考塊，現在 Claude 已完成整個工具使用週期，可以丟棄該塊。如果您傳回思考塊，API 將自動為您剝離它，或者您可以在此階段自由地自己剝離它。這也是您添加下一個 User 輪次的地方。
- 由於在工具使用週期之外有新的輪次，Claude 生成新的擴展思考塊並從那裡繼續。

工具使用與擴展思考的考慮事項：
- 發佈工具結果時，必須包含伴隨該特定工具請求的整個未修改的思考塊（包括簽名部分）。
- 工具使用擴展思考的有效上下文窗口計算變為：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?

User