等 30 秒才回話的 AI 代理，AWS 說能壓到 2 秒：數字先擺著，條件也要看

先把背景補上。2026 年 9 月 22 日，一篇技術分析文章整理了 AWS 對 Amazon Bedrock AgentCore Runtime 的更新：開發者只要把設定改成 platformVersion: V2，就能啟用按需記憶體管理與啟動快照兩項機制。宣傳裡最搶眼的一組數字是，冷啟動從 V1 接近 30 秒，降到約 2 秒。

聽起來像魔術，但官方測試有明確前提。把幾個常見疑問攤開來看，味道就出來了。

冷啟動到底是什麼在等？

很多人以為 AI 代理慢，都是模型在算。其實在模型開口之前，還有一整段前置作業：容器映像檔要載入、執行環境要初始化、網路路徑要打通。這段「代理程式還沒準備好接第一個請求」的等待，就是冷啟動。V2 動手的正是這一段，模型推論、工具呼叫那些時間，它管不到。

30 秒變 2 秒，測的是什麼？

AWS 公告寫得相當具體。測試用的是一支空白 echo agent，不呼叫任何模型與工具；從美國西部的 EC2 經公網呼叫美國東部的代理，用 Python 與 Boto3 發出 5,000 次冷啟動呼叫，所以數字裡還包含跨區網路往返。

結果是：在指定條件下，V2 對 200MB 至 2GB 映像檔的 P75 冷啟動約 2 秒；V1 則從約 5.4 秒起跳，映像檔越大越接近 30 秒。注意兩件事：這是 P75 而非平均值，且測試代理本身的回應時間只有約 34 毫秒，量測的主要是平臺啟動路徑。

使用者感受到的等待，會跟著變 2 秒嗎？

不會直接換算。完整回應時間等於冷啟動，加上模型推論、工具呼叫、資料處理、代理迴圈與網路延遲。如果第一個請求只做少量程式初始化，平臺啟動確實可能佔掉大部分等待，V2 的改善就很明顯；但如果請求一開始就要讀企業資料、呼叫模型或多個工具，V2 縮短的只是前段。

V2 實際改了什麼？

兩件事。第一，按需記憶體：工作階段先以較小的記憶體輪廓建立，依需求載入並回收。AWS 把 V1 描述為較容易受最高記憶體水位牽動，不過這是官方對自家新舊產品的比較，實際省不省，還是要拿自己的帳單和負載驗證。

第二，啟動快照：建立或更新 Runtime 時，平臺先啟動容器、跑完健康檢查，再把啟動結果儲存成快照，後續執行個體直接從快照還原，少走一段重複初始化的路。AWS 的開發指南也提醒，快照會繼承啟動當下的結果，隨機值、即時時間、權杖這類變動資料，必須在每次請求處理時重新取得，否則會出現微妙的狀態錯亂。

什麼場景最有感？

互動式代理。客服、程式協作或資料查詢這類服務，常在使用者送出第一個問題時才建立工作階段，V2 能直接壓掉前段的平臺等待。突發流量場景也可能受惠，批次工作或活動上線時請求集中抵達，快照還原讓擴容路徑比較可預測。但帳號配額、區域容量、下遊 API 與模型併發依然是瓶頸，Runtime 再快，資料庫或第三方 API 排隊，使用者照樣在等。

至於長工作階段與多步驟代理，帳要重算。代理迴圈越長，冷啟動改善佔整體時間的比例通常越低；而且對話歷史、任務進度這些狀態若只留在程序記憶體，執行個體一被回收就得從外部儲存恢復，外部儲存帶來的讀寫延遲與費用，應該和快照的啟動收益分開量測。

遷移前該做什麼？

原文給的方向很樸素：別只看官方基準，把使用者感知的等待拆成「工作階段建立前」與「建立後」兩段各自量測；基準測試要記錄每個依賴服務的等待時間，否則很容易把下遊排隊誤判成冷啟動問題。延遲、成本與程式相容性三件事核對完，再決定要不要把 platformVersion 改成 V2。

一句話收尾：2 秒是真的，但它是「特定條件下的平臺啟動 2 秒」，不是「你的代理 2 秒回話」。數字漂亮，條件更值得細讀。