prewarm() 啟動的行程，如果最後沒有被 claim()，會發生什麼事？會不會造成資源浪費？
官方 changelog 沒有詳細說明未被認領的備用行程的生命週期管理細節（例如是否有逾時自動回收機制），這是目前文件相對精簡、需要留意的一點。從設計邏輯合理推測，既然這是一組處理行程資源的 API，應該會有某種形式的逾時或上限控制,避免備用行程無限累積——但在官方補齊完整文件之前，比較保守的做法是自己在應用層加一層監控，確認 prewarm 的行程數量跟存活時間在合理範圍內，不要假設底層一定會幫你處理乾淨。
既然 prewarm/SpareProcess 跟既有的 startup() 概念上類似，兩者可以一起用嗎，還是互斥的？
官方 changelog 把這兩者各自列為獨立的功能項目，描述的角度也不完全重疊——startup() 是 v0.2.89 就有的既有效能最佳化手段，prewarm/SpareProcess 是新增的、標記為 alpha 的機制，進一步把「啟動」跟「認領」拆成兩步。公開文件沒有明確說明兩者是否設計成互斥、或是可以疊加使用，這點需要留意——如果你的應用已經在用 startup()，導入 prewarm 之前，比較保守的做法是先在小範圍測試兩者同時存在時會不會有衝突或重複啟動行程的狀況，而不是直接假設可以無痛疊加。
alpha 標籤的 API，一般建議多久之後可以考慮用在正式環境？
沒有一個放諸四海皆準的時間，這取決於這類 API 過去在同一個 SDK 的演進模式。比較務實的判斷方式，是觀察這組 API 在後續幾個版本的 changelog 裡有沒有出現「breaking change」或「行為調整」的紀錄——如果連續幾個版本都沒有再變動介面，只是持續修小 bug，通常代表它正在往穩定邁進；反過來說，如果短期內介面還在頻繁調整，就代表現在導入正式環境的風險還偏高，每次 SDK 升級都可能要重新檢查這部分程式碼有沒有受影響。
如果我的應用是伺服器端長駐服務（不是每次都重新啟動行程），prewarm() 對我還有意義嗎？
意義會比「每次都重新冷啟動」的場景小很多，但不是完全沒有。如果你的伺服器本來就維持一個行程池、長駐運行、重複處理多個使用者的 session，那麼單一行程的啟動成本本來就已經被攤提到服務的生命週期裡，不會每次請求都重新付出這個代價——這種架構下，prewarm 帶來的邊際效益有限。但如果你的架構是每個 session 或每個請求都對應一個全新行程（例如某些 serverless 或容器化部署模式，每次呼叫都是全新的執行環境），那麼 prewarm 仍然有價值,可以在請求到達前、確定參數前的空檔先把行程準備好。
用 Claude Agent SDK 建構應用程式時，每次呼叫 query() 背後，實際上都需要先啟動一個 Claude Code 子行程（subprocess），這個啟動過程本身需要時間——對於第一次查詢的延遲特別敏感的場景（例如使用者打開應用程式、送出第一句話就要等好幾秒才看到回應開始跑），這個行程啟動的成本會直接反映成使用者感受到的等待時間。新增的 prewarm() 跟 SpareProcess.claim()（目前標記為 alpha，也就是實驗性、介面可能還會變動的功能）提供了一個思路：把「啟動行程」跟「真正開始一個 session」這兩件事拆開，分開處理。
傳統流程是：你呼叫 query()，SDK 當下才去啟動一個 Claude Code 行程、綁定這次 session 需要的資料夾路徑跟各種 session 層級的選項，然後才真正開始處理你的訊息。prewarm() 打破了這個順序——它讓你可以在「還不知道這個行程最終會服務哪個 session」的時候，就先把行程啟動起來，放在一個「備用」的狀態；等到你真的準備好要開始一個 session、知道要綁定哪個資料夾跟哪些選項的時候，再用 SpareProcess.claim() 把這個已經啟動好的備用行程「認領」過來，直接接上這次 session 的設定，跳過原本從零啟動行程的那段時間。
這個機制最適合的情境，是「你大概知道接下來會需要一個 session，但確切的 session 參數還沒確定」的場景——比如說，使用者打開一個聊天介面但還沒打字，你可以趁這個空檔先呼叫 prewarm()，等使用者真正送出第一句話、你才知道要用哪個資料夾、哪些工具權限時，再呼叫 claim() 把備用行程接上。因為行程啟動本身的延遲已經在使用者打字的這段時間內被「攤銷」掉了，使用者實際感受到的「送出訊息到開始回應」的等待時間會明顯縮短。這跟同樣是效能最佳化方向的 startup()（SDK v0.2.89 加入的既有功能）概念上相近，都是把啟動成本從關鍵路徑上挪開，但 prewarm/SpareProcess 進一步把「啟動」跟「認領」拆成兩個獨立的動作，給你更多彈性去決定什麼時候做哪一步。
官方把這組 API 標記為 alpha，意味著介面設計本身還可能在後續版本調整，甚至可能有未公開的邊界情況尚未處理完整。如果你打算在正式環境裡採用，比較穩妥的做法是先在非關鍵路徑、或是可以容忍行為變動的場景裡試用，同時密切關注 SDK 後續版本的 changelog，確認這組 API 穩定下來之後再全面依賴它。目前官方 changelog 本身對於這組 API 的說明也相對精簡，沒有提供詳細的使用範例，比較完整的文件要查閱官方的 TypeScript API 參考。
如果你的應用對首次查詢延遲特別敏感——例如客服聊天介面、即時助理產品，使用者打字到第一個回應開始出現之間的等待時間直接影響體感——prewarm() 值得放進效能最佳化的待辦清單，先在非正式環境評估能帶來多少實際的延遲改善，再評估值不值得冒 alpha 階段的 API 變動風險導入正式環境。如果你的場景對首次查詢延遲沒有特別敏感（例如批次處理、背景任務），這個功能帶來的效益有限，不需要為了它去承擔 alpha API 的維護成本。