在《The Forrester Wave™: Public Cloud Platforms, Q3 2026》中，Google Cloud 被评为领导者，并在“当前产品能力”类别获得最高分。根据 Google 公布的信息，这次评估覆盖 10 家主要公有云厂商和 30 项标准，Google Cloud 在其中 23 项获得最高分，包括 AI 开发、数据库、分析、容器与 Kubernetes、现代化和安全服务。
比排名更值得工程团队关注的，是背后的平台判断：企业部署 AI 智能体，不能只采购模型 API。算力、容器调度、数据访问、隔离机制、可观测性和治理必须连成一个可以稳定运行的系统。
从芯片到模型，全栈协同正在变成云平台的分水岭
Google Cloud 将自己的优势归因于长期的全栈协同设计。TPU、Axion、Kubernetes、Transformer 和 Gemini 并不是彼此孤立的产品，而是从基础设施、编排软件一路延伸到模型和应用层的技术组合。
这种组合对普通企业也有现实意义。大多数团队不会训练前沿基础模型，但仍然需要解决几个棘手问题：
- 推理负载具有明显的突发性，GPU 或其他加速器容易闲置；
- 智能体可能生成并执行代码，传统应用级权限控制并不足够；
- 长会话会占用大量内存，但用户交互可能间隔数分钟；
- 智能体需要读取实时业务数据，同时不能绕开权限和审计；
- AI 工作负载最终仍要和微服务、数据库及批处理任务共享运维体系。
因此，“智能体平台”不应该成为一座新的孤岛。更可行的路线是把它放进企业已经熟悉的 Kubernetes、无服务器计算、身份管理和数据治理体系中。
GKE 的方向：让智能体与传统工作负载共用一个控制面
在容器与 Kubernetes、Serverless/FaaS 和运维管理等标准上，Google Cloud 获得了最高档评分。围绕智能体工作负载，公告特别提到三类能力：
- 隔离不可信代码：GKE Agent Sandbox 已正式可用，Cloud Run Sandboxes 处于预览阶段。它们通过基于 gVisor 的轻量隔离边界运行智能体代码。Google 给出的数据是单个隔离环境可在一秒内创建，单集群最高可达到每秒 300 个，但实际结果仍取决于区域、配额、集群和工作负载配置。
- 冻结空闲会话：GKE Pod Snapshots 可以把容器内存状态序列化到 Cloud Storage。公告称，这可减少最多 90% 的空闲计算成本，并把暂停和恢复时间分别压缩到约 100 毫秒和 280 毫秒。
- 优化推理路由：GKE Inference Gateway 通过持续训练的模型，根据实时流量做预测路由。Google 报告的结果包括首个 token 延迟最高降低 70%，缓存命中率提升一倍。
这些数字都应视为特定条件下的厂商测试结果，而不是容量规划时可以直接套用的保证值。上线前至少应使用自己的模型大小、上下文长度、并发模式和缓存策略进行压测。
可以这样实践：为智能体 Worker 建立最小隔离基线
下面的示例不是 GKE Agent Sandbox 完整产品配置，而是一份可改造的 Kubernetes 安全基线。它假设集群已经提供名为 gvisor 的 RuntimeClass；在运行前，请根据实际 GKE 集群配置确认或修改 runtimeClassName。
将以下内容保存为 agent-sandbox.yaml：
apiVersion: v1
kind: Namespace
metadata:
name: agent-lab
labels:
pod-security.kubernetes.io/enforce: restricted
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: agent-lab
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
---
apiVersion: batch/v1
kind: Job
metadata:
name: sandboxed-agent-worker
namespace: agent-lab
spec:
backoffLimit: 0
template:
spec:
runtimeClassName: gvisor
automountServiceAccountToken: false
restartPolicy: Never
containers:
- name: worker
image: python:3.12-alpine
command:
- python
- -c
- |
from pathlib import Path
result = "agent task completed inside an isolated runtime"
Path("/tmp/result.txt").write_text(result)
print(result)
resources:
requests:
cpu: "100m"
memory: "64Mi"
limits:
cpu: "500m"
memory: "256Mi"
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 10001
capabilities:
drop: ["ALL"]
seccompProfile:
type: RuntimeDefault
volumeMounts:
- name: scratch
mountPath: /tmp
volumes:
- name: scratch
emptyDir:
sizeLimit: 64Mi
执行并查看日志：
kubectl apply -f agent-sandbox.yaml
kubectl wait --for=condition=complete job/sandboxed-agent-worker \
-n agent-lab --timeout=120s
kubectl logs -n agent-lab job/sandboxed-agent-worker
kubectl delete namespace agent-lab
这份配置同时落实了几项容易被忽略的控制：默认拒绝入站和出站流量、不挂载 Kubernetes API 凭据、只读根文件系统、删除 Linux capabilities、限制 CPU 与内存，并为临时文件提供有大小限制的目录。
真正接入模型和业务 API 时，不要简单删除默认拒绝策略。更稳妥的做法是通过出口网关或代理，只放行明确的模型端点、数据服务和审计系统，并为每个工具调用设置超时、预算和身份边界。
数据层决定智能体能否从演示走向生产
一个能调用模型的智能体并不等于一个能处理业务的智能体。后者必须获得及时、可信且经过授权的上下文。
传统数据架构通常把交易数据库、数据仓库和对象存储拆成多个系统，再依赖 ETL 或消息管道同步。对于报表，这种延迟可能可以接受；对于自动审批、库存调整或风险控制，陈旧上下文会直接导致错误动作。
Google Cloud 在数据库、分析、数据集成和数据治理四项标准上均获得 5/5。其 Agentic Data Cloud 路线强调把事务处理、分析和治理连接起来，近期能力包括：
- 通过 SAP BDC Connect for BigQuery，在 SAP 与 BigQuery 之间进行双向、零复制数据共享；
- 使用 Knowledge Catalog 汇总 Google、合作伙伴平台、语义模型和第三方目录中的业务上下文；
- 通过 Lakehouse federation，从 PostgreSQL 数据平面访问 BigQuery 与 Iceberg 数据；
- 在 AlloyDB 事务数据与 BigQuery 或 Iceberg 历史数据之间执行实时关联；
- 使用 Datastream 把 AlloyDB 的变化持续复制到 BigQuery 或 Iceberg 表。
“零复制”或联邦查询可以减少搬运数据的成本，但不会自动解决所有问题。跨系统查询仍需评估延迟、并发限制、故障域、费用和权限传播。对于关键智能体，建议把数据接口设计成受控工具，而不是允许模型任意生成 SQL 并直连生产数据库。
一个常见的生产链路可以是：
用户请求
-> 智能体编排器
-> 经过身份校验的业务工具 API
-> AlloyDB / BigQuery / Iceberg / SAP
-> 策略检查与人工审批
-> 执行动作并写入审计日志
这里最重要的边界是：模型负责生成计划或建议，确定性的服务负责鉴权、校验和执行。涉及付款、删除、权限变更等高风险动作时，还应加入人工确认或双人审批。
采用建议：不要用榜单代替自己的验证
Forrester 的评估说明 Google Cloud 在完整产品能力上具备较强竞争力，尤其适合希望同时使用 AI、Kubernetes、数据库与分析服务的企业。但云平台选择仍然应该回到工作负载，而不是只看总分。
评估时可以使用下面这份清单：
- 隔离：智能体生成的代码是否运行在独立内核边界或强化沙箱中？
- 身份：每个智能体和工具是否使用最小权限的工作负载身份？
- 网络：是否默认拒绝出口，只允许访问明确的模型与数据端点？
- 数据：实时上下文是否有统一的语义、权限和审计记录？
- 弹性：冷启动、首 token 延迟和长会话恢复时间是否达到业务目标？
- 成本：是否分别核算推理、缓存、空闲会话、网络和跨系统查询费用？
- 可移植性：Kubernetes、PostgreSQL、Iceberg 等开放接口是否足以避免关键路径被锁死？
- 验证：厂商给出的“最高可达”数据是否已经在真实流量模型下复现？
智能体时代的云竞争不再只是比较虚拟机规格。真正的差异来自算力、编排、模型、数据和安全能否组成一个可运营的整体。Google Cloud 此次获得认可，体现的正是这种全栈路线；对工程团队而言，下一步则是用自己的延迟、成本和风险指标验证它是否适合生产环境。