1. 从skills这个模糊词说起它到底指什么第一次看到skills这个标题加上Google Cloud、GKE、Genkit这几个关键词我脑子里第一反应是这大概率不是指人类技能而是指Agent Skills——也就是给AI智能体挂载的能力包。最近一段时间围绕Agent Skills的讨论确实密集从Claude的Agent Skills到Codex的skills再到各种skills市场、skills下载平台热度一直没降下来。但问题在于skills这个词太泛了。它可以是前端开发skills可以是superpower skills也可以是自动挖洞skills。不同语境下它指向的东西完全不同。所以这篇内容我打算做一件事把skills这个概念从模糊拉回到具体讲清楚它在Agent场景下到底是什么、为什么会出现、怎么设计、怎么落地以及围绕Google Cloud这套技术栈GKE Genkit能怎么玩。如果你是一个正在做AI Agent应用的开发者或者你只是好奇为什么大家都在聊skills这篇内容应该能帮你把思路理顺。我不会只讲概念会带上具体的结构设计、代码示例、部署思路以及我自己在实操中踩过的坑。先给一个最直白的定义Agent Skill本质上是一段可被智能体识别、加载、执行的能力描述单元。它通常包含三部分——元信息这个skill叫什么、干什么用、触发条件什么情况下该调用它、执行逻辑具体怎么做。你可以把它理解成给AI写的一份岗位说明书操作手册。为什么这个东西突然火了因为大模型本身是通才但通才在具体任务上往往不够专。你让一个通用模型去处理GKE集群的滚动更新它可能给你一堆似是而非的命令。但如果你给它挂一个专门针对GKE的skill里面写清楚了正确的kubectl命令、回滚策略、健康检查逻辑它的输出质量会立刻上一个台阶。这就是skills的核心价值把领域知识从模型参数里外挂出来变成可维护、可复用、可版本控制的独立单元。模型负责理解和调度skill负责提供准确的动作。2. Agent Skills的底层逻辑为什么不是简单的Prompt很多人第一次接触skills会觉得这不就是高级一点的Prompt吗。我一开始也这么想但实际用下来发现两者有本质区别。理解这个区别是设计好skill的前提。2.1 Prompt是一次性对话Skill是可复用能力Prompt是你每次对话时临时写的一段指令用完就散了。Skill不一样它是一个持久化的、有结构的、可被检索的能力单元。当智能体遇到某个任务时它会先去找skill——就像人遇到问题会先想我有没有相关经验一样。这个找的过程就是skills体系里最关键的一环。它通常依赖两层机制元数据匹配每个skill都有name和description智能体先通过语义相似度筛选出候选skill。内容加载选中之后才把skill的完整内容通常是Markdown格式的操作指南加载进上下文。这样做的好处是上下文经济。你不可能把所有领域知识都塞进系统提示里那样token会爆炸。Skills让你按需加载用哪个调哪个。2.2 Skill的结构元信息、触发、执行三段式一个设计良好的skill我一般会拆成三段部分作用常见字段元信息让智能体知道有这个能力name、description、version触发条件判断什么时候用关键词、场景描述、前置条件执行逻辑告诉智能体具体怎么做步骤、命令、参数、异常处理元信息里的description尤其重要。它写得好不好直接决定智能体能不能在正确的时机找到这个skill。我见过太多skill因为description写得太笼统比如处理数据库相关操作导致该调用的时候调不到不该调用的时候乱调。2.3 和Function Calling的关系有人会问这和Function Calling有什么区别我的理解是Function Calling是模型调用外部函数的机制而Skill是给模型看的操作知识。一个skill内部可以包含多个function call也可以只是一段纯文本的操作指南。举个例子一个GKE集群健康检查的skill可能包含一段说明文字告诉智能体检查哪些指标几个命令kubectl get nodes、kubectl describe pod等判断逻辑什么情况下算异常处理建议异常时该怎么回滚或扩容这里面既有知识也有动作。Function Calling只解决了动作那一半Skill把知识那一半也补上了。3. 用Genkit搭建Skill调度层从零到跑通Genkit是Google推出的AI应用开发框架它的定位是帮你把模型调用、工具编排、流程控制这些事串起来。用它来做skills的调度层我觉得挺顺手因为它对工具这个概念的支持很自然。3.1 环境准备与项目初始化先装依赖。我习惯用Node环境因为Genkit对TypeScript的支持最完整npm init -y npm install genkit genkit-ai/googleai npm install -D typescript tsx然后初始化Genkit配置import { genkit } from genkit; import { googleAI } from genkit-ai/googleai; export const ai genkit({ plugins: [googleAI()], model: googleai/gemini-2.0-flash, });这里有个小坑模型选择要和你的skill复杂度匹配。如果skill里涉及多步推理和工具调用用flash可能会在中间步骤掉链子建议上pro。我实测下来简单skill用flash够用复杂的还是pro稳。3.2 把Skill定义成Genkit ToolGenkit里的tool概念天然适合承载skill的执行部分。你可以这样定义一个skillimport { z } from genkit; import { ai } from ./genkit-config; export const gkeHealthCheck ai.defineTool( { name: gkeHealthCheck, description: 检查GKE集群节点和Pod的健康状态返回异常列表, inputSchema: z.object({ clusterName: z.string().describe(GKE集群名称), namespace: z.string().optional().describe(命名空间默认default), }), outputSchema: z.object({ healthy: z.boolean(), issues: z.array(z.string()), }), }, async (input) { // 这里放实际的检查逻辑 // 可以是调用kubectl也可以是调用GKE API const issues: string[] []; // ... 检查逻辑 return { healthy: issues.length 0, issues }; } );注意description的写法。我特意写清楚了检查节点和Pod的健康状态返回异常列表这样智能体在遇到集群是不是有问题这类问题时能准确匹配到这个skill。3.3 让智能体自动选择Skill定义好tool之后Genkit可以自动处理什么时候调用哪个tool。你只需要在生成时把tools传进去const response await ai.generate({ prompt: 帮我看看生产集群现在有没有问题, tools: [gkeHealthCheck], });Genkit会根据prompt和tool的description做匹配。如果匹配上了它会自动调用并返回结果。这一步的体验很顺但前提是你的description写得够准。3.4 多Skill编排的注意事项当你有一堆skill的时候问题就来了智能体可能选错或者一次选太多。我的经验是每个skill的description要互斥不要有重叠的语义。比如检查集群健康和诊断集群问题就容易混。控制单次可用的skill数量。我一般不超过10个多了就分组按场景加载。给skill加优先级或场景标签在prompt里做前置过滤。这些细节在官方文档里不会写但实际项目里不注意就会翻车。4. 部署到GKE让Skill服务真正跑起来Skill定义好了Genkit流程也跑通了接下来就是部署。GKE是Google的Kubernetes服务用它来托管skill服务好处是弹性伸缩和滚动更新都很成熟。4.1 容器化Skill服务先把Genkit应用打包成镜像。Dockerfile大概长这样FROM node:20-slim WORKDIR /app COPY package*.json ./ RUN npm ci --production COPY . . RUN npm run build EXPOSE 3400 CMD [node, dist/server.js]Genkit默认跑在3400端口。构建镜像docker build -t skill-service:v1 .4.2 GKE部署清单的关键字段部署到GKE核心是Deployment和Service两个资源。我重点说几个容易配错的字段apiVersion: apps/v1 kind: Deployment metadata: name: skill-service spec: replicas: 2 selector: matchLabels: app: skill-service template: metadata: labels: app: skill-service spec: containers: - name: skill-service image: skill-service:v1 ports: - containerPort: 3400 resources: requests: memory: 512Mi cpu: 250m limits: memory: 1Gi cpu: 500m readinessProbe: httpGet: path: /health port: 3400 initialDelaySeconds: 10 periodSeconds: 5几个经验点readinessProbe一定要配。Genkit服务启动需要加载模型配置没配探针的话流量会在服务没准备好时就打进来导致请求失败。resources的requests和limits要拉开差距。skill服务的特点是平时CPU低、突发时高requests给低一点保证调度limits给高一点应对峰值。replicas至少2个。单副本在滚动更新时会有短暂不可用2个能保证平滑。4.3 滚动更新与回滚策略GKE默认的滚动更新策略是maxSurge 25%、maxUnavailable 25%。对于skill服务我建议调保守一点strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0maxUnavailable设为0意味着新Pod完全就绪之前旧Pod不会被干掉。这样更新过程中服务始终可用。代价是更新慢一点但skill服务通常不是高频更新慢一点无所谓。回滚就更简单了kubectl rollout undo deployment/skill-service但要注意回滚只回滚镜像不回滚配置。如果你的skill定义是挂在ConfigMap里的回滚镜像后配置可能不匹配。我的做法是把skill定义和镜像版本绑定一起发布一起回滚。4.4 用ConfigMap管理Skill定义Skill的文本内容那些Markdown操作指南不适合硬编码在代码里放ConfigMap更灵活apiVersion: v1 kind: ConfigMap metadata: name: skill-definitions data: gke-health-check.md: | # GKE健康检查 检查以下内容 1. 节点状态kubectl get nodes 2. Pod状态kubectl get pods --all-namespaces 3. 异常事件kubectl get events --sort-by.lastTimestamp这样改skill内容不用重新构建镜像改ConfigMap然后重启Pod就行。但记得ConfigMap更新后Pod不会自动重载需要手动触发滚动重启kubectl rollout restart deployment/skill-service5. Skill设计中的常见坑与排查思路这部分是我最想写的因为网上讲skill概念的多讲实际踩坑的少。下面这几个问题我几乎在每个项目里都遇到过。5.1 Skill匹配不上description写得太聪明最常见的坑智能体该调用skill的时候不调用。排查下来十有八九是description的问题。我见过有人把description写成处理集群相关的高级操作。这种描述对人是清楚的但对语义匹配来说太模糊。高级操作是什么智能体不知道。正确的写法是用具体的动作和对象检查GKE集群的节点状态、Pod运行情况和最近事件返回异常项列表这句话里有动作检查、对象节点、Pod、事件、输出异常列表。智能体一看就知道什么时候该用。5.2 Skill被滥用触发条件太宽反过来也有skill被乱调用的情况。比如一个发送通知的skilldescription写的是发送消息结果智能体在任何需要输出的时候都去调它。解决办法是在description里加约束当需要向指定渠道如邮件、Slack发送格式化通知时使用。不用于普通对话回复。明确写出不用于什么能大幅减少误调用。5.3 多Skill冲突语义重叠的排查方法当你有几十个skill的时候语义重叠几乎不可避免。我的排查方法是把所有skill的description列出来两两做语义相似度对比。相似度超过阈值的要么合并要么改写description拉开差异。在测试环境跑一批典型prompt看智能体的选择是否符合预期。这个工作很枯燥但做一次能省掉后面无数次的调试。5.4 上下文超限Skill内容太长被截断Skill的完整内容是要加载进上下文的。如果一个skill写了5000字加上其他上下文很容易超限。我的经验是单个skill的正文控制在800字以内。超长的操作指南拆成多个skill用主skill做索引。把不常变的部分如背景知识放到外部文档skill里只放操作步骤。5.5 排查链路一个真实的匹配失败案例说个具体的。有次上线后用户反馈问集群扩容的事智能体答非所问。我的排查过程是这样的第一步复现问题。用同样的prompt测试确认确实没调用扩容skill。第二步检查skill是否被加载。看日志发现skill在候选列表里但没被选中。第三步对比description。扩容skill的description是调整集群规模而另一个资源优化skill的description是优化集群资源配置。两者语义太近智能体选了后者。第四步改写。把扩容skill改成增加或减少GKE集群的节点数量把资源优化改成调整Pod的CPU和内存请求配额。改完之后匹配准确率明显提升。这个案例说明skill设计不是一劳永逸的需要根据实际调用数据持续迭代。6. Skill的版本管理与团队协作一个人用skill和团队用skill复杂度完全不是一个量级。团队协作场景下版本管理和规范约定特别重要。6.1 Skill的版本控制策略我建议把skill定义纳入Git管理和代码一起走PR流程。目录结构可以这样skills/ gke/ health-check.md scale-cluster.md genkit/ deploy-flow.md _index.yaml_index.yaml记录所有skill的元信息方便程序加载。每次改skill都走PR有人review避免有人随手改坏了description导致匹配失效。6.2 命名规范让Skill可检索命名这件事我踩过坑。早期我用的是checkCluster这种驼峰命名后来发现检索不方便。现在统一用领域-动作的格式gke-health-checkgke-scale-clustergenkit-deploy-flow这样按领域前缀一搜就能找到一组相关skill。6.3 测试Skill的单元测试怎么写Skill也需要测试。我的做法是给每个skill写一组触发用例const testCases [ { prompt: 集群现在健康吗, expectedSkill: gke-health-check }, { prompt: 帮我扩容到5个节点, expectedSkill: gke-scale-cluster }, { prompt: 今天天气怎么样, expectedSkill: null }, ];跑一遍看智能体的选择是否和预期一致。这个测试不用很频繁但每次改description之后一定要跑。6.4 团队共享Skill的注意事项团队共享skill最大的问题是上下文差异。A同学写的skill假设了某个环境变量存在B同学用的时候没有就报错。解决办法是在skill里明确写出前置依赖前置条件需要配置GKE_PROJECT_ID和GKE_CLUSTER_NAME环境变量。把依赖写清楚比事后排查省事得多。7. 从Skills延伸出去还能怎么玩Skills这套思路其实不局限于Agent。它的本质是把隐性知识显性化、结构化、可复用化。这个思路可以迁移到很多场景。比如前端开发skills可以把组件库的使用规范、常见布局模式、性能优化checklist做成skill让AI辅助写代码时直接调用。再比如自动挖洞skills可以把常见漏洞的检测逻辑和验证步骤结构化提升安全测试的效率。我甚至见过有人把分镜设计做成skill输入剧本输出分镜描述。这说明skills的边界只取决于你怎么定义它。回到Google Cloud这套栈Genkit GKE的组合我觉得最适合做的是企业内部的能力中台。把各个团队的专业能力做成skill统一注册、统一调度智能体按需调用。这样既避免了重复建设又保证了能力的一致性。最后分享一个我自己的体会skill的质量取决于你对业务的理解深度而不是你对AI的调参技巧。一个对GKE运维了五年的工程师写出来的skill一定比一个刚学Kubernetes的人写得好。所以做skills这件事别只盯着模型多花时间在领域知识上回报会更高。