上下文視窗

隨著對話持續進行，您最終會接近上下文視窗的限制。本指南說明上下文視窗的運作方式，並介紹有效管理上下文視窗的策略。

對於長時間執行的對話和代理工作流程，伺服器端壓縮是上下文管理的主要策略。對於更專門的需求，上下文編輯提供了額外的策略，例如清除工具結果和清除思考區塊。



理解上下文視窗

「Context window」（上下文視窗）是指語言模型在生成回應時可以參考的所有文本，包括回應本身。這與語言模型訓練所用的大型語料庫不同，而是代表模型的「工作記憶」。較大的上下文視窗允許模型處理更複雜和冗長的提示，但更多的上下文並不自動代表更好。隨著 token 數量增加，準確性和召回率會下降，這種現象稱為「context rot」（上下文腐化）。這使得精心管理上下文中的內容與可用空間的大小同樣重要。

Claude 在長上下文檢索基準測試（如 MRCR 和 GraphWalks）上取得了最先進的成果，但這些成果取決於上下文中的內容，而不僅僅是能容納多少內容。

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

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

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



搭配擴展思考的上下文視窗

使用擴展思考時，所有輸入和輸出 tokens（包括用於思考的 tokens）都會計入上下文視窗限制，但在多輪情況下有一些細微差異。

思考預算 tokens 是您 max_tokens 參數的子集，會以輸出 tokens 計費，並計入速率限制。使用自適應思考時，Claude 會動態決定其思考分配，因此實際的思考 token 使用量可能因請求而異。

然而，先前的思考區塊會由 Claude API 自動從上下文視窗計算中移除，並且不屬於模型在後續輪次中「看到」的對話歷史的一部分，從而為實際對話內容保留 token 容量。

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

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

這種架構具有 token 效率，並允許進行大量推理而不浪費 token，因為思考區塊的長度可能相當可觀。



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

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

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

Claude 的工具選擇設計為在處理大型輸入文件時仍能保持穩定，當對話包含 100K+ tokens 的非工具上下文時，能夠選擇正確的工具（或正確地不使用工具）。若要減少工具本身消耗的上下文，請參閱管理工具上下文，或使用工具搜尋工具延遲工具定義。

Claude Opus 4.8、Claude Mythos Preview、Claude Opus 4.7、Claude Opus 4.6 和 Claude Sonnet 4.6 在 Claude API、Amazon Bedrock 和 Vertex AI 上具有 1M-token 的上下文視窗。在 Microsoft Foundry 上，Claude Opus 4.8 具有 200k-token 的上下文視窗。其他 Claude 模型（包括 Claude Sonnet 4.5）具有 200k-token 的上下文視窗。

Claude Fable 5 和 Claude Mythos 5（claude-fable-5 和 claude-mythos-5）在 Claude API 上具有 1M-token 的上下文視窗。1M 的最大值也是預設值，單一請求最多可生成 128k 輸出 tokens（max_tokens）。

單一請求最多可包含 600 張圖片或 PDF 頁面（對於具有 200k-token 上下文視窗的模型則為 100 張）。當傳送大量圖片或大型文件時，您可能會在達到 token 限制之前先接近請求大小限制。



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

Claude Sonnet 4.6、Claude Sonnet 4.5 和 Claude Haiku 4.5 具備上下文感知功能。此功能讓這些模型能夠在整個對話過程中追蹤其剩餘的上下文視窗（即「token 預算」）。這使 Claude 能夠透過了解其可用的工作空間，更有效地執行任務和管理上下文。Claude 經過訓練能夠精確使用此上下文，持續執行任務直到最後，而不是猜測剩餘多少 tokens。對於模型而言，缺乏上下文感知就像在沒有時鐘的情況下參加烹飪比賽。具備上下文感知的模型改變了這一點，因為它們會明確接收有關剩餘上下文的資訊，從而能夠最大限度地利用可用的 tokens。

運作方式：

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

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

預算設定為 1M tokens（對於具有較小上下文視窗的模型則為 200k）。

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

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

這種感知能力幫助 Claude 判斷剩餘多少容量可用於工作，並使其能夠更有效地執行長時間運行的任務。圖片 tokens 包含在這些預算中。

優點：

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

• 需要持續專注的長時間運行代理工作階段
• 狀態轉換很重要的多上下文視窗工作流程
• 需要謹慎管理 token 的複雜任務

有關利用上下文感知的提示指南，請參閱提示最佳實務指南。



使用壓縮管理上下文

如果您的對話經常接近上下文視窗限制，伺服器端壓縮是建議的方法。壓縮提供伺服器端摘要功能，可自動濃縮對話的較早部分，以最少的整合工作實現超越上下文限制的長時間對話。此功能在 Claude Fable 5、Claude Mythos 5、Claude Opus 4.8、Claude Mythos Preview、Claude Opus 4.7、Claude Opus 4.6 和 Claude Sonnet 4.6 中以測試版提供。

對於更專門的需求，上下文編輯提供了額外的策略：

• 清除工具結果 - 在代理工作流程中清除舊的工具結果
• 清除思考區塊 - 搭配擴展思考管理思考區塊



上下文視窗溢位行為

在 Claude 4.5 及更新的模型上，如果輸入 tokens 加上 max_tokens 超過上下文視窗大小，API 會接受該請求。如果生成過程隨後達到上下文視窗限制，則會以 stop_reason: "model_context_window_exceeded" 停止。在較早的模型上，API 會改為傳回驗證錯誤；您可以使用 model-context-window-exceeded-2025-08-26 測試版標頭選擇啟用 model_context_window_exceeded 行為。詳情請參閱處理停止原因。

若要保持在上下文視窗限制內，請使用 token 計數 API 在向 Claude 傳送訊息之前估算 token 使用量。

請參閱模型比較表格，以取得各模型的上下文視窗大小清單。



後續步驟