AI Agent 不必 24 小時醒著：按需啟動真正要先設計好的三件事

AI 知識

從常駐思維走向可靠的按需 Agent

AI 知識｜AI Agent｜2026-08-10

很多人想像 AI Agent 時，腦中浮現的是一個永遠在線的數位同事：持續監看訊息、隨時處理任務、永遠記得上一輪發生什麼事。

但這不一定是最好的系統設計。

對許多工作而言，Agent 不需要一直佔著執行環境。它可以在訊息、排程、檔案變更或佇列任務出現時才啟動；沒有工作時，執行個體可以縮減到零。這種做法常被理解成節省資源，但真正重要的價值，是它迫使團隊把 Agent 的工作方式講清楚。

一個 Agent 要能可靠地按需啟動，至少要先回答三個問題：誰叫醒它？它醒來後從哪裡接手？哪些資訊不能跟著執行環境一起消失？

傳統伺服器思維容易把常駐當成穩定。程式一直在、記憶體還留著、背景工作也不會中斷，看起來很安心。

但 Agent 的工作往往不是每秒都需要運算。客服訊息還沒來、排程時間未到、檔案沒有更新、佇列沒有新任務時，持續運行不會讓它更聰明，只是讓系統維持待命。

雲端執行環境已經把另一種可能做成標準能力。以 Cloud Run 為例，當沒有請求時，服務可以移除最後一個 instance；有新請求時再建立新的 instance。Azure Container Apps 也能依 HTTP、佇列與事件等規則擴縮，並把最小 replica 設為 0。

這不代表所有 Agent 都應該縮到 0。需要低延遲互動、長時間連線或即時監測的流程，可能有不同要求。重點是，不要把「一直醒著」當成唯一預設。

按需啟動的第一步，不是設定縮放，而是定義觸發事件。

常見的觸發方式包括：收到新訊息、排程時間到、佇列出現工作、表單提交、檔案上傳、資料庫事件，或另一個系統明確送來任務。這些事件不是單純的技術細節，它們決定 Agent 的工作邊界。

如果觸發條件太寬鬆，Agent 可能被大量無關事件叫醒；如果條件太模糊，則很難判斷同一件事是否已經處理。較好的設計會讓每個工作都有能識別的任務 ID、來源、時間與狀態，避免「不知道誰叫它做什麼」的情況。

這也是為什麼 event-driven job 很適合部分 Agent 任務。它把工作拆成明確的一次觸發與一次執行，而不是讓背景程式無限等待。

當執行環境可被移除，最容易被忽略的是 cold start。第一個事件進來時，系統可能需要建立 instance、載入程式、建立連線，再開始工作。這段等待不一定長到無法接受，但它必須被納入設計，而不是發生後才被當成異常。

更重要的是，Agent 醒來時不該只靠「上一個 instance 的記憶」。它需要知道目前任務進行到哪一步、已完成什麼、下一個可安全執行的動作是什麼。

因此，長任務最好有明確 checkpoint。每一個 checkpoint 都應該能回答：這個步驟是否已成功？若重跑一次會不會重複發送訊息、重複扣款或重複建立資料？如果前一次在中途失敗，下一次要從頭做，還是接著做？

這裡沒有一個放諸四海皆準的答案，但「能重入、能追查、能安全重試」通常比「記憶體還留著」可靠得多。

容器執行環境很適合跑程式，但不適合當成永久記憶。Cloud Run 的文件特別提醒，容器檔案系統是可丟棄的；執行個體停止後，不應假設本機檔案還會存在。

這對 Agent 是很直接的提醒。對話脈絡、任務狀態、產出檔案、工具執行結果、失敗原因、重試次數與權限判斷，哪些必須留存，應由外部資料層承擔。那可以是資料庫、物件儲存、訊息佇列或其他持久化服務，關鍵不是名稱，而是它不能隨著一次執行結束而失效。

把狀態放在外面還有另一個好處：Agent 不必綁定某一台機器或某一個長存的 process。下一個 instance 可以讀到相同任務紀錄，照規則接手，而不是重新猜測之前做了什麼。

按需啟動看起來像成本與運算資源的問題，但它更像一次架構測驗。

如果一個 Agent 只能在常駐記憶體裡記得任務進度，代表狀態邊界還不清楚。如果它無法安全重試，代表每個動作的副作用還沒被設計好。如果它不知道何時該被叫醒，代表觸發條件仍停留在模糊描述。

反過來說，能在事件來了才啟動、做完後安全結束，下一次又能正確接手的 Agent，通常已經具備更清楚的任務模型、狀態保存與驗證機制。

AI 會做事只是第一步。真正可靠的 Agent，還要知道什麼時候該醒、醒來後如何不失憶，以及哪些資料必須留下來讓下一次自己能接得上。