--- title: 上下文視窗 url: https://platform.claude.com/docs/zh-TW/build-with-claude/context-windows description: 了解上下文視窗的運作方式、擴展思考與工具使用如何計入其中，以及隨著對話增長如何管理上下文。 --- 隨著對話增長，您最終會接近上下文視窗的限制。對於長時間執行的對話與代理式工作流程，[伺服器端壓縮](https://platform.claude.com/docs/zh-TW/build-with-claude/compaction)是上下文管理的主要策略。 ## 上下文視窗的運作方式 「Context window」（上下文視窗）是指語言模型在生成回應時可以參考的所有文本，包括回應本身。這與語言模型訓練所用的大型語料庫不同，而是代表模型的「工作記憶」。較大的上下文視窗允許模型處理更複雜、更冗長的提示，但更多的上下文並不會自動帶來更好的結果。隨著 token 數量增加，準確度與召回率會下降，這種現象稱為「context rot」（上下文衰退）。這使得精心挑選上下文中的內容，與可用空間的多寡同樣重要。 若想進一步了解長上下文為何會退化，以及如何透過工程手段加以因應，請參閱 [Effective context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)。 下圖說明了 API 請求的標準上下文視窗行為1： ![「Context window」（上下文視窗）示意圖：各輪對話在上下文視窗中累積，直到對話接近 token 限制](https://platform.claude.com/docs/zh-TW/images/context-window.svg) *1 諸如 [claude.ai](https://claude.ai/) 等聊天介面也可以採用滾動式的「先進先出」方式管理上下文視窗。* * **漸進式 token 累積：** 隨著對話逐輪推進，每則使用者訊息與助理回應都會在上下文視窗中累積，且先前的輪次會被完整保留。 * **上下文視窗容量：** 上下文視窗（[最多 1M tokens，視模型而定](https://platform.claude.com/docs/zh-TW/build-with-claude/context-windows#context-window-sizes-by-model)）容納對話歷史以及 Claude 生成的新輸出。 * **輸入輸出流程：** 每一輪包含： * **輸入階段：** 包含所有先前的對話歷史加上目前的使用者訊息 * **輸出階段：** 生成文本回應，該回應會成為下一輪輸入的一部分 請求中的所有內容都會計入上下文視窗：「system prompt」（系統提示）、`messages` 中的每則訊息（包括工具結果、圖片與文件），以及您的工具定義。Claude 在該輪生成的輸出（包括其擴展思考）也會計入。每個回應都會在其 `usage` 欄位中回報該請求所消耗的量。如果您使用「prompt caching」（提示快取），輸入計數會拆分為 `input_tokens`、`cache_read_input_tokens` 與 `cache_creation_input_tokens`，三者皆計入視窗；詳情請參閱[提示快取](https://platform.claude.com/docs/zh-TW/build-with-claude/prompt-caching)。若要在送出請求前進行估算，請使用 [token 計數 API](https://platform.claude.com/docs/zh-TW/build-with-claude/token-counting)。 ## 各模型的上下文視窗大小 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 Haiku 5.5 和 [Claude Mythos Preview](https://anthropic.com/glasswing) 擁有 1M token 的上下文視窗。對其中任何一個模型的單一請求最多可生成 128k 個輸出 token（`max_tokens`）。其他 Claude 模型，包括 Claude Sonnet 4.5（已棄用），擁有 200k token 的上下文視窗。 對於每個擁有 1M token 上下文視窗的模型，1M 都是預設值：您不需要 beta 標頭，長上下文請求會以[標準定價](https://platform.claude.com/docs/zh-TW/about-claude/pricing#long-context-pricing)計費，但 Claude Haiku 5.5 除外，其超過 100,000 個 token 的提示費用較高。 單一請求最多可包含 600 張圖片或 PDF 頁面（對於 200k-token 上下文視窗的模型則為 100）。如果您傳送大量圖片或大型文件，可能會在達到 token 上限之前先達到[請求大小限制](https://platform.claude.com/docs/zh-TW/api/overview#request-size-limits)。 請參閱[模型比較](https://platform.claude.com/docs/zh-TW/models/overview#latest-models-comparison)表格，以取得各模型上下文視窗大小的清單。 ## 搭配思考的上下文視窗 使用[思考](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking)時，所有輸入與輸出 tokens（包括思考 tokens）都會計入上下文視窗限制，但在多輪情境中有一些細微差異。 思考 tokens 是您 `max_tokens` 參數的子集，以輸出 tokens 計費，並計入「rate limit」（速率限制）。使用[自適應思考](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking)時，Claude 會動態決定其思考配額，因此思考 token 的用量會因請求而異。 先前助理輪次中的思考區塊是否保留在上下文視窗中，取決於模型。在 Claude Opus 4.5 及更新的 Opus 模型、Claude Sonnet 4.6 及更新的 Sonnet 模型、Claude Haiku 5.5、Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5 以及 Claude Mythos Preview 上，API 預設會保留先前的思考區塊，它們會像其他輸入 token 一樣計入上下文視窗。在較早的 Opus 和 Sonnet 模型以及直到 Claude Haiku 4.5 為止的所有 Haiku 模型上，當您將先前的思考區塊傳回時，API 會自動將其從對話歷史中移除，從而為對話內容保留 token 容量。關於各模型的預設行為，請參閱[各模型的思考區塊保留](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking#thinking-block-preservation-by-model)。若要在任一方向覆寫預設值，請使用[思考區塊清除](https://platform.claude.com/docs/zh-TW/build-with-claude/context-editing#thinking-block-clearing)。 下圖顯示在會移除先前思考區塊的模型上啟用思考時，tokens 的管理方式： ![在會移除先前「thinking block」（思考區塊）的模型上進行「thinking」（思考）的示意圖：每一輪的思考區塊在輸出中生成，且不會帶入後續輪次的輸入](https://platform.claude.com/docs/zh-TW/images/context-window-thinking.svg) * **移除思考區塊：** 在會移除先前思考區塊的模型上，思考區塊（以深灰色顯示）會在每一輪的輸出階段生成，但不會作為輸入 tokens 帶入後續輪次。您不需要自行移除思考區塊：如果您將它們傳回，Claude API 會自動移除。 * **計費：** 思考 tokens 在生成時以輸出 tokens 計費一次。在會保留先前思考區塊的模型上，被保留的區塊隨後會成為後續請求輸入的一部分，並與其餘對話歷史一樣以輸入 tokens 計費。 您可以在[思考](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking)指南中閱讀更多關於上下文視窗與思考的內容。 ## 搭配思考與工具使用的上下文視窗 下圖說明在會移除先前思考區塊的模型上，將思考與「tool use」（工具使用）結合時，tokens 的管理方式： ![「Thinking」（思考）搭配「tool use」（工具使用）的示意圖：思考會與其工具結果一起保留，然後在會移除先前思考區塊的模型上，於下一個使用者輪次時被捨棄](https://platform.claude.com/docs/zh-TW/images/context-window-thinking-tools.svg) * **輸入組成：** 工具設定與使用者訊息 * **輸出組成：** 思考 + 文本回應 + 工具使用請求 * **Token 計算：** 所有輸入與輸出組成皆計入上下文視窗，且所有輸出組成皆以輸出 tokens 計費。 * **輸入組成：** 第一輪中的每個區塊以及 `tool_result`。您必須將思考區塊連同對應的工具結果一起傳回。這是您唯一必須傳回思考區塊的情況。 * **輸出組成：** 工具結果傳回給 Claude 後，Claude 僅以文本回應（在下一則 `user` 訊息之前不會有額外的思考，除非啟用了[交錯思考](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking#interleaved-thinking)）。 * **Token 計算：** 所有輸入與輸出組成皆計入上下文視窗，且所有輸出組成皆以輸出 tokens 計費。 * **輸入組成：** 所有輸入以及前一輪的輸出都會被帶入。已完成的工具使用循環中的思考區塊不再需要留在上下文中：在會移除先前思考區塊的模型上，當您將其傳回時 API 會自動捨棄；在會保留先前思考區塊的模型上，除非您使用[思考區塊清除](https://platform.claude.com/docs/zh-TW/build-with-claude/context-editing#thinking-block-clearing)將其清除，否則它會保留。這也是您加入下一個 `user` 輪次的地方。 * **輸出組成：** 由於在工具使用循環之外有新的 `user` 輪次，Claude 會生成新的思考區塊並從那裡繼續。 * **Token 計算：** 在會移除先前思考區塊的模型上，先前的思考 tokens 不再計入上下文視窗。所有其他先前的區塊仍計入上下文視窗，目前 `assistant` 輪次中的思考區塊亦然。 * **搭配思考進行工具使用的注意事項：** * 當您送出工具結果時，必須包含伴隨該工具請求的完整且未經修改的思考區塊，包括其簽章。 * API 使用加密簽章來驗證思考區塊的真實性。如果您修改了思考區塊，API 會回傳錯誤。 大多數目前的 Claude 模型都支援[交錯思考](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking#interleaved-thinking)，讓 Claude 能夠在工具呼叫之間進行思考，包括在收到工具結果之後。在具有自適應思考的模型上，這是自動啟用的；Claude Opus 4.5、Claude Sonnet 4.5（已棄用）以及更早的 Claude 4 模型需要 `interleaved-thinking-2025-05-14` beta 標頭，而 Claude Haiku 4.5 不支援此功能。 有關搭配思考使用工具的更多資訊，請參閱[搭配工具使用的思考](https://platform.claude.com/docs/zh-TW/build-with-claude/thinking#thinking-with-tool-use)。 若要減少工具定義本身所消耗的上下文，請參閱[管理工具上下文](https://platform.claude.com/docs/zh-TW/agents-and-tools/tool-use/manage-tool-context)，或使用[工具搜尋工具](https://platform.claude.com/docs/zh-TW/agents-and-tools/tool-use/tool-search-tool)延後載入工具定義。 ## 上下文感知 Claude Sonnet 5、Claude Sonnet 4.6、Claude Sonnet 4.5（已棄用）和 Claude Haiku 4.5 具有「**context awareness**」（**上下文感知**）：這些模型會在整個對話過程中追蹤其剩餘的上下文視窗（即其「token 預算」）。這讓模型能夠根據剩餘空間來管理長時間執行的任務，而不必猜測還剩多少 token。上下文感知是自動的：您不需要啟用任何設定，也永遠不需要自行傳送本節中顯示的標籤。API 會自動注入它們。 ### 運作方式 在每個請求的系統提示中，API 會告知 Claude 其總上下文視窗： ```xml 200000 ``` 預算與您的請求可用的上下文視窗相符：Claude Sonnet 5 和 Claude Sonnet 4.6 為 1M 個 token，Claude Sonnet 4.5（已棄用）和 Claude Haiku 4.5 為 200k 個 token。本節中的範例顯示的是擁有 200k token 上下文視窗的模型。 每次工具呼叫後，API 會向 Claude 更新其剩餘容量： ```xml Token usage: 35000/200000; 165000 remaining ``` 圖片 tokens 包含在這些預算中。 Claude Opus 4.7 及更新的 Opus 模型、Claude Sonnet 5.5、Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5 和 Claude Haiku 5.5 不會收到這些注入的標籤。在這些模型上，您可以使用[任務預算](https://platform.claude.com/docs/zh-TW/build-with-claude/task-budgets)（目前為 beta 版）為模型提供明確的預算。 對於跨越多個工作階段的代理，請設計您的狀態產物，使新工作階段開始時能快速恢復上下文。[記憶工具的多工作階段模式](https://platform.claude.com/docs/zh-TW/agents-and-tools/tool-use/memory-tool#multisession-software-development-pattern)逐步說明了一種具體做法。另請參閱 [Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)。 有關運用上下文感知的提示指引，請參閱[提示最佳實務](https://platform.claude.com/docs/zh-TW/build-with-claude/prompt-engineering/claude-prompting-best-practices#context-awareness-and-multiwindow-workflows)。 ## 透過壓縮管理上下文 如果您的對話經常接近上下文視窗限制，請使用[伺服器端壓縮](https://platform.claude.com/docs/zh-TW/build-with-claude/compaction)。壓縮會在伺服器上自動摘要對話的較早部分，使對話能夠超越上下文視窗限制繼續進行。此功能以 beta 形式提供給 Claude 4.6 及更新的模型以及 [Claude Mythos Preview](https://anthropic.com/glasswing)。 對於更專門的需求，[上下文編輯](https://platform.claude.com/docs/zh-TW/build-with-claude/context-editing)提供了額外的策略： * **工具結果清除：** 在代理式工作流程中清除舊的工具結果 * **思考區塊清除：** 管理較早輪次中的思考區塊 已快取的提示前綴仍會佔用上下文視窗：[提示快取](https://platform.claude.com/docs/zh-TW/build-with-claude/prompt-caching)改變的是您為這些 tokens 支付的費用，而非它們是否計入。 ## 上下文視窗溢位行為 如果僅輸入本身就已超過模型的上下文視窗，API 會在所有模型上回傳 400 `invalid_request_error`（「prompt is too long」）。 在 Claude 4.5 及更新的模型上，如果輸入 tokens 加上 `max_tokens` 超過上下文視窗大小，API 會接受該請求。如果生成過程隨後達到上下文視窗限制，則會以 `stop_reason: "model_context_window_exceeded"` 停止。在較早的模型上，API 則會回傳[驗證錯誤](https://platform.claude.com/docs/zh-TW/api/errors)。若要在這些模型上選擇啟用 `model_context_window_exceeded` 行為，請使用 `model-context-window-exceeded-2025-08-26` beta 標頭。詳情請參閱[停止原因與後備處理](https://platform.claude.com/docs/zh-TW/build-with-claude/handling-stop-reasons)。 為了維持在上下文視窗限制之內，請在傳送訊息給 Claude 之前使用 [token 計數 API](https://platform.claude.com/docs/zh-TW/build-with-claude/token-counting) 估算 token 用量。 ## 後續步驟 伺服器端上下文壓縮，用於管理接近上下文視窗限制的長對話。 透過上下文編輯，隨著對話增長自動管理對話上下文。 請參閱模型比較表，以取得各模型的上下文視窗大小與輸入／輸出 token 定價清單。 為 Claude 提供處理複雜任務的增強推理能力，並控制思考內容的回傳方式。