一百萬 token 的 context 聽起來像是記憶問題的終點。對話塞得下，agent 就不會忘記；工作區能持久化，中斷後按一下 resume，理論上也該接得回來。

把任務留到隔天再 resume，常見的是另一種失憶：agent 看得到昨天的 transcript，卻不知道哪個方案已經定案。檔案都還在，它分不清哪個輸出才是目前版本；測試紀錄也留著，卻沒寫清楚失敗是已知問題，還是這次修改造成的 regression。

原因通常很單純：團隊把「曾經出現在對話裡」誤當成「可以恢復的工作記憶」。

長 context、持久化 workspace、工作記憶是三件事

Meta 對 Muse Spark 1.1 的說明，同時列出最多一百萬 token context、context compaction 與平行 subagents。Google 介紹 Antigravity 2.0 時，則把背景工作、工具呼叫與可持久化的隔離環境放進同一套開發流程，讓檔案和狀態能跨過暫停繼續存在。

三者解決的問題不同：

• context window 決定這一次推理看得到多少內容；
• persisted workspace 決定 process 中斷後，哪些檔案與執行狀態還活著；
• work memory 決定另一個 session 能不能重建任務目標、限制、已接受的決策與下一步。

前兩項是容量與保存能力，第三項才是交接能力。Agent 可以完整保留一段很長的討論，仍然無法判斷其中哪一句只是腦力激盪，哪一句已經成為產品限制。

所以 compaction 不能只做摘要。摘要擅長縮短內容，不一定保得住決策的權重、檔案的真實版本，以及「哪些事情還沒驗證」這類不太好看的細節。

可恢復的 checkpoint 要拆成四層

我會把長任務的 checkpoint 分成四層，不讓 agent 自己用一段散文混在一起。

1. Source context

保留穩定 URL、版本或日期、選用的 pattern，以及採用理由。不要把整份網頁複製進 transcript，也別只留一句「參考某個網站」。下一個 session 要能確認來源是什麼，還要知道當初取用了哪一部分。

2. Accepted decisions

記下已採用方案、被拒絕的選項與理由，以及不能被下一輪偷偷改掉的限制。討論過不等於接受；如果這兩種狀態沒有分開，resume 後最容易發生的事，就是 agent 把舊提案重新做一次。

3. Executable state

這一層放 branch、commit、artifact path、環境前提、最後成功執行的命令，以及尚未提交的變更。只寫「landing page 已完成八成」沒有用。下一個 session 需要知道該從哪個 SHA、哪個目錄與哪一條命令開始查。

4. Verification evidence

保存實際跑過的測試、preview 或 simulator 狀態、關鍵輸出，以及未完成的驗證。Apple 對 Xcode 27 agent 工作流的描述，把規劃、改檔、測試、Playground、Preview 與 simulator feedback 串在一起，剛好說明驗證已是 agent 執行面的一部分。Checkpoint 必須留下證據，不能只留下 agent 的結論。

JetBrains Air 把檔案、commit、class、method 等結構化 context 帶進多 agent 工作流，再把 terminal、Git、preview 與程式碼放回同一個 review surface。關鍵設計落在交付物：一組能互相對照的 artifact，比更長的聊天紀錄更容易接手。

用一個 landing page 任務看差異

假設任務是替新功能做 landing page，並準備 Instagram 宣傳素材。研究、實作與素材可以平行處理，但最後不能交回三串 subagent transcript。

研究 lane 可以從 生成式 UI 資源合集 找互動模式與實作參考。Checkpoint 不需要抄回整份索引，只記錄最後選中的 URL、採用的 pattern，以及它為什麼符合現有 component catalog。

實作 lane 要交付 component path、branch、commit、preview URL 與已執行的檢查。若決策是「只能使用既有受信任元件，不渲染模型產生的任意 HTML」，它應該寫進 accepted constraints，不能只留在某個 agent 的回答裡。

素材 lane 也不能只寫「IG 圖完成」。設計稿確定後，可以用 Resize Image for Instagram 在瀏覽器本機預覽並輸出 1080 × 1350 的直式貼文或 1080 × 1920 的限時動態版本。Checkpoint 應記錄來源檔、輸出路徑、尺寸與採用版本，reviewer 才知道實際要驗收哪個檔案。

最後的 review surface 對照的是決策、程式碼、素材與驗證結果。Transcript 可以留作除錯線索，但不該成為唯一交付物。

六個欄位，勝過一段很長的摘要

Checkpoint 不必做成新平台。一份放在 repo 或任務 artifact 裡的 YAML，就能先把契約固定下來：

goal: 發布新功能 landing page 與 Instagram 素材
accepted_constraints:
  - 只使用既有 component catalog
  - 不渲染模型產生的任意 HTML
  - Instagram 直式貼文輸出為 1080x1350
artifact_paths:
  - app/pages/new-feature.vue
  - assets/social/new-feature-instagram-portrait.png
commands_and_tests_run:
  - pnpm test
  - pnpm build
unresolved_questions:
  - CTA 文案仍待產品確認
next_safe_action: 先確認目前 commit 與素材檔存在，再重跑 build

如果其中一欄填不出來，先別補一段更長的摘要。這通常表示任務還沒準備好交接。

格式也應該能被程式檢查。例如 artifact path 不存在就阻擋 resume，記錄的 commit 與目前 HEAD 不同就要求重新確認，最後一次測試失敗則不能把 next safe action 寫成直接部署。文字說明可以補充脈絡，硬狀態要交給可驗證欄位。

Resume 按鈕通過不了 restore drill，就還不算可恢復

開一個 fresh session，只給它 checkpoint 與 repo，不提供原本的聊天內容。先要求它說明目前目標、已接受限制、現有 artifact、未知事項與下一個安全動作。在它完成這一步以前，不准改檔。

接著故意放入幾個現實會出現的問題：目前 branch 比 checkpoint 舊、社群圖片被移動、決策理由遭 compaction 截掉，或記錄中的測試其實失敗。可靠的 agent 應該停下來指出差異，而不是靠語意補洞後繼續產生程式碼。

這個 drill 測的不是模型記得多少，而是工作契約是否完整。換模型、換 session，甚至換成真人接手，都應該能得到接近的任務理解。

把「可以繼續跑」和「知道自己在做什麼」分開

長 context 讓 agent 一次帶著更多材料前進，持久化 workspace 讓它在中斷後保住檔案。這兩件事都重要，但都不會自動保存決策的效力與驗證狀態。

團隊需要的是一份可檢查的恢復契約：來源有定位、決策有狀態、執行面有版本、驗證有證據。百萬 token 可以讓 agent 走得更遠；至於它醒來後做的是不是同一件事，要看 fresh session 能否只靠 checkpoint 重建任務，並且知道哪裡不能猜。

Source notes

• Introducing Muse Spark 1.1
• Building the agentic future: Developer highlights from I/O 2026
• Air Launches as Public Preview
• Apple aids app development with new intelligence frameworks and advanced tools