Google Cloud CLI 远程 MCP 服务器现已进入公开预览。它把大量 gcloud 与 bq 操作封装成标准 MCP 工具，让 Agent 无需在容器或本地环境中安装 Cloud CLI，也能管理云资源、诊断故障和执行高级 BigQuery 工作流。
这项能力的重点不只是“让模型运行命令”，而是把命令执行放进隔离环境，并继续使用 Agent Identity、OAuth 2.0、IAM、组织政策、Model Armor 和审计日志建立安全边界。
为什么 Agent 适合通过 CLI 操作云资源
云管理 API 通常粒度较细。一个看似简单的运维动作，可能涉及多个 API 调用、分页、参数校验和状态轮询。gcloud 与 bq 已经把其中许多步骤包装成较高层的命令，例如列出实例、查询日志、查看 BigQuery 作业详情或管理资源预留。
对 Agent 来说，CLI 还有一个实际优势：主流模型在训练数据中见过大量公开的命令行文档和示例，往往能够较准确地生成参数、过滤器和输出格式。Google Cloud CLI 远程 MCP 服务器进一步把这些能力集中为两个工具：
run_gcloud_command：执行 Google Cloud 基础设施管理、诊断和安全相关的gcloud操作。run_bq_command：执行 BigQuery 作业、资源、调度和权限管理相关的bq操作。
它并不是向 Agent 开放一个任意 Shell。Agent 获得的是受控的 Cloud CLI 工具入口，命令在 Google Cloud 托管、网络受限的隔离环境中执行。
从本地二进制切换到远程 MCP
传统做法通常需要在 Agent 镜像中安装 Google Cloud CLI，并处理版本升级、Python 依赖、凭据挂载和不同环境之间的差异。远程 MCP 将这部分运行时责任移出 Agent 容器，尤其适合以下场景：
- Agent 运行在无法安装系统软件的 Web 托管平台上。
- 开发、测试和生产环境不希望分别维护 Cloud CLI 版本。
- 团队希望避免把长期密钥或默认凭据放入执行环境。
- 同一个 Agent 需要同时处理基础设施与 BigQuery 运维任务。
由于服务实现标准 Model Context Protocol，兼容 MCP 的客户端可以通过统一配置接入。最小配置可以这样写；身份认证字段取决于所使用的客户端和运行平台：
{
"mcpServers": {
"google-cloud-cli": {
"uri": "https://cloudcli.googleapis.com/mcp"
}
}
}
托管在 Google Cloud 上的 Agent 可以使用无密钥的 Agent Identity；外部运行时则可以使用标准 OAuth 2.0。不要把访问令牌直接硬编码进 MCP 配置文件，应交给客户端的 OAuth 流程或平台身份系统处理。
可复制的接入步骤
下面示例假设 Agent 使用一个服务账号身份。执行前需要安装并登录本地 gcloud，然后替换项目 ID 与服务账号名称。对于使用 Agent Identity 的托管平台，应把 --member 换成平台分配的实际主体。
#!/usr/bin/env bash
set -euo pipefail
PROJECT_ID="my-agent-project"
AGENT_SA="cloud-agent@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud config set project "${PROJECT_ID}"
# 启用 Cloud CLI Execution API
gcloud services enable cloudcli.googleapis.com
# 允许该身份调用 MCP 工具
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member="serviceAccount:${AGENT_SA}" \
--role="roles/mcp.toolUser"
roles/mcp.toolUser 允许身份调用 MCP 工具，但不会绕过目标资源原有的 IAM 权限。Agent 如果要读取日志、查看虚拟机或检查 BigQuery 作业，仍然需要对应资源上的最小必要权限。
接入后，可以先让 Agent 执行只读命令验证链路。例如，一个故障诊断 Agent 可以按顺序调用 run_gcloud_command 执行以下命令模板：
gcloud compute instances list \
--project=my-production-project \
--format=json
gcloud logging read 'severity>=ERROR' \
--project=my-production-project \
--freshness=1h \
--limit=50 \
--format=json
处理 BigQuery 故障时，则可以通过 run_bq_command 使用类似命令：
bq ls -j -a \
--project_id=my-analytics-project \
--max_results=20
bq show --job --format=prettyjson \
'my-analytics-project:US.example_job_id'
这些命令适合构造一个受限的诊断提示词：
你是只读的 Google Cloud 故障诊断助手。
1. 先列出项目 my-production-project 中的 Compute Engine 实例。
2. 查询最近一小时 severity>=ERROR 的日志，最多返回 50 条。
3. 只总结异常资源、时间范围和可能原因。
4. 不得执行 create、update、delete、add-iam-policy-binding 或 remove-iam-policy-binding 操作。
5. 如果权限不足，报告缺失权限，不要尝试扩大权限。
提示词限制不是安全边界，但它能减少误操作。真正的限制仍应由 IAM、组织政策和审批流程实施。
安全设计不能只依赖模型“听话”
远程 MCP 服务器采用零环境凭据设计：执行沙箱本身不携带可被命令随意继承的默认凭据，认证与授权通过 Agent Identity、OAuth 2.0 和 IAM 完成。每次命令都以已认证调用者的权限运行，并受到目标资源 IAM 与组织政策约束。
生产接入时建议同时落实以下措施：
- 拆分只读与变更身份：诊断 Agent 默认只授予查看权限；创建、删除和 IAM 修改使用独立身份。
- 为写操作增加人工确认：不要让自然语言请求直接触发删除实例、修改防火墙或更新数据集权限。
- 配置 Model Armor：对模型输入与输出进行筛查，降低提示词注入和恶意输入影响工具调用的风险。
- 开启数据访问审计日志：Cloud CLI MCP 的工具调用可以记录在
cloudcli.googleapis.com/mcp对应的数据访问日志中。 - 关注授权决策：安全团队可以审查调用者身份、OAuth 客户端和
mcp.googleapis.com/tools.call的 IAM 授权结果。 - 避免把敏感数据写入提示词：审计能力不等于可以放心传输密钥、令牌或完整生产数据。
审计日志能够提供调用可见性，同时不会暴露敏感命令载荷或个人身份信息。这有助于安全团队追踪“谁调用了哪个工具、授权是否通过”，但应用自身仍应保存必要且经过脱敏的业务操作记录。
适合怎样落地
Google Cloud CLI 远程 MCP 服务器目前处于公开预览阶段，MCP 服务本身不额外收费，但命令创建或使用的 Google Cloud 资源以及相关数据传输仍会正常计费。
建议从只读场景开始，而不是立即交给 Agent 完整的管理员权限：
- 先启用 API，并为专用 Agent 身份授予
roles/mcp.toolUser。 - 仅添加日志读取、资源查看和 BigQuery 作业查看等必要权限。
- 用固定项目和固定区域测试
run_gcloud_command、run_bq_command。 - 验证组织政策确实能阻止不允许的操作。
- 打开审计日志，并检查身份、OAuth 客户端与授权决策是否可追踪。
- 在引入创建、更新或删除操作前，增加审批、命令白名单和回滚方案。
远程 MCP 消除了 Agent 镜像里的 CLI 安装与凭据维护负担，但没有消除云权限本身的风险。把它视为一个受 IAM 管理的远程运维入口，而不是一个可以无限制执行自然语言指令的终端，才能真正发挥它的价值。