先看它想解掉的兩個痛點
Agent 已經不是問答玩具。AWS 在 2026 年 9 月 18 日的公告裡描述，agent 會處理理賠、寫與審查程式碼、跨系統協調，甚至無人看管跑好幾個小時。當工作型態從「幾秒一問一答」變成「長時間、事件觸發、常駐」，底下那層受管算力的假設就開始鬆動。
AWS 點出兩個具體問題。第一，session 一旦配置記憶體，就會一路持有到 session 結束，所以一個整天只偶爾爆量的 agent，等於用最高點在付整段時間的錢。第二，啟動時間不穩定：落在已初始化環境的 session 可以在 100 毫秒內開始，但要保證這件事就得常備算力；多數 session 其實走的是冷啟動，要開新環境、拉 image、初始化 agent，而這個延遲會隨 image 大小與併發量上升，在突發流量下最糟。
快照還原，把「開機」這件事只做一次
新版 runtime 的做法是：建立或更新執行個體時，先讓容器啟動並回報健康，然後對整個執行環境拍一張快照。你的一次性初始化（載入模型檔、抓靜態設定）就被烘進快照裡，之後每個新執行個體都是還原快照，而不是從零初始化。
關鍵在於這張快照被刻意縮小。AWS 說，naive 的做法會把 cache 與暫時性記憶體一起拍進去，讓還原時間隨 image 膨脹；新 runtime 把這些多餘部分剝掉，只留恢復所需的工作狀態，所以快照大小在 image 從 200 MB 長到 2 GB 時大致持平。
AWS 公布的量測方式是：用一個不回傳模型、不呼叫工具的空 echo agent，從 us-west-2 的 EC2 上用 boto3 呼叫 us-east-1 的 agent，走公網、沒有 VPC peering，每個版本、每種 image 大小各送 5,000 次冷啟動。這是客戶端數字，含跨區來回。在這個設定下，新 runtime 的 P75 冷啟動約 2 秒，且不隨 image 大小變動；原版則從約 5.4 秒升到接近 30 秒。
值得分清楚的是：這是平台啟動時間，不是 agent 工作的時間。同一份測試裡，agent 自己的程式碼在 P75 只跑了約 34 毫秒，其餘幾乎都是平台啟動。AWS 也給了一個實務建議——互動式 agent 可以在使用者一開啟對話框就先開 session，趁對方看招呼語、打第一句話的時候把環境暖起來。
記憶體改成隨需分頁，帳單跟著實際用量走
第二個改動是記憶體模型。新 runtime 讓 session 從一個小的常駐足跡開始，需要多少再分頁進來；當 agent 釋放 per-request buffer、或讓快取在請求之間過期，平台就把記憶體收回，而不是扣到 session 結束。AWS 說這是根據跨數十億個 session 的配置模式調出來的。
計費方式也跟著改：你付的是 agent 實際用到、隨需載入、閒置即回收的記憶體，而不是整場把整個 container image 留在記憶體裡。AWS 明確講這是一個取捨——單位費率變高，但 GB-hours 大幅變少，對多數 agent 來說足跡下降的幅度大於費率上升，帳單因此變低。
如果你的團隊正在把多模型 agent 搬進 AgentCore runtime，這層計費與啟動行為的變化會直接影響你原本的容量規劃假設，可以對照先前那篇搬遷筆記一起看。
對產品團隊的實際意義
把這兩件事放在一起，最直接的好處是少掉一批「自己蓋」的工作。AWS 描述客戶原本常自己常備閒置環境來躲冷啟動、自己調記憶體配置、再自己想辦法拆掉以控制帳單——這些都不是 agent 本身。
不過有幾個邊界要記住。第一，2 秒是特定測試條件下的 P75，不是保證值；你的 agent 若在啟動階段就做大量初始化，那部分已經被烘進快照，但第一次建立或更新執行個體時仍要付一次。第二，公告在「What’s next」段落被截斷，只提到還有更多定價、算力與相容性選項在路上，supplied RSS summary 沒有說明具體內容與時程，別把它當成已交付的能力來排 roadmap。
比較務實的下一步，是回頭看你自己 agent 的記憶體曲線：如果它一天只爆量幾次、其餘時間閒置，這次改版的計費模型對你有利；如果它本來就長時間滿載，那單位費率上升是否被足跡下降抵掉，就得用你自己的 session 資料算一次，而不是照搬 AWS 的「多數 agent」結論。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。