Context Window（上下文視窗）是 AI 在產生這一輪回答時能參考的「工作記憶」。 它和模型訓練時學過的知識不同，也不等於永久記憶。視窗放滿後，系統必須拒絕請求、截短舊內容，或先把歷史壓縮。
如果你遇到 AI 忘記前文、長文件漏掉關鍵條款，或 Agent 越跑越慢，問題通常就在 Context 的容量、內容品質或管理方式。
最大的誤解是把容量當成理解力。模型規格寫 1M Token，只表示請求可以容納到該範圍；它沒有承諾能同樣準確地找出每一處細節。真正好用的上下文，應該只留下完成當前任務需要的資訊。
哪些內容會占用 Context Window？
一個 API 請求可能同時包含：
- System Prompt 與開發者指令。
- 先前的使用者、助理訊息與推理內容。
- 上傳文件、圖片或音訊轉換後的 Token。
- Agent 的工具名稱、說明、參數 Schema 與工具結果。
- 這一輪預留或實際產生的輸出。
Claude 的 Context Window 文件明確說明，對話歷史、工具結果、圖片、文件、工具定義與輸出都會計入視窗。快取 Token 也仍占容量；Prompt Caching 改變的是處理成本，沒有把內容移出 Context Window。
不同模型對「輸入加輸出」的限制與溢位行為可能不同。送出前應使用供應商的 Token 計數工具，並替輸出保留空間。中文、英文、程式碼和圖片的切詞方式不同，不要用固定的「一個中文字等於幾個 Token」推算正式上限；先看 Token 計算入門，再用目標模型實測。
2026 年主流 Context Window 到多大？
截至 2026 年 8 月 12 日，主流 API 已普遍進入長上下文：
OpenAI 最新 GPT-5.6 系列列為 1.05M Context；Anthropic 部分現行 Claude 模型為 1M，其他型號仍有 200K；Google 表示多款 Gemini 模型提供 1M 或更大的 Context。比較時還要一起看最大輸出、思考 Token、多模態計算、價格與工具支援。
規格會改版，選型時請回到 OpenAI Models、Claude Context Windows與 Gemini Long Context確認。第三方聊天應用顯示的模型名稱，也不代表它把供應商完整 API 視窗開放給使用者。
為什麼放得下，模型還是會漏讀？
長上下文會增加三種負擔：輸入 Token 成本、首字延遲，以及模型從大量雜訊中找出關鍵證據的難度。Google 的長上下文指南也建議，沒有需要的 Token 就不要傳入，並提醒多個關鍵資訊同時埋在長內容時，表現會依情境變動。
經典研究 Lost in the Middle發現，把相關資訊移到長上下文不同位置時，模型表現會改變，資訊位於開頭或結尾時常較好，中間位置較容易退化。這項研究使用較早期模型，不能直接當成 2026 年所有模型的分數；它仍提供一個重要測試原則：不要只測「找不找得到」，還要改變證據位置與雜訊量。
我不建議把整個資料夾或完整資料庫無差別塞進模型。這會同時提高成本與漏讀風險，也讓你難以查明答案引用了哪一段。
長文件、知識庫與長對話怎麼選？
| 任務 | 建議起點 | 升級條件 |
|---|---|---|
| 單份合約、報告或程式碼 | 直接送入，要求標示頁碼或段落 | 超過視窗、重複查詢或召回不穩時切段 |
| 多份文件問答 | RAG先找相關段落 | 問題需要跨全文關聯時加入長上下文摘要 |
| 超長文件摘要 | 分段抽取事實，再合併摘要 | 跨章節關係重要時保留章節索引與中間結論 |
| 長對話 | 保留近期訊息，加上結構化歷史摘要 | 需要跨工作階段時把偏好與決策存到外部資料庫 |
| 長時間 Agent | 清除舊工具結果，保存任務狀態 | 工具很多時改成按需載入或搜尋工具定義 |
單一長文件：先直送，再用問題集驗證。
文件在視窗內時，直接送入的實作成本最低，也能保留跨段落關係。先準備一組真實問題，涵蓋開頭、中間、結尾、跨章節與「文件沒有答案」的情境。若品質與成本都過關，不必為了架構感提早上向量資料庫。
若同一份文件會被反覆提問，可以使用 Prompt Caching降低重複前綴的處理費。快取命中後仍要傳入並占用相同上下文容量，也不會改善漏讀。
多文件知識庫：RAG 負責縮小候選範圍。
RAG 適合文件總量超過視窗、資料常更新，或答案需要附可追溯來源的服務。檢索先找出候選段落，模型再閱讀與回答。不要只測檢索命中率；還要確認最後回答真的使用正確段落，並能在資料不足時拒絕猜測。
RAG 與長 Context 可以搭配：先檢索出幾份相關文件，再把完整候選章節交給長上下文模型做跨文件比較。
長對話：摘要要保存決策，不要只縮短文字。
對話摘要至少應分開保存目標、已確認事實、使用者偏好、已做決定、未解問題與下一步。只要求模型「摘要前文」，常會把例外條件和被否決方案一起壓掉。
每次摘要後用原始對話的測試題驗證：人名、數字、限制、否決理由與待辦是否還能正確回答。重要資料應存入結構化欄位或外部資料庫，不能把唯一副本留在會反覆改寫的摘要中。
Agent：工具結果通常比聊天文字更快膨脹。
Agent 會累積搜尋結果、終端輸出、網頁內容與大型 JSON。Anthropic 的工具上下文指南建議依壓力來源選擇工具搜尋、程式化工具呼叫、快取或 Context Editing。最實用的起點是把已完成步驟的原始輸出移除，只保留可驗證的結論、檔案位置、狀態與下一個動作。
若 Agent 跨多個工作階段執行，建立一份獨立的狀態檔。新工作階段先讀狀態與必要產物，再繼續任務；不要期待模型從一段不斷變長的對話自動恢復所有細節。Agent 的權限與狀態設計可延伸閱讀 AI Agent 指南。
長期記憶也不能只靠「多存一點」。AI Agent 記憶校準指南把寫入門檻、衝突處理、遺忘與回歸測試拆成可執行步驟，適合已經遇到舊偏好覆蓋新指令或跨任務污染的團隊。
上線前測試清單
- 記錄每個請求的輸入、快取、輸出與工具 Token。
- 對長文件測試關鍵資訊位於開頭、中間與結尾的表現。
- 加入無答案、矛盾資料、重複版本與惡意文件。
- 比較全文直送、RAG、分段摘要三種方案的正確率、延遲與成本。
- 對摘要後的對話做回歸測試，確認限制與決策沒有消失。
- 超過預算或視窗時，要有可預期的降級流程與錯誤訊息。
Context 管理沒有通用的最佳 Token 數。最小但足夠的內容，通常比追求用滿規格更可靠。成本面的量測與快取取捨，可接著看 AI API 成本最佳化。
常見問題
Context Window 是什麼？
它是模型產生本輪回答時可參考的工作記憶，包含指令、對話、文件、工具資料與輸出。超過上限後，API 可能拒絕、停止生成，或由應用程式先截短與壓縮。
1M 或 2M Token Context 代表什麼？
代表該模型或產品宣稱的單次上下文容量，實際還要看輸出是否共用上限、API 版本、檔案限制與應用程式是否另行縮減。容量大也不保證所有位置的資訊都能同樣準確地被使用。
Context Window 越大越好嗎？
沒有需要的內容放得越多，成本和延遲越高，模型也更難找到關鍵證據。應用程式應以真實問題測試最小足夠上下文，再決定是否需要更大視窗。
Prompt Caching 會增加可用 Context 嗎？
不會。快取降低重複內容的處理成本與部分延遲，被快取的 Token 仍占 Context Window。需要減少容量時要刪除、檢索或壓縮內容。
長文件該用 RAG 還是直接塞進 Context？
單一文件且在視窗內，可先直接送入並用問題集驗證。文件很多、更新頻繁或需要可追溯引用時，RAG 較合適；跨全文推理可讓 RAG 先縮小候選範圍，再交給長上下文模型。