Google Cloud AI Agent 部署验证模板实战Dry-Run、连通路由、安全治理与数据保护四维验收方案【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本指南讲解 skills 仓库中google-cloud-solution-build-deploy-agents技能配套的解决方案验证模板validation-template.md它用于把 AI Agent / 多智能体系统在 Google Cloud 上的部署验证计划落成一份结构化的 Markdown 文档。文章围绕模板内置的基础设施预演、网络连通与路由、安全与访问治理、数据保护与内容检查四个维度逐条拆解验证命令、参数含义、预期结果并结合仓库中的 SKILL.md、design-principles.md 与 product-mappings.md 给出落地补充读完后你可以在自己的 Agent 部署项目中直接套用并扩展这套验证方案。验证模板在技能工作流中的定位google-cloud-solution-build-deploy-agents技能将“在 Google Cloud 上设计、构建并部署 AI Agent 或多智能体系统”划分为四个阶段见 SKILL.mdPhase 1 需求发现与分析梳理工作负载的功能/非功能需求、依赖与现状Phase 2 解决方案设计基于 Google Cloud 设计最佳实践产出技术栈、架构与配置Phase 3 实施计划生成 IaC如 Terraform与部署说明Phase 4 解决方案验证验证部署满足工作负载需求。validation-template.md 正是Phase 4 的产出物模板技能要求把验证步骤、验证脚本与预期结果整理成单一 Markdown 文件命名为validation-plan.md其格式必须遵循本模板见 SKILL.md。模板文件头部注释也明确说明其用途“Use this template to compile the solution validation that you generate based on the instructions in SKILL.md”——即模板是编译/组织验证计划的骨架而非验证内容本身。因此一份完整的验证计划由两部分组成模板定义的验证维度骨架针对具体工作负载定制的检查项。模板在 1.2 节预留了占位符[Draft workloads-specific connectivity checks...]提示你需要根据实际架构负载均衡端点、serverless VPC 路径时延、私有数据库访问、DNS 解析规则等填充专属检查项。模板整体结构如下小节验证维度核心手段1.1 Infrastructure Dry-Run基础设施预演terraform plan1.2 Network Connectivity Routing网络连通与路由curl健康检查1.3 Security and Access Governance安全与访问治理gcloud projects get-iam-policy1.4 Data Protection Content Inspection数据保护与内容检查curl注入模拟 PII 请求1.1 Infrastructure Dry-Run上线前的无损预演目的在真正对生产环境应用变更之前使用预览工具验证部署计划提前发现资源层级、依赖关系与配置错误。验证命令模板原文terraform plan -outtfplan命令拆解terraform plan读取当前 Terraform 配置对比现有状态计算达成目标状态所需的变更集但不执行任何变更因此不会对线上环境产生副作用-outtfplan将生成的执行计划序列化保存到tfplan文件。保存计划文件的价值在于后续terraform apply tfplan可以精确执行本次预演所确认的变更避免在 apply 阶段重新计算导致计划漂移同时该文件也可作为评审、审计与回放的依据。预期结果模板原文预演验证资源层级正确并精确展示将要创建、更新或销毁的资源不出现配置错误。从仓库证据看该维度的扩展做法SKILL.md 在 Phase 4 的“定义验证检查”中将部署预演细化为两层基础设施层预演使用terraform plan预览变更Agent 部署层预演使用agents-cli deploy --dry-run或-n预览部署步骤以及即将执行的 Terraform 动作确认无误后再推向生产见 SKILL.md。此外在正式部署前还应把本地质量验证前移使用agents-cli run在本地运行并测试 Agent 逻辑使用agents-cli eval run在部署前系统化评估 Agent 的质量与性能见 SKILL.md。这与设计原则中“在 replica 预演环境模拟智能体间协调异常与意外行为再进入生产”的建议见 design-principles.md相呼应——预演不只是资源层的 dry-run还包括行为层的仿真测试。1.2 网络连通性与路由验证目的验证网络路径、负载均衡路由与服务端点是否符合预期确认流量能从公网入口正确到达后端 Agent 服务。验证命令模板原文curl -iv -H Host: [Target Domain] https://[LB-IP-Address]/healthz命令拆解-i在响应体前输出 HTTP 响应头用于核对状态码、Content-Type、Server 头等关键信息-vverbose输出完整的请求/响应交互过程包括 TLS 握手、DNS 解析、重定向链路与每个响应头便于定位证书、路由或代理层问题-H Host: [Target Domain]手动指定 HTTPHost头。当通过负载均衡器的 IP 地址直接访问、而该 IP 背后托管了多个域名服务时该参数用于让负载均衡按虚拟主机规则正确路由到目标后端https://[LB-IP-Address]/healthz对负载均衡 IP 的健康检查路径发起 HTTPS 请求。healthz是云原生服务常见的探活端点Agent 服务需确保暴露该路径。预期结果模板原文从正确的区域级regionalserverless 端点返回HTTP 200 OK。按工作负载定制的检查项模板在此处明确要求针对具体架构起草专属连通性检查例如负载均衡端点按上文方式逐一探测每个公开端点HTTP/HTTPS/WebSocketserverless VPC 路径时延当 Agent 通过 Serverless VPC Access connector 或 Direct VPC egress 访问私有资源时用time等工具观察路径时延是否符合性能要求私有数据库访问验证 Agent 到数据库如 Cloud SQL、AlloyDB的私有网络连通性确认没有绕过 VPC 走公网DNS 解析规则核对自定义域名、CNAME/A 记录以及跨项目解析是否符合预期。从仓库证据看架构侧依据产品映射文档中Cloud Run 网络入口的推荐主配置是“区域级外部应用负载均衡 Cloud Armor”用于 HTTP/HTTPS/WebSocket 入口并通过 Direct VPC egress 实现 Cloud Run 的私有网络访问见 product-mappings.md。因此连通性验证通常覆盖两条路径公网入口路径客户端 → 负载均衡 → Cloud Run 服务与私有出口路径Cloud Run → VPC 内数据库/工具。备选方案还包括 Global External ALB单一 anycast IP、全球低时延但 TLS 在边缘终止可能不满足严格区域数据驻留要求、Internal ALBVPC 内私有暴露与 Private Service Connect 接口需配合网络附件仅支持 RFC 1918 子网——这些备选会影响你验证的端点形态与网络路径见 product-mappings.md。部署后验证SKILL.md 还要求验证计划包含使用 Agents CLI 对已部署服务端点进行测试的步骤例如agents-cli run --url service-url直接对线上服务发起测试请求见 SKILL.md这是 curl 健康检查之外、面向 Agent 行为语义的端到端连通验证。1.3 安全与访问治理验证目的核对 IAM 角色映射、服务账号隔离与网络边界规则确认只有被授权的身份能访问系统资源。验证命令模板原文gcloud projects get-iam-policy [GCP-Project-ID] \ --flattenbindings[].members \ --formattable(bindings.role, bindings.members) \ --filterbindings.members:[Service-Account-Email]命令拆解gcloud projects get-iam-policy [GCP-Project-ID]拉取指定 GCP 项目的完整 IAM 策略输出为 JSON 结构其中bindings是role - members 列表的映射数组--flattenbindings[].members将嵌套的bindings[].members数组拍平使每个成员与它所属的 binding即角色形成独立行便于过滤与格式化--formattable(bindings.role, bindings.members)以表格形式仅展示role与members两列输出干净可读--filterbindings.members:[Service-Account-Email]只保留包含指定服务账号邮件的行从而聚焦审计某一个服务账号被授予的全部角色。预期结果模板原文确认该服务账号仅被授予指定角色落实最小权限principle of least privilege原则——即服务账号只拥有完成其职责所必需的最少权限不应出现通配权限或冗余角色。从仓库证据看该维度的扩展做法设计原则文档给出了与访问治理直接相关的安全基线可作为验证项的检查清单见 design-principles.md收敛公网暴露面禁用前端 Cloud Run 服务的默认run.appURL改由区域级外部应用负载均衡 Cloud Armor 承载请求过滤、速率限制与 DDoS 防护——验证时需确认默认 URL 已不可达A2A 通信安全使用带认证的扩展 agent card 保护 Agent2Agent 通信并附加 OpenID ConnectOIDC身份令牌让 IAM 校验只有被授权的 Agent 能访问数据人工介入流程纳入 human-in-the-loop 流程让监管者可监控、暂停、覆盖关键业务动作Agent Gateway 治理对 Gemini Enterprise Agent Runtime 部署用 Agent Gateway 治理、监控、保护客户端到 Agent 的入站流量与 Agent 到任意位置的出站流量并与 Agent Registry动态发现、Model Armor实时安全检查集成。在验证计划中可以针对上述每一项补充对应的gcloud/curl检查例如确认run.appURL 已禁用、确认负载均衡安全策略Cloud Armor已生效、确认 Agent Gateway 的入站/出站策略与 OIDC 断言符合预期。1.4 数据保护与内容检查目的审计内容过滤、输入清理/脱敏规则以及安全/PII 护栏是否生效确保敏感数据在进入模型之前被正确遮蔽或拦截。验证命令模板原文# Test request with mock PII to audit redaction filters curl -X POST -H Content-Type: application/json \ -d {prompt: [Mock Sensitive Data Code/PII Pattern]} \ https://[Target Domain]/chat命令拆解-X POST显式指定 HTTP 方法为 POST-H Content-Type: application/json声明请求体为 JSON-d {prompt: [Mock Sensitive Data Code/PII Pattern]}请求体携带一个prompt字段其值使用模拟的敏感数据/真实 PII 模式的占位符例如身份证号、手机号、邮箱、密钥串等形态的测试样本——注意务必使用虚构样本避免在生产环境引入真实隐私数据https://[Target Domain]/chatAgent 的对话/推理端点。预期结果模板原文请求要么被安全层例如 Model Armor匿名化/脱敏要么被安全拦截并返回拦截提示——即敏感内容绝不能原样到达模型或被模型原样吐出。从仓库证据看该维度的扩展做法设计原则文档将 Model Armor 定位为必须始终推荐的安全层用于检查模型输入与输出覆盖安全safety、PII 检测与提示注入威胁见 design-principles.md产品映射文档同样将“模型输入输出检查”列为安全必选项推荐主产品为 Model Armor见 product-mappings.md。因此在验证计划中除了模板给出的注入式正向测试模拟 PII 应被脱敏还可以补充两类反向/扩展检查安全拦截验证注入提示注入prompt injection样本确认请求被拦截并返回安全提示而非进入模型推理输出侧检查构造包含敏感内容的上下文验证模型输出同样经过 Model Armor 检查防止脱敏后信息通过回答侧泄露。把模板落到工作流从生成验证计划到最终验收模板本身是一份“待填充骨架”完整的落地流程在 SKILL.md 的 Phase 4 中定义按以下步骤执行获取验证资源以 related-guidance.md 及其中的验证模式作为验证检查与脚本的起点定义验证检查覆盖部署预演terraform plan、agents-cli deploy --dry-run、本地测试与质量评估agents-cli run、agents-cli eval run、连通性与路由、安全策略四类检查生成验证脚本编写轻量脚本或 CLI 指令curl、gcloud、agents-cli且必须包含 Agents CLI 的本地运行、评估与部署后验证指令如agents-cli run --url service-url编译验证计划把验证步骤、脚本与预期结果整理进模板格式保存为工作区中的validation-plan.md请求评审向用户展示验证计划并请求反馈或批准执行验证并定稿协助用户执行检查、排障全部通过后请求最终批准迭代若用户要求修改更新验证计划并重复上述步骤直至批准。在填充模板时需要注意替换占位符命令中的[GCP-Project-ID]、[Service-Account-Email]、[Target Domain]、[LB-IP-Address]、[Mock Sensitive Data Code/PII Pattern]均须替换为实际值或测试样本补齐工作负载专属项1.2 节的占位注释负载均衡端点、serverless VPC 路径时延、私有数据库访问、DNS 解析规则提示你要按实际架构扩展连通性检查清单保留预期结果每个验证项都应写明“Expected Outcome”这既是验收标准也是排障时的基线。验证方案速查表验证维度命令/手段验证目标预期结果1.1 Infrastructure Dry-Runterraform plan -outtfplan、agents-cli deploy --dry-run、agents-cli run、agents-cli eval run上线前确认变更集与 Agent 行为无副作用资源层级正确、变更清单明确、无配置错误1.2 Connectivity Routingcurl -iv -H Host: ... https://[LB-IP]/healthz、agents-cli run --url service-url公网入口、私有出口、负载均衡路由、DNS从正确的 regional serverless 端点返回HTTP 200 OK1.3 Security Access Governancegcloud projects get-iam-policy ... --flatten --format --filterIAM 角色映射、服务账号隔离、网络边界仅授予指定角色符合最小权限原则1.4 Data Protection Content Inspectioncurl -X POST注入模拟 PII / 提示注入样本内容过滤、脱敏、PII 与安全护栏被 Model Armor 脱敏或返回安全拦截提示配套文档与延伸阅读本技能仓库围绕“设计 → 实施 → 验证”提供了完整的模板与参考体系验证计划只是其中一环SKILL.md四阶段工作流总纲验证计划的生成规则在 Phase 4validation-template.md本文讲解的验证计划模板本体implementation-template.mdPhase 3 实施计划模板验证计划验证的就是它所生成的部署结果solution-template.mdPhase 2 解决方案架构模板定义了架构、产品映射与设计建议的文档结构product-mappings.md组件到 Google Cloud 产品的映射与备选方案权衡用于判断验证对象负载均衡形态、VPC 出口、模型运行时等design-principles.md安全、可靠性、成本、性能等支柱的设计原则是验证项最小权限、Model Armor、Cloud Armor 等的检查基准related-guidance.mdGoogle Cloud 官方架构文档、ADK 开发与部署指南、Agents CLI 等外部资料的汇总入口作为验证模式与排障知识来源。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考