編按：本文綜合整理自 Earendil Engineering 原始文章、OpenAI 官方推理模型文件、Google Gemini Interactions API 文件與 Anthropic Compaction 文件，並加入 Siami 編輯部觀點與分析。
AI 助理的價值，已不再只是一問一答。當代理能連續工作數小時、操作工具、委派子代理、查閱網頁並累積專案決策，真正有價值的資產就從「最後一段回答」變成整個工作階段。問題是，使用者下載到的聊天紀錄，未必等於模型實際使用過的完整狀態。
Earendil Engineering 在〈The Session You Cannot Take With You〉中提出警告：現代推論 API 正逐步混合可讀文字與只能由原供應商解讀的狀態。表面上，開發者仍保存了對話；實際上，關鍵脈絡可能留在加密推理、代管搜尋、壓縮內容、遠端檔案或伺服器回應 ID 裡。
從逐字稿到「只剩指標」的工作階段
早期聊天 API 的概念相對直接：應用程式送出輸入，模型回傳輸出，只要雙方內容都保存，便能檢查、封存或交給另一個模型繼續。即使模型的斷詞、取樣方式與能力不同，至少語意紀錄仍掌握在使用者手上。
新的狀態式 API 帶來便利，也改變了所有權邊界。應用程式可以只傳送上一個 response ID，供應商便在伺服器端接續工作；但對本機而言，那個 ID 只是指向外部資料庫的一把鑰匙。帳號失效、服務中斷、政策改變或模型退役時，使用者未必能重建當時的完整脈絡。
常見的不可攜狀態包括：
- 使用者付費產生、卻只能保存為不透明密文的推理內容。
- 模型看過完整片段，但客戶端只拿到網址或引文的代管搜尋結果。
- 只有原供應商能解讀的壓縮內容、向量資料庫與快取參照。
- 子代理之間不可讀的任務指派與訊息。
- 綁定遠端容器、檔案或 conversation ID 的工作成果。
這不代表每一項設計都出於惡意。伺服器端狀態可以降低傳輸量、提升快取效率，也能讓長任務延續得更順暢；問題在於，便利功能是否同時提供可讀、可匯出的中立版本。
五個問題，判斷 Session 是否真正屬於使用者
原文提出一套實用判準。可攜性並不是要求換模型後產生完全相同的下一個 token，而是要求另一套實作能理解先前發生的事，並在合理範圍內接手。
可用以下五項測試檢查：
- 檢視：使用者能否看見模型讀了什麼、工具做了什麼、代理彼此說了什麼？
- 匯出：工作階段是否能形成自足封存檔，而非依賴供應商解參照？
- 重播：另一套系統能否重建語意上相當的上下文？
- 稽核：事後能否解釋系統為何執行某個動作？
- 刪除：使用者能否辨識並刪除所有必要的伺服器副本？
只拿到回應 ID，不等於拿到對話；只拿到自己無法解密的內容，也不等於擁有資料。對企業而言，這些差異會直接影響事故調查、法遵稽核、資料刪除與供應商轉移。
密文、搜尋與壓縮：三個最容易忽略的缺口
第一個缺口是推理狀態。OpenAI 官方文件說明 Responses API 可跨回合保存推理狀態；在特定無資料保留情境下，應用程式可攜帶 encrypted_content，由服務端在記憶體解密。這對資料保留政策可能有幫助，但密文的意義仍無法交給其他模型理解。
第二個缺口是代管搜尋。模型可能看到排序後的結果、擷取段落與被過濾內容，客戶端卻只收到答案和幾個引用連結。網頁會更新，搜尋排序也會改變；只有 URL，無法證明模型當時究竟看見哪一段證據。
第三個缺口是上下文壓縮。長時間代理工作必須縮短歷史內容，這本身合理；但若壓縮結果只是一段供應商專用的不可讀狀態，使用者便失去檢查錯誤摘要的能力。相較之下，可讀摘要即使有資訊損失，仍可被編輯、審查並交由其他模型使用。
MCP 最新規格讓工具與資料來源的連接更標準化，但 MCP 解決的是介面整合，並不自動保證完整 session 可攜。若模型的隱藏推理、代管工具結果與壓縮狀態沒有一併匯出，工具插頭標準化後，工作記憶仍可能被鎖住。
數據解讀：733 分與 212 則討論代表什麼
這篇文章在本輪檢查時，Hacker News 已達 733 分、212 則留言，遠高於 feeds.json 初次記錄的 336 分與 77 則留言。數字快速攀升，顯示議題不只是 API 設計細節，而是大量實際使用 AI coding agent 的開發者已經碰到交接、壓縮與稽核問題。
但 HN 熱度不能被解讀成「所有狀態式 API 都有問題」。討論中也有人指出，完整對話常含大量雜訊，跨模型接手未必需要保存每個 token；比較實際的做法，是把決策、已完成工作、測試結果與下一步寫入專案內的 Markdown 文件。這項反方意見很重要：真正需要攜帶的，可能不是原封不動的內部推理，而是足以重建工作依據的可讀紀錄。
因此，爭議核心不是「是否必須公開完整思維鏈」，而是不可讀狀態是否成為唯一的語意載體。供應商可以保留專有最佳化，但不應讓使用者只能依賴密文才能繼續自己的工作。
為什麼這件事重要
AI 代理愈可靠，使用者愈容易把更多營運流程交給它；而愈長、愈複雜的流程，也愈難離開原本的供應商。當模型價格上漲、服務停機、地區政策改變，或機密階段必須移到本地模型時，無法轉移 session 會從不便升級成營運風險。
真正健康的架構，應把本機事件紀錄視為權威來源：提示、工具呼叫、工具結果、代理任務、可讀壓縮摘要、來源時間與內容雜湊，都能由使用者保存。伺服器狀態可以加速處理，卻不應是唯一能解讀專案歷史的地方。
對一般使用者而言，最務實的防線不是等產業完成標準，而是現在就建立可攜交接層：
- 要求代理定期寫入
DECISIONS.md、STATUS.md或工作日誌。 - 保存工具輸入、輸出、引用片段與擷取時間，不只保存網址。
- 將必要檔案、測試結果與產出存回自己的儲存空間。
- 使用可替換的工具介面，避免核心流程只能透過單一供應商內建工具執行。
- 定期用另一個模型讀取交接文件，實測是否真的能接手。
這些做法無法複製另一個模型的隱藏思考，卻能保存真正影響工作的事實、決策與證據。可攜性不是追求逐 token 重現，而是確保換掉供應商後，使用者仍握有理解與延續工作的最低自由。
網路社群怎麼看
Hacker News 討論呈現兩條路線。一派擔心供應商鎖定與不可稽核狀態，主張把工具、子代理與壓縮流程移到客戶端；另一派認為完整 session 本來就很吵雜，應以專案筆記取代逐字保存。
值得注意的回應包括：
- 有開發者表示，內建搜尋和程式執行看似只是工具，實際上卻形成難以替換的能力護城河。
- 有人建議把子代理呼叫外部化，並把壓縮摘要存成普通文件。
- 也有使用者經常讓 Claude 與 Codex 互相接手，雖然品質可能下降，但實務上仍能運作。
- 多位使用者採用 notes 目錄，記錄已知事項、進度與待辦，再讓下一個模型讀取。
這些回應共同指出一個方向：供應商層的完整可攜性尚未成熟，但應用程式與使用者仍可透過公開格式、專案文件和客戶端工具紀錄，先把最重要的語意狀態掌握在自己手上。
最低標準不該是「永遠使用同一個模型就沒事」，而是關閉帳號之後，仍能保留自己的工作紀錄，並交由另一個系統理解與繼續。
網友熱門留言 (4)