使用 Claude 構建

上下文視窗

了解 Claude 的上下文視窗如何運作，包括擴展思考、工具使用和 100 萬 token 上下文視窗功能。

理解上下文視窗

「上下文視窗」是指語言模型在生成新文本時可以回顧和參考的文本總量，加上它生成的新文本。這與語言模型訓練時使用的大型數據語料庫不同，而是代表模型的「工作記憶」。較大的上下文視窗允許模型理解和回應更複雜和冗長的提示，而較小的上下文視窗可能會限制模型處理較長提示或在延長對話中保持連貫性的能力。

下圖說明了 API 請求的標準上下文視窗行為¹：

上下文視窗圖表

¹對於聊天介面，例如 claude.ai，上下文視窗也可以設置為滾動的「先進先出」系統。

漸進式 token 累積： 隨著對話在回合中推進，每個用戶訊息和助手回應都會在上下文視窗中累積。先前的回合會完全保留。
線性增長模式： 上下文使用量隨著每個回合線性增長，先前的回合完全保留。
200K token 容量： 總可用上下文視窗（200,000 個 token）代表儲存對話歷史和從 Claude 生成新輸出的最大容量。
輸入-輸出流程： 每個回合包含：
- 輸入階段： 包含所有先前的對話歷史加上當前用戶訊息
- 輸出階段： 生成成為未來輸入一部分的文本回應

擴展思考的上下文視窗

當使用擴展思考時，所有輸入和輸出 token，包括用於思考的 token，都會計入上下文視窗限制，在多回合情況下有一些細微差別。

思考預算 token 是您 max_tokens 參數的子集，按輸出 token 計費，並計入速率限制。

然而，先前的思考區塊會自動從 Claude API 的上下文視窗計算中剝離，不是模型在後續回合中「看到」的對話歷史的一部分，為實際對話內容保留 token 容量。

下圖展示了啟用擴展思考時的專門 token 管理：

擴展思考的上下文視窗圖表

剝離擴展思考： 擴展思考區塊（以深灰色顯示）在每個回合的輸出階段生成，但不會作為輸入 token 傳遞到後續回合。您不需要自己剝離思考區塊。如果您將它們傳回，Claude API 會自動為您執行此操作。
技術實現細節：
- 當您將思考區塊作為對話歷史的一部分傳回時，API 會自動排除先前回合的思考區塊。
- 擴展思考 token 僅在生成時按輸出 token 計費一次。
- 有效的上下文視窗計算變為：context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens。
- 思考 token 包括 thinking 區塊和 redacted_thinking 區塊。

這種架構具有 token 效率，允許廣泛推理而不浪費 token，因為思考區塊可能相當長。

您可以在我們的擴展思考指南中閱讀更多關於上下文視窗和擴展思考的內容。

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

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

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

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

擴展思考工具使用的考慮事項：
- 發布工具結果時，必須包含伴隨該特定工具請求的完整未修改思考區塊（包括簽名/編輯部分）。
- 擴展思考與工具使用的有效上下文視窗計算變為：context_window = input_tokens + current_turn_tokens。
- 系統使用加密簽名來驗證思考區塊的真實性。在工具使用期間未能保留思考區塊可能會破壞 Claude 的推理連續性。因此，如果您修改思考區塊，API 將返回錯誤。

Claude 4 模型支援交錯思考，這使 Claude 能夠在工具調用之間思考，並在接收工具結果後進行更複雜的推理。

Claude Sonnet 3.7 不支援交錯思考，因此在沒有非 tool_result 用戶回合的情況下，擴展思考和工具調用之間沒有交錯。

有關將工具與擴展思考一起使用的更多資訊，請參閱我們的擴展思考指南。

100 萬 token 上下文視窗

Claude Sonnet 4 和 4.5 支援 100 萬 token 上下文視窗。這個擴展的上下文視窗允許您處理更大的文檔、維持更長的對話，並處理更廣泛的程式碼庫。

100 萬 token 上下文視窗目前對使用層級 4 的組織和具有自定義速率限制的組織處於測試階段。100 萬 token 上下文視窗僅適用於 Claude Sonnet 4 和 Sonnet 4.5。

要使用 100 萬 token 上下文視窗，請在您的 API 請求中包含 context-1m-2025-08-07 測試標頭：

from anthropic import Anthropic

client = Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "處理這個大型文檔..."}
    ],
    betas=["context-1m-2025-08-07"]
)

重要考慮事項：

測試狀態：這是一個可能會變更的測試功能。功能和定價可能在未來版本中修改或移除。
使用層級要求：100 萬 token 上下文視窗適用於使用層級 4 的組織和具有自定義速率限制的組織。較低層級的組織必須升級到使用層級 4 才能存取此功能。
可用性：100 萬 token 上下文視窗目前在 Claude API、Amazon Bedrock 和 Google Cloud 的 Vertex AI 上可用。
定價：超過 200K token 的請求會自動按高級費率收費（2 倍輸入，1.5 倍輸出定價）。詳情請參閱定價文檔。
速率限制：長上下文請求有專門的速率限制。詳情請參閱速率限制文檔。
多模態考慮事項：處理大量圖像或 PDF 時，請注意文件的 token 使用量可能會有所不同。當將大型提示與大量圖像配對時，您可能會遇到請求大小限制。

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

Claude Sonnet 4.5 和 Claude Haiku 4.5 具有上下文感知功能，使這些模型能夠在對話過程中追蹤其剩餘的上下文視窗（即「token 預算」）。這使 Claude 能夠通過了解它有多少工作空間來更有效地執行任務和管理上下文。Claude 經過原生訓練，能夠精確使用此上下文持續執行任務直到最後，而不必猜測剩餘多少 token。對於模型來說，缺乏上下文感知就像在沒有時鐘的烹飪節目中競爭。Claude 4.5 模型通過明確告知模型其剩餘上下文來改變這一點，因此它可以最大限度地利用可用的 token。

運作方式：

在對話開始時，Claude 會收到關於其總上下文視窗的資訊：

<budget:token_budget>200000</budget:token_budget>

預算設置為 200K token（標準）、500K token（Claude.ai Enterprise）或 100 萬 token（測試版，適用於符合條件的組織）。

每次工具調用後，Claude 會收到剩餘容量的更新：

<system_warning>Token 使用量：35000/200000；剩餘 165000</system_warning>

這種感知幫助 Claude 確定還有多少容量可用於工作，並能夠更有效地執行長期運行的任務。圖像 token 包含在這些預算中。

好處：

上下文感知對以下情況特別有價值：

需要持續專注的長期運行代理會話
狀態轉換很重要的多上下文視窗工作流程
需要仔細 token 管理的複雜任務

有關利用上下文感知的提示指導，請參閱我們的 Claude 4 最佳實踐指南。

較新 Claude 模型的上下文視窗管理

在較新的 Claude 模型中（從 Claude Sonnet 3.7 開始），如果提示 token 和輸出 token 的總和超過模型的上下文視窗，系統將返回驗證錯誤，而不是靜默截斷上下文。這種變化提供了更可預測的行為，但需要更仔細的 token 管理。

要規劃您的 token 使用並確保您保持在上下文視窗限制內，您可以使用 token 計數 API 在將訊息發送給 Claude 之前估計您的訊息將使用多少 token。

請參閱我們的模型比較表格，了解按模型列出的上下文視窗大小清單。

下一步

模型比較表格

查看我們的模型比較表格，了解按模型列出的上下文視窗大小和輸入/輸出 token 定價清單。

擴展思考概述

了解更多關於擴展思考如何運作以及如何與其他功能（如工具使用和提示快取）一起實現它。

使用 Claude 構建

上下文視窗

了解 Claude 的上下文視窗如何運作，包括擴展思考、工具使用和 100 萬 token 上下文視窗功能。

理解上下文視窗

下圖說明了 API 請求的標準上下文視窗行為¹：

上下文視窗圖表

¹對於聊天介面，例如 claude.ai，上下文視窗也可以設置為滾動的「先進先出」系統。

漸進式 token 累積： 隨著對話在回合中推進，每個用戶訊息和助手回應都會在上下文視窗中累積。先前的回合會完全保留。
線性增長模式： 上下文使用量隨著每個回合線性增長，先前的回合完全保留。
200K token 容量： 總可用上下文視窗（200,000 個 token）代表儲存對話歷史和從 Claude 生成新輸出的最大容量。
輸入-輸出流程： 每個回合包含：
- 輸入階段： 包含所有先前的對話歷史加上當前用戶訊息
- 輸出階段： 生成成為未來輸入一部分的文本回應

擴展思考的上下文視窗

當使用擴展思考時，所有輸入和輸出 token，包括用於思考的 token，都會計入上下文視窗限制，在多回合情況下有一些細微差別。

思考預算 token 是您 max_tokens 參數的子集，按輸出 token 計費，並計入速率限制。

下圖展示了啟用擴展思考時的專門 token 管理：

擴展思考的上下文視窗圖表

剝離擴展思考： 擴展思考區塊（以深灰色顯示）在每個回合的輸出階段生成，但不會作為輸入 token 傳遞到後續回合。您不需要自己剝離思考區塊。如果您將它們傳回，Claude API 會自動為您執行此操作。
技術實現細節：
- 當您將思考區塊作為對話歷史的一部分傳回時，API 會自動排除先前回合的思考區塊。
- 擴展思考 token 僅在生成時按輸出 token 計費一次。
- 有效的上下文視窗計算變為：context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens。
- 思考 token 包括 thinking 區塊和 redacted_thinking 區塊。

這種架構具有 token 效率，允許廣泛推理而不浪費 token，因為思考區塊可能相當長。

您可以在我們的擴展思考指南中閱讀更多關於上下文視窗和擴展思考的內容。

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

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

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

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

擴展思考工具使用的考慮事項：
- 發布工具結果時，必須包含伴隨該特定工具請求的完整未修改思考區塊（包括簽名/編輯部分）。
- 擴展思考與工具使用的有效上下文視窗計算變為：context_window = input_tokens + current_turn_tokens。
- 系統使用加密簽名來驗證思考區塊的真實性。在工具使用期間未能保留思考區塊可能會破壞 Claude 的推理連續性。因此，如果您修改思考區塊，API 將返回錯誤。

Claude 4 模型支援交錯思考，這使 Claude 能夠在工具調用之間思考，並在接收工具結果後進行更複雜的推理。

Claude Sonnet 3.7 不支援交錯思考，因此在沒有非 tool_result 用戶回合的情況下，擴展思考和工具調用之間沒有交錯。

有關將工具與擴展思考一起使用的更多資訊，請參閱我們的擴展思考指南。

100 萬 token 上下文視窗

Claude Sonnet 4 和 4.5 支援 100 萬 token 上下文視窗。這個擴展的上下文視窗允許您處理更大的文檔、維持更長的對話，並處理更廣泛的程式碼庫。

100 萬 token 上下文視窗目前對使用層級 4 的組織和具有自定義速率限制的組織處於測試階段。100 萬 token 上下文視窗僅適用於 Claude Sonnet 4 和 Sonnet 4.5。

要使用 100 萬 token 上下文視窗，請在您的 API 請求中包含 context-1m-2025-08-07 測試標頭：

from anthropic import Anthropic

client = Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "處理這個大型文檔..."}
    ],
    betas=["context-1m-2025-08-07"]
)

重要考慮事項：

測試狀態：這是一個可能會變更的測試功能。功能和定價可能在未來版本中修改或移除。
使用層級要求：100 萬 token 上下文視窗適用於使用層級 4 的組織和具有自定義速率限制的組織。較低層級的組織必須升級到使用層級 4 才能存取此功能。
可用性：100 萬 token 上下文視窗目前在 Claude API、Amazon Bedrock 和 Google Cloud 的 Vertex AI 上可用。
定價：超過 200K token 的請求會自動按高級費率收費（2 倍輸入，1.5 倍輸出定價）。詳情請參閱定價文檔。
速率限制：長上下文請求有專門的速率限制。詳情請參閱速率限制文檔。
多模態考慮事項：處理大量圖像或 PDF 時，請注意文件的 token 使用量可能會有所不同。當將大型提示與大量圖像配對時，您可能會遇到請求大小限制。

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

運作方式：

在對話開始時，Claude 會收到關於其總上下文視窗的資訊：

<budget:token_budget>200000</budget:token_budget>

預算設置為 200K token（標準）、500K token（Claude.ai Enterprise）或 100 萬 token（測試版，適用於符合條件的組織）。

每次工具調用後，Claude 會收到剩餘容量的更新：

<system_warning>Token 使用量：35000/200000；剩餘 165000</system_warning>

這種感知幫助 Claude 確定還有多少容量可用於工作，並能夠更有效地執行長期運行的任務。圖像 token 包含在這些預算中。

好處：

上下文感知對以下情況特別有價值：

需要持續專注的長期運行代理會話
狀態轉換很重要的多上下文視窗工作流程
需要仔細 token 管理的複雜任務

有關利用上下文感知的提示指導，請參閱我們的 Claude 4 最佳實踐指南。

較新 Claude 模型的上下文視窗管理

要規劃您的 token 使用並確保您保持在上下文視窗限制內，您可以使用 token 計數 API 在將訊息發送給 Claude 之前估計您的訊息將使用多少 token。

請參閱我們的模型比較表格，了解按模型列出的上下文視窗大小清單。

下一步

模型比較表格

查看我們的模型比較表格，了解按模型列出的上下文視窗大小和輸入/輸出 token 定價清單。

擴展思考概述

了解更多關於擴展思考如何運作以及如何與其他功能（如工具使用和提示快取）一起實現它。