Google Cloud 8 月 AI 基礎設施更新：資料庫代理與持久化 Cloud Run 執行個體登場

Google Cloud 今年 8 月的更新，瞄準 AI 代理基礎設施中兩個反覆出現的難題：資料庫仍需要專業人員負責部署、監控與除錯；而長時間運作的代理，也需要一個不會在沒有請求時立刻縮減至零的執行環境。Google 因此推出 Database Operations Agents，以及預覽版 Cloud Run instances，分別處理資料層與執行層的問題。231

兩項產品，解決不同的基礎設施痛點

Database Operations Agents 著重資料庫管理。它們透過 Gemini Cloud Assist，以自然語言引導使用者完成資料庫選擇、佈建、監控、診斷與維護等工作流程。23

Cloud Run instances 則著重代理的執行環境，為個人 AI 代理等需要持續可用程序、固定端點或長時間互動的工作負載，提供單例且持久的執行個體。1

兩者並非互相替代：持久化執行環境不代表代理的資料會自動永久保存；資料庫自動化功能也不會單獨提供一個永遠在線的代理執行位置。對於完整的 AI 代理系統而言，這兩項更新是互補的基礎元件。

Database Operations Agents 能做什麼？

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

• Database Onboarding Agent： 負責 Day 0 工作，包括資料庫選擇、設定、組態與初始部署。
• Database Observability Agent： 負責 Day 1 與 Day 2 維運，包括監控、疑難排解與持續維護。23

其核心概念，是把原本需要人工拼湊的佈建腳本、組態步驟、監控查詢與診斷流程，轉化為由自然語言引導的操作。這有機會減少資料庫管理員、開發人員、網站可靠性工程師（SRE）與 DevOps 團隊的重複性工作，同時在涉及生產環境的變更時保留人工審核環節。

支援哪些資料庫服務？

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

不過，這些資料庫代理並非全面開放。Google 的公告將 onboarding 與 observability 功能列為預覽版，其中部分 Observability Agent 功能僅提供給特定客戶及特定資料庫服務使用。2934

Observability Agent 如何調查問題？

Observability Agent 的設計重點，不是只查看單一資料庫指標，而是將多種營運訊號交叉比對。調查過程可參考 Database Insights、Cloud Monitoring、Cloud Logging 與 Cloud Trace 等來源，用來找出查詢熱點、延遲上升、鎖定競爭與資源壓力等問題的可能原因。23

完成分析後，代理可以說明疑似根因、提出修改建議，並交代理由與預期影響。對於支援的操作，系統會要求使用者核准後才執行；公告列舉的例子包括啟用 Cloud SQL 連線池，以及新增索引。2344

這道核准關卡對生產環境尤其重要。資料庫變更看似只是局部最佳化，卻可能影響成本、延遲、鎖定行為或應用程式運作，因此由代理提出建議、由人員決定是否執行，能建立必要的風險邊界。

可以從哪些介面使用？

Google 將相關能力整合到雲端團隊原本使用的操作位置，包括 Gemini Cloud Assist 聊天介面、Google Cloud 控制台中的資料庫頁面、Database Center 資料庫機群檢視、命令列工具、IDE 與第三方工具。23

Database Insights 與 Database Center 的功能也可透過相容 MCP 的介面提供。Google 的託管 MCP 伺服器讓 Gemini 與其他 MCP 用戶端連接資料庫及基礎設施功能，而使用者不需要自行部署 MCP 伺服器。36

這使資料庫代理更容易成為大型代理工作流程的工具元件：外部開發工具或維運代理，可以透過標準化工具介面取得資料庫機群清單、資料庫指標或已偵測到的問題，不必只依賴圖形化控制台。

Cloud Run instances 為 AI 代理帶來什麼？

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

每個執行個體最長可連續運作 7 天，預設設定自動重新啟動策略。使用者也可以在不需要時停止執行個體，之後再恢復使用；每個執行個體都會取得一個在更新與重新啟動後仍維持不變的 HTTPS 網址。1

這些特性針對傳統請求驅動、可能縮減至零的無伺服器部署，解決了幾個常見問題：

• 不會因縮減至零而中斷： 程序可持續在線，不會在請求之間消失。
• 單例執行： 工作負載以一個專用副本運作，而不是由自動擴展機制複製多份。
• 固定網址： 執行個體重新啟動或更新時，HTTPS 端點不會改變。
• 託管式基礎設施： 開發人員可以取得持久程序模型，卻不必自行管理虛擬機器的客作業系統、防火牆規則或 HTTPS 端點設定。1

Google 將這項功能定位為部分工作負載持續使用虛擬機器的替代方案，但並不是虛擬機器或具備自動擴展能力的 Cloud Run service 的全面替代品。

價格與冷啟動取捨

Google 表示，若 Cloud Run instance 持續運作，配置 1 個共用 vCPU 與 1 GiB 記憶體，連續 30 天的費用為 5.70 美元。這項服務也使用 burst budget 應付偶發的計算尖峰，讓開發人員不必為每一次峰值都預留完整的運算規模。1

持續執行也可能降低冷啟動的影響。一名早期用戶表示，其長時間運作的代理冷啟動次數減少 88%；但這是個別客戶結果，不能視為普遍適用的效能保證。1

因此，5.70 美元應理解為特定配置的官方價格示例，而不是每種部署的完整成本估算。實際支出仍可能包括額外的運算資源、網路、儲存空間或相關服務費用。

關鍵限制：持久化執行不等於永久記憶

Cloud Run instance 可以讓程序保持運作，但只存放在記憶體中的資料，並不保證能在所有重新啟動、停止或執行期限結束後保留。Google 的架構指南區分了記憶體內工作階段狀態與外部狀態：應用程式重新啟動時，記憶體中的對話紀錄會遺失；需要可靠性與擴充性的生產系統，則應採用外部狀態管理。19

對生產環境的代理而言，這通常代表要把工作階段、工作流程進度及其他需要長期保存的狀態，寫入資料庫或其他持久化系統。Google 對長時間運作代理的指引，也提到以資料庫保存工作階段，例如在生產情境使用 Cloud SQL。21

因此，「有狀態」在這裡指的是 Cloud Run 提供了一種有狀態的執行模型，而不是讓代理不再需要持久化儲存。若代理必須在重新啟動後恢復未完成工作，或在執行個體生命週期結束後保留上下文，外部資料儲存仍不可或缺。

Google 這次更新透露的代理基礎設施方向

合併來看，Google Cloud 正同時處理 AI 代理系統的兩端：

1. 執行代理： Cloud Run instances 為專用、長時間運作的程序與固定端點，提供較低管理負擔的選項。1
2. 維運資料層： Database Operations Agents 自動化部分佈建、可觀測性、診斷與經使用者核准的修復工作。23
3. 跨環境連接工具： MCP 整合把資料庫能力延伸至外部用戶端、IDE、CLI 與其他代理。36
4. 在高風險操作保留人工參與： Observability Agent 可以提出變更建議，但支援的修復操作仍需取得使用者核准。23

實際結果並不是一套能完全消除工程判斷的全自動基礎設施，而是一組由 Google 託管的原語，協助團隊降低日常維運負擔；系統架構、權限設定、持久化狀態與生產變更治理，仍然是工程團隊必須負責的設計工作。

對於打造個人助理、非同步工作流程或多輪互動代理的團隊，Cloud Run instances 解決的是執行連續性的問題；對於管理這些代理所依賴資料庫的團隊，Database Operations Agents 則降低了系統設定、健康狀態判讀與問題回應的重複工作。更廣泛的方向已相當明確：Google 正透過自然語言、遙測資料與標準化工具介面，讓代理更容易參與雲端運算與資料庫維運。