AI智能体Skill工程实战：从函数到可部署服务的完整落地指南

2026/10/8 5:34:56 拓冰建站浏览量

1. 这不是“技能列表”而是一套可执行、可验证、可集成的智能体能力系统你搜“skills”时看到的那些词——Google Cloud、GKE、Gemini、Agent Platform、superpower skills、gemini code assist、claude agent skills、codex skills、reasonix安装新skills……它们表面是零散热词实则指向一个正在快速收敛的技术共识现代AI工程中“skills”已不再是抽象能力描述而是具备明确定义接口、可独立部署、可组合调用、可版本管理的最小功能单元。它既不是前端开发里“会Vue就算有skills”的模糊标签也不是简历上“沟通能力强”这类无法验证的软性表述它是运行在Kubernetes集群上的轻量服务是Gemini Agent Platform里被skill注解标记的Python函数是Claude调用时通过tool_use协议触发的标准化动作是Codex在写论文时自动调用的文献检索格式校验引用生成三段式流水线。我从2021年就开始在生产环境落地这类能力模块最早用Flask封装NLP预处理逻辑后来迁移到GKE上跑gRPC微服务再到去年全面转向Gemini Agent Platform的Skill SDK。过程中踩过太多坑比如把一个PDF解析skill当成纯函数调用结果因超时被Agent平台静默降级又比如在本地测试好好的reasonix skill一上GKE就因缺失/dev/shm挂载导致多进程崩溃还有更隐蔽的——Gemini Code Assist报错“your account is not eligible”根本不是权限问题而是你注册时选的地区不支持该skill的底层模型调度策略。这些都不是文档里写的是日志里一行行grep出来的。这篇文章不讲概念不列清单只讲怎么让一个skill真正跑起来、稳得住、查得清、扩得开。适合三类人一是正在用Gemini或Claude做Agent开发的工程师需要知道skill不是写个函数就能用二是运维侧同学得明白GKE上部署skill和普通API服务的关键差异三是技术决策者想搞清为什么“skills推荐”背后是整套基础设施重构。全文所有步骤、参数、配置都来自我们线上灰度环境的真实快照连GKE节点池的--preemptible开关要不要开、Gemini Skill SDK里max_retries2设成3会不会引发雪崩都给你算清楚。2. 技术本质拆解skills为何必须脱离“函数思维”走向“服务化实体”2.1 从“函数”到“skill”的四个不可逆转变很多人第一次写skill习惯性地把它当成一个带装饰器的Python函数skill def search_papers(query: str) - List[Paper]: return _call_arxiv_api(query)这看似简洁但实际在生产中会立刻撞墙。原因在于skill的本质是跨信任域、跨网络边界、跨生命周期的协作契约而函数只是单机内存里的执行片段。这种认知偏差会导致四个致命问题状态隔离失效函数内定义的cache {}在GKE多副本下变成每个Pod各自维护一份缓存命中率暴跌。真实方案必须用Redis或GCP Memorystore且连接池要按Pod数动态伸缩——我见过团队因没配max_connections50导致10个Pod抢20个连接大量请求卡在WAITING_FOR_CONNECTION。错误传播失真函数抛出ValueError(timeout)Agent平台可能直接转成{error: unknown}。而规范的skill必须返回结构化错误码如422_UNPROCESSABLE_ENTITY和机器可读的error_codeARXIV_RATE_LIMIT否则下游无法做熔断策略。Gemini SDK里SkillResult.error_code字段就是为此设计的。资源约束失控本地跑search_papers(LLM)耗时800ms但上线后发现峰值QPS 200时单Pod CPU飙升到95%原因是没设resource.limits.cpu500mK8s默认给1核而arXiv API响应波动大GC压力陡增。我们最终在Helm chart里强制加了resources.requests.memory1Gi因为实测低于这个值PyArrow反序列化会OOM。可观测性归零函数里print(start search)在GKE里全进/dev/null。真正的skill必须注入OpenTelemetry tracer且Span name要带skill名如skill.search_papers否则在Jaeger里根本分不清是哪个skill拖慢了整个Agent链路。我们甚至给每个skill加了service.name标签这样在Cloud Monitoring里能直接看agent_skill_latency_ms{skill_namesearch_papers}。提示别信“serverless就不用管资源”的说法。GKE上skill的Pod本质是常驻服务CPU limit设太低会触发Linux OOM Killer设太高又浪费成本。我们用kubectl top pods --use-protocol-buffers持续采样72小时取P95 CPU使用率×1.8作为limit值这是最稳的实践。2.2 Google Cloud生态下的skill分层架构当你在Google Cloud控制台点开Agent Platform看到的“skills”列表其实是三层架构的聚合视图层级组件关键特性典型问题底座层GKE集群 Anthos Config Management提供K8s原生调度、Istio服务网格、Binary Authorization镜像签名节点池OS镜像未启用containerd导致skill init容器启动失败运行时层Gemini Skill SDK Cloud Run for Anthos自动注入gRPC网关、JWT鉴权中间件、Prometheus指标暴露端点cloud-run-proxysidecar未配置--enable-tracingSpan丢失能力层用户定义的skill包含Dockerfile、skill.yaml、main.py支持skill装饰器、SkillContext上下文注入、ToolResult标准化返回skill.yaml里version: 1.2.0未同步更新requirements.txt中的google-cloud-aiplatform1.26.0这个分层不是理论模型而是我们踩坑后画的拓扑图。比如“gemini macbook 下载”热词背后其实是Mac用户想本地调试skill但Gemini SDK默认依赖grpcio1.60.0而macOS Monterey的Python 3.9.16自带openssl 1.1与新版grpcio冲突。解决方案不是降级grpcio会丢gRPC-Web支持而是用pyenv装Python 3.11.8再编译安装——这个细节官网文档根本没提。再比如“claude 国内安装skills 官方市场”这个需求本质是网络策略问题。Claude的skill registry走的是AWS us-east-1国内直连延迟300ms。我们最终在GKE集群里部署了istio-ingressgateway配置DestinationRule强制走阿里云CDN中转把平均延迟压到87ms且成功率从92%升到99.97%。2.3 为什么“superpower skills”必须绑定具体基础设施热词里反复出现的“superpower skills”听起来很玄其实就两件事极低延迟响应极高置信度输出。但这两点完全依赖底层设施延迟控制一个“分镜skills”要求200ms内返回5帧关键画面坐标。我们实测发现单纯优化Python代码只能到320ms瓶颈在GPU显存带宽。最终方案是把TensorRT引擎固化到nvidia.com/gpu: 1的NodePool且用hostPath挂载预编译的.engine文件跳过runtime编译——这步让P99延迟从410ms降到186ms。置信度保障所谓“codex写论文的skills”核心是引用校验。我们最初用正则匹配DOI结果把10.1000/xyz123误判为无效。后来改用Crossref API但发现其/works端点QPS限制严苛。最终方案是在GKE上起一个crossref-proxyDeployment用Redis做LRU缓存TTL1h且对429 Too Many Requests自动退避重试——这个proxy现在日均处理27万次请求缓存命中率83%。注意“nature skills”这类热词表面是领域名词实则是模型权重领域词典后处理规则的三位一体。我们部署Nature Journal的skill时发现其bert-base-cased模型在TPU v3上推理慢换成distilbert-base-uncased后精度掉0.7%但吞吐翻3倍。权衡后选择后者因为Agent平台SLA要求99%请求500ms精度损失由下游人工复核兜底。3. 实操全流程从本地开发到GKE生产部署的12个关键环节3.1 环境准备避开MacBook与Windows的三大陷阱本地开发环境是第一个雷区。“gemini macbook 下载”热词背后90%的人卡在环境配置。我们统一用VS Code Remote - ContainersDockerfile基于gcr.io/google.com/cloudsdk:440.0.0构建关键配置如下# Dockerfile.dev FROM gcr.io/google.com/cloudsdk:440.0.0 # 必须装这个否则gcloud auth login失败 RUN apt-get update apt-get install -y libsecret-1-0 # Python环境用pyenv避免版本冲突 RUN curl https://pyenv.run | bash \ export PYENV_ROOT$HOME/.pyenv \ export PATH$PYENV_ROOT/bin:$PATH \ eval $(pyenv init -) # 安装指定版本Python RUN pyenv install 3.11.8 pyenv global 3.11.8 # 安装skill SDK及依赖 RUN pip install google-cloud-aiplatform1.26.0 \ grpcio-tools1.60.0 \ opentelemetry-exporter-google-cloud1.10.0Windows用户特别注意不要用WSL2跑GKE kubectl。我们实测发现WSL2的/mnt/c/路径在kubectl cp时会触发NTFS权限错误。正确做法是用PowerShell原生命令且kubeconfig必须放在C:\Users\${USER}\.kube\config不能放WSL里。MacBook M系列芯片用户tensorflow官方wheel不支持arm64必须用tensorflow-macos2.15.0且配套tensorflow-metal1.1.0。我们曾因混用x86 wheel导致skill在GKE上启动时报Illegal instruction——这是ARM指令集不兼容的典型错误。3.2 Skill定义skill.yaml与main.py的黄金配比一个可部署的skill核心是skill.yaml和main.py的协同。很多人以为skill.yaml只是元数据其实它控制着整个生命周期# skill.yaml name: search-papers version: 1.3.2 description: Search academic papers via arXiv API # 这个endpoint决定gRPC服务名必须小写短横线 endpoint: search-papers.default.svc.cluster.local:50051 # resource limits必须精确我们用kubecost监控后定的值 resources: requests: memory: 1Gi cpu: 300m limits: memory: 2Gi cpu: 600m # health check路径Agent平台用它做liveness probe health_check_path: /healthz # 这个很重要决定skill在Agent UI里的展示名称 display_name: 学术论文搜索 # 权限声明这里声明需要调用arXiv API permissions: - https://arxiv.org/api/query对应的main.py必须严格遵循SDK约定from google.cloud.aiplatform import skills from google.cloud.aiplatform.skills import SkillContext, ToolResult skills.skill( # name必须和skill.yaml里一致否则注册失败 namesearch-papers, # version也必须一致GKE上会校验 version1.3.2 ) def search_papers( query: str, context: SkillContext # 自动注入含trace_id、user_id等 ) - ToolResult: try: # 从context获取token避免硬编码 auth_token context.get_secret(arxiv_api_key) # 调用API带超时和重试 response requests.get( https://export.arxiv.org/api/query, params{search_query: query, max_results: 5}, headers{Authorization: fBearer {auth_token}}, timeout(3.0, 10.0) # connect, read timeout ) response.raise_for_status() # 解析XML用lxml而非xml.etree快3倍 root etree.fromstring(response.content) papers [] for entry in root.xpath(//entry): papers.append({ title: entry.xpath(title/text())[0].strip(), doi: entry.xpath(doi/text())[0] if entry.xpath(doi/text()) else None }) return ToolResult(successTrue, datapapers) except requests.exceptions.Timeout: return ToolResult( successFalse, error_codeARXIV_TIMEOUT, error_messagearXiv API timeout ) except Exception as e: # 所有异常必须捕获否则skill进程崩溃 return ToolResult( successFalse, error_codeARXIV_UNKNOWN_ERROR, error_messagestr(e) )关键细节context.get_secret(arxiv_api_key)密钥必须通过GCP Secret Manager注入不能写死。我们在GKE里配置SecretProviderClass自动挂载到/etc/secrets/arxiv_api_key。timeout(3.0, 10.0)第一个值是连接超时第二个是读超时。Agent平台默认等待15秒所以read timeout必须15s否则会被强制中断。ToolResult的error_code必须是大写字母下划线且长度≤32字符这是Agent平台的校验规则。3.3 本地调试用gRPCurl绕过Agent平台的黑盒别急着往Agent Platform里注册先用grpcurl本地验证接口。这是最高效的调试方式# 安装grpcurl brew install grpcurl # Mac # 或 choco install grpcurl # Windows # 启动skill服务假设在localhost:50051 python main.py # 查看服务定义 grpcurl -plaintext localhost:50051 list # 调用search_papers方法 grpcurl -plaintext \ -d {query: large language models} \ localhost:50051 \ google.cloud.aiplatform.skills.v1.SkillService/SearchPapers为什么不用Postman因为Agent Platform用gRPC-WebPostman发JSON会丢metadata。而grpcurl能模拟真实调用头比如加-H x-user-id: test123传入context。我们发现一个隐藏bug当query含中文时grpcurl默认用UTF-8编码但某些skill SDK版本会把字节流当ASCII解析。解决方案是在grpcurl命令里加-formatjson并确保main.py里query: str参数能正确decode。3.4 Docker镜像构建精简到127MB的实战技巧Dockerfile决定部署效率。我们从最初的842MB镜像压到127MB关键步骤# Dockerfile.prod # 多阶段构建build阶段装编译工具 FROM python:3.11.8-slim-bookworm AS builder RUN apt-get update apt-get install -y build-essential libpq-dev COPY requirements.txt . RUN pip wheel --no-cache-dir --no-deps --wheel-dir /app/wheels -r requirements.txt # 运行时阶段只复制wheel包 FROM python:3.11.8-slim-bookworm # 删除所有apt缓存 RUN apt-get clean rm -rf /var/lib/apt/lists/* # 复制wheel包pip install --no-index --find-links COPY --frombuilder /app/wheels /wheels RUN pip install --no-cache-dir --no-index --find-links /wheels --upgrade pip RUN pip install --no-cache-dir --no-index --find-links /wheels -r requirements.txt # 删除wheel包节省空间 RUN rm -rf /wheels # 复制应用代码 COPY . /app WORKDIR /app # 设置非root用户符合GKE安全策略 RUN addgroup -g 1001 -f appgroup adduser -S appuser -u 1001 USER appuser # 暴露端口 EXPOSE 50051 # 启动命令 CMD [python, main.py]requirements.txt精简原则移除pytest、black等dev依赖用pipreqs --ignore tests/ --savepath requirements.txt .重新生成。google-cloud-aiplatform必须指定1.26.0因为1.27.0引入了breaking changeSkillContext新增get_user_context()方法旧skill会报AttributeError。grpcio用1.60.0这是GKE 1.27集群的兼容版本更高版本在ARM节点上会core dump。3.5 GKE集群配置NodePool与NetworkPolicy的生死线GKE部署不是kubectl apply -f就完事。我们用Terraform管理集群关键配置# gke.tf resource google_container_cluster primary { name skill-cluster location asia-east1 # 必须开启Workload Identity否则skill无法访问Secret Manager workload_identity_config { identity_namespace ${var.project_id}.svc.id.goog } # 启用Autopilot不行Autopilot不支持hostPath挂载而我们的TensorRT engine需要 enable_autopilot false # NodePool配置 node_pool { name skill-nodes node_count 3 # 使用e2-standard-8性价比最高CPU:MEM1:4匹配skill的内存密集型特征 machine_type e2-standard-8 # 预抢占式实例成本降60%但需容忍重启 preemptible true # 必须挂载shm否则multiprocessing崩溃 local_ssd_count 0 # GPU节点单独建Pool避免污染CPU节点 taint { key nvidia.com/gpu value true effect NO_SCHEDULE } } }NetworkPolicy必须配否则skill间调用会失败# network-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-skill-traffic spec: podSelector: matchLabels: app: skill-service ingress: - from: - podSelector: matchLabels: app: agent-platform ports: - protocol: TCP port: 50051 egress: - to: - namespaceSelector: matchLabels: name: default podSelector: matchLabels: app: redis-cache ports: - protocol: TCP port: 6379提示preemptible true虽省钱但GKE会每24小时强制重启节点。我们因此在skill里加了on_shutdown钩子保存临时状态到Cloud Storage避免任务中断。这个hook在main.py里用atexit.register()实现实测重启后恢复时间3秒。3.6 Helm Chart部署解决GKE上12个YAML的手动噩梦手写Deployment、Service、ConfigMap太容易出错。我们用Helm统一管理# templates/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: {{ include skill.fullname . }} labels: {{- include skill.labels . | nindent 4 }} spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: {{- include skill.selectorLabels . | nindent 6 }} template: metadata: labels: {{- include skill.selectorLabels . | nindent 8 }} # 注入OpenTelemetry自动instrumentation annotations: prometheus.io/scrape: true prometheus.io/port: 8080 spec: serviceAccountName: {{ include skill.serviceAccountName . }} containers: - name: {{ .Chart.Name }} image: {{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }} imagePullPolicy: {{ .Values.image.pullPolicy }} # 关键设置startupProbe避免gRPC端口未就绪就被流量打进来 startupProbe: tcpSocket: port: 50051 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: /healthz port: 8080 resources: {{- toYaml .Values.resources | nindent 10 }} env: - name: GCP_PROJECT_ID value: {{ .Values.gcpProjectId }} # 从Secret挂载API密钥 volumeMounts: - name: arxiv-secret mountPath: /etc/secrets/arxiv_api_key readOnly: true volumes: - name: arxiv-secret secret: secretName: arxiv-api-keyvalues.yaml里控制不同环境# values.yaml replicaCount: 3 image: repository: gcr.io/my-project/search-papers-skill tag: 1.3.2 pullPolicy: Always resources: requests: memory: 1Gi cpu: 300m limits: memory: 2Gi cpu: 600m gcpProjectId: my-project # 生产环境必须开metrics metrics: enabled: true port: 8080helm upgrade命令helm upgrade --install search-papers ./charts/skill \ --namespace skills \ --set image.tag1.3.2 \ --set resources.limits.memory2Gi \ --wait --timeout 5m--wait --timeout 5m确保Deployment Ready才返回避免CI/CD流程误判。3.7 Agent Platform注册绕过“not eligible”错误的七步法“your account is not eligible for gemini code assist for individuals at this time”这个错误99%不是账号问题而是注册流程没走完。我们总结出七步必做确认Billing Account已关联在GCP Console Billing里检查skill-cluster项目是否绑定了活跃账单账户。未绑定会静默失败。启用必要APIaiplatform.googleapis.com、cloudresourcemanager.googleapis.com、iam.googleapis.com必须启用。用gcloud services enable aiplatform.googleapis.com一键开启。创建Service Accountgcloud iam service-accounts create skill-sa --display-nameSkill Service Account然后赋予roles/aiplatform.user角色。绑定Workload Identitygcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member serviceAccount:my-project.svc.id.goog[skills/search-papers] \ skill-samy-project.iam.gserviceaccount.com在GKE集群里注解Service Accountkubectl annotate serviceaccount \ --namespace skills \ search-papers-sa \ iam.gke.io/gcp-service-accountskill-samy-project.iam.gserviceaccount.com上传skill.yaml到Cloud Storagegsutil cp skill.yaml gs://my-bucket/skills/search-papers/1.3.2/skill.yaml最后注册gcloud aiplatform skills register \ --locationasia-east1 \ --display-name学术论文搜索 \ --descriptionSearch academic papers via arXiv API \ --sourcegs://my-bucket/skills/search-papers/1.3.2/skill.yaml \ --service-accountskill-samy-project.iam.gserviceaccount.com关键点第4步的--member字符串里[skills/search-papers]必须和你的K8s namespace/serviceaccount名完全一致大小写都不能错。我们曾因写成[Skills/Search-Papers]导致注册后skill状态一直是PENDING。3.8 流量接入Istio VirtualService的精准路由Agent Platform调用skill走的是内部服务网格。必须配VirtualService否则流量进不来# virtual-service.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: search-papers-vs namespace: skills spec: hosts: - search-papers.default.svc.cluster.local gateways: - mesh http: - route: - destination: host: search-papers.default.svc.cluster.local port: number: 50051 weight: 100 # 添加重试应对短暂网络抖动 retries: attempts: 3 perTryTimeout: 5s retryOn: connect-failure,refused-stream,gateway-error,unavailable,reset,resource-exhausted为什么不用K8s Service因为Agent Platform的调用带JWT tokenIstio需要解析token里的aud字段做鉴权。K8s Service做不到这点必须用Istio的VirtualServicePeerAuthentication。3.9 监控告警用Cloud Monitoring盯住三个黄金指标GKE上skill的监控只看三个指标就够了指标查询语句告警阈值说明成功率fetch k8s_containermetric custom.googleapis.com/skill_success_ratealign rate(1m)P95延迟fetch k8s_containermetric custom.googleapis.com/skill_latency_msalign percentile95(1m)错误码分布fetch k8s_containermetric custom.googleapis.com/skill_error_codegroup_by [resource.label.container_name, metric.label.error_code], count()告警用Cloud Monitoring的Alerting Policy条件设为metric.type custom.googleapis.com/skill_success_rateconditionThreshold.valueThreshold 0.995duration 60s实操心得我们最初用count()统计错误结果发现ARXIV_TIMEOUT和ARXIV_UNKNOWN_ERROR混在一起无法区分是网络问题还是代码bug。后来改成按error_code分组立刻定位到是DNS解析超时于是加了dnsPolicy: ClusterFirstWithHostNet到Deployment。3.10 日志分析用Logging Router过滤99%的噪音GKE日志默认全量上报费用爆炸。我们用Logging Router精准过滤# logging-router.tf resource google_logging_project_router skill-router { project var.project_id description Route skill logs to BigQuery # 只转发ERROR级别日志 rule { description Forward skill errors disabled false match resource.type\k8s_container\ AND jsonPayload.level\ERROR\ AND resource.labels.namespace_name\skills\ action send_to_bigquery } # INFO日志只保留关键字段 rule { description Sample skill info logs disabled false match resource.type\k8s_container\ AND jsonPayload.level\INFO\ AND resource.labels.namespace_name\skills\ action send_to_cloud_storage # 采样率5%避免存储膨胀 sampling 0.05 } }BigQuery表结构CREATE TABLE my-project.skill_logs.errors ( timestamp TIMESTAMP, skill_name STRING, error_code STRING, error_message STRING, trace_id STRING, user_id STRING, pod_name STRING );这样查问题时直接SELECT * FROM skill_logs.errors WHERE error_code ARXIV_TIMEOUT5秒出结果不用在千条日志里grep。3.11 版本灰度用K8s Canary Release平滑升级skills下载平台有哪些、skills大全这类热词反映用户对新skill的渴求但不能全量推。我们用Argo Rollouts做金丝雀发布# rollout.yaml apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: search-papers namespace: skills spec: strategy: canary: steps: - setWeight: 5 # 先切5%流量 - pause: {duration: 300} # 观察5分钟 - setWeight: 20 # 再切到20% - pause: {duration: 600} # 观察10分钟 - setWeight: 100 # 全量 revisionHistoryLimit: 3 selector: matchLabels: app: search-papers template: metadata: labels: app: search-papers spec: containers: - name: skill image: gcr.io/my-project/search-papers-skill:1.3.3灰度判断标准不是看时间而是看监控指标。我们写了个Prometheus Rule# 如果新版本P95延迟比老版本高20%自动回滚 avg_over_time(skills_latency_ms_p95{jobsearch-papers-new}[5m]) / avg_over_time(skills_latency_ms_p95{jobsearch-papers-old}[5m]) 1.23.12 故障演练chaos-mesh注入的三次必做测试上线前必须用Chaos Mesh做故障注入网络延迟测试kubectl apply -f latency.yaml给skill Pod注入100ms延迟验证Agent平台的超时重试是否生效。CPU飙高测试kubectl apply -f cpu-stress.yaml用stress-ng --cpu 4 --timeout 60s占满CPU看livenessProbe能否及时杀掉僵死进程。Secret挂载失败测试kubectl apply -f secret-fail.yaml删除arxiv-api-keySecret验证skill是否优雅降级返回error_codeMISSING_SECRET而非panic。实测结果第一次测试时CPU飙高后livenessProbe没触发因为initialDelaySeconds设成了30s而skill启动要25sprobe在第30秒才开始第35秒CPU就100%了。后来改成initialDelaySeconds10periodSeconds10问题解决。4. 常见问题与排查技巧实录从“找不到skills”到“skills不生效”的27个真实案例4.1 注册与发现类问题8个高频场景问题1Agent Platform里“find skills”搜不到刚注册的skill现象gcloud aiplatform skills register返回成功但在Console里搜不到。根因skill.yaml里的name字段含大写字母或空格如name: Search Papers。Agent Platform只认小写短横线。解决name: search-papers且display_name用驼峰命名。问题2“skills推荐”列表为空现象Agent UI里“推荐skills”区域显示“暂无推荐”。根因GCP项目未开通recommendationengine.googleapis.comAPI。解决gcloud services enable recommendationengine.googleapis.com问题3your account is not eligible错误持续出现现象反复确认Billing、API、SA都OK还是报错。根因注册时--location参数用了us-central1但你的账号注册地区是asia-east1区域不匹配。解决gcloud aiplatform skills register --locationasia-east1 ...问题4skill状态一直是CREATING现象gcloud aiplatform skills describe显示state: CREATING超过30分钟。根因skill.yaml里endpoint指向的Service不存在或Service的selector标签不匹配Pod。解决kubectl get svc -n skills确认Service存在kubectl get pods -n skills -l appsearch-papers确认Pod Ready。**问题5本地grpcurl能通Agent Platform调用

建站实战干货

AI智能体Skill工程实战：从函数到可部署服务的完整落地指南