你已經知道：模型 (Model) 依這次提供的上下文 (Context) 回答，而文字可以用 token 計量。接下來的問題是：上下文能一直增加嗎？

上下文視窗 (Context Window) 是模型一次可容納的內容範圍。文字對話的既有訊息、新問題與本輪輸出都需要空間；程式提供的 系統指示 (System Prompt)、工具定義等也可能占用容量。系統指示與一般使用者訊息的用途和權限不同，不能只因都占空間就視為同一種訊息。

為什麼有上限？

模型要根據這次提供的內容生成下一個 token，不能只把訊息「存著」：它需要處理輸入，生成時也可能保留先前內容的運算結果。內容越長，通常就需要更多運算與記憶體，開始回答也可能等得更久。模型能處理多長的內容，取決於模型設計和服務提供的限制；不同模型與服務不一定相同。

更多 token → 更多內容要處理與暫存 → 資源與等待時間增加 → 一次可用長度設有上限

這個上限說的是這一次能提供多少內容，不是模型訓練時總共讀過多少文字。它也不是「把所有舊對話永久存進模型」的容量。

容量足夠只代表放得下，不保證模型正確利用每段資訊。檔案大小、輸出長度與上下文容量也可能是不同限制。

本章的核心是：模型一次能處理的內容有限。 下面的裁切策略只是在超出上限後處理請求的方式，不是上限形成的原因。

補充實驗：超出上限時，產品怎麼處理？

超出時如何處理，要看產品與設定。有的請求會報錯，有的系統先摘要，有的刪除較舊內容。整則丟棄是其中一種程式策略，不是模型必然的行為。

先預測：內容超出預算 300 token，策略是從最舊的整則訊息開始刪，而最舊一則有 800 token，刪完會留下多少空間？

刪掉 800 token 後就比上限少了 500 token。因為刪除單位是整則訊息，通常不會剛好貼齊上限。

這個算式只適用於所述的裁切條件。換成「不裁切」，超量依然存在；保留 system 時，可刪訊息也不同。改用摘要則要另外評估摘要保留了什麼，不能套用整則丟棄的結果。

真正重要的是：剩下的上下文是否仍有完成任務所需的資訊？ 如果會議時間那一則被刪掉，即使總數已低於上限，也不能期待模型憑空知道新時間。

參考：Claude 的上下文說明（2026-09-22 查核）、Google 的長上下文說明、Hugging Face 的生成快取說明（後兩者 2026-09-24 查核）。裁切實驗依本工具實作，不代表特定產品預設策略；不同模型的長內容處理方式也可能不同。