gcloud CLI 安装、认证与配置全解google-cloud-developer 插件中的 CLI Usage 参考指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文基于google-cloud-developer插件下 gcloud 技能的 CLI Usage 参考文档系统讲解 Google Cloud SDKgcloudCLI在安装、认证授权、本地配置管理三个环节上的完整操作细节并结合技能文件 SKILL.md 中的 Agent 执行约束说明这些 CLI 操作在 AI Agent 自动化场景下的配套实践。读完本文你可以为本地或无浏览器headless环境完成 gcloud 的组件管理、凭证配置与多环境 profile 切换并理解该技能为什么强调--quiet、显式--project等约束。文档定位gcloud 技能的双执行模式在开始细节之前先明确该文档在整个技能中的位置。SKILL.md 定义了 AI Agent 操作 Google Cloud 资源的两种主要执行模式直接 CLI 执行Direct CLI Execution在本地或自动化 shell 环境中直接执行gcloud命令。本文档references/cli-usage.md正是该模式的参考手册覆盖安装、认证流程与配置管理。Model Context ProtocolMCP通过 Cloud CLI 远程 MCP 服务器的run_gcloud_command工具发起结构化调用详见 mcp-usage.md。这一点很重要因为cli-usage.md中描述的gcloud auth、gcloud config等本地配置与凭证管理命令只在直接 CLI 模式下有意义——远程 MCP 模式运行在受管理的沙箱环境中其工具不支持gcloud auth、gcloud config这类管理本地机器状态的命令组mcp-usage.md的 Prohibited Unsupported Commands 一节明确列出了这一点。因此认证与配置工作必须在本地或容器内先完成MCP 侧则依赖客户端附带的 ADC 凭证。安装与组件管理文档指出若执行环境中尚未安装gcloud二进制文件应参照官方 Google Cloud CLI 安装指南按平台Linux、macOS、Windows、各包管理器、容器镜像进行安装。安装完成后gcloud components命令组负责管理可选组件附加工具、模拟器、语言运行时等文档给出了三条基础命令列出可用组件gcloud components list安装指定组件gcloud components install {component_id} --quiet更新所有已安装组件gcloud components update --quiet这里有两点值得注意包管理器安装的 gcloud 不能混用组件命令。文档特别提示如果gcloud是通过 APT、DNF 等系统包管理器安装的必须继续使用系统包管理器安装组件而不是使用gcloud components install。混用会导致组件版本与主程序版本脱节。--quiet标志在自动化中是标配。该技能面向 AI Agent 场景Agent 运行在没有 TTY 的 headless 环境中SKILL.md 的 Execution Constraints 一节将其解释得很清楚不加--quiet或-q时任何需要交互确认的命令删除资源、确认默认值、选择区域都会无限期挂起等待输入导致后台任务超时加上--quiet后gcloud 会强制进入非交互模式自动接受安全默认值或在必需参数缺失时立即报错。因此文档在components install/components update上预先带上--quiet是刻意为之。此外SKILL.md 还规定了一个前置强制步骤在提出或执行任何具体gcloud命令之前必须先运行gcloud help leaf_command验证叶子命令级的语法例如gcloud help compute instances create。它强调父命令组的 help 不具备传递性且禁止用网络搜索替代本地 help 作为语法权威。这条规则贯穿整个技能也适用于本文介绍的每一条安装与认证命令。认证与授权六种凭证路径按环境选型cli-usage.md的核心章节是 Authorization Authentication。它按运行环境的不同给出六条认证路径这也是 GCP 工具链中最常混淆的部分。下面按文档顺序完整展开并补充各路径的适用边界。1. 用户账号交互式登录User Account, Interactivegcloud auth login执行后按浏览器提示完成登录并授权。这是桌面开发机上的标准流程命令会拉起本地浏览器走 OAuth 流程凭证写入用户级配置文件。2. 用户账号无浏览器登录Headless Flow适用于容器、远程 SSH 等无法弹出浏览器的环境gcloud auth login --no-browser流程是命令在终端生成一个 URL将其复制到另一台有浏览器的机器上打开并完成登录再把页面返回的授权码粘贴回原终端。文档给出的场景容器、远程 SSH正是 CI 之外的典型开发环境也是 Agent 在受限容器中操作时最常用的人机协作方式。3. 应用默认凭证Application Default Credentials, ADCgcloud auth application-default loginADC 面向客户端库和本地应用Python/Go 等 Google Cloud 客户端库在本地运行时默认按固定顺序查找凭证ADC 文件~/.config/gcloud/application_default_credentials.json是其中一环。文档同样注明headless 环境下追加--no-browser。ADC 在本仓库语境中还有一个关键联动MCP 远程执行模式下客户端必须通过authProviderType: google_credentials将 ADC 附带https://www.googleapis.com/auth/cloud-platformscope 发送给 MCP 服务器否则会收到401 Unauthorized见 mcp-usage.md 的客户端配置说明。也就是说CLI 侧配好 ADC 与 MCP 侧认证通过 是同一套凭证的两端消费。4. 服务账号密钥Service Account Key, Headless Automationgcloud auth activate-service-account --key-filepath/to/key.json适用于完全无人值守的自动化。文档附带的安全提示值得单独强调应限制 JSON 密钥文件的文件系统权限或优先改用 Workload Identity / 身份模拟方案。长期私钥文件一旦泄露攻击者即获得对应服务账号的完整权限这也是文档将其排在模拟方案之前的原因。5. 服务账号身份模拟Service Account Impersonation——开发与 Agent 场景的首选gcloud config set auth/impersonate_service_account {service_account_email}文档明确标注该方式为Development Agents 的首选Preferred。其工作机制是用户身份已登录的真人或 Agent 背后的凭证临时扮演某个服务账号执行操作而无需在任何磁盘上存储长期私钥文件。使用该方式的前置条件当前身份必须在目标服务账号上持有roles/iam.serviceAccountTokenCreator角色。从安全模型看这一设计实现了两个目标——最小权限least privilege能否模拟取决于是否被授予 token creator 角色而不是是否拿到了私钥可审计性所有操作以目标身份执行并被 Cloud Audit Logs 记录同时保留了谁发起了模拟的上游身份线索。需要注意这是通过gcloud config set写入的本地配置属性因此它只影响本机 CLI 会话不会随命令参数传递——这正好引出下一节的配置管理。6. 工作负载身份联合Workload Identity Federation面向 CI/CD 与外部计算环境如 GitHub Actions、AWS、自建数据中心。思路是外部运行环境签发其自身身份令牌通过 GCP 侧配置的联合策略换取短期 GCP 凭证全程无需管理服务账号密钥。文档将其指向官方的 gcloud CLI 授权专题文档。对于需要跨云、跨 IDP 的流水线这是唯一不需要把任何长寿命凭证带入外部环境的方案。选型小结桌面开发用auth login容器/SSH 用--no-browser本地跑客户端库代码配 ADC无人值守且能改基础设施时优先身份模拟或 Workload Identity Federation仅在短期内快速自动化时才退回服务账号密钥。本地配置管理命名配置与默认属性gcloud config命令组管理本地配置属性、profile 与默认值。文档将其分为两部分。命名配置Named Configurations配置configuration俗称 profile允许维护多套相互隔离的属性集合例如 dev、staging、prod 三套环境。文档给出三条操作命令创建新配置gcloud config configurations create {config_name}列出现有配置gcloud config configurations list激活指定配置gcloud config configurations activate {config_name}典型用法是为每个环境create一个配置在其中分别set core/project与compute/region、compute/zone切换环境时只需activate对应配置而无需改动任何命令。常用属性设置属性为gcloud命令的常用标志提供默认值设置活动项目gcloud config set core/project {project_id}设置默认计算区域与可用区gcloud config set compute/region {region} gcloud config set compute/zone {zone}查看所有生效的配置属性gcloud config list配置默认值与 Agent 显式参数之间的张力这里存在一个文档与父技能之间值得注意的张力cli-usage.md教你会用配置默认值而 SKILL.md 的 Project and Location Scoping 一节却要求 Agent不要依赖活动配置的默认值而是对所有资源操作与查询命令显式附加--projectPROJECT_ID纯本地配置命令除外并始终显式提供--region/--zone/--location因为缺失位置标志会触发交互式区域选择提示违反非交互原则。两者的定位其实一致但受众不同配置默认值服务于人类开发者的效率少敲参数显式参数服务于Agent 执行的确定性不猜测、不提示、不错项目。文档本身还给出了位置发现命令供不知道目标区域/可用区时使用Compute Enginegcloud compute regions list --projectPROJECT_ID、gcloud compute zones list --projectPROJECT_ID多数 GCP 服务统一走gcloud GROUP locations list --projectPROJECT_ID例如gcloud artifacts locations list、gcloud kms locations list、gcloud secrets locations list配套约束从 CLI 操作走向 Agent 安全执行cli-usage.md负责回答命令怎么装、怎么认证、怎么配而 SKILL.md 负责回答Agent 拿着这些命令能做什么、不能做什么。以下四条与认证/配置结果直接相关是阅读本文档时不可分割的上下文数据缩减Data Reduction任何list命令必须携带至少一个--limit、--filter或--format标志推荐模式是--formatjson(key1, key2, ...)做字段投影--limitN封顶返回条数--filter做服务端过滤冒号模式匹配且右侧不加引号。不确定 JSON 结构时先执行gcloud GROUP RESOURCE list --limit1 --formatjson探测 schema再构造完整的过滤或投影查询。执行约束一次只执行一条命令禁止命令替换$(...)、管道|与重定向,,所有执行类命令携带--quiet。禁止操作清单DenylistIAM 策略/角色/绑定的任何修改、主动启用 API、gcloud * delete、gcloud billing *、gcloud organizations *、gcloud kms *、gcloud infra-manager deployments apply均不得由 Agent 自主执行必须获得用户显式授权。注意其中 No Proactive API Enabling 意味着即便某命令因 API 未启用而失败Agent 也不应自行去gcloud services enable。计划模板与干运行生成执行计划时必须包含四步结构——gcloud help leaf_command语法验证、参数核验含确认是否支持--dry-run/--validate-only、干运行预览、命令提案与授权。支持--dry-run或--validate-only的命令必须先干运行再真实执行长时操作推荐--async并轮询 operation 状态gcloud operations describe OPERATION_ID。从源码结构看这套规则的工程动机在 SKILL.md 开头的 CAUTION 块中说得最直接模型对 gcloud 命令的先验知识过时且容易幻觉所以叶子级 help 验证被设为强制前置条件而不是可选项。与 MCP 远程执行模式的分工边界最后把两种执行模式的分工固化下来避免误用本文文档维度直接 CLI 模式本文档适用Cloud CLI 远程 MCP 模式凭证按上述六种路径在本地配置ADC/模拟/密钥等客户端通过google_credentials附带 ADC需https://www.googleapis.com/auth/cloud-platformscopegcloud auth/gcloud config支持即本文核心内容不支持——这些命令组管理本地机器状态被明确列为不可用项目上下文可用 config 默认值Agent 场景建议显式--projectproject参数projects/{api_project}仅用于配额/计费/API 启用资源命令必须在command字符串内显式写--project{resource_project}前置条件gcloud 已安装并完成认证目标项目已启用 Cloud CLI Execution API调用身份持有roles/mcp.toolUser否则返回403 Forbidden也就是说cli-usage.md中所有gcloud auth与gcloud config命令都是为直接 CLI 模式的本地/容器环境准备的若走 MCP 远程执行本地仍需配好 ADC供客户端认证但activate-service-account、config set core/project等本地操作在远端沙箱中并不生效项目作用域必须靠命令参数表达。小结cli-usage.md作为 gcloud 技能的 CLI 侧参考文档给出了三个层次的完整操作基线安装与组件管理注意包管理器场景的例外规则、六种按环境选择的认证路径其中服务账号身份模拟是开发/Agent 场景首选Workload Identity Federation 覆盖外部环境、以及基于命名配置的多环境本地配置管理。把它与 SKILL.md 的强制验证流程gcloud help leaf_command、数据缩减规则、--quiet非交互约束、denylist 和干运行要求合起来读就构成了一份面向 AI Agent 的、从装好 CLI到安全地执行一条命令的完整链路。该插件google-cloud-developer见 plugin.json随仓库以 Apache-2.0 协议发布可通过仓库 README 中的插件安装方式引入到各 Agent 工具链中。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
gcloud CLI 安装、认证与配置全解：google-cloud-developer 插件中的 CLI Usage 参考指南
gcloud CLI 安装、认证与配置全解google-cloud-developer 插件中的 CLI Usage 参考指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文基于google-cloud-developer插件下 gcloud 技能的 CLI Usage 参考文档系统讲解 Google Cloud SDKgcloudCLI在安装、认证授权、本地配置管理三个环节上的完整操作细节并结合技能文件 SKILL.md 中的 Agent 执行约束说明这些 CLI 操作在 AI Agent 自动化场景下的配套实践。读完本文你可以为本地或无浏览器headless环境完成 gcloud 的组件管理、凭证配置与多环境 profile 切换并理解该技能为什么强调--quiet、显式--project等约束。文档定位gcloud 技能的双执行模式在开始细节之前先明确该文档在整个技能中的位置。SKILL.md 定义了 AI Agent 操作 Google Cloud 资源的两种主要执行模式直接 CLI 执行Direct CLI Execution在本地或自动化 shell 环境中直接执行gcloud命令。本文档references/cli-usage.md正是该模式的参考手册覆盖安装、认证流程与配置管理。Model Context ProtocolMCP通过 Cloud CLI 远程 MCP 服务器的run_gcloud_command工具发起结构化调用详见 mcp-usage.md。这一点很重要因为cli-usage.md中描述的gcloud auth、gcloud config等本地配置与凭证管理命令只在直接 CLI 模式下有意义——远程 MCP 模式运行在受管理的沙箱环境中其工具不支持gcloud auth、gcloud config这类管理本地机器状态的命令组mcp-usage.md的 Prohibited Unsupported Commands 一节明确列出了这一点。因此认证与配置工作必须在本地或容器内先完成MCP 侧则依赖客户端附带的 ADC 凭证。安装与组件管理文档指出若执行环境中尚未安装gcloud二进制文件应参照官方 Google Cloud CLI 安装指南按平台Linux、macOS、Windows、各包管理器、容器镜像进行安装。安装完成后gcloud components命令组负责管理可选组件附加工具、模拟器、语言运行时等文档给出了三条基础命令列出可用组件gcloud components list安装指定组件gcloud components install {component_id} --quiet更新所有已安装组件gcloud components update --quiet这里有两点值得注意包管理器安装的 gcloud 不能混用组件命令。文档特别提示如果gcloud是通过 APT、DNF 等系统包管理器安装的必须继续使用系统包管理器安装组件而不是使用gcloud components install。混用会导致组件版本与主程序版本脱节。--quiet标志在自动化中是标配。该技能面向 AI Agent 场景Agent 运行在没有 TTY 的 headless 环境中SKILL.md 的 Execution Constraints 一节将其解释得很清楚不加--quiet或-q时任何需要交互确认的命令删除资源、确认默认值、选择区域都会无限期挂起等待输入导致后台任务超时加上--quiet后gcloud 会强制进入非交互模式自动接受安全默认值或在必需参数缺失时立即报错。因此文档在components install/components update上预先带上--quiet是刻意为之。此外SKILL.md 还规定了一个前置强制步骤在提出或执行任何具体gcloud命令之前必须先运行gcloud help leaf_command验证叶子命令级的语法例如gcloud help compute instances create。它强调父命令组的 help 不具备传递性且禁止用网络搜索替代本地 help 作为语法权威。这条规则贯穿整个技能也适用于本文介绍的每一条安装与认证命令。认证与授权六种凭证路径按环境选型cli-usage.md的核心章节是 Authorization Authentication。它按运行环境的不同给出六条认证路径这也是 GCP 工具链中最常混淆的部分。下面按文档顺序完整展开并补充各路径的适用边界。1. 用户账号交互式登录User Account, Interactivegcloud auth login执行后按浏览器提示完成登录并授权。这是桌面开发机上的标准流程命令会拉起本地浏览器走 OAuth 流程凭证写入用户级配置文件。2. 用户账号无浏览器登录Headless Flow适用于容器、远程 SSH 等无法弹出浏览器的环境gcloud auth login --no-browser流程是命令在终端生成一个 URL将其复制到另一台有浏览器的机器上打开并完成登录再把页面返回的授权码粘贴回原终端。文档给出的场景容器、远程 SSH正是 CI 之外的典型开发环境也是 Agent 在受限容器中操作时最常用的人机协作方式。3. 应用默认凭证Application Default Credentials, ADCgcloud auth application-default loginADC 面向客户端库和本地应用Python/Go 等 Google Cloud 客户端库在本地运行时默认按固定顺序查找凭证ADC 文件~/.config/gcloud/application_default_credentials.json是其中一环。文档同样注明headless 环境下追加--no-browser。ADC 在本仓库语境中还有一个关键联动MCP 远程执行模式下客户端必须通过authProviderType: google_credentials将 ADC 附带https://www.googleapis.com/auth/cloud-platformscope 发送给 MCP 服务器否则会收到401 Unauthorized见 mcp-usage.md 的客户端配置说明。也就是说CLI 侧配好 ADC 与 MCP 侧认证通过 是同一套凭证的两端消费。4. 服务账号密钥Service Account Key, Headless Automationgcloud auth activate-service-account --key-filepath/to/key.json适用于完全无人值守的自动化。文档附带的安全提示值得单独强调应限制 JSON 密钥文件的文件系统权限或优先改用 Workload Identity / 身份模拟方案。长期私钥文件一旦泄露攻击者即获得对应服务账号的完整权限这也是文档将其排在模拟方案之前的原因。5. 服务账号身份模拟Service Account Impersonation——开发与 Agent 场景的首选gcloud config set auth/impersonate_service_account {service_account_email}文档明确标注该方式为Development Agents 的首选Preferred。其工作机制是用户身份已登录的真人或 Agent 背后的凭证临时扮演某个服务账号执行操作而无需在任何磁盘上存储长期私钥文件。使用该方式的前置条件当前身份必须在目标服务账号上持有roles/iam.serviceAccountTokenCreator角色。从安全模型看这一设计实现了两个目标——最小权限least privilege能否模拟取决于是否被授予 token creator 角色而不是是否拿到了私钥可审计性所有操作以目标身份执行并被 Cloud Audit Logs 记录同时保留了谁发起了模拟的上游身份线索。需要注意这是通过gcloud config set写入的本地配置属性因此它只影响本机 CLI 会话不会随命令参数传递——这正好引出下一节的配置管理。6. 工作负载身份联合Workload Identity Federation面向 CI/CD 与外部计算环境如 GitHub Actions、AWS、自建数据中心。思路是外部运行环境签发其自身身份令牌通过 GCP 侧配置的联合策略换取短期 GCP 凭证全程无需管理服务账号密钥。文档将其指向官方的 gcloud CLI 授权专题文档。对于需要跨云、跨 IDP 的流水线这是唯一不需要把任何长寿命凭证带入外部环境的方案。选型小结桌面开发用auth login容器/SSH 用--no-browser本地跑客户端库代码配 ADC无人值守且能改基础设施时优先身份模拟或 Workload Identity Federation仅在短期内快速自动化时才退回服务账号密钥。本地配置管理命名配置与默认属性gcloud config命令组管理本地配置属性、profile 与默认值。文档将其分为两部分。命名配置Named Configurations配置configuration俗称 profile允许维护多套相互隔离的属性集合例如 dev、staging、prod 三套环境。文档给出三条操作命令创建新配置gcloud config configurations create {config_name}列出现有配置gcloud config configurations list激活指定配置gcloud config configurations activate {config_name}典型用法是为每个环境create一个配置在其中分别set core/project与compute/region、compute/zone切换环境时只需activate对应配置而无需改动任何命令。常用属性设置属性为gcloud命令的常用标志提供默认值设置活动项目gcloud config set core/project {project_id}设置默认计算区域与可用区gcloud config set compute/region {region} gcloud config set compute/zone {zone}查看所有生效的配置属性gcloud config list配置默认值与 Agent 显式参数之间的张力这里存在一个文档与父技能之间值得注意的张力cli-usage.md教你会用配置默认值而 SKILL.md 的 Project and Location Scoping 一节却要求 Agent不要依赖活动配置的默认值而是对所有资源操作与查询命令显式附加--projectPROJECT_ID纯本地配置命令除外并始终显式提供--region/--zone/--location因为缺失位置标志会触发交互式区域选择提示违反非交互原则。两者的定位其实一致但受众不同配置默认值服务于人类开发者的效率少敲参数显式参数服务于Agent 执行的确定性不猜测、不提示、不错项目。文档本身还给出了位置发现命令供不知道目标区域/可用区时使用Compute Enginegcloud compute regions list --projectPROJECT_ID、gcloud compute zones list --projectPROJECT_ID多数 GCP 服务统一走gcloud GROUP locations list --projectPROJECT_ID例如gcloud artifacts locations list、gcloud kms locations list、gcloud secrets locations list配套约束从 CLI 操作走向 Agent 安全执行cli-usage.md负责回答命令怎么装、怎么认证、怎么配而 SKILL.md 负责回答Agent 拿着这些命令能做什么、不能做什么。以下四条与认证/配置结果直接相关是阅读本文档时不可分割的上下文数据缩减Data Reduction任何list命令必须携带至少一个--limit、--filter或--format标志推荐模式是--formatjson(key1, key2, ...)做字段投影--limitN封顶返回条数--filter做服务端过滤冒号模式匹配且右侧不加引号。不确定 JSON 结构时先执行gcloud GROUP RESOURCE list --limit1 --formatjson探测 schema再构造完整的过滤或投影查询。执行约束一次只执行一条命令禁止命令替换$(...)、管道|与重定向,,所有执行类命令携带--quiet。禁止操作清单DenylistIAM 策略/角色/绑定的任何修改、主动启用 API、gcloud * delete、gcloud billing *、gcloud organizations *、gcloud kms *、gcloud infra-manager deployments apply均不得由 Agent 自主执行必须获得用户显式授权。注意其中 No Proactive API Enabling 意味着即便某命令因 API 未启用而失败Agent 也不应自行去gcloud services enable。计划模板与干运行生成执行计划时必须包含四步结构——gcloud help leaf_command语法验证、参数核验含确认是否支持--dry-run/--validate-only、干运行预览、命令提案与授权。支持--dry-run或--validate-only的命令必须先干运行再真实执行长时操作推荐--async并轮询 operation 状态gcloud operations describe OPERATION_ID。从源码结构看这套规则的工程动机在 SKILL.md 开头的 CAUTION 块中说得最直接模型对 gcloud 命令的先验知识过时且容易幻觉所以叶子级 help 验证被设为强制前置条件而不是可选项。与 MCP 远程执行模式的分工边界最后把两种执行模式的分工固化下来避免误用本文文档维度直接 CLI 模式本文档适用Cloud CLI 远程 MCP 模式凭证按上述六种路径在本地配置ADC/模拟/密钥等客户端通过google_credentials附带 ADC需https://www.googleapis.com/auth/cloud-platformscopegcloud auth/gcloud config支持即本文核心内容不支持——这些命令组管理本地机器状态被明确列为不可用项目上下文可用 config 默认值Agent 场景建议显式--projectproject参数projects/{api_project}仅用于配额/计费/API 启用资源命令必须在command字符串内显式写--project{resource_project}前置条件gcloud 已安装并完成认证目标项目已启用 Cloud CLI Execution API调用身份持有roles/mcp.toolUser否则返回403 Forbidden也就是说cli-usage.md中所有gcloud auth与gcloud config命令都是为直接 CLI 模式的本地/容器环境准备的若走 MCP 远程执行本地仍需配好 ADC供客户端认证但activate-service-account、config set core/project等本地操作在远端沙箱中并不生效项目作用域必须靠命令参数表达。小结cli-usage.md作为 gcloud 技能的 CLI 侧参考文档给出了三个层次的完整操作基线安装与组件管理注意包管理器场景的例外规则、六种按环境选择的认证路径其中服务账号身份模拟是开发/Agent 场景首选Workload Identity Federation 覆盖外部环境、以及基于命名配置的多环境本地配置管理。把它与 SKILL.md 的强制验证流程gcloud help leaf_command、数据缩减规则、--quiet非交互约束、denylist 和干运行要求合起来读就构成了一份面向 AI Agent 的、从装好 CLI到安全地执行一条命令的完整链路。该插件google-cloud-developer见 plugin.json随仓库以 Apache-2.0 协议发布可通过仓库 README 中的插件安装方式引入到各 Agent 工具链中。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考