Google Cloud 8月出招：AI 資料庫代理人登場，Cloud Run 可長駐運行

Google Cloud 今年8月公布的兩項基礎設施更新，正正針對 AI agent 開發者最頭痛的兩件事：資料庫應該點揀、點部署及點維護；以及一個需要長時間保持在線的 agent，應該放喺邊度運行。

第一項係整合 Gemini Cloud Assist 的 Database Operations Agents，第二項係進入預覽階段的 Cloud Run instances——一種面向長時間、有狀態工作負載的單例運行環境。兩者合計，反映 Google Cloud 正同時改造 agentic application 的資料層及運算層。2411

Database Operations Agents：由部署到日常運維

Google Cloud 以 Agentic Data Cloud 策略為框架，推出 Database Onboarding Agent 及 Database Observability Agent。簡單講，前者處理資料庫上線前的 Day 0 工作，後者則負責部署後的 Day 1 及 Day 2 運作。2

Onboarding Agent：用需求描述揀資料庫

Database Onboarding Agent 會理解團隊對工作負載的要求，建議合適的 Google Cloud 託管資料庫，並協助完成設定及部署。對開發團隊或者平台團隊而言，作用係減少以往要人手處理的架構選擇及資源配置工作。

目前支援 AlloyDB、Bigtable、Cloud SQL 及 Spanner。2

換句話講，團隊可以先講清楚應用程式的工作負載特性、效能要求及營運需要；至於邊一種 Google Cloud 資料庫最適合，則由 agent 協助評估，而唔係完全靠人逐份文件比較。

Observability Agent：由監察到獲批後修正

Database Observability Agent 就負責資料庫部署之後的整個營運生命周期。Google 列出的功能包括資料庫群組監察、異常偵測、診斷、故障排解、效能優化及維護，支援 Cloud SQL、AlloyDB、Spanner、Bigtable、Firestore 及 Memorystore。224

佢唔係淨係睇單一圖表或者一項指標，而係會整合多個資料來源，包括 Database Insights 及 Database Center 遙測資料、Cloud Monitoring、Cloud Logging 和 Cloud Trace。相關背景可以涵蓋指標、查詢資料、資料庫資產清單及問題資訊，用嚟協助追查潛在根因。2

因此，目標唔只係彈出一個「系統有問題」的 dashboard 警報。agent 可以解釋問題、建議處理方法，並支援多步驟的修復流程。Google 舉的例子包括啟用 Cloud SQL connection pooling，或者為資料庫新增索引。

不過，涉及生產環境的重要變更，仍然要由人員批准，agent 才可以執行已驗證的修正。調查及修復功能當時屬於面向特定客戶的預覽能力。224

開發者可以喺邊度使用這些資料庫 agent？

兩個 agent 已整合到 Gemini Cloud Assist，使用者可以透過 Gemini 聊天介面，以及 Cloud Console 內相關的資料庫頁面存取。Google 亦提到，相關能力可以經由命令列工具、MCP server 及工具、第三方工具和整合式開發環境（IDE）使用。2

這個安排的重點係：資料庫協助唔再局限於一個獨立的營運 dashboard。開發者可以喺平日調查基礎設施、配置資源，或者寫 code 的工作環境入面，用自然語言完成相近的操作流程。

Cloud Run instances：為需要長駐的 AI agent 而設

8月28日，Google Cloud 預覽 Cloud Run instances。它同一般會按流量自動擴展的 Cloud Run service 並唔一樣：每個 instance 都係 singleton（單例），即係只維持一個運行中的 instance，而且唔會自動擴展。4

Google 將這項功能定位為長時間、有狀態工作負載的運行環境，例如個人 AI agent。主要特點包括：

• 最長可連續運行 7日
• 預設配置自動重新啟動政策
• 每個 instance 都有固定 HTTPS URL，更新及重新啟動後仍然維持不變
• 可以喺暫時唔使用時停止，之後再恢復運行
• 只提供一個專用運行環境，而唔係按照請求量擴展成一組 instance 4

這種模式適合需要維持身份、狀態或者背景活動的 agent，例如一個長時間服務單一使用者的個人助理。相反，如果工作負載係傳統、無狀態的網站 endpoint，主要需求係應付突發的大量並行流量，Cloud Run instances 就未必係最自然的選擇。

$5.70 月費應該點理解？

Google 引述的價格係：以 1 vCPU 及 1 GiB RAM、採用 shared vCPU 及 burst budget 的配置，連續運行30日約 5.70美元。4

Google 強調的優勢唔只係價格，亦包括運維工作較少。相對於自行管理一部專用虛擬機器，使用者可以省卻虛擬機器及作業系統維護、防火牆管理，以及自行建立 HTTPS endpoint 等工作。

不過，$5.70 應該視為 Google 對預覽產品的公布示例，而唔係適用於所有情況的成本比較。實際費用仍會受到配置、用量、地區及 billing 詳情影響。43031

Google 另外引用客戶 OffDeal 的說法，指冷啟動減少 88%。這是客戶自行報告的結果，並非 Google 對所有部署作出的效能保證，亦唔等同獨立 benchmark。4

點解 AI agent 需要另一套基礎設施？

傳統雲端應用程式通常將無狀態的請求處理，交畀可以按流量伸縮的運算服務；需要長期保存的資料，就交畀資料庫。但 AI agent 令這種分工變得複雜：它可能需要持久身份及 endpoint、記憶或狀態、長時間背景執行，以及存取工具和營運資料。

Google Cloud 8月的更新，正好從兩邊處理這些要求：

1. 資料層變得更加自主。 Onboarding Agent 協助揀選及配置託管資料庫；Observability Agent 就負責監察整個資料庫環境、調查故障，並可喺獲得批准後執行修正。2
2. 運算層加入持續運行選項。 Cloud Run instances 為唔適合 scale-to-zero、需要一個固定及單一運行環境的 agent，提供穩定的 runtime。4

這亦同 Google Cloud 所講的 Agentic Data Cloud 方向一致：將資料、AI 模型及營運資料庫連成一個可供 agent 採取行動的系統。11 值得留意的是，Google 雖然嘗試將更多運維流程自動化，但對可能影響生產環境的資料庫變更，仍然保留人手批准這道關卡。2

實際上應該點揀？

這兩項更新唔係一個包辦所有事情的「萬能 AI agent 平台」，而係針對兩個具體痛點提供工具：

• 如果問題係資料庫選型、配置、整個資料庫群組的可見度，或者故障排解，可以考慮 Database Operations Agents。
• 如果 agent 需要一個固定網址、單一而持續的運行環境，而且唔適合一般 serverless service 的 scale-to-zero 模式，可以考慮 Cloud Run instances。

兩者目前都帶有預覽性質。團隊在投入生產環境之前，應先核實可用地區、支援的配置、權限要求、收費方式，以及自動修復功能的實際限制。

方向就相當清楚：Google Cloud 正將 AI agent 視為一類同傳統網站不同的工作負載——它們需要更自主的營運能力，亦需要更持久、更穩定的基礎設施。