上下文視窗

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

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

理解上下文視窗

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

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

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

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

延伸思考的上下文視窗

使用延伸思考時，所有輸入和輸出 token，包括用於思考的 token，都計入上下文視窗限制，在多輪次情況下有一些細微差異。

思考預算 token 是 max_tokens 參數的子集，按輸出 token 計費，並計入速率限制。使用自適應思考時，Claude 會動態決定其思考分配，因此實際思考 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 管理：

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

1M token 上下文視窗

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

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

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: context-1m-2025-08-07" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Process this large document..."}
    ]
  }'

重要注意事項：

• Beta 狀態： 這是一個可能會變更的 beta 功能。功能和定價可能會在未來版本中修改或移除。
• 使用層級要求： 1M token 上下文視窗適用於使用層級 4 的組織和具有自訂速率限制的組織。較低層級的組織必須升級到使用層級 4 才能存取此功能。
• 可用性： 1M token 上下文視窗目前可在 Claude API、Microsoft Foundry、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）或 1M token（beta，適用於符合資格的組織）。

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

<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>

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

優勢：

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

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

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

使用壓縮管理上下文

如果您的對話經常接近上下文視窗限制，伺服器端壓縮是推薦的方法。壓縮提供伺服器端摘要功能，自動濃縮對話的早期部分，使長時間運行的對話能夠超越上下文限制，且整合工作量最小。目前以 beta 形式提供給 Claude Opus 4.6。

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

• 工具結果清除 - 在代理工作流程中清除舊的工具結果
• 思考區塊清除 - 使用延伸思考管理思考區塊

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

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

使用 token 計數 API 在向 Claude 發送訊息之前估算 token 使用量。這有助於您規劃並保持在上下文視窗限制內。

請參閱模型比較表格，了解各模型的上下文視窗大小列表。

後續步驟