昨天說 session 是 harness 的地基，今天把它蓋起來。先講清楚問題：使用者跟 agent 工作到一半，關筆電下班，明天打開希望「接著昨天的進度繼續」。但 LLM API 每一次呼叫都是獨立的（OpenAI、Anthropic 的 API 都不替你保存任何對話狀態），「繼續」這件事，模型和 API 都做不到，只能由你的系統做到。

這就是 session 設計的定義：在永遠無狀態的 API 之上，蓋一層讓對話可以持續、中斷、恢復的抽象。

兩條路線：Stateless 與 Durable

先標適用邊界：你在做的是每次一問一答的 API 服務、對話不長，stateless 加上「前端自己帶歷史」就夠了，別急著上重武器。Durable 的複雜度只在任務跨越 context window、需要中斷續跑的時候才值回票價。

四種連續性策略，由簡到繁

策略一：全量重放。 每次請求把完整歷史塞回去。實作最簡單、正確性最好，Day 3（成本的物理學）講過它的帳：input 隨輪數線性成長，遲早打爆窗口。適合短對話，當第一版沒有問題。

策略二：滑動窗口。 保留最近 N 輪，超出就截斷或摘要。可以無限對話、成本可控，代價是早期的重要資訊可能被切掉。一般 chatbot 和客服系統多半停在這一級。

策略三：Checkpoint。 LangGraph（LangChain 家的 agent 工作流框架）是代表：把 agent 的完整狀態（對話歷史、執行到哪個節點、還沒跑完的工具呼叫）存進資料庫，用一個 thread_id 識別。恢復時帶同一個 thread_id，系統從資料庫載入 checkpoint，從上次停的節點繼續，連跑到一半的工具呼叫都接得回來。這是「中斷再續」體驗的完整解，也順便送你時光回溯除錯的能力。代價是每一步都有存取延遲，checkpoint 本身可能很大。

策略四：Compaction 接力。 Claude Code 的模式，Day 13（Compaction）講過機制：歷史滿了就摘要成一份總結，新 session 拿著總結繼續。它犧牲了細節的完整性，換來 session 可以無限接力。

實務上成熟系統是混搭的：checkpoint 管中斷恢復、compaction 管長度、滑動窗口管日常。挑策略的判斷點只有一個：你的任務會不會超過一個 context window 的壽命？ 會，就至少需要三或四。

Session 該裝什麼：任務的連續性，而非個人記憶

儲存策略之外，還有一個更容易做錯的決策：session 裡該裝什麼。大多數人想 session 時，問的是「agent 怎麼記住使用者是誰、喜歡什麼」。Claude Code 問的是另一個問題：這個工作做到哪了、下一個 session 從哪裡繼續？ 兩個問題會長出完全不同的架構。

看它的實際取捨。工具輸出只活在 context window 裡，沒有任何機制自動把它存進資料庫；compaction 觸發時，保留的是結構性狀態 — 還有什麼沒做完、動過哪些檔案、最近幾個使用者請求。你的 find 結果、API 回傳的內容，壓縮之後全部蒸發。要讓重要的輸出活過壓縮，模型必須在當下主動把它寫進檔案，系統不會代勞。這是刻意的設計：session 只對任務的連續性負責，其他的它不管。

交接的機制也同樣克制。SessionStart hook 會掃描最近的工作交接檔，但只是「通知」模型這些檔案存在，不自動載入內容，讀不讀由模型自己判斷（Day 8 的 progressive disclosure 再次出現）。

這個區分給你一條清楚的架構邊界：任務狀態歸 session，跨任務的知識歸記憶系統（Day 10 到 12 講的那一套）。兩種常見的錯置各有各的下場：把使用者偏好塞進 session 交接單，交接單會越長越髒；指望 session 歷史充當長期記憶，它會在某次 compaction 之後無聲消失。

一個 production 細節：session 恢復要恢復到什麼程度

Day 4（兩層快取）講過 HermesAgent 的 frozen snapshot，當時的視角是省錢。換到 session 的視角再看一次：它的 gateway 是無狀態的 HTTP handler，每次收到訊息都重建 agent，那 system prompt 怎麼跨請求保持一致？答案是存進 SQLite — session 恢復時，直接取回上一輪一模一樣的 system prompt，位元級相同，prompt cache 才會命中。

這個細節說明 session 設計的深度：恢復不只是「把歷史找回來」，連 system prompt 的位元組都是狀態的一部分。差一個字元，體驗一樣，帳單不一樣。

Session 撐起了時間，接著是手腳

Session 解決了 harness 五維度裡的狀態持久化：模型活在一次次獨立的呼叫裡，你的系統讓這些呼叫串成一段有記憶的工作。但一個只能對話的 agent 還是廢的，它需要手腳：工具。

工具的設計有一個大多數人靠直覺會做錯的地方：需要什麼功能就加什麼工具，加到十幾個之後，agent 開始悄悄地選錯工具，而且沒有報錯、沒有警告。明天講 Tool Design：為什麼工具越多越選錯，以及真實系統怎麼控制這件事。