Google Cloud 8月一口氣補上 AI agent 基建的兩個關鍵部分：一邊是令數據庫更容易開通、監察及維護的 Database Operations Agents；另一邊是讓個別 AI agent 可以長時間運行的 Cloud Run instances。前者將 Google 的 Agentic Data Cloud 由數據層推向日常營運，後者則針對傳統 serverless 平台未必擅長處理的持久程序和單一使用者工作負載。78

Database Operations Agents：由開通到排錯都可用自然語言處理

整套、整合 Gemini Cloud Assist 的方案，主要包括兩個代理：

• Database Onboarding Agent：負責 Day 0 工作，即選擇數據庫、建立資源、完成配置及初次部署。
• Database Observability Agent：負責 Day 1 及 Day 2 工作，包括持續監察、故障排查、效能分析及後續維護。8

Google 的方向，是將以往要靠 DBA、開發者、SRE 或 DevOps 人員反覆處理的架構規劃、腳本、資源配置、schema／index 設定、查詢調校及診斷工作，改為由 agent 以自然語言引導完成，減少大量重複的操作工夫。8

Onboarding Agent 支援哪些數據庫？

使用者可以用自然語言描述需求，讓 Onboarding Agent 引導數據庫 provisioning 及初始配置。現時支援的 Google Cloud 託管數據庫包括 AlloyDB、Bigtable、Cloud SQL 及 Spanner。8

Observability Agent 如何找出問題？

Observability Agent 會整合多個遙測來源，包括 Database Insights、Cloud Monitoring、Cloud Logging 及 Cloud Trace，再將不同訊號串連起來，協助找出問題根源，例如延遲突然上升、熱門查詢造成瓶頸、鎖競爭或資源不足。8

它不只會「報告有問題」，還會提出經驗驗證過的修改建議，交代建議原因及預期影響。經使用者批准後，代理可執行部分支援的修復，例如為 Cloud SQL 啟用 connection pooling 或新增索引。部分調查及修復功能當時仍只向指定客戶提供預覽版本。8

不用局限於單一介面

這些功能可在 Gemini Cloud Assist 對話介面、Google Cloud Console 內相關數據庫頁面、Database Center fleet 檢視、CLI、IDE 及第三方工具中使用。8

另外，Database Insights 和 Database Center 的能力亦可透過 Google Remote MCP servers 以 MCP 工具形式提供，讓外部開發工具及兼容 MCP 的 agent 取得系統及查詢指標、數據庫 fleet 清單，以及已偵測到的問題。8

Cloud Run instances：讓單一 AI agent 長時間「住」在雲端

Google Cloud 於8月27日預覽推出 Cloud Run instances，定位是 Cloud Run 上的專用 singleton compute runtime，即每個 instance 只運行一份程序，適合個人 AI agent 等長時間、具狀態、通常由單一使用者使用的工作負載。9

它與一般 Cloud Run service 有幾項明顯分別：

• 只運行一個 instance，不會自動擴展，也不會 scale to zero；
• 配合預設自動重啟政策，最長可連續運行 7 日；
• 每個 instance 都有固定的 HTTPS URL，更新及重啟後網址不變；
• 不使用時可以停止，之後再恢復運行。9

簡單講，Google 想提供一個介乎傳統 VM 和一般 serverless service 之間的選擇。相比長期運行的 VM，Cloud Run instances 可免卻作業系統維護，以及自行處理防火牆和 HTTPS endpoint 設定；相比會按需求啟動、閒置時歸零的 serverless service，它則保留較持久的程序模型。9

Google 指出，以 1 個 shared vCPU 及 1 GiB 記憶體連續運行 30 日計，價格為 5.70 美元。設計上亦可利用 burst budget 應付偶爾出現的運算高峰，而毋須一直按照最壞情況為 VM 配置及付費。9

持續運行亦有助減少 cold start 影響。一名早期使用者表示，其長時間運行的 agent cold start 次數減少了 88%；不過這是個別客戶分享，並非 Google 對所有工作負載作出的普遍效能保證。9

兩項發布對 AI agent 有甚麼意義？

AI agent 要真正投入生產環境，通常同時需要兩樣東西：一個成本合理、可以維持長時間互動及處理非同步工作的運行環境，以及一套容易管理、能夠及早發現問題的數據層。

Cloud Run instances 針對的是前者，適合需要編排非同步工作、支援多輪互動，或不希望每次請求都重新啟動程序的 agent。Database Operations Agents 則處理後者，令數據庫的開通、健康監察及部分修復流程可以用自然語言和 MCP 兼容工具完成。18

但要留意，「stateful」runtime 不代表 agent 的狀態會永久保存。若 agent 需要在程序重啟後保留對話紀錄、工作進度或 session，仍要將狀態放到外部持久化儲存。Google 的相關建議亦提到，生產環境可使用 Cloud SQL 等持久化 session storage。5

Google Cloud 8月一口氣補上 AI agent 基建的兩個關鍵部分：一邊是令數據庫更容易開通、監察及維護的 Database Operations Agents；另一邊是讓個別 AI agent 可以長時間運行的 Cloud Run instances。前者將 Google 的 Agentic Data Cloud 由數據層推向日常營運，後者則針對傳統 serverless 平台未必擅長處理的持久程序和單一使用者工作負載。78

Database Operations Agents：由開通到排錯都可用自然語言處理

整套、整合 Gemini Cloud Assist 的方案，主要包括兩個代理：

• Database Onboarding Agent：負責 Day 0 工作，即選擇數據庫、建立資源、完成配置及初次部署。
• Database Observability Agent：負責 Day 1 及 Day 2 工作，包括持續監察、故障排查、效能分析及後續維護。8

Google 的方向，是將以往要靠 DBA、開發者、SRE 或 DevOps 人員反覆處理的架構規劃、腳本、資源配置、schema／index 設定、查詢調校及診斷工作，改為由 agent 以自然語言引導完成，減少大量重複的操作工夫。8

Onboarding Agent 支援哪些數據庫？

使用者可以用自然語言描述需求，讓 Onboarding Agent 引導數據庫 provisioning 及初始配置。現時支援的 Google Cloud 託管數據庫包括 AlloyDB、Bigtable、Cloud SQL 及 Spanner。8

Observability Agent 如何找出問題？

Observability Agent 會整合多個遙測來源，包括 Database Insights、Cloud Monitoring、Cloud Logging 及 Cloud Trace，再將不同訊號串連起來，協助找出問題根源，例如延遲突然上升、熱門查詢造成瓶頸、鎖競爭或資源不足。8

它不只會「報告有問題」，還會提出經驗驗證過的修改建議，交代建議原因及預期影響。經使用者批准後，代理可執行部分支援的修復，例如為 Cloud SQL 啟用 connection pooling 或新增索引。部分調查及修復功能當時仍只向指定客戶提供預覽版本。8

不用局限於單一介面

這些功能可在 Gemini Cloud Assist 對話介面、Google Cloud Console 內相關數據庫頁面、Database Center fleet 檢視、CLI、IDE 及第三方工具中使用。8

另外，Database Insights 和 Database Center 的能力亦可透過 Google Remote MCP servers 以 MCP 工具形式提供，讓外部開發工具及兼容 MCP 的 agent 取得系統及查詢指標、數據庫 fleet 清單，以及已偵測到的問題。8

Cloud Run instances：讓單一 AI agent 長時間「住」在雲端

Google Cloud 於8月27日預覽推出 Cloud Run instances，定位是 Cloud Run 上的專用 singleton compute runtime，即每個 instance 只運行一份程序，適合個人 AI agent 等長時間、具狀態、通常由單一使用者使用的工作負載。9

它與一般 Cloud Run service 有幾項明顯分別：

• 只運行一個 instance，不會自動擴展，也不會 scale to zero；
• 配合預設自動重啟政策，最長可連續運行 7 日；
• 每個 instance 都有固定的 HTTPS URL，更新及重啟後網址不變；
• 不使用時可以停止，之後再恢復運行。9

簡單講，Google 想提供一個介乎傳統 VM 和一般 serverless service 之間的選擇。相比長期運行的 VM，Cloud Run instances 可免卻作業系統維護，以及自行處理防火牆和 HTTPS endpoint 設定；相比會按需求啟動、閒置時歸零的 serverless service，它則保留較持久的程序模型。9

Google 指出，以 1 個 shared vCPU 及 1 GiB 記憶體連續運行 30 日計，價格為 5.70 美元。設計上亦可利用 burst budget 應付偶爾出現的運算高峰，而毋須一直按照最壞情況為 VM 配置及付費。9

持續運行亦有助減少 cold start 影響。一名早期使用者表示，其長時間運行的 agent cold start 次數減少了 88%；不過這是個別客戶分享，並非 Google 對所有工作負載作出的普遍效能保證。9

兩項發布對 AI agent 有甚麼意義？

AI agent 要真正投入生產環境，通常同時需要兩樣東西：一個成本合理、可以維持長時間互動及處理非同步工作的運行環境，以及一套容易管理、能夠及早發現問題的數據層。

Cloud Run instances 針對的是前者，適合需要編排非同步工作、支援多輪互動，或不希望每次請求都重新啟動程序的 agent。Database Operations Agents 則處理後者，令數據庫的開通、健康監察及部分修復流程可以用自然語言和 MCP 兼容工具完成。18

但要留意，「stateful」runtime 不代表 agent 的狀態會永久保存。若 agent 需要在程序重啟後保留對話紀錄、工作進度或 session，仍要將狀態放到外部持久化儲存。Google 的相關建議亦提到，生產環境可使用 Cloud SQL 等持久化 session storage。5