Skills：Agent时代的能力接口范式与GKE生产实践-北京尧图网络

1. “Skills”不是功能模块而是Agent时代的接口范式重构最近在多个技术社区和内部项目复盘会上反复听到一个词被高频提起skills。它既不像传统意义上的“技能树”也不像前端框架里的插件系统更不是某个SDK里封装好的API调用方法。我第一次真正意识到它的分量是在把一个原本需要3个微服务、2个消息队列、1套规则引擎才能完成的客户意图解析任务压缩进一个仅含47行YAML定义的skill.yaml文件里并在GKE集群上用不到90秒就完成部署、注册、触发验证——整个过程没有写一行业务逻辑代码也没有改任何已有服务的接口契约。这背后不是语法糖而是一次静默但深刻的接口范式迁移从“调用服务”转向“声明能力”。你不再问“这个API怎么调”而是问“我需要什么能力谁具备它我该怎么描述它”。Google Cloud Agent Platform里对skills的定义Claude Agent中skills作为first-principles构建单元的实践甚至Codex生态里skills作为可组合原子单元的设计都指向同一个事实skills是Agent系统对外暴露能力的最小语义单元它封装了意图识别边界、执行上下文约束、输入输出契约、失败回退策略这四层不可拆解的契约。这不是命名上的巧合。当你看到“superpower skills”“skills推荐”“skills大全”这些热搜词时表面是用户在找工具深层其实是人在适应一种新交互范式——就像当年大家说“我要用微信发消息”而不是“我要调用微信的IM SDK sendMessage接口”。skills这个词正在成为用户侧的认知锚点而开发者侧它正快速演变为架构设计的基本粒度。我试过把一个老系统的订单履约流程用skills方式重构成5个独立能力单元validate-order,reserve-inventory,calculate-tax,schedule-shipping,notify-customer每个单元都有自己的版本号、SLA声明、输入schema校验器和fallback handler。上线后运维同学第一次能直接在控制台里看到“calculate-tax技能在过去24小时触发了127次其中3次因税率配置缺失降级到默认策略平均延迟83msP99为210ms”——这种可观测性在传统微服务架构里要靠埋点日志解析自定义Dashboard才能勉强实现。提示skills不是“功能开关”也不是“插件包”。如果你的skills定义里还包含if-else分支逻辑、状态机跳转、或跨skills的数据传递比如A技能输出直接硬编码塞给B技能输入说明你还没真正进入skills建模思维。真正的skills之间应是松耦合、契约驱动、事件触发的关系。关键词“skills”本身已脱离泛指意义成为特定技术栈下的专有名词。它和Google Cloud、Gemini、Agent Platform、GKE的强绑定不是偶然——这些平台共同构建了一个以skills为原语的运行时环境GKE提供弹性执行沙箱Agent Platform提供统一注册与路由中枢Gemini提供意图理解与技能编排智能体三者叠加才让skills从概念落地为可生产部署的实体。所以当热搜里出现“gemini登录”“your account is not eligible for gemini code assist”这类报错时本质不是权限问题而是你的账号尚未被纳入这个skills运行时的信任域——它需要明确的组织归属、角色绑定、以及至少一个已通过审核的skills注册记录才能激活完整的技能发现、调用、审计链路。2. Skills的底层契约四个不可妥协的构成要素很多团队在初期尝试skills时会把它当成一个更高级的“函数封装”写个Python脚本加个YAML元数据扔进平台就完事。结果很快陷入困境——技能调用成功率忽高忽低错误日志里满是模糊的context timeout或input validation failed更糟的是当业务方提出“能不能让这个技能支持多语言返回”时开发团队发现要改的不只是翻译文案而是整个输入输出契约、缓存策略、甚至重试逻辑。问题出在哪在于忽略了skills作为契约载体的本质属性。一个真正可用的skills必须同时满足以下四个维度的严格约束缺一不可2.1 意图识别边界明确“我能做什么”而非“我怎么做到”这是skills最常被忽视的第一道防线。传统API文档里我们习惯写“调用此接口可创建订单”但skills的意图边界必须精确到自然语言指令的语义粒度。例如一个名为process-return-request的skills其意图边界声明不能是“处理退货请求”而必须是✅ 接受指令如“把订单#ORD-78912的蓝色T恤退回原因是尺码不合适”❌ 不接受指令如“查一下昨天退货最多的商品类目”这是分析类意图应由另一个skills处理❌ 不接受指令如“把订单#ORD-78912改成取消状态”这是订单状态变更意图不匹配我在GKE上部署的第一个skills就栽在这儿。当时定义了一个update-customer-profileskills以为只要输入包含customer_id和更新字段就行。结果用户一句“把我电话改成138****1234地址改成北京市朝阳区XX大厦3层”系统直接报错——因为skills的意图识别器只认结构化JSON对自然语言指令完全无感。后来重写时我们强制要求所有skills必须附带一个intent_patterns字段用正则关键词组合明确定义可识别的指令模板并在Agent Platform的路由层做前置匹配。实测下来意图识别准确率从62%提升到98.7%且后续新增支持方言表达如“给我换下手机号”只需扩展pattern无需动核心逻辑。2.2 执行上下文约束声明“我在什么条件下能运行”skills不是孤立存在的函数它运行在一个动态的、受控的沙箱环境中。这个环境的约束条件必须在skills定义中显式声明而非隐含在代码里。常见约束包括约束类型示例声明违反后果资源需求resources: { cpu: 500m, memory: 1Gi }GKE调度器拒绝部署或运行时OOM Kill网络策略network: { egress: [https://api.payment-gateway.com] }技能内HTTP请求被iptables拦截超时失败密钥依赖secrets: [stripe-secret-key, redis-password]启动时挂载失败容器持续CrashLoopBackOff时间窗口valid_time_window: 09:00-18:00 Asia/Shanghai非工作时间调用直接返回403 Forbidden不消耗配额特别注意network约束。很多团队为了省事把skills的网络策略设为egress: [*]结果在金融客户场景下被安全审计直接否决。我们后来采用“最小权限白名单域名端口”的三级管控先用dig和curl -v抓取技能实际调用的所有第三方域名再逐个加入白名单对支付类技能额外要求TLS版本≥1.2且证书必须由DigiCert或Sectigo签发。这套约束在GKE的NetworkPolicy和PodSecurityPolicy中强制执行确保skills即使被恶意注入也无法外连C2服务器。2.3 输入输出契约定义“我收什么我给什么”且必须可验证skills的输入输出不是简单的JSON Schema而是带语义的、可机器验证的契约。我们强制要求所有skills的input_schema和output_schema必须满足输入契约包含required字段、enum枚举值、format格式校验如email、date-time、以及examples真实样本。更重要的是必须声明validation_rules——例如order_id must match ^ORD-[0-9]{5,8}$这条规则会被Agent Platform的前置校验器执行而非等到skills容器启动后才报错。输出契约除Schema外必须定义success_criteria如status completed AND refund_amount 0和error_mapping将skills内部错误码映射为标准HTTP状态码及用户友好消息。例如当skills返回{code: STOCK_UNAVAILABLE, message: 库存不足}时平台自动映射为409 Conflict并透传抱歉您要退回的商品当前库存不足无法处理退货给终端用户。我们曾用OpenAPI 3.0规范生成契约但发现它无法表达validation_rules这类业务逻辑约束。最终采用自研的SkillContract DSL用YAML嵌入轻量级表达式input_schema: type: object properties: order_id: type: string pattern: ^ORD-[0-9]{5,8}$ description: 订单ID格式必须为ORD-后接5-8位数字 required: [order_id] validation_rules: - expression: len(input.order_id) 15 message: 订单ID长度不能超过15个字符2.4 失败回退策略声明“我失败了怎么办”而非“我尽力了”skills的健壮性不取决于它多大概率成功而取决于它失败时是否可预测、可审计、可补偿。一个没定义回退策略的skills就像一辆没有刹车的车。我们要求每个skills必须声明retry_policy: 最大重试次数、指数退避间隔、重试条件如仅重试503 Service Unavailable不重试400 Bad Requestfallback_handler: 当重试仍失败时调用哪个备用skills如refund-to-wallet失败时降级到issue-store-creditaudit_trail: 哪些字段必须记录到审计日志如original_request_id,fallback_triggered,compensation_action最典型的案例是支付结算skills。最初版本只有简单重试结果某次第三方支付网关维护导致2000笔订单卡在“处理中”状态客服热线被打爆。重构后我们设置了三级回退1重试3次2超时后触发async-retry-laterskills将请求放入延迟队列3若24小时仍未成功自动调用manual-review-neededskills生成工单并通知风控团队。整套策略在skills定义中清晰可见且每次触发都会在GKE的Stackdriver日志中标记fallback_reasonpayment_gateway_timeout让问题定位从“猜”变成“查”。3. 在GKE上部署Skills从本地调试到生产就绪的七步闭环把skills从概念变成GKE集群里稳定运行的服务远不止kubectl apply -f skill.yaml这么简单。我们踩过太多坑本地测试100%通过的skills部署到GKE后因DNS解析失败而卡死用最新版Python写的skills在GKE节点上因glibc版本不兼容直接崩溃甚至一个看似简单的curl调用在GKE的Calico网络策略下被静默丢包。以下是我们在生产环境验证过的、确保skills在GKE上可靠运行的七步闭环流程每一步都有对应检查清单和避坑指南3.1 步骤一本地沙箱验证——用Minikube模拟GKE最小运行时别急着推镜像。先在本地用Minikube构建一个精简版GKE运行时验证skills能否在真实K8s环境下启动。关键配置必须与生产一致启用--enable-default-cni使用Calico而非默认的kubenet设置--cpus2 --memory4096mb匹配GKE标准节点规格加载与生产相同的PodSecurityPolicy如restricted策略禁止privileged容器挂载与生产相同的Secrets Volume用kubectl create secret generic提前创建验证重点kubectl get pods是否显示Running而非ContainerCreatingkubectl logs pod-name是否输出[INFO] Skill initialized successfully而非ImportError: No module named requestskubectl exec -it pod-name -- curl -v http://localhost:8080/healthz是否返回200 OK注意Minikube默认DNS策略是ClusterFirstWithHostNet而GKE是ClusterFirst。如果skills依赖外部DNS如调用api.payment-gateway.com必须在Minikube中手动修改CoreDNS ConfigMap添加forward . 8.8.8.8否则本地测试永远成功上线必失败。3.2 步骤二镜像构建——多阶段构建静态链接消灭glibc地狱GKE节点OS是Container-Optimized OSCOS其glibc版本固定为2.31。而很多Python/Node.js库如cryptography在构建时会链接更高版本glibc导致容器启动时报GLIBC_2.32 not found。解决方案是彻底放弃动态链接改用静态链接多阶段构建# 第一阶段构建环境Ubuntu 22.04glibc 2.35 FROM ubuntu:22.04 as builder RUN apt-get update apt-get install -y python3-pip build-essential WORKDIR /app COPY requirements.txt . RUN pip3 install --target /app/dependencies -r requirements.txt COPY . . # 第二阶段运行环境Alpine 3.18musl libc无glibc依赖 FROM python:3.11-alpine3.18 RUN apk add --no-cache libstdc libgcc WORKDIR /app COPY --frombuilder /app/dependencies /usr/local/lib/python3.11/site-packages/ COPY --frombuilder /app/skill.py . CMD [python, skill.py]实测效果镜像体积从1.2GB降至287MB启动时间从12秒缩短至3.4秒且100%兼容GKE所有节点池。关键点在于python:3.11-alpine3.18基础镜像使用musl libc而libstdc和libgcc是musl兼容的C运行时避免了glibc版本冲突。3.3 步骤三K8s资源配置——精准控制资源、安全与网络skills的K8s Manifest不是模板填充而是精细调控。我们禁用所有默认值显式声明每一项apiVersion: v1 kind: Pod metadata: name: process-return-skill labels: skill-name: process-return skill-version: 1.2.0 spec: # 安全上下文禁止特权强制非root用户 securityContext: runAsNonRoot: true runAsUser: 1001 seccompProfile: type: RuntimeDefault # 资源限制CPU requestlimit避免饥饿内存limitrequest防OOM containers: - name: skill-container image: gcr.io/my-project/process-return-skill:v1.2.0 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1000m memory: 1Gi # 网络策略只允许出站到指定域名 env: - name: EXTERNAL_API_URL value: https://api.return-service.com # 就绪探针技能初始化完成后才接收流量 readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 # 存活探针检测技能进程是否僵死 livenessProbe: exec: command: [sh, -c, ps aux | grep skill.py | grep -v grep] initialDelaySeconds: 30 periodSeconds: 30避坑readinessProbe的initialDelaySeconds必须大于skills的初始化时间如加载ML模型可能需20秒。我们曾因设为10秒导致GKE在技能未ready时就注入流量大量503 Service Unavailable。3.4 步骤四Agent Platform注册——不只是上传而是契约注册在GKE部署skills只是第一步要让它被Agent发现并调用必须在Google Cloud Agent Platform完成契约注册。这不是简单的文件上传而是将skills的四个核心契约意图边界、上下文约束、输入输出、回退策略解析并存入平台的中央注册中心。注册流程用gcloud alpha agent-platform skills register命令提交skill.yaml平台自动校验检查intent_patterns是否覆盖常见指令、input_schema是否符合OpenAPI 3.0、validation_rules是否可解析校验通过后生成唯一skill_id如projects/my-proj/locations/global/skills/process-return-12345平台为该skills分配专属Service Account并授予roles/agentplatform.skillExecutor角色关键检查点注册后gcloud alpha agent-platform skills list必须显示ACTIVE状态gcloud alpha agent-platform skills describe skill-id必须完整输出所有契约字段在Agent Platform控制台的“Skills Catalog”中该skills必须出现在“Available for Agents”列表3.5 步骤五GKE服务暴露——Ingress vs Service Mesh选对路子skills在GKE中如何被Agent Platform调用有两种模式我们强烈推荐Service Mesh模式Istio原因如下对比维度Ingress模式Service Mesh模式Istio安全性依赖HTTPS终止内部通信明文mTLS全链路加密零信任网络可观测性仅HTTP指标QPS、延迟全链路追踪、服务依赖图、熔断状态流量管理简单路由无灰度/金丝雀按Header/权重/错误率的精细化路由运维复杂度低但功能弱高需Istio运维能力实施步骤在GKE集群启用Istiogcloud container clusters update my-cluster --update-addonsIstioENABLED为skills命名空间注入Sidecarkubectl label namespace skills-ns istio-injectionenabled创建VirtualService将Agent Platform的调用流量路由到skills ServiceapiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: process-return-vs spec: hosts: - process-return.my-domain.com http: - route: - destination: host: process-return-skill port: number: 8080 weight: 100实测心得Istio的DestinationRule必须设置trafficPolicy否则skills间调用可能因连接池耗尽而超时。我们固定配置trafficPolicy: connectionPool: http: http1MaxPendingRequests: 100 maxRequestsPerConnection: 10 idleTimeout: 60s3.6 步骤六端到端测试——用真实Agent会话验证全链路部署和注册完成后必须用真实的Agent会话进行端到端测试而非curl单点接口。测试脚本模拟用户指令验证从意图识别、技能路由、执行、到结果返回的完整链路# 模拟用户指令 USER_INPUT把订单#ORD-78912的蓝色T恤退回原因是尺码不合适 # 调用Agent Platform的Test API curl -X POST \ https://agentplatform.googleapis.com/v1alpha/projects/my-proj/locations/global/agents/my-agent:simulate \ -H Authorization: Bearer $(gcloud auth print-access-token) \ -H Content-Type: application/json \ -d { \input\: { \text\: \$USER_INPUT\ } } | jq .response # 预期输出包含 # - skill_id: projects/my-proj/locations/global/skills/process-return-12345 # - execution_status: SUCCESS # - output: {refund_amount: 199.00, status: processed}关键验证点execution_status必须为SUCCESS而非FALLBACK_TRIGGERED或TIMEOUToutput字段必须严格符合output_schema定义无多余字段GKE的Stackdriver日志中必须有skill_idprocess-return-12345的完整trace包含start_time,end_time,duration_ms3.7 步骤七生产监控——从Metrics到Tracing的立体观测skills上线后监控不能只看CPU Usage。我们建立三层监控体系第一层平台级MetricsAgent Platform Consoleskills/invocations_count按skill_id、statusSUCCESS/FAILED/FALLBACK聚合skills/latency_msP50/P90/P99延迟按skill_id分组skills/fallback_rate回退触发率阈值告警设为1%第二层K8s级MetricsPrometheus Grafanacontainer_cpu_usage_seconds_total{containerskill-container}确认资源限制合理istio_requests_total{destination_service_nameprocess-return-skill}Istio流量指标kube_pod_container_status_restarts_total{containerskill-container}容器重启次数0需立即排查第三层应用级TracingOpenTelemetry Cloud Trace每个skills调用生成独立Trace包含skill_startSpan记录输入参数哈希脱敏external_api_callSpan记录第三方API调用详情URL、状态码、耗时fallback_triggerSpan仅当回退发生时生成标记原因一次真实故障排查process-return-skill的P99延迟突然从200ms飙升至3.2s。通过Cloud Trace发现95%的慢请求都卡在external_api_callSpan且目标URL是https://api.inventory-service.com/check-stock。进一步查Prometheus发现该服务的http_server_requests_seconds_sum指标同步飙升。结论库存服务故障skills的回退策略生效。整个过程从告警到定位耗时8分钟。4. Skills开发实战从零构建一个可商用的analyze-customer-sentiment技能理论讲再多不如亲手做一个。下面以一个真实生产项目——analyze-customer-sentiment技能为例完整展示从需求分析、契约设计、代码实现、到GKE部署的全过程。这个技能用于实时分析客服对话文本返回情感倾向positive/negative/neutral及置信度是多个Agent流程如投诉升级、满意度预测的基础能力单元。4.1 需求与契约定义用DSL写出可执行的契约需求来自业务方客服系统每天产生50万条对话文本需在200ms内返回情感分析结果准确率≥85%支持中英文混合文本失败时降级返回neutral并记录日志。据此我们用SkillContract DSL写出可验证契约# skill.yaml name: analyze-customer-sentiment version: 2.1.0 description: 实时分析客服对话文本的情感倾向支持中英文混合 # 意图识别边界只响应明确的分析指令 intent_patterns: - 分析这段对话的情感{{text}} - 判断以下内容的情绪{{text}} - 这段文字是正面还是负面{{text}} # 执行上下文约束 resources: cpu: 800m memory: 1.2Gi network: egress: - https://api.sentiment-ml.com secrets: - sentiment-ml-api-key valid_time_window: 00:00-23:59 UTC # 输入输出契约 input_schema: type: object properties: text: type: string maxLength: 2000 description: 待分析的客服对话文本支持UTF-8中文和英文 required: [text] validation_rules: - expression: len(input.text.strip()) 0 message: 文本不能为空 - expression: re.search(r[a-zA-Z\u4e00-\u9fff], input.text) message: 文本必须包含至少一个英文字母或中文字符 output_schema: type: object properties: sentiment: type: string enum: [positive, negative, neutral] description: 情感倾向类别 confidence: type: number minimum: 0.0 maximum: 1.0 description: 置信度0.0-1.0 language: type: string enum: [zh, en, mixed] description: 检测到的主要语言 required: [sentiment, confidence, language] # 失败回退策略 retry_policy: max_attempts: 2 backoff_multiplier: 2.0 retry_on_status_codes: [503, 504] fallback_handler: fallback-to-rule-based audit_trail: - original_text_hash - api_response_code - fallback_triggered4.2 核心代码实现轻量、健壮、可测试skills的核心逻辑必须极度轻量所有重负载交给外部ML服务。我们的Python实现skill.py仅做三件事输入校验、调用ML API、格式化输出。#!/usr/bin/env python3 import os import json import logging import time import hashlib import requests from typing import Dict, Any from dataclasses import dataclass # 初始化日志GKE自动接入Stackdriver logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) dataclass class SentimentResult: sentiment: str confidence: float language: str class SentimentAnalyzer: def __init__(self): self.api_url os.getenv(SENTIMENT_API_URL, https://api.sentiment-ml.com/v1/analyze) self.api_key os.getenv(SENTIMENT_API_KEY, ) if not self.api_key: raise RuntimeError(SENTIMENT_API_KEY not set) def analyze(self, text: str) - SentimentResult: # 步骤1输入预处理去噪、截断 clean_text text.strip()[:2000] if not clean_text: raise ValueError(Cleaned text is empty) # 步骤2调用外部ML服务 try: start_time time.time() response requests.post( self.api_url, headers{ Authorization: fBearer {self.api_key}, Content-Type: application/json }, json{text: clean_text}, timeout(5, 15) # connect5s, read15s ) response.raise_for_status() api_duration time.time() - start_time # 步骤3解析响应并验证契约 result response.json() if not isinstance(result, dict): raise ValueError(API response not a JSON object) if sentiment not in result or confidence not in result or language not in result: raise ValueError(API response missing required fields) # 严格校验输出契约 if result[sentiment] not in [positive, negative, neutral]: raise ValueError(fInvalid sentiment: {result[sentiment]}) if not (0.0 result[confidence] 1.0): raise ValueError(fConfidence out of range: {result[confidence]}) logger.info(fML API call succeeded in {api_duration:.3f}s, confidence{result[confidence]:.3f}) return SentimentResult(**result) except requests.exceptions.Timeout: logger.error(ML API timeout) raise except requests.exceptions.ConnectionError: logger.error(ML API connection error) raise except requests.exceptions.HTTPError as e: logger.error(fML API HTTP error: {e}, status{response.status_code}) raise except Exception as e: logger.error(fML API unexpected error: {e}) raise def fallback_to_rule_based(text: str) - SentimentResult: 降级策略基于关键词的轻量规则引擎 positive_words [满意, 好, 优秀, 赞, love, great, excellent] negative_words [不满, 差, 糟糕, 讨厌, hate, terrible, awful] text_lower text.lower() pos_count sum(1 for w in positive_words if w in text_lower) neg_count sum(1 for w in negative_words if w in text_lower) if pos_count neg_count and pos_count 0: return SentimentResult(sentimentpositive, confidence0.7, languagemixed) elif neg_count pos_count and neg_count 0: return SentimentResult(sentimentnegative, confidence0.7, languagemixed) else: return SentimentResult(sentimentneutral, confidence0.9, languagemixed) # 主入口符合GKE健康检查和HTTP服务规范 if __name__ __main__: analyzer SentimentAnalyzer() # 健康检查端点 from flask import Flask, request, jsonify app Flask(__name__) app.route(/healthz, methods[GET]) def healthz(): return jsonify({status: ok, timestamp: int(time.time())}) app.route(/analyze, methods[POST]) def analyze_endpoint(): try: # 1. 解析输入 input_data request.get_json() if not input_data or text not in input_data: return jsonify({error: Missing text field}), 400 # 2. 执行主逻辑带重试 for attempt in range(3): # 包含fallback的总尝试次数 try: result analyzer.analyze(input_data[text]) # 计算文本哈希用于审计 text_hash hashlib.sha256(input_data[text].encode()).hexdigest()[:16] logger.info(fAnalysis success: {result.sentiment}, hash{text_hash}) return jsonify({ sentiment: result.sentiment, confidence: result.confidence, language: result.language, text_hash: text_hash }) except Exception as e: if attempt 2: # 最后一次尝试触发fallback logger.warning(fUsing fallback after {attempt} attempts: {e}) fallback_result fallback_to_rule_based(input_data[text]) return jsonify({ sentiment: fallback_result.sentiment, confidence: fallback_result.confidence, language: fallback_result.language, fallback_triggered: True }) time.sleep(2 ** attempt) # 指数退避 except Exception as e: logger.error(fUnexpected error: {e}) return jsonify({error: Internal server error}), 500 app.run(host0.0.0.0, port8080)关键设计说明超时控制timeout(5,15)确保连接5秒内建立读取15秒内完成避免长尾请求拖垮整个skills契约校验在analyze()方法内二次校验API响应确保外部服务返回符合契约而非盲目信任降级兜底fallback_to_rule_based()是纯Python实现无外部依赖确保在ML服务完全不可用时仍能返回合理结果审计友好text_hash字段用于关联原始输入满足GDPR等合规要求4.3 Docker镜像构建与GKE部署Dockerfile采用前述多阶段构建策略确保兼容性# 构建阶段 FROM python:3.11-slim-bookworm as builder WORKDIR /app COPY requirements.txt . RUN pip install --target /app/dependencies -r requirements.txt COPY skill.py . # 运行阶段 FROM python:3.11-alpine3.18 RUN apk add --no-cache libstdc libgcc WORKDIR /app COPY --frombuilder /app/dependencies /usr/local/lib/python3.11/site-packages/ COPY --frombuilder /app/skill.py . CMD [python, skill.py]requirements.txt极简只保留必要依赖Flask2.3.3 requests2.31.0部署到GKE的K8s Manifestskill-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: analyze-sentiment-skill labels: skill-name: analyze-customer-sentiment spec: replicas: 3 selector: matchLabels: app: analyze-sentiment-skill template: metadata: labels: app: analyze-sentiment-skill spec: serviceAccountName: skill-executor-sa # 绑定Agent Platform授予的SA securityContext: runAsNonRoot: true runAsUser: 1001 containers: - name: skill-container image: gcr.io/my-project/analyze-sentiment-skill:v2.1.0 ports: - containerPort: 8080 env: - name: SENTIMENT_API_URL value: https://api.sentiment-ml.com/v1/analyze - name: SENTIMENT_API_KEY valueFrom: secretKeyRef: name: sentiment-ml-secrets key: api-key resources: requests: cpu: 800m memory: 1.2Gi limits: cpu: 1200

Skills：Agent时代的能力接口范式与GKE生产实践

相关推荐

FPGA设计中PLL locked信号与复位逻辑的可靠实现

AI安全生产力三步走：数据底子、单点闭环、组织能力

UE5蓝图背包系统实现：从数据结构到拾取、堆叠与UI交互全解析

更多资讯

USB3.0 HUB设计与调试实战：从选型到PCB Layout的完整指南

智慧警务平台建设方案落地拆解：分层架构、数据治理与权限设计

无线脑电采集显示系统：基于BW16与ESP32-CYD的完整实现

MOS管驱动波形调试：示波器测量与米勒平台分析实战指南

从零设计STM32最小系统扩展板：原理图、PCB布局到打样焊接全流程

74LS194环形计数器从原理到实战：移位寄存器、自启动电路与调试全解析

今日更新

Multisim仿真NE555 PWM控制器：从搭电路到调占空比全流程

S32K312 AUTOSAR BSW开发实战：从配置踩坑到烧录交付

双目视觉三维人脸重建：从视差图到点云粗配准全流程解析

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？