AI 编码代理接入云平台时，难点通常不是生成一条 gcloud 命令，而是同时处理身份认证、IAM 权限、项目上下文、官方文档以及危险操作确认。Google Cloud 新发布的 google-cloud-developer 插件试图把这些彼此关联的能力封装成一个可安装单元，让代理不必依赖零散技能和手工拼接的 MCP 配置。
插件解决的是能力耦合，而不只是安装问题
单个 Agent Skill 适合描述边界明确的任务，例如检查 gcloud 是否存在、解释某项 IAM 权限，或者给出项目初始化步骤。它通常比把整套文档塞进提示词更节省上下文窗口，也容易独立安装。
问题出现在真实工作流中。以新项目接入为例，代理需要连续完成几类工作：
- 理解 Google Cloud 的认证与授权模型；
- 检查本机 CLI、当前账号、项目和组织状态；
- 从最新官方文档中检索准确步骤；
- 调用
gcloud或其他工具读取、修改实际环境； - 在创建资源、修改 IAM 或启用计费前暂停并请求确认。
如果这些能力分别由独立技能、提示词和 MCP 服务器提供，开发者就要自己维护依赖关系。插件则把相关 Skills、工具配置和 MCP 服务声明放入统一目录，作为一个整体分发。这样做的价值不是“少装几个文件”，而是让领域知识、实时文档和环境操作在同一目标下协同工作。
首个基础插件 google-cloud-developer 面向通用 Google Cloud 开发场景，覆盖认证、授权、项目管理和 gcloud 操作护栏，并包含 Developer Knowledge MCP Server 的配置，使代理可以用 Google 官方开发者文档进行最新信息校准。
开放规范让同一能力进入不同代理
该插件遵循开放、厂商中立的 Agent Plugins 规范。规范提供统一的清单文件与目录结构，用来打包 Agent Skills 和 MCP Servers，减少为每一种 AI 助手重复编写包装层与配置的工作。
这带来两个直接影响：
- 团队可以把插件视为可版本化的开发依赖，而不是散落在个人电脑上的提示词集合。
- 同一个能力包可以进入多种兼容的编码代理环境，同时保持相近的工具边界和工作方式。
不过，可移植不等于执行结果完全一致。不同代理的工具授权模型、确认界面、沙箱策略和提示词解释仍可能不同。团队应测试实际使用的代理，而不是只验证插件能否成功安装。
安装并验证基础插件
根据使用的代理选择一组命令即可，不需要全部执行。
Antigravity CLI
agy plugin install https://github.com/google/skills/plugins/cloud/google-cloud-developer
Claude Code
claude plugin marketplace add google/skills
claude plugin install google-cloud-developer@google-plugins
Codex CLI
codex plugin marketplace add google/skills
codex plugin add google-cloud-developer@google-plugins
安装后，可以先用只读任务验证插件能否识别本机环境。下面这段提示词可以直接交给代理：
检查我的本地 Google Cloud 开发环境，但不要创建、修改或删除任何资源。
请完成以下工作：
1. 检查 gcloud CLI 是否可用，并报告版本。
2. 显示当前活动账号和项目；如果没有配置，只解释下一步，不要替我修改。
3. 检查 Application Default Credentials 是否可能已配置，但不要输出任何令牌或凭据内容。
4. 根据官方开发者文档说明“用户身份”和“脚本使用的服务身份”之间的区别。
5. 在提出任何写操作命令时，先解释影响并等待我确认。
也可以在终端手工运行一组只读命令，与代理的环境判断交叉核对：
set -eu
gcloud version
gcloud auth list --filter=status:ACTIVE --format='value(account)'
gcloud config get-value project 2>/dev/null || true
gcloud config list --format='yaml(core.account,core.project)'
这些命令不会创建云资源，但输出中仍可能包含账号和项目标识，不应直接粘贴到公开工单或日志中。
用护栏完成项目接入
更完整的场景是：创建首个项目、关联计费，并让本地脚本以服务身份访问 API。可以这样实践，但应要求代理将计划和执行分开：
我需要为一个本地 Python 脚本准备 Google Cloud 项目，并让脚本以服务身份调用 API，而不是直接使用我的个人身份。
先只执行环境检查和方案设计，不要修改资源。请：
- 检查现有账号、组织、项目、计费与 gcloud 配置；
- 基于最小权限原则提出身份与 IAM 方案；
- 优先考虑不下载长期服务账号密钥的认证方式；
- 列出每条拟执行命令、影响范围、费用风险和回滚方式；
- 对创建项目、关联计费、启用 API、修改 IAM 等步骤分别等待确认；
- 不要显示、保存或提交任何令牌、私钥与凭据文件。
这类提示词明确区分“检查”“规划”和“执行”。插件可以帮助代理识别环境、查询文档并组织工作流，但不能替代组织政策、预算审批或人工权限审查。尤其要警惕长期服务账号密钥：如果业务场景允许，应优先评估 Application Default Credentials、服务账号模拟或其他短期凭据机制。
接入团队工作流前的检查清单
正式采用时，不要从高权限生产账号开始。先在隔离项目中验证以下事项：
- 插件来源和版本是否可审计，升级是否经过代码审查；
- MCP Server 能访问哪些网络、文档和本地数据；
- 代理是否会在写操作前展示完整命令并等待确认；
- IAM 建议是否遵循最小权限，而不是直接授予宽泛角色；
- 日志、聊天记录和 Git 提交是否可能泄露账号、令牌或密钥；
- 项目创建、计费关联和 API 启用是否符合组织治理流程。
google-cloud-developer 的关键意义，是把通用云知识、官方文档检索和实际工具调用放进一个可移植插件，而不是让每位开发者重复配置。它降低了接入成本，但权限边界仍必须由团队定义。最稳妥的落地路径是从只读检查开始，随后在沙箱项目中验证写操作，最后才把经过审计的插件版本引入生产工作流。