1. 从“skills”这个标题说起它到底在指什么第一次看到“skills”这个标题很多人会以为是某个泛泛而谈的能力清单或者一份简历上的技能罗列。但结合热搜词里反复出现的 Agent Skills、Google Cloud、GKE、Genkit以及“claude agent skills: a first principles deep dive”“codex skills”“skills开发”“skills安装包下载”这些词基本可以判断这里说的 skills不是人类职场技能而是给 AI Agent 用的可插拔能力模块。说白了Agent Skills 就是一套让 AI 助手从“只会聊天”变成“能干活”的机制。它把某个具体任务所需的指令、脚本、资源、模板打包成一个独立单元Agent 在需要的时候按需加载用完即走。你可以把它理解成给一个刚入职的实习生配了一本本操作手册查数据库有查数据库的手册写周报有写周报的手册做代码审查有代码审查的手册。手册不在多在于每本都能落地。这个标题背后真正值得拆的是三个层面的问题。第一skills 的结构设计——一个 skill 到底由哪些文件组成为什么这样分。第二skills 的运行机制——Agent 怎么知道该加载哪个 skill加载之后怎么执行。第三skills 的工程化落地——怎么开发、测试、分发、复用以及和 Google Cloud、GKE、Genkit 这类云原生工具链怎么配合。适合读这篇内容的人有三类。一类是正在用 Claude、Codex 这类工具做自动化的人想搞清楚 skills 到底怎么装、怎么写。一类是做 AI 应用开发的工程师想把 skills 机制引入自己的产品。还有一类是纯好奇的技术爱好者看到“今天学会了 skills打开新世界”这种话想知道新世界到底长什么样。下面我按自己实际折腾下来的顺序把这件事从头到尾讲清楚。2. Agent Skills 的整体设计与核心思路拆解2.1 为什么是“技能包”而不是“一个大提示词”早期做 AI 自动化最常见的做法是把所有要求塞进一个超长提示词里。系统提示词写三千字用户提示词再补两千字模型确实能干活但问题很快暴露出来。第一提示词越长模型注意力越分散关键指令容易被淹没。第二所有能力耦合在一起改一个查天气的逻辑可能把写代码的逻辑带崩。第三无法复用A 项目写的提示词B 项目只能复制粘贴再改维护成本极高。Agent Skills 的核心思路就是解耦。它把“能力”从“对话”里抽出来做成独立目录。每个 skill 有自己的名字、描述、指令文件必要时还有脚本和参考文档。Agent 启动时只加载所有 skill 的元数据名字和描述真正需要某个能力时才把对应的完整指令读进来。这个设计和操作系统的动态链接库很像程序启动时不把所有库都加载进内存用到哪个加载哪个。这样设计带来的直接好处是上下文可控。一个 Agent 可以挂载几十个 skill但单次对话消耗的 token 只和当前任务相关。另一个好处是可测试。每个 skill 可以单独跑测试用例输入什么、期望输出什么边界清晰。还有一个容易被忽略的好处是可协作。团队里每个人负责几个 skill通过版本管理合并比所有人改同一份巨型提示词靠谱得多。2.2 一个 skill 的最小结构长什么样我实际拆过几个公开的 skill 包也自己写过几个最小可用的结构其实非常朴素。一个目录里面至少有一个SKILL.md文件。这个文件用 YAML frontmatter 写元数据正文写具体指令。类似这样--- name: weekly-report description: 根据本周的 git commit 记录和任务清单生成结构化周报 --- ## 目标 把零散的提交记录整理成管理层能看懂的周报。 ## 步骤 1. 读取本周 commit 记录按模块归类 2. 对照任务清单标记完成和未完成项 3. 按“进展、风险、下周计划”三段式输出name和description是给 Agent 看的用来判断“这个 skill 是干什么的、什么时候该用”。正文是给 Agent 执行时看的详细指令。如果任务复杂还可以加scripts/目录放可执行脚本加references/目录放参考文档加assets/目录放模板文件。Agent 在执行过程中可以按需读取这些资源。这里有个关键设计点description 的写法直接决定 skill 会不会被正确触发。写得太窄该用的时候用不上写得太宽不该用的时候乱用。我的经验是description 里要同时包含“做什么”和“什么时候用”比如“当用户要求生成周报、总结本周工作、整理提交记录时使用”。这比只写“生成周报”的触发准确率高很多。2.3 和 Google Cloud、GKE、Genkit 的关系在哪热搜词里出现 Google Cloud、GKE、Genkit说明 skills 不只是本地玩具它正在往云原生方向走。GKE 是 Kubernetes 托管服务Genkit 是 Google 出的 AI 应用开发框架。把 skills 和这些结合解决的是规模化运行的问题。本地跑一个 Agent 加载几个 skill用命令行就够了。但如果要同时服务几百个用户每个用户有自己的一套 skill还要保证隔离、扩缩容、日志追踪就必须上容器编排。GKE 提供的就是这个能力每个 skill 执行环境可以打包成容器按需调度。Genkit 则提供了更上层的抽象把 skill 的调用、模型的接入、工具的定义统一成一套接口。我自己的判断是skills 的形态会分两层。一层是个人效率层本地文件目录加一个 Agent 客户端就能跑适合个人开发者和小团队。另一层是平台服务层skills 作为可注册、可发现、可计费的服务运行在云上适合企业级应用。两层之间通过标准化的 skill 描述格式打通。现在这个标准还在快速演进但方向已经比较清晰了。3. 核心细节解析与实操要点3.1 SKILL.md 的元数据字段怎么填才不踩坑元数据看起来简单实际写起来坑不少。我按字段逐个说。name字段建议用短横线分隔的小写英文比如code-review、>