Agent Starter Pack ADK 部署实战指南从 Terraform 基础设施、Secret 管理到 CI/CD 生产发布【免费下载链接】agent-starter-packShip AI Agents to Google Cloud in minutes, not months. Production-ready templates with built-in CI/CD, evaluation, and observability.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-starter-pack本指南基于 Agent Starter Pack 仓库中的 ADK 部署指南 编写系统讲解 ADKAgent Development KitAgent 从开发环境到生产环境的完整部署链路如何用 Terraform 声明式地创建自定义云基础设施、如何用 Secret Manager 安全托管 API 凭证、如何运行部署前测试、如何在开发环境验证后选择「单项目直连」或「全量 CI/CD」两条生产路线以及部署完成后如何测试 Agent Engine / Cloud Run 上的服务、验证 A2A 协议调用并执行负载测试。读完本文你将掌握一条可复制、可审计、可回滚的 ADK Agent 上线流程并理解 Agent Starter Pack 模板中每一个部署环节背后的源码实现。一、部署全景ADK Agent 的完整上线路径Agent Starter Pack 生成的 ADK 项目自带一套围绕Makefile组织的部署工作流。仓库根目录的 Makefile 展示了核心命令的语义make test运行uv run pytest tests对项目做测试make test-e2e加载tests/cicd/.env后执行端到端部署测试make load-test触发基于 Locust 的并发压测。部署相关命令make setup-dev-env、make deploy、make playground、make local-backend则定义在生成后的 agent 项目内部由 cookiecutter 模板按部署目标agent_engine / cloud_run / gke注入。一个典型的 ADK Agent 上线流程如下在本地完成 Agent 开发与评估评估阈值达标运行make test通过全部测试经人工确认后make deploy部署到开发环境进行实测在 dev 环境验证通过后与用户确认选择生产路线Option A 单项目直连 或 Option B 全量 CI/CD部署完成后通过 Notebook、Python SDK、Playground 或 curl 对线上 Agent 做验证并按需执行负载测试。下文按这条链路逐一展开。二、自定义基础设施坚持 Terraform 声明式杜绝手敲 gcloud原文档开篇即给出最高优先级原则CRITICAL当 Agent 需要自定义基础设施Cloud SQL、Pub/Sub Topic、Eventarc 触发器、BigQuery 数据集、VPC Connector 等时必须在 Terraform 中定义绝不能通过gcloud命令手工创建资源。手工创建的资源不进入 Terraform state会导致后续terraform apply覆盖、删除或产生漂移且无法纳入 CI/CD 的审计链路。2.1 自定义 Terraform 放哪里场景位置使用时机仅开发环境的基础设施deployment/terraform/dev/快速原型验证、单环境部署Option ACI/CD 环境staging/proddeployment/terraform/生产部署需要 staging/prod 环境隔离Option B在 Agent Starter Pack 模板中deployment/terraform/dev/与deployment/terraform/是一套并行目录dev 目录只作用于开发项目顶层目录则通过local.deploy_project_ids映射到 staging 和 prod 两个项目。仓库中 agent_starter_pack/deployment_targets/cloud_run/python/deployment/terraform/dev/ 与 agent_starter_pack/base_templates/_shared/deployment/terraform/ 分别是这两个层级的模板源码后者包含providers.tf、locals.tf、service_accounts.tf、wif.tf、build_triggers.tf、github.tf等生产级配置为 CI/CD 路线预置了 WIFWorkload Identity Federation与构建触发器。2.2 为开发环境添加自定义资源在deployment/terraform/dev/下新建.tf文件即可。原文档给出的完整示例可直接复制到生成项目中# deployment/terraform/dev/custom_resources.tf # 示例用于事件处理的 Pub/Sub Topic resource google_pubsub_topic events { name ${var.project_name}-events project var.dev_project_id } # 示例用于分析的 BigQuery 数据集 resource google_bigquery_dataset analytics { dataset_id ${replace(var.project_name, -, _)}_analytics project var.dev_project_id location var.region } # 示例Cloud Storage 触发的 Eventarc 触发器 resource google_eventarc_trigger storage_trigger { name ${var.project_name}-storage-trigger location var.region project var.dev_project_id matching_criteria { attribute type value google.cloud.storage.object.v1.finalized } matching_criteria { attribute bucket value google_storage_bucket.uploads.name } destination { cloud_run_service { service google_cloud_run_v2_service.app.name region var.region path /invoke } } service_account google_service_account.app_sa.email }注意var.project_name、var.dev_project_id、var.region是模板预置的输入变量可在deployment/terraform/dev/variables.tf或vars/env.tfvars中查看与覆盖。2.3 为 staging/prod 添加自定义资源CI/CD 环境Option B的资源要加到deployment/terraform/下该目录中的资源会同时应用到 staging 和 prod 两个项目因此要用for_each配合local.deploy_project_ids实现多环境创建# deployment/terraform/custom_resources.tf # 这里的资源会在 staging 和 prod 两个项目中同时创建 # 使用 for_each 配合 local.deploy_project_ids 实现多环境 resource google_pubsub_topic events { for_each local.deploy_project_ids name ${var.project_name}-events project each.value }2.4 为自定义资源配置 IAM新增资源后必须保证 Agent 运行所用的 App Service Account 具备访问权限。在deployment/terraform/dev/iam.tf或deployment/terraform/iam.tf中添加绑定# 示例授予 Pub/Sub 发布者权限 resource google_pubsub_topic_iam_member app_publisher { topic google_pubsub_topic.events.name project var.dev_project_id role roles/pubsub.publisher member serviceAccount:${google_service_account.app_sa.email} } # 示例授予 BigQuery 数据编辑权限 resource google_bigquery_dataset_iam_member app_editor { dataset_id google_bigquery_dataset.analytics.dataset_id project var.dev_project_id role roles/bigquery.dataEditor member serviceAccount:${google_service_account.app_sa.email} }2.5 应用基础设施# 仅开发环境的基础设施 make setup-dev-env # 在 deployment/terraform/dev/ 中执行 terraform apply # CI/CD 环境的基础设施自动应用 # - setup-cicd 时Terraform 会同时为 staging 和 prod 执行 # - git push 后CI/CD 流水线自动执行 terraform plan/apply仓库源码对这套原则有直接印证在 cloud_run 的 dev service.tf 中模板用resource random_password db_password、google_sql_database_instance、google_secret_manager_secret等资源组合把 Cloud SQL 实例、数据库、用户、密码托管全部声明式地生成出来并借助lifecycle { ignore_changes [template[0].containers[0].image] }防止 Terraform 覆盖由 Cloud Run 部署流程如 CI/CD 管道更新的容器镜像——这正是Terraform 管基础设施、部署管道管镜像职责分离的体现。2.6 常见模式速查模式要点Cloud Storage 触发EventarcTerraform 中建 bucket创建指向/invoke端点的 Eventarc 触发器给 App Service Account 授予eventarc.eventReceiver角色Pub/Sub 处理Terraform 中创建 Topic 与 push subscriptionsubscription 指向/invoke端点授予iam.serviceAccountTokenCreator角色以支持 push 认证BigQuery Remote FunctionTerraform 中创建 BigQuery connection授予 connection 的 Service Account 调用 Cloud Run 的权限部署后通过 SQL 创建 remote functionCloud SQL 会话使用--session-type cloud_sql时由 ASP 模板自动配置额外的表/结构可通过迁移脚本添加关于 Cloud SQL 的自动配置可从 fast_api_app.py 模板 中看到运行时侧的实现模板读取DB_USER、DB_NAME、DB_PASS、INSTANCE_CONNECTION_NAME环境变量拼接出postgresqlasyncpg://...?host/cloudsql/...的 Unix Socket 连接串并对用户名、密码、实例名做了 URL 编码防止[、?、#、$等特殊字符破坏连接串解析。三、Secret Manager托管 API 凭证的正确姿势把 API Key 等敏感信息直接塞进环境变量存在被日志记录或在控制台泄露的风险。原文档明确建议使用 GCP Secret Manager 托管凭证。Agent Starter Pack 的 Cloud Run 模板在生成 Terraform 时会默认把数据库密码存入 Secret Manager见 dev/service.tf 中google_secret_manager_secret.db_password与google_secret_manager_secret_version.db_password的声明以及容器环境变量中通过secret_key_ref引用latest版本的做法。3.1 通过 gcloud 存储密钥# 创建密钥从 stdin 读取内容 echo -n YOUR_API_KEY | gcloud secrets create MY_SECRET_NAME --data-file- # 更新已有密钥新增一个版本 echo -n NEW_API_KEY | gcloud secrets versions add MY_SECRET_NAME --data-file-3.2 授权 Agent 的 Service AccountAgent 的 Service Account 需要Secret Manager Secret Accessor角色。对于部署在 Agent Engine 上的 Agent其底层使用的是 AI Platform RE 系统服务账号PROJECT_ID$(gcloud config get-value project) PROJECT_NUMBER$(gcloud projects list --filterproject_id:$PROJECT_ID --formatvalue(project_number)) SA_EMAILservice-$PROJECT_NUMBERgcp-sa-aiplatform-re.iam.gserviceaccount.com gcloud projects add-iam-policy-binding $PROJECT_ID \ --memberserviceAccount:$SA_EMAIL \ --roleroles/secretmanager.secretAccessor3.3 部署时注入密钥Agent Engine 部署通过SECRETS变量在部署时传入格式为ENV_VARSECRET_ID或ENV_VARSECRET_ID:VERSION省略版本时默认使用latestmake deploy SECRETSAPI_KEYmy-api-key,DB_PASSdb-password:2如需从已部署的 Agent 上移除全部密钥make deploy SECRETSAgent 代码中通过os.environ读取支持 JSON 格式的密钥import os import json api_key os.environ.get(API_KEY) # JSON 格式的密钥 db_creds json.loads(os.environ.get(DB_PASS, {}))Cloud Run 部署将密钥挂载为环境变量gcloud run deploy SERVICE_NAME \ --set-secretsAPI_KEYmy-api-key:latest,DB_PASSdb-password:2代码中同样通过os.environ读取import os api_key os.environ.get(API_KEY)3.4 运行时主动拉取密钥如果不想在部署时注入也可以在运行时直接用 Secret Manager SDK 拉取适合需要轮转、按需读取的场景from google.cloud import secretmanager import google.auth def get_secret(secret_id: str) - str: Retrieves the latest version of a secret from Secret Manager. _, project_id google.auth.default() client secretmanager.SecretManagerServiceClient() name fprojects/{project_id}/secrets/{secret_id}/versions/latest response client.access_secret_version(request{name: name}) return response.payload.data.decode(UTF-8) API_KEY get_secret(MY_SECRET_NAME)四、部署前测试与开发环境部署4.1 部署前测试评估阈值达标后、正式部署之前先运行全量测试make test若测试失败修复问题后重跑直到全部通过。仓库根目录 Makefile 中test目标执行uv run pytest tests覆盖单元与集成测试对于部署目标为 agent_engine 的项目集成测试位于 test_agent_engine_app.py例如test_agent_stream_query通过async_stream_query验证流式响应并断言至少存在一段文本内容test_agent_feedback验证反馈注册并断言非法分数会抛出ValueError。4.2 部署到开发环境部署到 dev 环境做最终联调遵循「人工把关」流程通知人类Eval scores meet thresholds and tests pass. Ready to deploy to dev?评估达标、测试通过是否可部署到 dev等待明确批准批准后执行make deploy。IMPORTANT未经人工明确批准绝不执行make deploy。make deploy会将 Agent 部署到 dev GCP 项目供联机测试。4.3 部署超时处理Agent Engine 的部署通常需要5-10 分钟。若make deploy超时按以下步骤确认查询 Agent Engine 是否已创建成功import vertexai client vertexai.Client(locationus-east1) for engine in client.agent_engines.list(): print(engine.name, engine.display_name)若引擎已存在将引擎 ID 写入deployment_metadata.json。该文件是部署元数据的唯一来源模板默认内容为{remote_agent_engine_id: None, deployment_timestamp: None}见 deployment_metadata.json部署完成后会被写入真实的引擎资源名供后续测试脚本自动加载。五、生产部署两条路线二选一在 dev 环境验证通过后先询问用户偏好哪种部署方式。5.1 Option A单项目直连部署推荐入门适用场景个人项目或原型无复杂 CI/CD 需求的团队希望快速部署到单一环境步骤make setup-dev-env # 1. 初始化基础设施 make deploy # 2. 部署优点设置简单、上手快只需管理一个 GCP 项目部署可控、直接缺点无自动化 staging/prod 流水线每次都是手工部署push 时无自动化测试5.2 Option B全量 CI/CD 流水线推荐生产适用场景生产级应用需要 staging - production 晋升机制的团队需要自动化测试与部署工作流前置条件项目不能位于被 gitignore 的目录中用户提供 staging 与 production 两个 GCP 项目 ID提供 GitHub 仓库名与 owner注意setup-cicd会在需要时自动初始化 git。步骤若是原型项目先补全 Terraform/CI-CD 文件编程方式调用--cicd-runner配合-y可跳过交互提示uvx agent-starter-pack enhance . \ --cicd-runner github_actions \ -y -s确保已登录 GitHub CLIgh auth login # 已认证可跳过使用 GCP 项目 ID 运行 setup-cicd无需 PAT使用 gh authuvx agent-starter-pack setup-cicd \ --staging-project YOUR_STAGING_PROJECT \ --prod-project YOUR_PROD_PROJECT \ --repository-name YOUR_REPO_NAME \ --repository-owner YOUR_GITHUB_USERNAME \ --auto-approve \ --create-repository说明CI/CD runner 类型会根据enhance生成的 Terraform 文件自动检测。在 staging 和 production 两个项目中创建基础设施配置 GitHub Actions 触发器push 代码触发部署。优点每次 push 自动测试安全的 staging - production 晋升完整审计轨迹与审批工作流缺点需要 2-3 个 GCP 项目staging、prod、可选 cicd初始设置耗时更长依赖 GitHub 仓库上述命令的实现可在仓库 cli/commands/setup_cicd.py 与 cli/commands/enhance.py 中查看CI/CD 所需的 WIF、service account、构建触发器定义在 base_templates/_shared/deployment/terraform/ 下wif.tf、service_accounts.tf、build_triggers.tf、github.tf等Terraform 会据此自动配置 GitHub 侧的 secrets 与 variables。5.3 选择 CI/CD RunnerRunner优点缺点github_actions默认无需 PAT使用gh auth基于 WIF全自动化需要 GitHub CLI 认证google_cloud_build原生 GCP 集成需要交互式浏览器授权或编程模式下提供 PAT App 安装 ID认证原理github_actionsTerraform 的 GitHub provider 自动使用你的gh auth凭据无需单独导出 PATgoogle_cloud_build交互模式走浏览器授权编程模式需要--github-pat与--github-app-installation-id。六、CI/CD 设置完成后激活流水线IMPORTANTsetup-cicd只创建基础设施不会自动部署 Agent。Terraform 会自动配置所有必需的 GitHub secrets 与 variablesWIF 凭据、项目 ID、Service Account 等无需手工配置。6.1 提交并推送git add . git commit -m Initial agent implementation git push origin main6.2 监控部署GitHub Actions在仓库的 Actions 标签页查看Cloud Buildgcloud builds list --projectYOUR_CICD_PROJECT --regionYOUR_REGIONstaging 部署push 到 main 后自动触发。production 部署需要人工审批# GitHub Actions推荐在仓库 Actions 标签页审批 # 生产部署由环境保护规则environment protection rules把关 # Cloud Build找到 pending 的构建并审批 gcloud builds list --projectPROD_PROJECT --regionREGION --filterstatusPENDING gcloud builds approve BUILD_ID --projectPROD_PROJECT七、CI/CD 排障与监控7.1 常见问题速查问题解决方案Terraform state 被锁在deployment/terraform/中执行terraform force-unlock LOCK_IDCloud Build 授权挂起改用github_actionsrunnerGitHub Actions 认证失败确认 Terraform 已成功完成重新执行terraform applyTerraform apply 失败检查 GCP 权限与 API 是否启用资源已存在用terraform import将现有资源导入 stateAgent Engine 部署超时部署需 5-10 分钟通过gh run view RUN_ID查看状态7.2 监控 CI/CD 部署# 列出最近的工作流运行 gh run list --repo OWNER/REPO --limit 5 # 查看运行详情与任务状态 gh run view RUN_ID --repo OWNER/REPO # 查看具体任务的日志完成后 gh run view --jobJOB_ID --repo OWNER/REPO --log # 实时观察部署进度 gh run watch RUN_ID --repo OWNER/REPO八、测试已部署的 Agent部署完成后即可对线上 Agent 进行验证测试方式取决于部署目标。部署端点在make deploy完成后写入deployment_metadata.json。8.1 测试 Agent Engine 部署Agent 已部署到 Vertex AI Agent Engine有三种方式方式 1使用测试 Notebook推荐jupyter notebook notebooks/adk_app_testing.ipynbNotebook 会自动从deployment_metadata.json加载部署信息提供通过vertexai.Client进行远程测试使用async_stream_query做流式查询反馈feedback注册仓库中提供了现成的 Notebook 模板例如 adk 的 adk_app_testing.ipynb 与 adk_a2a 的 adk_app_testing.ipynb。方式 2Python 脚本import json import vertexai # 加载部署信息 with open(deployment_metadata.json) as f: engine_id json.load(f)[remote_agent_engine_id] # 连接 Agent client vertexai.Client(locationus-east1) agent client.agent_engines.get(nameengine_id) # 发送消息 async for event in agent.async_stream_query(messageHello!, user_idtest): print(event)方式 3使用 Playgroundmake playground # 浏览器打开 http://localhost:80008.2 测试 Cloud Run 部署Agent 已部署到 Cloud Run也有三种方式方式 1测试 Notebook推荐同上打开notebooks/adk_app_testing.ipynb。方式 2Python 脚本使用 ADK 的 HTTP API先建会话再发消息import json import requests SERVICE_URL YOUR_SERVICE_URL # 从 deployment_metadata.json 获取 ID_TOKEN !gcloud auth print-identity-token -q headers {Content-Type: application/json, Authorization: fBearer {ID_TOKEN[0]}} # 第 1 步创建会话 user_id test_user session_resp requests.post( f{SERVICE_URL}/apps/your-agent-directory/users/{user_id}/sessions, headersheaders, json{state: {}} ) session_id session_resp.json()[id] # 第 2 步发送消息SSE 流式 message_resp requests.post( f{SERVICE_URL}/run_sse, headersheaders, json{ app_name: your-agent-directory, user_id: user_id, session_id: session_id, new_message: {role: user, parts: [{text: Hello!}]}, streaming: True }, streamTrue ) for line in message_resp.iter_lines(): if line and line.decode().startswith(data: ): print(json.loads(line.decode()[6:]))这段请求格式与仓库 Cloud Run 负载测试脚本 中ChatStreamUser的实现一一对应先POST /apps/agent_directory/users/{user_id}/sessions创建会话再向/run_sse提交new_message并解析 SSE 事件流Cloud Run 端点的实现可参考 fast_api_app.py 模板 中get_fast_api_app(agents_dirAGENT_DIR, webTrue, ...)的装配逻辑。方式 3Playgroundmake playground后打开http://localhost:8000。8.3 为前端 UI 部署启用 IAP若需要认证访问 UI私有部署默认推荐启用# 部署前端在 Cloud Build 上构建避免 Apple Silicon 的 ARM/AMD64 架构不匹配问题 gcloud run deploy SERVICE --source . --region REGION # 启用 IAP gcloud beta run services update SERVICE --region REGION --iap # 授权用户访问 gcloud beta iap web add-iam-policy-binding \ --resource-typecloud-run \ --serviceSERVICE \ --regionREGION \ --memberuser:EMAIL \ --roleroles/iap.httpsResourceAccessor注意IAP 访问授权请使用iap web add-iam-policy-binding不要使用run services add-iam-policy-binding后者用于授予roles/run.invoker角色语义不同。九、测试 A2A 协议 AgentAgent 通过 A2AAgent-to-Agent协议实现 Agent 间通信。原文档建议参考tests/integration/下的集成测试来学习正确的消息格式与 API 用法。仓库中 agent_engine 的集成测试 提供了可直接对照的样例test_agent_on_message_send构造messageId/role/content完整消息并轮询任务完成test_agent_card则断言了 A2A Agent Card 的核心字段——protocolVersion 0.3.0、preferredTransport HTTPJSON、capabilities.streaming以及skills列表结构。9.1 A2A 常见错误与修复错误现象修复用content而非textInvalid message format使用parts[].text不要用parts[].content用input而非messageMissing message parameter使用params.message不要用params.input缺少messageIdValidationError每个请求都要带message.messageId缺少roleValidationError必须包含message.role通常为 user9.2 A2A 协议关键细节协议版本0.3.0传输协议JSON-RPC 2.0必填字段task_id、message.messageId、message.role、message.partsPart 结构{text: ..., mimeType: text/plain}9.3 按部署目标选择测试方式Agent Engine使用测试 Notebook 或 Python SDK参考集成测试Cloud Run使用带身份令牌的 curl 或测试 Notebook。9.4 示例在 Cloud Run 上测试 A2A Agent# 从部署输出或 Cloud Console 获取服务 URL SERVICE_URLhttps://your-service-url.run.app # 使用 A2A 协议发送测试消息 curl -X POST \ -H Authorization: Bearer $(gcloud auth print-identity-token) \ -H Content-Type: application/json \ -d { jsonrpc: 2.0, method: message/send, params: { task_id: test-task-001, message: { messageId: msg-001, role: user, parts: [ { text: Your test query here, mimeType: text/plain } ] } }, id: req-1 } \ $SERVICE_URL/a2a/your-agent-directory # 获取 Agent Card描述 Agent 能力 curl -H Authorization: Bearer $(gcloud auth print-identity-token) \ $SERVICE_URL/a2a/your-agent-directory/.well-known/agent-card.json/a2a/agent-directory路由在 fast_api_app.py 模板 中由A2AFastAPIApplication动态注册模板通过A2aAgentExecutor(runnerrunner)包装 ADK Runner将A2A_RPC_PATH设为/a2a/{adk_app.name}并在 lifespan 中把 RPC 端点、Agent Card 端点AGENT_CARD_WELL_KNOWN_PATH与扩展卡端点一并挂载到 FastAPI 应用上。十、运行负载测试对已部署的 Agent 执行并发压测make load-test该命令基于Locust模拟多个并发用户。仓库中的 load_test.py 展示了完整的压测实现ChatStreamUser继承HttpUserwait_time between(1, 3)模拟 1-3 秒思考间隔每次任务都会创建独立user_id、创建会话、发送流式消息并逐行解析 SSE 响应——特别地脚本会检测429 Too Many Requests以单独统计被限流的请求同时解析事件 JSON 中的code字段将任何 400的错误标记为请求失败避免状态码 200 但流内报错被误判为成功。若环境变量_ID_TOKEN存在还会自动附加 Bearer 身份令牌对应 Cloud Run 的 IAM 认证场景。十一、高级进阶批处理与事件处理11.1 何时使用批处理/事件处理当前 Agent 以交互式服务运行但很多场景需要异步处理大批量数据批处理BigQuery Remote Function用 Gemini 处理海量行例如SELECT analyze(customer_data) FROM customers数据管道集成从 Dataflow、Spark 或其他批处理系统触发 Agent 分析事件驱动处理Pub/Sub实时响应事件例如订单处理、欺诈检测Eventarc响应 GCP 事件例如 Cloud Storage 新增文件Webhooks接受外部系统的 HTTP 回调11.2 添加 /invoke 端点在 Agent 的fast_api_app.py中添加/invoke端点即可支持批处理/事件处理。该端点会自动识别输入格式BigQuery Remote Function、Pub/Sub、Eventarc 或直接 HTTP。核心模式用RunnerInMemorySessionService创建无状态处理的run_agent辅助函数配合信号量semaphore做并发控制然后按请求结构分流app.post(/invoke) async def invoke(request: Dict[str, Any]): if calls in request: # BigQuery: {calls: [[row1], [row2]]} results await asyncio.gather(*[run_agent(fAnalyze: {row}) for row in request[calls]]) return {replies: results} if message in request: # Pub/Sub: {message: {data: base64...}} payload base64.b64decode(request[message][data]).decode() return {status: success, result: await run_agent(payload)} if type in request: # Eventarc: {type: google.cloud..., data: {...}} return {status: success, result: await run_agent(str(request[data]))} if input in request: # Direct HTTP: {input: prompt} return {status: success, result: await run_agent(request[input])}11.3 本地验证先用make local-backend起本地服务再分别用 curl 测试各格式# BigQuery 格式 curl -X POST http://localhost:8000/invoke -H Content-Type: application/json \ -d {calls: [[test input 1], [test input 2]]} # 直接 HTTP 格式 curl -X POST http://localhost:8000/invoke -H Content-Type: application/json \ -d {input: your prompt here}11.4 对接 GCP 服务# Pub/Sub push subscription gcloud pubsub subscriptions create my-sub --topicmy-topic \ --push-endpointhttps://your-service-name.run.app/invoke # Eventarc 触发器 gcloud eventarc triggers create my-trigger \ --destination-run-serviceyour-service-name \ --destination-run-path/invoke \ --event-filterstypegoogle.cloud.storage.object.v1.finalized11.5 生产级注意事项使用信号量限制并发 Gemini 调用避免触发 429 限流设置 Cloud Run--max-instances限制最大实例数返回逐行per-row错误而非让整个批次失败保证部分成功可用。结语把部署也变成可审计的工程资产回顾全文Agent Starter Pack 的 ADK 部署体系可以浓缩为四条纪律基础设施全部 Terraform 化杜绝手工 gcloud、凭证全部走 Secret Manager杜绝明文环境变量、生产发布必须经过人工闸门与 staging 晋升杜绝裸奔上线、线上能力用测试与压测闭环验证杜绝能跑就行。当这四条纪律落实为make命令与 CI/CD 流水线后从本地原型到生产发布的时间被压缩到几次命令与一次 git push而每一步都留有审计轨迹这正是本仓库Ship AI Agents to Google Cloud in minutes的工程根基。【免费下载链接】agent-starter-packShip AI Agents to Google Cloud in minutes, not months. Production-ready templates with built-in CI/CD, evaluation, and observability.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-starter-pack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考