Google Cloud 8月加码 AI 基础设施：数据库代理与持久化 Cloud Run 实例登场

Google Cloud 在2026年8月发布的两项能力，瞄准了 AI 代理基础设施中两个反复出现的难题：数据库的选型、配置和故障排查仍然需要专业人员介入；而长期运行的 AI 代理，又需要一个不会在请求结束后立即缩容到零的运行环境。为此，Google 推出了 Database Operations Agents，以及预览版 Cloud Run 实例。 231

两项发布，分别解决数据层与运行层问题

Database Operations Agents 面向数据层。它们借助 Gemini Cloud Assist，通过自然语言引导数据库选型、配置、监控、诊断和维护。 23

Cloud Run 实例面向执行层，为个人 AI 代理等需要持续运行进程、固定访问地址或长期交互的工作负载提供专属运行时。 1

两者并不能相互替代：持久化运行时不会自动让代理数据具备长期存储能力，数据库自动化也不会为始终在线的代理提供运行环境。更准确地说，Google 的这两项发布是互补关系。

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 支持包括 AlloyDB、Bigtable、Cloud SQL 和 Spanner 在内的 Google Cloud 托管数据库服务。 29

不过，这些数据库代理并非全面开放。Google 的公告将数据库接入和可观测性能力描述为预览功能，其中部分 Observability Agent 能力目前仅面向特定客户和数据库服务开放。 2934

Observability Agent 如何排查问题

Observability Agent 的设计重点，不是孤立地查看某一项数据库指标，而是关联多个运维信号。它可以结合 Database Insights、Cloud Monitoring、Cloud Logging 和 Cloud Trace 等信息，分析查询热点、延迟上升、锁竞争和资源压力等问题，并寻找可能的根因。 23

随后，代理会解释疑似原因，提出调整方案，并说明操作依据及预期影响。对于支持的修复动作，系统会在执行前要求用户批准。Google 在发布说明中列举的操作包括启用 Cloud SQL 连接池和添加索引。 2344

这一审批机制对生产环境十分关键。数据库变更看似只是局部优化，却可能影响成本、延迟、锁行为甚至应用逻辑，因此自动化诊断与自动执行之间需要保留清晰的审核边界。

可从哪些入口使用

Google 将这些能力分布到云运维团队已经使用的多个入口，包括 Gemini Cloud Assist 聊天界面、Google Cloud 控制台中的数据库页面、Database Center 资产视图、命令行、IDE 和第三方工具。 23

Database Insights 和 Database Center 的部分能力还可以通过兼容 MCP 的接口使用。Google 的托管 MCP 服务器运行在 Google Cloud 中，目标是让 Gemini 及其他 MCP 客户端连接数据库和基础设施能力，而无需用户自行部署 MCP 服务器。 36

这意味着，数据库代理可以成为更大规模代理工作流的基础组件：外部开发工具或运维代理能够通过标准化工具接口获取数据库资产清单、指标和已发现问题，而不必完全依赖图形化控制台。

Cloud Run 实例为 AI 代理增加了什么

Cloud Run 实例是专属的单例 Cloud Run 运行时。与传统 Cloud Run 服务不同，它只运行一个副本，不进行自动扩缩容，也不会缩容到零。Google 目前以预览形式推出该能力，目标场景包括个人 AI 代理及其他长期运行、通常面向单一用户的工作负载。 1

每个实例最多可连续运行7天，默认配置自动重启策略。用户也可以在不需要时停止实例，之后再恢复运行。每个实例都会获得一个 HTTPS 地址，并且该地址在更新和重启后保持不变。 1

这些特性针对的是请求驱动型无服务器部署中的几个常见问题：

• 不会因缩容到零而中断： 进程可以持续存在，不必在每次新请求到来时重新启动。
• 单例执行： 工作负载以一个专属副本运行，而不是被自动扩容为多个实例。
• 地址稳定： 实例更新或重启后，HTTPS 端点不会改变。
• 基础设施托管： 开发者无需像管理虚拟机那样维护来宾操作系统、防火墙规则和 HTTPS 端点，但仍能获得持续运行的进程模型。 1

Google 将其定位为部分工作负载的虚拟机替代方案，而不是所有场景下取代虚拟机或具备自动扩缩容能力的 Cloud Run 服务。

价格与冷启动取舍

Google 表示，配置为 1个共享 vCPU 和1 GiB 内存 的 Cloud Run 实例，连续运行30天的费用为 5.70美元。该产品还提供突发计算预算，让开发者可以应对偶发峰值，而不必始终按照最高峰值为运行时配置资源。 1

持续运行也有助于减少冷启动。一位早期用户表示，其长期运行代理的冷启动次数减少了88%；但这属于客户反馈，并不是 Google 对所有工作负载作出的性能保证。 1

因此，5.70美元应理解为特定配置下的官方示例，而不是所有部署的完整成本估算。实际费用还可能包括额外的计算资源、网络、存储及相关服务费用。

需要注意：持续运行不等于持久化记忆

Cloud Run 实例能够让进程保持运行，但不能保证仅存放在内存中的数据在每次重启、停止或运行时到期后都能保留。Google 的架构指南区分了内存中的会话状态与外部状态管理：应用重启后，内存中的对话历史会丢失；需要可靠性和可扩展性的生产系统，则应使用外部状态管理。 19

对于生产级 AI 代理，这通常意味着要把会话、工作流进度和其他需要长期保留的数据写入数据库或其他持久化系统。Google 关于长期运行代理的指导也提到，在生产场景中可以使用数据库支持的会话存储，例如 Cloud SQL。 21

所以，“有状态”更准确地描述的是 Cloud Run 实例的执行模型：它在有限的运行周期内保持一个持续进程，但并没有消除代理对持久化存储的需求。只要代理需要在重启后恢复未完成工作，或在实例生命周期结束后保留上下文，外部数据存储仍不可或缺。

Google Cloud 的整体思路：同时覆盖代理的运行与数据

把两项发布放在一起看，可以看到 Google Cloud 正在同时覆盖 AI 代理系统的两端：

1. 运行代理： Cloud Run 实例为专属、长期运行的进程和稳定端点提供了较低运维负担的选择。 1
2. 管理数据层： Database Operations Agents 自动化数据库配置、可观测性、诊断和经批准的修复操作。 23
3. 连接不同环境中的工具： MCP 集成将数据库能力扩展到外部客户端、IDE、CLI 和其他代理。 36
4. 在高风险环节保留人工参与： Observability Agent 可以提出变更建议，而支持的修复动作需要用户批准。 23

这并不意味着 Google 已经提供了一套可以完全取代工程判断的自主基础设施。更实际的变化是：这些托管能力减少了运维消耗，把架构设计、权限控制、持久化状态以及生产变更治理继续留给工程团队负责。

对于构建个人助手、异步工作流或多轮交互代理的团队，Cloud Run 实例主要解决运行连续性问题；对于维护这些代理所依赖数据库的团队，Database Operations Agents 则减少了系统配置、健康分析和故障响应中的重复工作。整体方向已经十分明确：Google 正通过自然语言、遥测数据和标准化工具接口，让 AI 代理更容易参与计算与数据运维。