数据库运维正在从“给人提供更多监控面板”转向“让智能体理解上下文并协助执行操作”。在 Agentic Data Cloud 发布中，Google Cloud 公布了两个面向数据库生命周期的 AI 智能体：Database Onboarding Agent 负责 Day 0 阶段的选型、配置与初始部署，Database Observability Agent 则覆盖 Day 1 和 Day 2 的监控、故障诊断及持续维护。
这两个智能体的重点并不只是生成一段建议，而是把数据库库存、指标、日志、调用链和查询数据放进同一条分析链路，并通过 Cloud 控制台、Chat、CLI、MCP Server 与 IDE 等入口接入现有工作流。
两个智能体，覆盖两类高成本决策
传统数据库管理的复杂性集中在两个阶段。
系统上线前，团队需要在 Cloud SQL、Spanner、AlloyDB、Bigtable 等服务之间做选择，同时评估数据模型、IOPS、延迟、扩展方式、高可用和复制延迟。选错数据库或初始配置不合理，短期内可能看不出问题，却会在业务增长后形成昂贵的迁移成本。
系统上线后，问题则变成持续观察和定位：CPU 为什么突然升高？写延迟来自热点、锁竞争，还是下游资源限制？某次发布是否引入了慢查询？这类调查往往需要人工切换多个工具，再按时间线拼接指标、日志和 Trace。
Database Onboarding Agent 与 Database Observability Agent 分别处理这两组问题：
- Onboarding Agent：理解工作负载、数据类型、性能、规模与可靠性要求，推荐合适的托管数据库，并在确认服务后生成配置和部署命令。
- Observability Agent：关联 Database Insights、Cloud Monitoring、Cloud Logging、Cloud Trace 等遥测数据，生成根因分析和修复建议。
- 人工审批边界：对于增加索引、启用连接池等变更，智能体可以说明理由和预期影响；执行经过验证的修复操作仍需用户批准。
这里最重要的边界是：智能体适合缩短信息收集和假设验证过程，但数据库变更仍然需要权限控制、变更审查、回滚方案和效果验证。
从告警跳转升级为跨信号调查
传统告警通常只能回答“哪个指标超过了阈值”。Observability Agent 试图继续回答三个更有价值的问题：
- 异常影响了哪些实例、查询或应用请求？
- 指标、日志、数据库等待事件与调用链之间是否存在时间相关性？
- 哪个修复动作最可能有效，它的风险和预期影响是什么？
例如，面对 Cloud SQL CPU 持续升高，调查不应止于 CPU 曲线。智能体还可以检查高负载查询、连接数、缺失索引、锁等待以及应用 Trace。如果原因是大量短连接造成的额外开销，它可能建议启用连接池；如果瓶颈来自全表扫描，则可能给出索引建议。
它也支持舰队级问题，例如查询过去七天 CPU 消耗最高的数据库。对管理大量实例的 SRE 或 DBA 来说，这比逐个打开监控页更接近真实工作方式。
部分能力需要注意可用性边界：跨遥测的产品内调查和可执行修复仍处于面向部分客户的预览阶段，不能默认所有项目、区域和数据库引擎都已开放。
可以这样实践：先建立只读数据库快照
在接入智能体之前，团队可以先用 gcloud 建立一个可重复执行的数据库库存采集脚本。下面示例只读取 Cloud SQL 实例和基础配置，不执行变更。
运行前需要安装 Google Cloud CLI，并把 PROJECT_ID 替换为目标项目：
#!/usr/bin/env bash
set -euo pipefail
PROJECT_ID="your-project-id"
gcloud auth application-default login
gcloud config set project "$PROJECT_ID"
echo "Cloud SQL fleet inventory"
gcloud sql instances list \
--project="$PROJECT_ID" \
--format="table(name,databaseVersion,region,state,settings.tier,settings.availabilityType)"
echo
echo "Detailed JSON snapshot"
gcloud sql instances list \
--project="$PROJECT_ID" \
--format=json > cloud-sql-inventory.json
printf 'Snapshot written to %s\n' "cloud-sql-inventory.json"
这份 JSON 可以作为人工调查、变更评审或智能体上下文的一部分。不要把数据库密码、连接字符串或业务数据直接拼进提示词；优先通过受控工具暴露必要的指标和元数据。
对于 Onboarding Agent，可以使用结构化提示词，减少模型自行补全关键条件的空间：
请为以下工作负载推荐 Google Cloud 托管数据库，但先列出缺失信息，不要直接生成部署命令。
应用：多租户订单服务
数据模型：关系型，事务需要强一致性
峰值流量：8,000 次写入/秒，25,000 次读取/秒
延迟目标：P99 读取低于 50 ms
数据规模：当前 2 TB，预计每年增长 80%
可用性：跨可用区，RPO 小于 5 分钟，RTO 小于 30 分钟
运维约束：团队熟悉 PostgreSQL，希望尽量减少应用改造
输出：
1. 推荐服务及两个备选方案
2. 每个方案不满足要求的风险
3. 需要验证的容量与成本假设
4. 仅生成只读检查命令，部署命令等待人工确认
这种提示方式要求智能体显式暴露假设，并把“推荐”和“执行”拆成两个步骤。接入 Database Insights MCP Server 或 Database Center MCP Server 后，IDE 中的智能体还可以通过受控工具读取系统指标、查询指标、实例库存和已知问题，而不必依赖开发者手工粘贴大量上下文。
支持范围与落地顺序
相关能力覆盖 AlloyDB、Bigtable、Cloud SQL、Firestore、Memorystore 和 Spanner 等服务，其中 Cloud SQL 包括 PostgreSQL、MySQL 与 SQL Server。不同引擎的典型调查目标并不相同：Spanner 常见重点是读写延迟、热点与锁竞争，AlloyDB 需要关注实例负载、查询性能和副本延迟，Bigtable 则更关注读写延迟及访问模式。
实际采用时，可以按风险由低到高推进：
- 先开放数据库库存、指标和日志的只读访问，用历史故障验证根因分析质量。
- 将智能体建议与现有 Runbook 对照，记录误报、漏报和缺失上下文。
- 对生成的命令执行静态检查，明确项目、区域、实例和环境，禁止隐式默认值。
- 只允许执行预先批准的动作，并使用最小权限、审批记录和审计日志。
- 每次修复后重新检查延迟、错误率、资源消耗和查询计划，确认问题确实得到改善。
数据库智能体的现实价值，不是取代 DBA 或 SRE，而是把跨系统检索、初步诊断和候选方案生成压缩到更短时间。真正可靠的自动化仍然取决于清晰的权限边界、可验证的遥测数据，以及人在关键变更前保留最终决定权。