AI Coding 詞典拆解（02）：Session、Turn 與 Context Window 的界線

「我前面明明交代過，怎麼它又問一次？」這種情況不一定是模型突然失憶。資訊可能還留在對話紀錄，卻沒有放進這次請求；也可能摘要遺漏了細節，或產品把不同工作分到不同 Session。要找原因，先分清楚資訊放在哪一層，以及它跨過了哪個邊界。

本文依照《Dictionary of AI Coding》第二單元的八個詞目，拆解 Stateless、Context、Context window、Stateful、Agent、System prompt、Session 和 Turn。本文以原課綱為範圍，透過新的工程情境教學，不是逐句翻譯原詞條。API 是否自行保存對話、產品如何切 Session，以及窗口如何計算，都要以當前文件為準。

Request、Turn、Session 是不同尺度

可以先用三層來描述一次互動：最外層是 Session，裡面有多個 Turn，每個 Turn 又可能包含多個 Provider request。這種層級關係有助於推理，但產品 UI 不一定用相同方式呈現或命名它們。

Session 是一段延續中的工作或互動歷程。聊天產品可能把數則訊息、一組工具活動和一個可恢復的識別碼放進 Session。新的使用者要求通常會成為下一個 Turn，並能引用先前歷史。Session 的保存位置可能在瀏覽器、桌面應用程式、服務端或專案資料裡；何時開始、何時結束，以及是否跨裝置恢復，都由產品設計決定。

Session 有紀錄，不等於模型一直看得到所有紀錄。產品可以保存完整逐字稿，卻只把其中一部分、摘要或重新檢索到的片段放進下一次請求。持久化與載入是兩件事。前者回答「資料是否還保存」，後者回答「資料是否進入目前請求」。

Turn 是使用者交出一項要求後，Agent 處理並交回控制權的互動單位。使用者只看到一則要求和最後一段回覆，背後卻可能有多次模型請求與工具活動。若 Agent 要讀檔、跑命令、根據錯誤再改檔，這些步驟通常仍屬於同一個 Turn。接著使用者補充「只修改這個模組」時，產品一般會把補充當成新的輸入，開啟後續 Turn。

最內層的 Provider request 是一次模型呼叫。它可能產生最終文字，也可能只提出一個工具呼叫，要求 Harness 先執行動作。工具輸出回來後，Harness 再送另一個 request。這表示「一則使用者訊息」不是成本、延遲或模型思考次數的單位；Turn 的內部長度取決於工作流程、可用工具和模型決策。有些系統甚至會把使用者看不到的摘要或路由請求算進流程。

Turn 也劃出人可以介入的時間點。Agent 連續工作得越久，使用者越少機會在中途調整方向。有些 Harness 可以暫停或中斷，有些只會在當前動作完成後讀取新訊息；具體行為依產品而異。若一次交辦會牽涉許多不確定選擇，可以先要求列出計畫或先完成一個可檢查的小步驟，讓方向更容易校正。

Stateless 說的是模型，不是整個產品

Stateless 表示模型本身不會自動保留前一次推論的對話狀態。模型的 Parameters 在一般推論時不因為你回覆而改寫。下一次請求要引用舊資訊，就得在該次 Context 裡再次提供，或使用某種由外部管理的延續機制。

這不代表所有 API 都要求應用程式每次手動重送整段逐字稿。以 OpenAI API 文件為例，獨立的文字生成請求可以由應用程式自行附上先前訊息；Responses API 也支援沿用前次 response，Conversations API 則提供可跨請求保存對話項目的物件。服務可以替你保存並串接狀態，但那是 API 或應用程式的工作，不是模型參數記住了對話。OpenAI Conversation state 文件

因此，看到「模型是無狀態的」時，要問說的是哪一層。模型可以是 stateless，API 卻有儲存對話的能力；Agent 可以在同一個 Session 延續狀態，卻不會自動帶著狀態進入另一個 Session；開啟新 Session 的產品也可能透過外部記憶載入少量舊資料。它們不矛盾，因為狀態保存在不同地方。

另一個常見誤解是，以為服務端保留對話就等於免費或永久記憶。保存期限、刪除方式、下一次請求實際使用哪些內容，以及歷史 Token 如何計費，都是 API 的具體規則。OpenAI 文件指出，即使沿用 previous_response_id，前面請求的輸入 Token 仍計入後續用量。其他 Provider 的計算方式可能不同，查當前 usage 欄位才能知道實際成本。

Context 是任務所需資訊，Context window 是請求上限

Context 是 Agent 在目前處理任務時可用的相關資訊。它可能來自使用者描述、專案規則、已讀取的程式碼、工具結果或 Session 歷史。這個詞談的是「目前有什麼資訊可用」，也要考慮資訊是否和任務相關。整段 Session 都保存著，不代表每個細節都在目前 Context 裡；相反地，一個從磁碟讀進來的型別定義，即使不在聊天紀錄中，也可能已成為目前 Context 的一部分。

Context window 則是模型單次請求能處理的 Token 容量限制。每個模型有自己的限制，輸入、預留輸出、推理內容和多模態資料如何計入，必須看 Provider 對該模型的說明。有些 API 把對話歷史存在服務端，但這不會消除模型每次生成時需要處理的有效上下文限制。若服務把歷史摘要或挑選片段送給模型，模型當次可用的仍是實際進入請求的那部分。

兩者的差異可以這樣看：Context window 是容器的容量，Context 是本次工作拿來用的內容。把窗口填滿不等於提供了好的脈絡。若一半內容是上週的錯誤輸出和已撤回的方案，模型可能需要在過時資訊中找真正限制。反過來說，只有幾段最相關的接口定義、測試案例和修改目標，往往更容易判斷。

容量也不等於理解保證。文件很長時，即使沒有超限，關鍵條件仍可能被忽略。模型對長上下文的使用效果會受到模型、任務和內容位置影響；不能從「可容納很多 Token」推論成「每條內容都會被同樣準確地取用」。因此要分開檢查兩件事：內容有沒有進入請求，以及進入後是否支援它完成任務。

例如，Session 裡有一段「日期一律使用 UTC」的早期決定，但最近幾十個 Turn 都在討論 CSS。若下一次任務需要改時間處理，產品可以重送完整歷史、只送最近幾輪、摘要舊內容，或透過檔案搜尋相關決定。這些策略讓模型當次收到的 Context 不同，即使 Session 顯示的逐字稿完全一樣。查錯時不要只看聊天紀錄，要查看 Harness 實際選了哪些片段和工具結果。

Stateful 行為由外部系統維持

Stateful 描述某個系統能否在多次操作間延續資訊。Session 可以在多個 Turn 之間保有歷史；API 可以保留 Conversation object；Agent 也可以透過外部記憶檔或資料庫，在新 Session 開始時載入偏好和專案狀態。這些都是某一層具備持續狀態，不代表模型本身成為 stateful。

一個實務上的檢查法是追問「狀態存在哪裡、何時讀取、由誰更新」。如果決定只存在聊天文字裡，新 Session 不一定知道；如果寫在文件裡但 Harness 沒有載入，模型當下仍看不到；如果 API 物件保存了對話，也要確認接續請求真的引用同一物件。只說「它有記憶」不足以描述這些條件。

可以按讀寫流程檢查狀態是否真的延續。先找出工作完成後哪些資料被保存，再確認新 Turn 或新 Session 從哪個位置讀取；接著確認它讀到的版本是否最新，最後看這些資料是否被納入當次模型請求。這四個環節任一處斷掉，都會表現成「記不住」。如果系統只保留原始逐字稿，問題可能是沒有載入；若載入了摘要，問題可能是摘要漏掉細節；若資料讀取正確但模型做錯，問題就在使用或理解，而非保存。

重置 Session 是有用的診斷方式，但要知道它改變了什麼。用完全相同的任務在新 Session 重現，可以檢查問題是否依賴舊歷史或產品記憶；不過新 Session 也可能載入同一套專案指令和持久記憶，所以「在新對話重試」不一定代表乾淨環境。若要做可比較的重現，記錄模型、指令、工具、工作目錄和當次提供的檔案，並明確說明哪些持久資料仍然有效。

跨 Session 的記憶還需要選擇哪些內容值得保存。短期錯誤輸出通常不應被當成長期事實；使用者確認的規格或專案慣例可能值得持久化。持久化機制還要有更新與刪除途徑，否則過時指示可能在新任務反覆出現。這些規則屬於記憶系統和 Harness 設計，超出單次 Context window 的範圍。

Agent 和 System prompt 決定互動方式

Agent 是使用者互動時真正接觸的配置單位。它通常包含 Model、Harness 提供的能力、指令、可用 Context 和停止條件。這個名稱沒有跨產品完全一致的定義，所以應看產品實際允許 Agent 做什麼。相同 Model 放在兩種產品裡，若一個能讀專案並執行測試，另一個只能回答文字，使用感受就會不同；差異可能來自工具、指令、權限或上下文管理，不一定是模型變了。

System prompt 是 Harness 或服務在請求中加入的高層指令，用來設定任務角色、互動規則或工具使用方式。產品可能把使用者看不到的指令放在這裡，也可能使用 API 中名稱或優先順序不同的角色。System prompt 並非所有產品共用的一份文字；更不能把它當成安全邊界。模型是否遵循指令仍受模型行為和請求結構影響，涉及檔案、命令或資料權限時，必須由 Harness 在執行邊界實際檢查。

專案中的常駐規則也不必然等於 Provider 的 System prompt。某些 Harness 會把 AGENTS.md、專案設定或使用者偏好讀入請求；另一些產品使用自己的配置方式。要診斷模型為何沒有照某條規則做，先確認該檔案是否被產品載入、是否針對當前目錄生效，以及最後送入請求的指令是否包含它。檔案存在於磁碟上，並不能證明它在模型當次可見的 Context 裡。

若兩條指令互相衝突，例如上層設定要求「所有檔案都要格式化」，而使用者要求「只改一個檔案」，不要只憑文字出現的位置猜誰必然勝出。檢查該產品對指令角色和優先順序的文件，再看當次 request 如何組合 system、developer 和 user 訊息。高層指令的作用是引導模型，不會替工具做授權檢查；若某個操作不能發生，執行層仍須拒絕它。

System prompt 也會隨產品版本變更。昨天相同的使用者要求能觸發某項工具，今天卻不行，可能是工具清單、提示或權限預設變了。若產品沒有公開完整提示，至少記下產品版本、可用工具和可觀察到的設定。這些資訊不能還原隱藏指令，卻能幫助排除模型、Harness 和 Session 狀態的差異。

用一次測試修復追蹤八個詞

假設你要求 Agent 修復日期格式測試。Harness 先組合 System prompt、你的要求和必要規則，並依產品機制接續 Session；這些資料中，與測試及格式有關的部分構成此次工作的 Context。序列化後送進模型的內容受 Context window 限制。模型依 Stateless 推論產生下一步，可能請求讀取測試檔；Harness 執行工具，將結果放入下一次 request。整段來回仍可能是同一個 Turn。如果 Harness 保存並帶入對話，應用在多個 Turn 間呈現 Stateful 行為。整個由指令、模型和工具組合的互動對象就是這裡所說的 Agent。

若 Agent 說找不到測試卻已經在對話裡看過檔名，先不要急著判定它「忘了」。檢查目前 Turn 是否仍接在原 Session，檔案內容有沒有被放進這次請求，工具結果是否回到模型，以及歷史是否只以摘要形式延續。若是新 Session，檢查持久記憶或交接資訊是否被載入。若它有上下文卻仍答錯，再檢查任務資訊是否清楚、內容是否被大量舊輸出稀釋，以及模型本身對此類任務的能力。

可用出錯邊界縮小範圍：

• 若同一個 Turn 的下一次工具往返就漏掉剛讀到的內容，查工具結果是否回到下一個 request。
• 若同一個 Session 隔幾輪後才漏掉決定，查歷史選取、摘要和 Context window 使用方式。
• 若只有新 Session 不知道，查外部狀態是否保存、載入，以及載入的是不是最新版本。
• 若相關內容確實在 Context 中，Agent 卻違反規則，查 System prompt 和其他指令如何組合，再用測試判定模型是否遵循。

這些步驟讓「忘記」從一句印象變成可以檢查的假設。記錄出錯時的 Session、Turn、模型輸入和工具輸出，通常比把同一段要求貼更多次，更快找到缺少的是哪一層。

本篇完整對應原 repo 課綱的 Section 2 — Sessions, Context Windows & Turns。詞目來源見固定版本的 README 詞典。API 對話保存和 Token 計數的現行行為，請參考 OpenAI Conversation state 與 OpenAI Token counting。