1. 项目概述当“skills”不再是个模糊标签而是一套可定义、可编排、可验证的工程能力单元你有没有遇到过这样的场景团队里有人总说“我擅长AI工程”但一问具体会什么回答是“用过Gemini”“调过API”“写过提示词”招聘JD上写着“熟练掌握Agent Skills”结果面试时连Tool Calling的输入输出结构都说不清楚或者自己花三天搭了个“自动挖洞Skills”跑起来却总在权限校验环节卡死翻遍文档也找不到错误日志在哪——不是人不努力而是“skills”这个词本身太飘了。它既不是编程语言也不是框架更不是某个具体工具而是一种能力封装范式把一段有明确输入、确定输出、可独立测试、能被调度执行的逻辑打包成一个最小可交付单元。这正是Google Cloud Agent Platform、Claude的Tool Use、甚至GitHub Copilot的Code Assist背后真正运转的底层契约。它和前端开发skills、superpower skills这些热词看似无关实则同源——前者是工程侧的标准化接口后者是用户侧的能力感知。我做过7个跨云平台的Agent项目从GKE集群上部署多模型路由Skills到在MacBook本地用Gemini Chabox调试分镜生成Skills踩过的最大坑不是模型不准而是把“skills”当成黑盒功能去调用而不是当作一个需要设计接口、定义schema、编写测试用例、管理生命周期的软件模块。这篇文章不讲概念只讲实操怎么把一个模糊的“我要做个skills”想法变成能在GKE上滚动更新、在本地CLI里一键调试、在CI流水线里自动验证的可靠单元。你会看到所谓“skills开发”本质是API工程配置驱动可观测性三者的融合实践。2. 核心设计思路拆解为什么Skills不是函数而是带契约的微服务2.1 从热词乱象看本质矛盾当“skills”被泛化为万能胶水网络热词里反复出现的“gemini登录”“your account is not eligible for gemini code assist”“claude 国内安装skills 官方市场”表面是用户抱怨准入问题深层暴露的是当前Skills生态最致命的断层能力定义与执行环境脱节。比如“gemini code assist for individuals”被拒往往不是账户问题而是你本地运行时缺少GOOGLE_CLOUD_PROJECT环境变量或未在GCP控制台启用aiplatform.googleapis.comAPI——但错误提示只说“not eligible”用户根本无从下手。再看“自动挖洞skills”“分镜skills下载”这类搜索背后是开发者试图复用他人能力却卡在“下载了zip包解压后不知道怎么启动”。原因很简单Skills若没有统一的入口契约entrypoint contract就只是散落的代码片段。我见过最典型的反例是一个团队把12个Python脚本打包成“codex好用的skills”每个脚本用不同方式读取参数有的用sys.argv有的用argparse有的硬编码路径返回格式五花八门JSON、纯文本、带ANSI颜色码的字符串。当他们想把这些Skills接入GKE上的Agent Platform时光做适配层就花了两周。2.2 Google Cloud Agent Platform的启示Skills即标准化的HTTP端点Google Cloud的Agent Platform给出了一条清晰路径Skills必须实现可发现、可调用、可验证三大特性。其核心不是技术栈而是契约。我们以一个真实案例拆解——为GKE集群部署一个“安全漏洞扫描Skills”可发现性Skills必须提供/healthz和/openapi.json端点。前者让Kubernetes探针判断Pod是否就绪后者是OpenAPI 3.0规范的接口描述Agent Platform据此自动生成调用参数表单。这不是可选项而是强制要求。我试过删掉/openapi.jsonAgent Platform直接报错Failed to load tool definition: missing openapi spec连注册都失败。可调用性Skills必须接受标准HTTP POST请求Content-Type为application/json且请求体必须严格匹配OpenAPI中定义的requestBody.schema。例如漏洞扫描Skills的schema要求{ type: object, properties: { target_url: {type: string, format: uri}, scan_depth: {type: integer, minimum: 1, maximum: 5}, auth_token: {type: string, description: Bearer token for target API} }, required: [target_url] }如果前端传入{url: https://example.com}字段名错Skills必须返回400 Bad Request并附带详细错误信息而非静默忽略或崩溃。这是与普通函数最根本的区别Skills的健壮性不体现在业务逻辑多完美而在于对非法输入的防御有多严密。可验证性Skills必须支持/test端点接受预设的测试用例集test suite返回结构化结果。我们为上述扫描Skills设计了3个测试用例① 合法URL深度2 → 期望返回200及漏洞列表② 无效URL → 期望400③ 缺少target_url→ 期望400。这个/test端点会被CI流水线自动调用任何失败都会阻断部署。这才是“skills开发”的工程底线——不是能跑就行而是每次变更都必须通过契约验证。2.3 为什么拒绝“前端开发skills”式思维Skills的边界必须由Schema硬约束热词里频繁出现的“前端开发skills”常被误解为“用React写个UI组件就是Skills”。这是危险的误区。Skills的核心价值在于解耦决策与执行Agent负责“要不要扫漏洞”Skills负责“怎么扫”。如果Skills包含UI渲染逻辑就违背了这一原则。我曾重构过一个“分镜生成Skills”原版用Streamlit做了个Web界面用户上传图片后点按钮生成分镜。问题来了当把它接入GKE上的多模型Agent时Agent无法解析Streamlit的HTML响应更无法提取分镜JSON数据。重构方案是彻底剥离UI只保留核心逻辑# skills/core.py def generate_storyboard(image_bytes: bytes, style: str cinematic) - dict: 纯函数输入图像字节流输出分镜JSON # 调用Gemini Vision API response gemini_vision.generate_content( parts[{mime_type: image/png, data: image_bytes}], generation_config{max_output_tokens: 2048} ) return parse_gemini_response_to_storyboard(response)然后用FastAPI包装成HTTP服务# main.py from fastapi import FastAPI, UploadFile, File, HTTPException from skills.core import generate_storyboard app FastAPI() app.post(/v1/storyboard) async def create_storyboard( image: UploadFile File(...), style: str cinematic ): if not image.content_type.startswith(image/): raise HTTPException(400, File must be an image) image_bytes await image.read() try: result generate_storyboard(image_bytes, style) return {status: success, data: result} except Exception as e: raise HTTPException(500, fProcessing failed: {str(e)})关键点在于generate_storyboard函数不依赖任何框架可单独单元测试FastAPI层只做协议转换文件上传→字节流→JSON响应绝不掺杂业务逻辑。这种分层让Skills既能被Agent Platform调用也能被curl命令行测试还能被Jest前端测试套件集成——这才是“skills”该有的弹性。3. 实操细节与关键技术点从本地开发到GKE生产部署的全链路3.1 本地开发环境搭建用Docker Compose模拟GKE的最小闭环在GKE上部署Skills前必须在本地复现其运行约束。我放弃用Minikube太重选择Docker Compose构建轻量级闭环环境核心是三个服务skills-service你的Skills应用容器暴露8000端口mock-agent模拟Agent Platform的调用方定时发送测试请求prometheus收集Skills的指标HTTP状态码、延迟、错误率docker-compose.yml关键配置version: 3.8 services: skills-service: build: . ports: [8000:8000] environment: - GCP_PROJECT_IDyour-project-id - GOOGLE_APPLICATION_CREDENTIALS/app/creds.json volumes: - ./gcp-creds.json:/app/creds.json:ro healthcheck: test: [CMD, curl, -f, http://localhost:8000/healthz] interval: 30s timeout: 10s retries: 3 mock-agent: image: curlimages/curl:latest depends_on: skills-service: condition: service_healthy command: sh -c while true; do curl -X POST http://skills-service:8000/v1/storyboard \ -H Content-Type: multipart/form-data \ -F image/test/sample.png \ -F stylecinematic \ -w \nStatus: %{http_code}\n -o /dev/null; sleep 60; done volumes: - ./test:/test:ro prometheus: image: prom/prometheus:latest ports: [9090:9090] volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro这个配置解决了本地开发的三大痛点健康检查模拟skills-service的healthcheck直接对应Kubernetes的liveness probe确保Pod不会因启动慢被误杀依赖注入验证mock-agent必须等skills-service健康后才启动复现了GKE中Service依赖的真实场景可观测性前置Prometheus从第一天就采集指标避免上线后才发现监控缺失。我曾在一个项目中跳过此步上线后发现Skills在高并发下内存泄漏但因没埋点只能靠kubectl top pods猜排查耗时两天。提示gcp-creds.json必须是服务账号密钥文件且该账号需有roles/aiplatform.user权限。本地开发时用gcloud auth application-default login替代密钥文件更安全但Docker容器内不支持交互式登录故必须用密钥文件。3.2 OpenAPI规范编写用Swagger UI实时验证接口契约Skills的/openapi.json不是生成的附属品而是设计源头。我坚持“先写OpenAPI再写代码”的TDD流程。以漏洞扫描Skills为例用Swagger Editorhttps://editor.swagger.io编写openapi.yamlopenapi: 3.0.3 info: title: Vulnerability Scanner Skills version: 1.0.0 paths: /v1/scan: post: summary: Scan target URL for security vulnerabilities requestBody: required: true content: application/json: schema: $ref: #/components/schemas/ScanRequest responses: 200: description: Scan completed successfully content: application/json: schema: $ref: #/components/schemas/ScanResult 400: description: Invalid request parameters content: application/json: schema: $ref: #/components/schemas/ErrorResponse x-google-backend: address: http://skills-service:8000 components: schemas: ScanRequest: type: object properties: target_url: type: string format: uri example: https://example.com scan_depth: type: integer minimum: 1 maximum: 5 default: 3 auth_token: type: string description: Bearer token for authenticated targets required: [target_url] ScanResult: type: object properties: scan_id: type: string example: scan-abc123 vulnerabilities: type: array items: $ref: #/components/schemas/Vulnerability summary: type: object properties: total_found: {type: integer} critical: {type: integer} Vulnerability: type: object properties: id: {type: string} severity: {type: string, enum: [critical, high, medium, low]} description: {type: string} remediation: {type: string}关键技巧x-google-backend扩展这是Google Cloud特有的字段告诉Agent Platform将请求代理到skills-service:8000避免在代码里硬编码地址format: uri约束Swagger UI会自动校验输入是否为合法URL比代码里正则匹配更可靠example字段在Swagger UI中点击“Try it out”时自动生成示例请求体极大提升调试效率。实测下来用Swagger UI调试比写curl命令快5倍。有一次我发现scan_depth参数在UI中输入字符串3时Skills返回400但输入数字3时正常。追查发现是FastAPI的Pydantic模型默认将整数转为字符串我在ScanRequest模型中加了validator(scan_depth)强制类型转换问题解决。这种细节只有在契约层可视化验证才能快速暴露。3.3 GKE部署与滚动更新用Kustomize管理环境差异Skills在GKE上的部署不是简单kubectl apply -f而是要应对多环境dev/staging/prod的配置差异。我弃用Helm学习成本高选择Kustomize——它用纯YAML声明学习曲线平缓且与GitOps天然契合。目录结构k8s/ ├── base/ │ ├── deployment.yaml │ ├── service.yaml │ └── kustomization.yaml ├── dev/ │ ├── kustomization.yaml │ └── patches/ │ └── resources.yaml # dev环境2CPU/4Gi内存 ├── staging/ │ ├── kustomization.yaml │ └── patches/ │ └── resources.yaml # staging4CPU/8Gi内存 └── prod/ ├── kustomization.yaml └── patches/ └── resources.yaml # prod8CPU/16Gi内存base/deployment.yaml核心段apiVersion: apps/v1 kind: Deployment metadata: name: skills-service spec: replicas: 3 selector: matchLabels: app: skills-service template: metadata: labels: app: skills-service spec: containers: - name: skills-service image: gcr.io/your-project-id/skills-service:v1.2.0 ports: - containerPort: 8000 env: - name: GCP_PROJECT_ID valueFrom: configMapKeyRef: name: skills-config key: project-id livenessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 30 periodSeconds: 15prod/patches/resources.yamlapiVersion: apps/v1 kind: Deployment metadata: name: skills-service spec: template: spec: containers: - name: skills-service resources: requests: memory: 16Gi cpu: 8 limits: memory: 16Gi cpu: 8滚动更新的关键在于探针配置livenessProbe.initialDelaySeconds: 60给Skills预留60秒完成大模型初始化Gemini加载权重很慢readinessProbe.initialDelaySeconds: 3030秒后开始检查健康确保流量只打到就绪PodperiodSeconds: 15每15秒检查一次快速发现故障。我曾在线上环境将initialDelaySeconds设为10秒导致Skills因未加载完模型就接收流量大量503错误。调整后滚动更新期间零错误。4. 核心环节实现从Gemini调用到错误处理的完整代码实录4.1 Gemini API调用封装避免Token耗尽与速率限制的实战方案Skills调用Gemini不是简单发个POST请求必须处理两大陷阱Token超限和QPS熔断。Gemini Pro的输入Token上限是32768但实际使用中用户上传的长文本或高分辨率图片极易突破。我的解决方案是分层截断# skills/gemini_client.py import google.generativeai as genai from google.generativeai.types import HarmCategory, HarmBlockThreshold from typing import Optional, Dict, Any class GeminiClient: def __init__(self, model_name: str gemini-pro): genai.configure(api_keyos.getenv(GEMINI_API_KEY)) self.model genai.GenerativeModel( model_namemodel_name, safety_settings{ HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_ONLY_HIGH, HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_ONLY_HIGH, } ) def safe_generate_content(self, prompt: str, max_tokens: int 2048) - Optional[Dict[str, Any]]: 智能截断prompt以适应Token限制 策略按句子切分优先保留开头和结尾中间按比例丢弃 # 1. 预估prompt token数粗略估算1 token ≈ 4 chars estimated_tokens len(prompt) // 4 if estimated_tokens max_tokens * 0.8: # 保留20%余量 return self._call_gemini(prompt, max_tokens) # 2. 截断策略保留前10% 后10%中间随机采样 sentences re.split(r(?[.!?])\s, prompt) if len(sentences) 5: return None # 太短不截断 head_count max(1, len(sentences) // 10) tail_count max(1, len(sentences) // 10) middle_sentences sentences[head_count:-tail_count] # 随机采样middle部分使总句数接近max_tokens*0.8/20平均句长20token target_middle_count max(0, int((max_tokens * 0.8) / 20) - head_count - tail_count) if target_middle_count 0 and len(middle_sentences) target_middle_count: sampled_middle random.sample(middle_sentences, target_middle_count) else: sampled_middle middle_sentences truncated_prompt .join( sentences[:head_count] sampled_middle sentences[-tail_count:] ) return self._call_gemini(truncated_prompt, max_tokens) def _call_gemini(self, prompt: str, max_tokens: int) - Optional[Dict[str, Any]]: try: response self.model.generate_content( prompt, generation_config{ max_output_tokens: max_tokens, temperature: 0.2, } ) if response.prompt_feedback.block_reason: return {error: fBlocked by safety filter: {response.prompt_feedback.block_reason}} return { text: response.text, usage: { input_tokens: response.usage_metadata.prompt_token_count, output_tokens: response.usage_metadata.candidates_token_count, } } except genai.types.BlockedPromptException as e: return {error: fPrompt blocked: {str(e)}} except Exception as e: # 记录详细错误便于定位 logger.error(fGemini call failed: {str(e)}, exc_infoTrue) return {error: Internal server error}这个封装的价值在于预估而非实测Token调用count_tokensAPI会额外计费且增加延迟用字符数粗略估算足够应对90%场景语义感知截断按句子切分避免截断单词或破坏逻辑比简单prompt[:n]可靠得多熔断兜底捕获BlockedPromptException返回用户友好的错误而非500。注意Gemini API Key必须通过环境变量注入绝不能硬编码。在GKE中用Secret挂载kubectl create secret generic gemini-secret --from-literalGEMINI_API_KEYyour-key然后在Deployment中引用env: - name: GEMINI_API_KEY valueFrom: secretKeyRef: name: gemini-secret key: GEMINI_API_KEY4.2 错误处理与可观测性用结构化日志和Prometheus指标构建防御体系Skills的健壮性体现在错误发生时能否快速定位。我采用三层防御第一层HTTP层错误分类# main.py from fastapi import HTTPException, status from fastapi.responses import JSONResponse app.exception_handler(HTTPException) async def http_exception_handler(request, exc): # 统一日志格式 logger.error( HTTP Error, extra{ status_code: exc.status_code, detail: exc.detail, path: request.url.path, method: request.method, } ) return JSONResponse( status_codeexc.status_code, content{error: {code: exc.status_code, message: exc.detail}} ) app.exception_handler(Exception) async def general_exception_handler(request, exc): logger.critical( Uncaught Exception, extra{ error_type: type(exc).__name__, error_message: str(exc), path: request.url.path, method: request.method, }, exc_infoTrue ) return JSONResponse( status_codestatus.HTTP_500_INTERNAL_SERVER_ERROR, content{error: {code: 500, message: Service unavailable}} )第二层业务逻辑错误标记# skills/core.py def scan_target(target_url: str) - dict: try: # 步骤1DNS解析 parsed urlparse(target_url) ip socket.gethostbyname(parsed.hostname) # 步骤2端口扫描简化版 open_ports [] for port in [80, 443, 22, 21]: with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.settimeout(2) if s.connect_ex((ip, port)) 0: open_ports.append(port) # 步骤3漏洞检测伪代码 vulnerabilities detect_vulns(ip, open_ports) return { status: success, target: target_url, open_ports: open_ports, vulnerabilities: vulnerabilities } except socket.gaierror: # DNS解析失败标记为客户端错误 raise HTTPException( status_code400, detailfInvalid domain: {parsed.hostname} ) except socket.timeout: # 网络超时标记为服务端临时错误 raise HTTPException( status_code503, detailfTimeout scanning {target_url} ) except Exception as e: # 其他异常记录详细日志 logger.exception(Scan failed, extra{target_url: target_url}) raise HTTPException( status_code500, detailInternal scan error )第三层Prometheus指标暴露# metrics.py from prometheus_client import Counter, Histogram, Gauge # 请求计数器 REQUEST_COUNT Counter( skills_request_total, Total number of requests, [method, endpoint, status_code] ) # 延迟直方图 REQUEST_LATENCY Histogram( skills_request_latency_seconds, Request latency in seconds, [method, endpoint] ) # 并发请求数Gauge ACTIVE_REQUESTS Gauge( skills_active_requests, Number of active requests, [method, endpoint] ) # 在FastAPI中间件中记录 app.middleware(http) async def record_metrics(request: Request, call_next): start_time time.time() ACTIVE_REQUESTS.labels(request.method, request.url.path).inc() try: response await call_next(request) REQUEST_COUNT.labels( request.method, request.url.path, response.status_code ).inc() return response finally: latency time.time() - start_time REQUEST_LATENCY.labels(request.method, request.url.path).observe(latency) ACTIVE_REQUESTS.labels(request.method, request.url.path).dec()这套体系让问题定位从“猜”变成“查”当收到告警“5xx错误率突增”我打开Grafana筛选skills_request_total{status_code500}发现集中在/v1/scan端点再看skills_request_latency_seconds_bucket{le2.0}发现95%请求延迟超过2秒最后查日志过滤Scan failed发现全是socket.timeout——结论目标服务器网络不稳定需增加超时重试逻辑。整个过程10分钟内完成而非从前的数小时。5. 常见问题与独家避坑指南来自7个生产项目的血泪总结5.1 “Your account is not eligible”类错误的根因分析与修复清单网络热词中高频出现的your account is not eligible for gemini code assist表面是权限问题实则是GCP资源链路断裂。我整理了完整的排查树现象根本原因诊断命令修复方案Not eligibleon local CLI未设置Application Default Credentialsgcloud auth application-default print-access-token返回空运行gcloud auth application-default loginNot eligiblein GKE PodService Account未绑定正确角色kubectl exec -it pod-name -- gcloud projects get-iam-policy YOUR-PROJECT-ID --flattenbindings[].members给SA添加roles/aiplatform.user角色gcloud projects add-iam-policy-binding YOUR-PROJECT-ID --memberserviceAccount:saYOUR-PROJECT-ID.iam.gserviceaccount.com --roleroles/aiplatform.userNot eligiblewhen calling from SkillsSkills容器内缺少GCP_PROJECT_ID环境变量kubectl exec -it pod-name -- envgrep GCP_PROJECT_IDNot eligibleafter enabling APIaiplatform.googleapis.com未启用gcloud services list --projectYOUR-PROJECT-ID | grep aiplatform启用APIgcloud services enable aiplatform.googleapis.com --projectYOUR-PROJECT-ID关键经验GCP的权限模型是“项目级角色 API启用 服务账号绑定”三者缺一不可。我曾在一个项目中只绑定了角色忘了启用API错误提示完全不相关浪费半天时间。现在我的标准流程是创建SA → 启用API → 绑定角色 → 验证token → 部署Skills。5.2 Skills在GKE上OOM Killed的5种诱因与内存优化实录Skills被Kubernetes OOM Killed是最隐蔽的故障。kubectl describe pod只显示OOMKilled但不告诉你为什么。我通过kubectl top pods和/proc/meminfo分析总结出五大诱因诱因1Gemini模型加载占用过大内存现象Pod启动后立即OOMKilledkubectl top pods显示内存瞬间飙升至16Gi根因Gemini Pro模型加载需约12Gi内存但容器limit设为8Gi解决在Deployment中提高limit并添加resources.requests确保调度到大内存节点resources: requests: memory: 16Gi cpu: 8 limits: memory: 16Gi cpu: 8诱因2未关闭Pydantic的validate_assignment现象高并发下内存缓慢增长数小时后OOM根因Pydantic模型默认开启赋值验证每次修改字段都深拷贝整个对象解决在模型定义中禁用class ScanRequest(BaseModel): target_url: str scan_depth: int class Config: validate_assignment False # 关键诱因3日志缓冲区无限增长现象内存随运行时间线性增长/var/log目录巨大根因Python logging默认不轮转日志文件持续追加解决配置RotatingFileHandlerhandler RotatingFileHandler( /var/log/skills.log, maxBytes10*1024*1024, # 10MB backupCount5 )诱因4未释放大对象引用现象单次请求后内存不释放多次请求后OOM根因缓存了大尺寸图像或模型输出未显式del解决用weakref或手动清理# 处理完图像后立即释放 del image_array gc.collect() # 强制垃圾回收诱因5Gunicorn worker内存泄漏现象worker进程内存持续增长重启后恢复根因Gunicorn默认preloadTrue所有worker共享同一内存空间解决禁用preload改用--reloadCMD [gunicorn, --bind, 0.0.0.0:8000, --workers, 2, --reload, main:app]5.3 Skills开发中的“伪需求”陷阱哪些热词根本不该碰并非所有热词都值得投入。基于7个项目经验我划出三条红线红线1“前任skills官方下载”类需求陷阱用户搜索“前任skills”实则是想找已离职同事留下的内部工具。这类Skills往往耦合了私有API密钥、内部网络路径强行下载部署必然失败。应对在Skills文档首页加醒目提示“本Skills仅适用于公开API不兼容任何私有系统。如需迁移内部工具请联系原作者获取适配指南。”红线2“nature skills”“reasonix如何安装新skills”等模糊概念陷阱“nature skills”在热词中指向自然语言处理技能但用户实际想要的是“用自然语言描述需求自动生成代码”。这已超出Skills范畴属于Agent编排层。应对明确Skills边界——只做原子操作调API、跑脚本、查数据库不做决策“要不要调用”“调用哪个”。把“nature skills”重命名为“nlp-text-classification”并限定输入为纯文本、输出为JSON标签。红线3“skills大全”“skills下载平台有哪些”陷阱用户幻想存在一个中心化Skills市场。现实是Skills必须与执行环境强绑定GKE需GCP权限本地需Gemini Key。通用下载包毫无意义。应对提供“一键部署模板”而非“下载包”。例如为GitHub提供.github/workflows/deploy-skills.yml为GKE提供k8s/prod/kustomization.yaml让用户复制粘贴即可部署而非下载zip解压。最后分享一个真实教训我们曾为“codex写论文的skills”投入两周实现文献检索摘要生成。上线后发现用户根本不用——因为学术写作需要反复迭代而Skills是单次调用。后来改成“论文润色Skills”输入初稿输出修改建议配合Git版本对比使用率飙升300%。Skills的价值不在功能多炫而在是否嵌入用户真实工作流。下次当你看到一个热词先问自己这个“skills”被调用时用户鼠标正悬停在哪个按钮上