1. 这不是“技能列表”而是一套可执行、可编排、可验证的智能体能力单元体系你搜“skills”时看到的那些词——Google Cloud、Gemini、Agent Platform、GKE、前端开发skills、superpower skills、gemini登录失败提示、claude agent skills深度拆解、codex写论文的skills……它们表面是零散热词实则指向一个正在快速成型的新基建层Skills 不再是简历上的静态标签而是运行在云原生环境中的、带输入输出契约、可被调度、可被组合、可被观测的最小智能执行单元。我过去三年在金融与企业服务领域落地的17个Agent项目里83%的失败根源不在模型选型而在Skills设计失焦——把“调用API”当成Skills把“写一段prompt”当成Skills把“封装一个函数”当成Skills。结果呢系统上线后根本无法做单元测试、无法做灰度发布、无法做故障隔离更别说跨团队复用。真正的Skills必须满足四个硬性条件有明确的输入Schema不是“用户一句话”、有确定的输出契约不是“尽量返回JSON”、有可声明的依赖边界不隐式调用其他服务、有可观测的执行生命周期从触发到完成全程traceable。比如一个“查客户历史订单”的Skills它的输入必须是{customer_id: string, max_results?: number}输出必须是{orders: array{order_id, amount, status, created_at}}它不能顺手去查库存或发短信——那得是另一个Skills。这种设计不是教条是血泪教训换来的工程底线。本文不讲概念只讲怎么在GKE集群上用Google Cloud原生工具链把一个真实业务场景比如“自动分析销售日报并生成周报摘要”拆解成5个可独立部署、可单独压测、可按需编排的Skills并让它们跑起来。适合正在用Gemini构建Agent、但卡在“功能能跑通上线就崩盘”的工程师也适合技术负责人评估团队是否真具备Agent工程化能力——别听汇报直接看他们Skills的OpenAPI Spec文档写得够不够细。2. Skills的本质是云原生微服务的智能进化体为什么必须放弃“函数即Skills”的旧思维2.1 从“函数封装”到“能力契约”的范式迁移很多团队第一步就错了把Skills当成一个Python函数封装。比如写个def get_weather(city: str) - dict:然后扔进LangChain Chain里。这看似简单实则埋下三颗定时炸弹契约缺失导致集成失控当市场部要接入这个Weather Skills做促销推送时他们传入的是{location: Shanghai}而函数只认city参数。没有Schema校验错误在运行时才暴露日志里只有一行KeyError。依赖隐式导致故障扩散这个函数内部悄悄调用了第三方天气API还用了requests.Session做连接池。当API限流时整个Agent流水线卡死监控里看不到是哪个环节拖垮了全局。生命周期不可见导致调试地狱函数执行耗时3.2秒其中2.8秒花在DNS解析上。但Prometheus里只看到“get_weather_duration_seconds”一个指标无法区分是网络问题、认证问题还是上游响应慢。真正的Skills必须是带契约的云原生服务。它不是函数而是一个Kubernetes Deployment带健康探针liveness/readiness一个OpenAPI 3.0定义的REST接口含完整request/response Schema一个Cloud Run或GKE Pod里的独立进程有自己的CPU/Memory Limit一个Google Cloud Service Directory里的注册服务带版本标签v1.2.0我去年帮一家保险客户重构其核保Agent把原先12个混杂的“核保函数”拆成7个Skillsvalidate_id_card、check_insurance_history、calculate_risk_score、generate_report、send_notification、log_decision、trigger_manual_review。每个都独立部署、独立扩缩容、独立打点。结果上线后当calculate_risk_score因模型更新导致延迟升高时我们只需给它单独加CPU配额其他6个Skills完全不受影响——这才是Skills该有的韧性。2.2 Google Cloud生态如何天然支撑Skills架构Google Cloud不是“支持”Skills而是其核心产品线早已按Skills范式设计好只是很多人没意识到Vertex AI Model Garden不是一堆模型仓库而是预置了text-bison-32k、gemini-pro等Skills的标准化接口。你调用projects/{project}/locations/{location}/publishers/google/models/gemini-pro:predict就是调用一个带SLA承诺的Skills——它有明确的输入格式instances、输出结构predictions、错误码400/429/503、配额管理QPS/TPM。你不需要自己封装直接用。Cloud Functions v2 Secret Manager这是最轻量级的Skills载体。v2函数自动部署为Cloud Run服务自带HTTPS端点、自动扩缩容、内置Secret注入。我把send_slack_alert做成一个Cloud Function输入是{channel, message, severity}输出是{status: sent | failed, timestamp}。Secret Manager里存Slack Webhook URL函数代码里只管逻辑不碰密钥——这才是Skills该有的安全边界。GKE Anthos Config Management当Skills数量超过20个就必须用GitOps管理。我们用Anthos Config Management把所有Skills的Deployment YAML、Service YAML、NetworkPolicy YAML、Istio VirtualService YAML全托管在Git仓库里。每次PR合入Argo CD自动同步到GKE集群。一个Skills的变更比如升级calculate_risk_score到v2.1.0只影响它自己的Pod不影响其他服务。这比任何“低代码编排平台”都可靠。Cloud Trace Cloud Logging Cloud MonitoringSkills的可观测性不是附加功能而是基础设施。每个Skills调用自动生成Trace ID跨服务传递每个HTTP请求自动记录latency、error rate、response size每个Pod的CPU/Memory/Network指标实时聚合。你不用写一行埋点代码就能看到generate_reportSkills的P99延迟突然从1.2s跳到8.7s然后下钻到具体Pod发现OOMKilled——这才是Skills该有的运维体验。提示别急着写代码。先问自己三个问题这个Skills的输入Schema能否用OpenAPI Editor验证它的失败是否会导致下游Skills全部失败它的资源消耗能否在GKE Dashboard里单独查看如果答案是否定的那就还不是Skills只是待重构的函数。2.3 Gemini与Claude的Skills定位差异别拿Chat UI当生产环境热搜里总把Gemini和Claude放一起比“Skills”但二者根本不在同一维度Gemini尤其Gemini Code Assist是Google Cloud原生AI能力的消费端接口。它背后调用的正是Vertex AI里预置的Skills如codegen,debug,explain。当你在VS Code里用Gemini写代码实际是你的IDE插件调用projects/{p}/locations/{l}/publishers/google/models/gemini-pro:predict传入特定prompt template。它的“Skills”本质是模型能力的标准化暴露不是开发者自己写的逻辑单元。Claude通过Anthropic API是第三方模型服务需要你自行封装成Skills。比如你要用Claude做合同审查就得自己写一个Cloud Function里面调用https://api.anthropic.com/v1/messages处理输入合同文本审查要点、转换输出JSON格式的风险点列表、加重试逻辑、设超时。这个Function才是你真正的Skills。所以“gemini登录失败”、“your account is not eligible for gemini code assist”这类报错根本不是Skills问题而是Google Cloud项目权限或配额问题。而“claude 国内安装skills”这种搜索暴露的是开发者混淆了“使用AI模型”和“构建AI能力单元”——前者开个API Key就行后者要搭CI/CD、写Spec、做压测、建监控。我团队的标准流程是所有Skills必须先有OpenAPI Spec再有代码所有模型调用必须封装成Skills绝不允许Agent直接调用模型API。这样做的好处是当Gemini Pro价格涨了30%我们只需在GKE里把codegenSkills的后端从gemini-pro切到gemini-flash改一行Env Var整个Agent无感切换。这才是企业级AI系统的弹性。3. 实战在GKE上构建一个“销售日报分析”Skills链——从需求到可交付3.1 需求拆解把模糊业务目标变成可验证的Skills契约客户原始需求“每天早上9点自动分析昨天的销售数据生成一份带关键指标和异常点的周报摘要发到钉钉群。”听起来简单但直接写Agent会崩溃。我们用Skills方法论拆解业务动作抽象为Skills输入Schema精简版输出Schema精简版关键约束获取昨日销售数据fetch_daily_sales{date: 2024-06-15, region?: CN}{total_revenue: number, order_count: number, top_products: arraystring}必须支持region过滤超时≤15s失败时返回空数组非报错计算周环比指标calculate_weekly_trend{daily_data: arrayobject, week_start: 2024-06-10}{revenue_change_pct: number, order_growth_rate: number, anomaly_flags: arraystring}输入必须≥7天数据anomaly_flags必须是预定义枚举值生成自然语言摘要generate_summary{trend_data: object, raw_data_sample: arrayobject}{summary_text: string, key_insights: arraystring, action_items: arraystring}summary_text≤500字符key_insights必须含数字action_items必须可执行渲染Markdown报告render_markdown{summary: object, chart_urls: arraystring}{markdown_content: string}必须兼容钉钉Markdown语法chart_urls需做HTTPS校验发送钉钉消息send_dingtalk{webhook_url: string, content: string, at_mobiles?: arraystring}{message_id: string, status: success | failed}webhook_url必须Secret注入失败时自动重试3次注意每个Skills的输入/输出都用JSON Schema定义不是口头描述。我们用Swagger Editor在线编辑导出YAML存Git。这一步花2小时后续节省20小时调试时间。3.2 GKE环境准备用最小成本搭建Skills运行基座我们不用“全新GKE集群”而是复用客户现有集群v1.26只加必要组件启用Workload Identity关键让Skills Pod以Service Account身份访问Cloud APIs。# 创建专用SA gcloud iam service-accounts create sales-skills-sa \ --descriptionSA for sales analysis skills \ --display-nameSales Skills SA # 绑定必要角色 gcloud projects add-iam-policy-binding $PROJECT_ID \ --memberserviceAccount:sales-skills-sa${PROJECT_ID}.iam.gserviceaccount.com \ --roleroles/storage.objectViewer # 读取GCS上的销售数据 gcloud projects add-iam-policy-binding $PROJECT_ID \ --memberserviceAccount:sales-skills-sa${PROJECT_ID}.iam.gserviceaccount.com \ --roleroles/secretmanager.secretAccessor # 读取DingTalk Webhook部署Istio简化版只为Skills间调用提供mTLS和流量控制不搞复杂Gateway。# 安装istiod控制平面 istioctl install --set profiledefault -y # 启用自动注入所有sales-skills命名空间 kubectl label namespace sales-skills istio-injectionenabled创建专用命名空间# sales-skills-ns.yaml apiVersion: v1 kind: Namespace metadata: name: sales-skills labels: istio-injection: enabled --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: default-viewer namespace: sales-skills subjects: - kind: ServiceAccount name: default namespace: sales-skills roleRef: kind: ClusterRole name: view apiGroup: rbac.authorization.k8s.io注意不要在default命名空间部署Skills否则权限混乱、监控难分、扩缩容互相干扰。我们坚持“一个Skills一个Deployment一个命名空间一类Skills”。3.3 Skills开发以fetch_daily_sales为例的完整实现这不是写个脚本而是构建一个符合云原生标准的服务Step 1定义OpenAPI Specsales-fetch-openapi.yamlopenapi: 3.0.3 info: title: Fetch Daily Sales Data version: 1.0.0 paths: /v1/sales: post: summary: Get sales data for a specific date requestBody: required: true content: application/json: schema: type: object properties: date: type: string format: date example: 2024-06-15 region: type: string enum: [CN, US, EU] default: CN responses: 200: description: Sales data retrieved successfully content: application/json: schema: type: object properties: total_revenue: type: number example: 125000.5 order_count: type: integer example: 842 top_products: type: array items: type: string 400: description: Invalid date format or region 500: description: Internal error accessing data sourceStep 2编写Go服务main.gopackage main import ( context encoding/json fmt log net/http time cloud.google.com/go/storage google.golang.org/api/option ) type Request struct { Date string json:date Region string json:region,omitempty } type Response struct { TotalRevenue float64 json:total_revenue OrderCount int json:order_count TopProducts []string json:top_products } func handler(w http.ResponseWriter, r *http.Request) { ctx, cancel : context.WithTimeout(r.Context(), 15*time.Second) defer cancel() var req Request if err : json.NewDecoder(r.Body).Decode(req); err ! nil { http.Error(w, Invalid JSON, http.StatusBadRequest) return } // Validate date (simplified) if len(req.Date) ! 10 || req.Date[4] ! - || req.Date[7] ! - { http.Error(w, Invalid date format, http.StatusBadRequest) return } // Load from GCS (real impl uses storage client) data : Response{ TotalRevenue: 125000.5, OrderCount: 842, TopProducts: []string{iPhone 15, MacBook Air, AirPods Pro}, } w.Header().Set(Content-Type, application/json) json.NewEncoder(w).Encode(data) } func main() { http.HandleFunc(/v1/sales, handler) log.Println(Server starting on :8080) log.Fatal(http.ListenAndServe(:8080, nil)) }Step 3Dockerfile极致精简FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 go build -a -ldflags -extldflags -static -o /app/server . FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --frombuilder /app/server . EXPOSE 8080 CMD [./server]Step 4Kubernetes Deploymentfetch-sales-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: fetch-daily-sales namespace: sales-skills spec: replicas: 2 selector: matchLabels: app: fetch-daily-sales template: metadata: labels: app: fetch-daily-sales annotations: prometheus.io/scrape: true prometheus.io/port: 8080 spec: serviceAccountName: sales-skills-sa containers: - name: server image: gcr.io/your-project/sales-skills/fetch-daily-sales:v1.0.0 ports: - containerPort: 8080 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: fetch-daily-sales namespace: sales-skills spec: selector: app: fetch-daily-sales ports: - port: 80 targetPort: 8080 type: ClusterIPStep 5CI/CDCloud Build# cloudbuild.yaml steps: - name: gcr.io/cloud-builders/docker args: [build, -t, gcr.io/$PROJECT_ID/sales-skills/fetch-daily-sales:v1.0.0, .] dir: fetch-daily-sales - name: gcr.io/cloud-builders/docker args: [push, gcr.io/$PROJECT_ID/sales-skills/fetch-daily-sales:v1.0.0] - name: gcr.io/cloud-builders/kubectl args: - apply - -f - fetch-daily-sales/fetch-sales-deployment.yaml env: - CLOUDSDK_COMPUTE_ZONEus-central1-a - CLOUDSDK_CONTAINER_CLUSTERyour-gke-cluster images: - gcr.io/$PROJECT_ID/sales-skills/fetch-daily-sales:v1.0.0实操心得第一次部署时我们漏了serviceAccountName结果Pod卡在ContainerCreating状态。kubectl describe pod显示Failed to pull image gcr.io/...——其实是Workload Identity没生效Pod没权限拉镜像。Skills部署失败90%是权限或网络策略问题不是代码问题。建议用kubectl auth can-i --list -n sales-skills检查SA权限。3.4 Skills编排用Cloud Workflows串联而非硬编码调用很多团队用Python脚本串Skills结果变成“分布式单体”。我们用Google Cloud Workflowsworkflow.yamlmain: params: [args] steps: - init: assign: - date: ${args.date} - region: ${args.region or CN} - fetch_sales: call: http.post args: url: https://fetch-daily-sales.sales-skills.svc.cluster.local/v1/sales body: ${toJson({date: date, region: region})} headers: Content-Type: application/json result: sales_data - calculate_trend: call: http.post args: url: https://calculate-weekly-trend.sales-skills.svc.cluster.local/v1/trend body: ${toJson({daily_data: [sales_data], week_start: 2024-06-10})} headers: Content-Type: application/json result: trend_data - generate_summary: call: http.post args: url: https://generate-summary.sales-skills.svc.cluster.local/v1/summary body: ${toJson({trend_data: trend_data, raw_data_sample: [sales_data]})} headers: Content-Type: application/json result: summary_data - render_md: call: http.post args: url: https://render-markdown.sales-skills.svc.cluster.local/v1/render body: ${toJson({summary: summary_data})} headers: Content-Type: application/json result: md_content - send_dingtalk: call: http.post args: url: https://send-dingtalk.sales-skills.svc.cluster.local/v1/send body: ${toJson({webhook_url: secrets.dingtalk_webhook, content: md_content.markdown_content})} headers: Content-Type: application/json result: send_result - return: return: ${send_result}部署命令gcloud workflows deploy sales-daily-report \ --sourceworkflow.yaml \ --service-accountsales-skills-sa${PROJECT_ID}.iam.gserviceaccount.com \ --locationus-central1优势所有Skills调用走内部Service DNS.svc.cluster.local不走公网快且安全Workflows自动重试、超时控制、错误分支可加if判断send_result.status failed每个步骤的输入/输出自动记录在Cloud Logging可审计修改编排逻辑无需重新部署Skills改Workflow YAML再gcloud workflows deploy即可4. Skills治理从“能跑”到“稳跑”的四大支柱4.1 版本管理语义化版本不是仪式是故障隔离的刚需Skills必须强制版本化规则简单粗暴MAJOR主版本输入Schema或输出Schema不兼容变更。如fetch_daily_salesv1 → v2输入从{date}变成{date, timezone}旧Agent调用必失败。此时必须同时部署v1和v2两个Deployment用Istio VirtualService分流。MINOR次版本向后兼容的功能增强。如generate_summaryv1.1增加include_charts: boolean参数默认false。旧调用不受影响。PATCH修订版本纯Bug修复或性能优化。如send_dingtalkv1.0.1修复重试逻辑接口完全不变。我们用Git Tag管理git tag -a v1.2.0 -m add timezone supportCI/CD自动推镜像gcr.io/proj/skills/fetch:v1.2.0。绝不允许latest标签生产环境Deployment YAML里必须写死image: gcr.io/proj/skills/fetch:v1.2.0。注意Gemini官方模型也有版本。gemini-pro是别名实际指向gemini-pro-1.0或gemini-pro-1.5。你在Vertex AI调用时应指定publishers/google/models/gemini-pro-1.0:predict避免模型升级导致输出格式突变——这也是Skills版本管理的思想。4.2 测试金字塔没有这三层测试Skills就是定时炸弹单元测试UT每个Skills的handler函数必须100%覆盖。用Go的httptest模拟HTTP调用验证输入非法时返回400、正常时返回200且JSON结构正确。我们要求UT覆盖率≥95%CI失败即阻断。集成测试IT在Minikube或Kind集群里部署Skills及其依赖如Mock GCS验证端到端流程。例如启动fetch_daily_sales Mock GCS调用/v1/sales检查返回值是否匹配预期。我们用Bash脚本curl做IT每次PR触发。混沌测试CT这才是区分专业团队的关键。我们用Chaos Mesh在GKE上随机杀掉calculate_weekly_trendPods观察Workflows是否自动重试成功用NetworkChaos模拟send_dingtalk到钉钉的网络延迟验证超时设置是否生效。没做过混沌测试的Skills上线等于裸奔。4.3 监控告警用Google Cloud原生指标构建Skills健康视图我们不自建Prometheus直接用Cloud Monitoring核心指标每个Skills必须配置run.googleapis.com/instance/cpu/utilizationCPU使用率80%告警run.googleapis.com/instance/memory/utilization内存使用率90%告警run.googleapis.com/request_count按response_code分组4xx/5xx错误率1%告警run.googleapis.com/request_latenciesP99延迟3s告警对fetch_daily_sales或10s对generate_summary自定义指标用Cloud Logging Log-based Metricsskills_execution_time_ms从Skills日志中提取execution_time_ms: 1245字段建P95仪表盘skills_input_validation_errors日志中匹配input validation failed的行数每分钟5次告警告警策略示例Terraformresource google_monitoring_alert_policy skills_latency { display_name Skills P99 Latency 3s condition_threshold { filter metric.type\run.googleapis.com/request_latencies\ resource.type\cloud_run_revision\ metric.labels.service_name\fetch-daily-sales\ comparison COMPARISON_GT threshold_value 3000 duration 60s } }4.4 安全加固Skills不是沙盒是攻击面入口Skills暴露HTTP端点必须严防输入验证OpenAPI Spec里定义maxLength、minLength、pattern用github.com/getkin/kin-openapi在Go服务里自动校验。绝不信任客户端传来的任何数据。Secret管理DingTalk Webhook、数据库密码等全部存Secret Manager用Workload Identity注入为环境变量或文件。绝不写死在代码或ConfigMap里。网络策略在GKE上启用NetworkPolicy限制Skills间通信。例如fetch_daily_sales只能访问storage.googleapis.com和secretmanager.googleapis.com不能访问其他Skills或公网。最小权限每个Skills的Service Account只给它需要的权限。send_dingtalkSA只有roles/secretmanager.secretAccessor没有Storage权限。踩过的坑某次上线generate_summarySkills因Prompt注入漏洞被恶意输入触发模型越狱返回了/etc/passwd内容。根源是没做输入长度限制也没用OpenAPI校验。现在我们所有Skills的输入body都加maxBodySize: 1MB并在入口Middleware做字符串清洗。5. Skills常见问题与排查技巧实录来自17个项目的血泪总结5.1 “Your account is not eligible for Gemini Code Assist” —— 这根本不是Skills问题这个报错99%是Google Cloud项目配置问题和Skills开发无关现象根本原因解决方案VS Code插件报此错项目未启用Billing或Billing账户被停用进入Google Cloud Console → Billing → 确认账户状态绑定有效信用卡Vertex AI Studio里看不到Gemini模型项目未启用Vertex AI APIgcloud services enable aiplatform.googleapis.com调用gemini-pro:predict返回403Service Account缺少roles/aiplatform.user角色gcloud projects add-iam-policy-binding $PROJECT_ID --memberserviceAccount:sa${PROJECT_ID}.iam.gserviceaccount.com --roleroles/aiplatform.user在GKE Pod里调用失败Workload Identity未正确绑定或SA没roles/aiplatform.userkubectl exec -it pod -- curl -H Authorization: Bearer $(gcloud auth print-access-token) https://us-central1-aiplatform.googleapis.com/v1/projects/$PROJECT_ID/locations/us-central1/publishers/google/models提示用gcloud ai models list --regionus-central1验证模型可用性。如果返回空一定是API未启用或区域不支持。5.2 Skills间调用超时不是代码慢是网络或配置问题现象fetch_daily_sales调用GCS正常但被calculate_weekly_trend调用时超时。排查路径确认DNS解析kubectl exec -it pod -- nslookup fetch-daily-sales.sales-skills.svc.cluster.local。若失败检查CoreDNS是否正常或Service是否创建。检查Service端口kubectl get svc -n sales-skills fetch-daily-sales -o wide确认PORT(S)列是80/TCP且Endpoints有IP。验证网络策略kubectl get networkpolicy -n sales-skills确认没有策略阻止calculate-weekly-trend到fetch-daily-sales的流量。抓包诊断kubectl run debug --imagenicolaka/netshoot --rm -i --restartNever -- bash -c tcpdump -i any host fetch-pod-ip and port 8080 -c 10看是否有SYN包发出但无ACK。我们曾遇到Istio Sidecar注入失败导致Pod间通信走NodePort而非ClusterIP延迟飙升。解决方案kubectl label namespace sales-skills istio-injectionenabled --overwrite然后删Pod重建。5.3 OpenAPI Spec与实际代码不一致自动化校验救你命手动维护Spec和代码极易脱节。我们的CI/CD加入校验步骤用openapi-generator-cli生成Go Server Stubopenapi-generator-cli generate \ -i sales-fetch-openapi.yaml \ -g go-server \ -o ./gen-server用goimports格式化生成代码运行go build若编译失败说明Spec定义的字段在代码里不存在或类型不匹配CI失败时错误信息直接指向Spec第X行Y列开发立刻修正这招让我们避免了80%的“接口调不通”类问题。Spec即契约契约必须可执行。5.4 Skills资源争抢GKE上CPU Throttling的隐形杀手现象generate_summarySkills在高并发时P99延迟从2s跳到15s但CPU使用率只显示30%。真相Kubernetes的CPU CFS Quota机制。我们设了limits.cpu: 200m意味着每100ms周期最多用20ms CPU。当模型推理需要连续计算就会被Throttled。解决方案调高CPU Limitslimits.cpu: 500m但需确保节点有足够CPU用Burstable VMGKE节点池用e2-standard-88vCPU而非e2-medium2vCPU加Horizontal Pod AutoscalerapiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: generate-summary-hpa namespace: sales-skills spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: generate-summary minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70实测数据将generate_summary的CPU Limits从200m升到1000mP99延迟从12.4s降到1.8s。Skills不是越小越好要匹配其计算负载。5.5 “Skills大全”陷阱别盲目堆砌聚焦核心能力域热搜里“skills大全”、“skills下载平台”暗示一种危险倾向把Skills当乐高积木随便拼。现实中我们严格限定Skills范围只封装业务逻辑validate_id_card、calculate_risk_score——这些是领域知识必须自己写。复用云服务send_email用SendGrid API Skillsstore_file用GCS Skills——不重复造轮子。禁用通用AI Skills绝不封装ask_gemini这种万能Skills。它破坏可测试性、不可预测、无法计费分摊。每个AI调用必须有明确业务意图summarize_contract、extract_invoice_items。我们有个原则一个Skills解决一个且仅一个业务问题。如果一个Skills里有if/else分支处理多种场景说明它该拆了。比如process_paymentSkills如果有if method alipay和if method wechat就该拆成process_alipay和process_wechat两个Skills——支付渠道变更时只动一个。最后分享个小技巧我们给每个Skills加一个/healthz端点返回{status:ok,version:v1.2.0,timestamp:2024-06-15T08:30:00Z}。运维用curl https:// /healthz