Google Cloud 以資料庫代理及持久化 Cloud Run，補上 AI Agent 基建兩大缺口

Google Cloud 8月公布兩項針對 AI Agent 基建的更新，正面處理兩個常見難題：資料庫設定及故障排查往往要靠專家逐項處理，而需要長時間運行的 Agent 又不適合使用一有空檔便自動縮減至零的典型 serverless 模式。

這次推出的 Database Operations Agents 針對資料層，Cloud Run instances 就針對執行層。前者利用 Gemini Cloud Assist 協助資料庫選擇、部署、監察和維護；後者則提供專用、單例（singleton）的持久化運行環境，讓個人 AI Agent 等長時間工作負載保持在線。231

兩項更新，各自解決不同問題

Database Operations Agents 主要處理資料庫的生命週期管理，包括由零開始設定資料庫，以及日常監察、診斷和維護。23

Cloud Run instances 則提供一個不會自動縮減至零的執行個體，適合需要長時間運作程序、穩定端點或持續互動的工作負載，例如個人 AI Agent。1

兩者並非互相替代：持久化的運行環境不會自動令記憶體內資料永久保存，而資料庫自動化功能本身亦不會提供一個長期在線的 Agent 執行位置。對建構 Agent 的團隊來說，兩項服務是互補而非二選一。

Database Operations Agents 可以做甚麼？

Google 將這兩個代理納入其 Agentic Data Cloud 策略：

• Database Onboarding Agent： 處理 Day 0 工作，包括選擇資料庫、設定、配置及首次部署。
• Database Observability Agent： 處理 Day 1 及 Day 2 工作，包括監察、故障排查和持續維護。23

簡單講，團隊可以由逐項撰寫 provisioning script、配置步驟、監察查詢及診斷流程，轉向以自然語言描述需求，再由代理引導操作。這有望減少資料庫管理員、開發者、SRE 及 DevOps 團隊的重複性工作，同時保留人手審批關鍵變更的控制點。

支援哪些資料庫？

Google 表示，Onboarding Agent 支援包括 AlloyDB、Bigtable、Cloud SQL 及 Spanner 在內的 Google Cloud 託管資料庫服務。29

不過，相關功能並非全面公開。Google 的公告把 onboarding 和 observability 能力列為預覽功能，而部分 Observability Agent 功能只向特定客戶及指定資料庫服務提供。2934

Observability Agent 如何找出問題？

Observability Agent 的重點不只是查看單一指標，而是把多種運行訊號串連起來。它可以參考 Database Insights、Cloud Monitoring、Cloud Logging 及 Cloud Trace 等來源，協助找出查詢熱點、延遲上升、鎖競爭及資源壓力等問題的可能成因。23

之後，代理會解釋推測的根本原因，提出修改方案，並交代理由及預期影響。對於支援的操作，系統會先要求用戶批准，才會真正執行。公告列出的例子包括啟用 Cloud SQL connection pooling，以及新增索引。2344

這個審批關口對生產環境尤其重要。看似局部的資料庫優化，可能牽涉成本、延遲、鎖定情況，甚至改變應用程式行為；由代理提出建議可以加快排查，但不代表應該完全跳過工程審核。

可在哪些介面使用？

Google 把這些能力放進團隊原本進行雲端操作的地方，包括 Gemini Cloud Assist 對話介面、Google Cloud Console 內相關資料庫頁面、Database Center fleet 視圖、命令列、IDE 及第三方工具。23

Database Insights 和 Database Center 的功能亦可以透過支援 MCP 的介面使用。Google 的託管 MCP server 在 Google Cloud 運行，用戶毋須自行部署 MCP server，Gemini 及其他 MCP client 便可連接資料庫和基建能力。36

這代表外部開發工具或其他運維 Agent，可以透過標準化工具介面取得資料庫清單、資料庫指標或偵測到的問題，而不必只依賴圖形化 Console。對多 Agent 工作流程而言，這種接駁方式可以減少各工具之間的「各自為政」。

Cloud Run instances 為 AI Agent 帶來甚麼？

Cloud Run instances 是專用的單例 Cloud Run 運行環境。與一般 Cloud Run service 不同，每個 instance 只運行一份工作負載，不會自動擴展，也不會縮減至零。Google 以預覽形式推出這項能力，對象包括個人 AI Agent 及其他長時間運行、通常面向單一用戶的工作負載。1

每個 instance 最長可以連續運行 7日，預設配置自動重啟策略。用戶也可以在不需要時停止 instance，之後再恢復使用。每個 instance 都會獲分配一個 HTTPS URL，而且在更新及重啟後維持不變。1

對比由請求驅動的 serverless 部署，這種模式主要有幾個分別：

• 不會因縮減至零而中斷： 程序會持續存在，不會每次新請求都重新啟動。
• 單例執行： 工作負載只運行一份專用副本，不會因自動擴展而複製多個 instance。
• 網址穩定： 更新或重啟後，HTTPS endpoint 不會改變。
• 毋須管理虛擬機： 開發者可以取得持久化程序模型，同時不用自行處理虛擬機作業系統、Firewall 或 HTTPS endpoint 設定。1

Google 將它定位為部分工作負載的虛擬機替代方案，而不是全面取代 VM 或具自動擴展能力的 Cloud Run service。

$5.70 的代價與冷啟動取捨

Google 表示，持續運行一個配備 1 個 shared vCPU 及 1 GiB 記憶體的 Cloud Run instance，費用為每 30 日 5.70 美元。服務亦使用 burst budget 應付偶爾的運算高峰，開發者不必按最高峰值長期配置資源。1

持續執行有助減少 cold start。Google 引述一名早期用戶表示，其長時間運行的 Agent 冷啟動次數減少 88%；不過，這是個別客戶結果，並非普遍適用的效能保證。1

因此，5.70 美元應理解為指定配置下的價格例子，而不是所有部署的完整預算。實際成本仍可能包括額外運算資源、網絡、儲存或相關服務費用。

最容易誤會的一點：持久化運行不等於永久記憶

Cloud Run instance 可以令程序保持運行，但如果資料只放在記憶體內，並不代表它能在每次重啟、停止或運行期限結束後繼續存在。Google 的架構指引區分了記憶體內 session state 和外部狀態管理：應用程式重啟後，記憶體內的對話紀錄會消失；需要可靠性及擴展能力的生產系統，則應使用外部狀態管理。19

對生產環境的 Agent 來說，session、工作流程進度及其他需要保存的資料，通常要寫入資料庫或其他持久化系統。Google 關於長時間運行 Agent 的指引亦提到資料庫支援的 session 儲存，並以生產環境使用 Cloud SQL 作為例子。21

所以，「stateful」在這裏主要是指持久化的執行模式，而不是 Cloud Run 自動提供永久記憶。若 Agent 要在重啟後繼續未完成工作，或要保存超出 instance 壽命的上下文，仍然需要可靠的外部儲存。

Google Cloud 的 Agent 基建方向

把兩項更新放在一起看，可以看到 Google Cloud 正同時處理 Agent 系統的兩邊：

1. 運行 Agent： Cloud Run instances 為專用、長時間運行的程序及穩定端點提供較輕量的選項。1
2. 管理資料層： Database Operations Agents 自動化部分資料庫配置、監察、診斷及經批准的修復工作。23
3. 跨環境連接工具： MCP 整合讓 IDE、CLI、第三方工具及其他 Agent 使用資料庫能力。36
4. 在高風險操作保留人手： Observability Agent 可以提出修正建議，但支援的修復操作仍須用戶批准。23

實際效果不是建立一套完全自主、可以取代工程判斷的基建，而是提供一批託管元件，減少日常運維工夫。架構設計、權限控制、持久化狀態及生產環境變更治理，仍然是團隊需要自行負責的部分。

對於建構個人助理、非同步工作流程或多輪互動 Agent 的團隊，Cloud Run instances 解決的是運行連續性；對於管理這些 Agent 所依賴資料庫的團隊，Database Operations Agents 則減少設定系統、了解健康狀況及處理問題的重複工作。Google 的方向相當清晰：透過自然語言、遙測資料和標準化工具介面，讓 Agent 更容易使用運算及資料庫運維能力。