Messages上下文管理

上下文視窗

了解上下文視窗的運作方式、擴展思考與工具使用如何計入其中，以及隨著對話增長如何管理上下文。

隨著對話增長，您最終會接近上下文視窗的限制。對於長時間執行的對話與代理式工作流程，伺服器端壓縮是上下文管理的主要策略。

上下文視窗的運作方式

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

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

對話輪次在 context window（上下文視窗）中逐步累積，直到對話接近 token 上限的示意圖

¹ 諸如 claude.ai 等聊天介面也可以採用滾動式的「先進先出」方式管理上下文視窗。

漸進式 token 累積： 隨著對話逐輪推進，每則使用者訊息與助理回應都會在上下文視窗中累積，且先前的輪次會被完整保留。
上下文視窗容量： 上下文視窗（最多 1M tokens，視模型而定）容納對話歷史以及 Claude 生成的新輸出。
輸入輸出流程： 每一輪包含：
- 輸入階段： 包含所有先前的對話歷史加上目前的使用者訊息
- 輸出階段： 生成文本回應，該回應會成為下一輪輸入的一部分

請求中的所有內容都會計入上下文視窗：「system prompt」（系統提示）、messages 中的每則訊息（包括工具結果、圖片與文件），以及您的工具定義。Claude 在該輪生成的輸出（包括其擴展思考）也會計入。每個回應都會在其 usage 欄位中回報該請求所消耗的量。如果您使用「prompt caching」（提示快取），輸入計數會拆分為 input_tokens、cache_read_input_tokens 與 cache_creation_input_tokens，三者皆計入視窗；詳情請參閱提示快取。若要在送出請求前進行估算，請使用 token 計數 API。

各模型的上下文視窗大小

Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Opus 5.5、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 5.5、Claude Sonnet 5、Claude Sonnet 4.6 和 Claude Mythos Preview 具有 1M token 的上下文視窗。對其中任何一個模型發出的單一請求，最多可生成 128k 個輸出 token（max_tokens）。其他 Claude 模型，包括 Claude Sonnet 4.5，具有 200k token 的上下文視窗。

對於每個擁有 1M-token 上下文視窗的模型，1M 即為預設值：您不需要 beta 標頭，且長上下文請求依標準定價計費。

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

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

搭配思考的上下文視窗

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

思考 tokens 是您 max_tokens 參數的子集，以輸出 tokens 計費，並計入「rate limit」（速率限制）。使用自適應思考時，Claude 會動態決定其思考配額，因此思考 token 的用量會因請求而異。

先前助理輪次的思考區塊是否保留在上下文視窗中，取決於模型。在 Claude Opus 4.5 及更新的 Opus 模型、Claude Sonnet 4.6 及更新的 Sonnet 模型、Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5 以及 Claude Mythos Preview 上，API 預設會保留先前的思考區塊，且它們與其他輸入 tokens 一樣計入上下文視窗。在較早的 Opus 與 Sonnet 模型以及所有 Haiku 模型上，當您將先前的思考區塊傳回時，API 會自動將其從對話歷史中移除，從而為對話內容保留 token 容量。各模型的預設值請參閱各模型的思考區塊保留。若要朝任一方向覆寫預設值，請使用思考區塊清除。

下圖顯示在會移除先前思考區塊的模型上啟用思考時，tokens 的管理方式：

在會移除先前 thinking blocks（思考區塊）的模型上進行思考的示意圖：每一輪的思考區塊在輸出中生成，且不會帶入後續輪次的輸入

移除思考區塊： 在會移除先前思考區塊的模型上，思考區塊（以深灰色顯示）會在每一輪的輸出階段生成，但不會作為輸入 tokens 帶入後續輪次。您不需要自行移除思考區塊：如果您將它們傳回，Claude API 會自動移除。
計費： 思考 tokens 在生成時以輸出 tokens 計費一次。在會保留先前思考區塊的模型上，被保留的區塊隨後會成為後續請求輸入的一部分，並與其餘對話歷史一樣以輸入 tokens 計費。

搭配思考與工具使用的上下文視窗

下圖說明在會移除先前思考區塊的模型上，將思考與「tool use」（工具使用）結合時，tokens 的管理方式：

思考搭配 tool use（工具使用）的示意圖：思考區塊與其工具結果一同保留，然後在會移除先前思考區塊的模型上，於下一個使用者輪次被捨棄

1
第一輪架構
- 輸入組成： 工具設定與使用者訊息
- 輸出組成： 思考 + 文本回應 + 工具使用請求
- Token 計算： 所有輸入與輸出組成皆計入上下文視窗，且所有輸出組成皆以輸出 tokens 計費。
2
工具結果處理（第 2 輪）
- 輸入組成： 第一輪中的每個區塊以及 tool_result。您必須將思考區塊連同對應的工具結果一起傳回。這是您唯一必須傳回思考區塊的情況。
- 輸出組成： 工具結果傳回給 Claude 後，Claude 僅以文本回應（在下一則 user 訊息之前不會有額外的思考，除非啟用了交錯思考）。
- Token 計算： 所有輸入與輸出組成皆計入上下文視窗，且所有輸出組成皆以輸出 tokens 計費。
3
新的使用者輪次（第 3 輪）
- 輸入組成： 所有輸入以及前一輪的輸出都會被帶入。已完成的工具使用循環中的思考區塊不再需要留在上下文中：在會移除先前思考區塊的模型上，當您將其傳回時 API 會自動捨棄；在會保留先前思考區塊的模型上，除非您使用思考區塊清除將其清除，否則它會保留。這也是您加入下一個 user 輪次的地方。
- 輸出組成： 由於在工具使用循環之外有新的 user 輪次，Claude 會生成新的思考區塊並從那裡繼續。
- Token 計算： 在會移除先前思考區塊的模型上，先前的思考 tokens 不再計入上下文視窗。所有其他先前的區塊仍計入上下文視窗，目前 assistant 輪次中的思考區塊亦然。

搭配思考進行工具使用的注意事項：
- 當您送出工具結果時，必須包含伴隨該工具請求的完整且未經修改的思考區塊，包括其簽章。
- API 使用加密簽章來驗證思考區塊的真實性。如果您修改了思考區塊，API 會回傳錯誤。

若要減少工具定義本身所消耗的上下文，請參閱管理工具上下文，或使用工具搜尋工具延後載入工具定義。

上下文感知

Claude Sonnet 5、Claude Sonnet 4.6、Claude Sonnet 4.5 與 Claude Haiku 4.5 具備「context awareness」（上下文感知）： 這些模型會在整個對話過程中追蹤其剩餘的上下文視窗（即其「token 預算」）。這讓模型能夠依據剩餘空間管理長時間執行的任務，而不必猜測還剩多少 tokens。上下文感知是自動的：您無需啟用任何設定，也永遠不需要自行傳送本節所示的標籤。API 會注入它們。

運作方式

在每個請求的系統提示中，API 會告知 Claude 其總上下文視窗：

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

預算與您的請求可用的上下文視窗相符：Claude Sonnet 5 與 Claude Sonnet 4.6 為 1M tokens，Claude Sonnet 4.5 與 Claude Haiku 4.5 為 200k tokens。本節的範例顯示的是具有 200k-token 上下文視窗的模型。

每次工具呼叫後，API 會向 Claude 更新其剩餘容量：

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

圖片 tokens 包含在這些預算中。

Claude Opus 4.7 及更新的 Opus 模型、Claude Sonnet 5.5、Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5 和 Claude Mythos 5 不會收到這些注入的標籤。在這些模型上，您可以使用任務預算（目前為 beta 版）為模型提供明確的預算。

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

透過壓縮管理上下文

如果您的對話經常接近上下文視窗限制，請使用伺服器端壓縮。壓縮會在伺服器上自動摘要對話的較早部分，使對話能夠超越上下文視窗限制繼續進行。此功能以 beta 形式提供給 Claude 4.6 及更新的模型以及 Claude Mythos Preview。

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

工具結果清除： 在代理式工作流程中清除舊的工具結果
思考區塊清除： 在使用擴展思考時管理思考區塊

已快取的提示前綴仍會佔用上下文視窗：提示快取改變的是您為這些 tokens 支付的費用，而非它們是否計入。