1. 从“skills”这个热词说起：它到底指什么
最近“skills”这个词在技术圈出现的频率高得离谱。你刷技术社区，能看到“agent skills测试”“codex好用的skills”“skills开发”这类讨论；你翻云厂商的更新日志，又能看到“Google Cloud Agent Skills”“GKE”“Genkit”这些关键词绑在一起。很多人第一反应是：这不就是“技能”吗，有什么好聊的？但真正上手过一轮的人会告诉你，这里的 skills 已经不是一个泛泛的概念，而是一套可安装、可组合、可复用、可分发的能力单元。
我先把话说清楚：这篇内容里的 skills，指的是围绕 AI Agent（智能体）构建的、以文件或包为载体的能力模块。它可能是一个提示词模板加配套脚本，可能是一组工具调用封装，也可能是一段带上下文约束的工作流定义。你把它装进某个 Agent 运行时里，这个 Agent 就多了一项具体本事——比如自动挖洞、写论文、做分镜、跑测试、查日志。它和传统意义上的“插件”有重叠，但更轻、更偏“行为约定”，很多时候一个 Markdown 文件加几个辅助脚本就能跑起来。
为什么它突然火了？我的判断是三个因素叠加。第一，Agent 框架成熟到一定程度，大家发现“通用大模型 + 通用工具”解决不了垂直场景的最后一公里，必须靠 skills 这种细粒度能力去补。第二，分发成本极低，一个 skills 包往往就是几个文件，复制粘贴就能用，社区传播速度极快。第三，云厂商开始把它产品化，Google Cloud 把 Agent Skills 和 GKE、Genkit 放在一起讲，意味着 skills 不再只是个人玩具，而是能进生产环境的东西。
这篇文章适合谁看？如果你是刚听说 skills、想搞清楚它和插件/工具/提示词有什么区别的新手，前面几节会帮你把概念理顺。如果你已经在用 codex、claude 这类工具，想找好用的 skills、想自己开发一个、想知道安装和分发的坑，中间几节是重点。如果你关注的是 Google Cloud 那套 Agent Skills 在 GKE 上的落地，后面也有对应拆解。我不打算写成官方文档的复读机，而是按一个实际折腾过的人的视角，把“为什么这么设计”“哪里容易翻车”“怎么抄作业”讲透。
2. skills 和插件、工具、提示词到底差在哪
2.1 一个生活化类比：skills 是“菜谱”，不是“厨具”
很多人第一次接触 skills 会把它和插件混为一谈。我用做饭打个比方。工具（tool）是厨具，比如刀、锅、烤箱，它提供的是原子能力，你给它输入，它给你输出。插件（plugin）更像是往厨房里加了一台新设备，通常要注册、要配置、要跟主程序的生命周期绑定。而skills是一张菜谱：它告诉你先切什么、火候多大、什么时候放盐，甚至附带了“如果锅太干就加点水”这种条件判断。菜谱本身不产生热量，但它决定了厨具怎么被组合使用。
这个区别非常关键。工具是“能做什么”，skills 是“该怎么做、按什么顺序做、遇到什么情况怎么调整”。所以你会看到 skills 的载体经常是 Markdown、YAML、JSON 这类描述性文件，而不是编译后的二进制。它的核心价值在于把隐性经验显性化。一个老手排查线上问题时的思路，写成 skills 之后，新手 Agent 也能照着走一遍。
2.2 和提示词工程的边界
那 skills 和提示词（prompt）又差在哪？提示词是“一次性指令”，你这次让它这么干，下次换个任务就得重写。skills 是“可持久化的能力包”，它通常包含：触发条件（什么时候该用这个 skill）、执行步骤（分几步、每步调用什么工具）、上下文约束（有哪些前提、哪些禁止事项）、输出规范（结果长什么样）、以及可选的辅助脚本。换句话说，提示词是句子，skills 是带目录结构的小型项目。
我实测下来的体会是：单轮简单任务用提示词就够了，多步骤、需要复用、需要团队共享的任务才值得做成 skills。如果你只是让模型帮你改个错别字，做 skills 是杀鸡用牛刀。但如果你要反复做“拉取日志 → 定位异常 → 关联最近提交 → 生成报告”这种链路，做成 skill 之后效率提升是数量级的。
2.3 为什么“可分发”是 skills 的杀手锏
skills 真正引爆社区的，是它的分发属性。你可以把 skill 打包成一个目录，扔到代码仓库、内部市场或者社区平台，别人下载解压放进指定目录就能用。这就催生了“skills 下载平台有哪些”“skills 大全”“skills 推荐”这类搜索需求。它有点像早期手机刷机时代的 ROM 包，或者前端圈的 npm 包——一旦有了统一的分发约定，生态就会自己长出来。
但这里有个容易被忽略的点：分发的不只是代码，还有“行为契约”。一个 skill 装进去，Agent 的行为模式会变。所以安装第三方 skills 时，你必须看清楚它到底让 Agent 干了什么，尤其是涉及文件读写、网络请求、命令执行的部分。这一点我在后面“避坑”章节会展开讲。
3. 拆解一个 skill 的内部结构：从触发到产出
3.1 触发层：Agent 怎么知道该用哪个 skill
一个设计良好的 skill，第一件事是解决“什么时候用我”。常见做法是在 skill 的描述文件里写清楚适用场景和关键词。Agent 运行时会把用户请求和这些描述做匹配，命中后才加载完整内容。这背后其实是一个检索 + 排序的过程：先粗筛出候选 skills，再根据上下文精细判断。
我见过不少新手写的 skill，功能很强但触发描述写得含糊，结果 Agent 要么不调用，要么乱调用。经验是：触发描述要写得像“症状描述”而不是“功能说明”。比如不要写“本 skill 用于日志分析”，而要写“当用户提到线上报错、异常堆栈、接口 5xx、需要定位最近变更时使用”。前者是功能，后者是症状，Agent 匹配症状的准确率高得多。
3.2 执行层：步骤编排与工具调用
触发之后就是执行。一个 skill 的执行部分通常是一串有序步骤，每步可能调用一个或多个工具。这里的设计难点在于错误处理和分支。真实任务很少一路顺风，网络会超时、文件会不存在、接口会返回意料之外的结构。好的 skill 会把这些情况写进去，比如“如果第一步返回为空，则跳过第二步直接进入兜底逻辑”。
我个人的做法是给每个关键步骤加一个“验证点”：做完这步，怎么判断它成功了？是看返回码、看文件是否生成、还是看输出里是否包含某个字段？验证点写清楚，Agent 才不会在错误的基础上继续往下跑，最后给你一个看似完整实则全错的结论。
3.3 产出层：输出规范为什么不能省
很多 skill 只写了“怎么做”，没写“做成什么样”。结果就是同一个 skill，今天输出一段散文，明天输出一个表格，后天又变成 JSON。对于要接入下游流程的 skill，这是灾难。输出规范要明确到字段级别：是 Markdown 还是 JSON？包含哪些字段？字段类型是什么？有没有必填项？
我建议在 skill 里附一个输出示例，哪怕只是几行样例。模型对“示例”的遵循程度远高于对“描述”的遵循程度。这一点在“codex 写论文的 skills”这类场景里尤其明显——论文结构、引用格式、字数要求，写成示例比写成规则管用。
4. 自己动手写一个 skill：完整流程与关键决策
4.1 先想清楚：这个 skill 解决的是“高频”还是“高难”
不是所有任务都值得做成 skill。我的筛选标准是两条：要么高频，要么高难。高频指的是你每周都要重复做几次，做成 skill 能省时间；高难指的是步骤复杂、容易漏、对新手不友好，做成 skill 能保证质量下限。两者都不占的，用提示词对付一下就行。
举个例子，“自动挖洞”这种安全测试类的 skill，属于高难——步骤多、判断依赖经验、漏一步可能就前功尽弃。而“生成周报”属于高频——每周都要做，格式固定。这两类都值得投入时间做 skill。反过来，“帮我查一下今天天气”这种，做 skill 就是浪费。
4.2 目录结构怎么定：一个可复用的骨架
虽然不同运行时的约定略有差异，但一个通用的 skill 目录大致长这样：
my-skill/ ├── SKILL.md # 主描述文件：触发条件、步骤、输出规范 ├── scripts/ # 辅助脚本 │ ├── fetch.py │ └── parse.py ├── templates/ # 输出模板 │ └── report.md └── examples/ # 输入输出示例 ├── input.json └── output.jsonSKILL.md是核心，其他都是可选增强。我强烈建议至少放一个 examples 目录，因为示例是给模型看的“标准答案”，比任何文字描述都有效。scripts 目录则用来放那些“用代码做比用模型做更靠谱”的部分，比如精确的字符串处理、正则匹配、数据格式转换。
4.3 写 SKILL.md 的实操要点
写主描述文件时，我踩过的坑集中在三个地方。第一，步骤粒度太粗。写“分析日志并给出结论”这种，模型会自由发挥；写成“1. 读取最近 100 行日志 2. 提取包含 ERROR 的行 3. 按时间排序 4. 归纳前三类高频错误”，可控性就上来了。第二，缺少反例。只告诉它该怎么做，没告诉它不该怎么做，模型容易过度发挥。加一句“不要修改原始日志文件”“不要执行任何写操作”，能挡掉很多意外。第三，上下文太长。把所有背景都塞进去，反而稀释了关键指令。该拆成多个 skill 的就拆开。
提示：SKILL.md 里的指令尽量用祈使句和编号列表，避免大段叙述。模型对结构化指令的遵循度明显更高。
4.4 本地测试：怎么判断一个 skill 写好了
写完不是终点，测试才是。我的测试方法分三层。第一层是正常路径：给一个典型输入，看输出是否符合预期。第二层是边界情况：空输入、超长输入、格式错误的输入，看它会不会崩或者胡编。第三层是干扰测试：给一个不该触发这个 skill 的请求，看它会不会误触发。三层都过了，才算基本可用。
这里有个反直觉的经验：误触发比不触发更危险。不触发顶多是没帮上忙，误触发可能让 Agent 在错误的场景下执行了不该执行的操作。所以触发描述宁可写窄一点，也不要写太宽。
5. 安装、分发与生态：skills 从哪里来，到哪里去
5.1 常见的 skills 获取渠道
现在找 skills 的渠道大致分几类。官方市场是最稳的，通常经过审核，版本管理规范，但数量有限、更新偏慢。社区仓库是数量最多的，GitHub 上搜 skills 能出来一大堆，质量参差不齐，需要自己甄别。个人分享则散落在各种技术社区和博客里，往往是某个具体场景的解决方案，实用但缺乏维护。
我一般建议新手从官方市场起步，先装几个官方推荐的、场景通用的 skills，把安装流程和运行机制摸熟，再去社区淘。直接上社区仓库，很容易因为版本不匹配、依赖缺失而卡在安装环节，打击积极性。
5.2 安装一个 skill 的标准动作
安装流程因运行时不同而有差异，但核心动作是相似的：下载 → 放到指定目录 → 声明依赖 → 重启或重载 → 验证。这里最容易出问题的是“放到指定目录”和“声明依赖”。不同工具对 skills 目录的约定不一样，有的放在项目根目录下的特定文件夹，有的放在用户级配置目录。放错位置，Agent 根本扫不到。
验证环节我有个小技巧：装完之后，用一个明确会触发该 skill 的请求去测，同时观察日志里有没有加载记录。如果日志里没有加载痕迹，说明路径或声明有问题，别急着怀疑 skill 本身。
5.3 分发自己的 skill 时要注意什么
如果你想把自研的 skill 分享出去，有几件事必须做。第一，写清楚依赖：需要哪些运行时版本、哪些外部工具、哪些环境变量。第二，写清楚权限：这个 skill 会读写哪些文件、会发起哪些网络请求。第三，给出版本号：skills 也会迭代，没有版本号，别人没法判断自己装的是哪一版。第四，附上最小可运行示例：让人能在五分钟内跑通，这是决定别人愿不愿意用你的 skill 的关键。
我见过太多 skill 因为缺少依赖说明，别人装完跑不起来，最后被弃用。分发这件事，降低别人的上手成本就是提升自己的影响力。
6. 踩坑实录：skills 使用中最容易翻车的几个地方
6.1 版本不匹配：最隐蔽的坑
skills 和运行时版本不匹配，症状往往不是报错，而是“行为诡异”。比如某个工具调用的参数格式在新版本里变了，skill 还按老格式传，结果要么静默失败，要么返回一堆垃圾数据。这种问题最难查，因为表面上一切正常。
我的应对办法是：在 skill 里显式声明兼容的运行时版本范围，安装时先核对。另外，升级运行时之前，先把关键 skills 在测试环境跑一遍，别直接在生产上升级。
6.2 权限过大：第三方 skill 的安全边界
这是我最想强调的一点。第三方 skill 本质上是一段会被 Agent 执行的指令加脚本，如果它要求文件写入、命令执行、网络请求权限，你就得掂量一下。最小权限原则在这里同样适用：能只读的就别给写权限，能限定目录的就别给全盘。
我自己的做法是，装任何第三方 skill 之前，先把它目录里的脚本通读一遍，尤其是涉及exec、eval、文件删除、外部请求的部分。看不懂的，宁可不装。这不是小题大做，Agent 执行 skill 时的权限往往继承自宿主环境，一旦被滥用，影响范围可能超出预期。
6.3 触发冲突：两个 skill 抢同一个请求
当你装的 skills 多了，会出现两个 skill 都认为自己该被触发的情况。结果要么是随机选一个，要么是都执行一遍，产生重复操作。解决思路有两个：一是把触发描述写得更精确，缩小重叠范围；二是在 skill 里加优先级声明，让运行时知道冲突时该选谁。
我一般会定期清理 skills 列表，把功能重叠的合并或删掉。skills 不是越多越好，维护一个精简、边界清晰的能力集，比堆一大堆半成品更有效。
6.4 输出不稳定：同一个 skill 两次结果不一样
这是模型类系统的通病。同样的输入，两次输出可能结构不同、详略不同。缓解办法有三：降低温度参数（如果运行时支持）、强化输出模板、在 skill 里加入自检步骤（让 Agent 输出前先对照规范检查一遍）。实测下来，输出模板 + 自检步骤的组合，能把稳定性提升一大截。
7. Google Cloud 那条线：Agent Skills 在 GKE 与 Genkit 上的落地
7.1 为什么云厂商要推 Agent Skills
个人开发者玩 skills，图的是效率；云厂商推 Agent Skills，图的是把 Agent 能力标准化、可运维化。当企业要把 Agent 部署到生产环境，面临的问题就不再是“能不能跑”，而是“怎么管、怎么扩、怎么审计”。Google Cloud 把 Agent Skills 和 GKE（Kubernetes 引擎）、Genkit 放在一起，逻辑就很清楚了：GKE 提供运行和编排底座，Genkit 提供 AI 应用开发框架，Agent Skills 则是跑在上面的能力单元。
这个组合的意义在于，skills 从“个人电脑上的几个文件”变成了“集群里可调度、可观测、可版本化的资源”。对企业来说，这才是能进生产环境的形态。
7.2 在 GKE 上跑 Agent Skills 的关键考量
把 Agent Skills 放到 GKE 上，核心要解决几个问题。资源隔离：不同 skill 可能对 CPU、内存、网络的需求差异很大，需要合理设置 requests 和 limits。状态管理：有些 skill 是无状态的，有些需要缓存或临时存储，得区分对待。可观测性：skill 执行到哪一步、耗时多少、失败在哪，都要有日志和指标。版本灰度：新版本 skill 先小流量验证，再全量。
这些其实都是云原生那套东西，只不过对象从微服务换成了 skills。如果你本来就熟悉 Kubernetes，上手会快很多；如果不熟，建议先用托管方案跑通，再考虑自建。
7.3 Genkit 在其中的角色
Genkit 是面向 AI 应用的开发框架，它让定义、测试、部署 skills 有了统一的工程化路径。你可以把它理解成“skills 的脚手架 + 运行时 + 调试工具”。它解决的是开发体验问题：怎么写、怎么本地调、怎么打包、怎么发布。对于要把 skills 做成产品的团队，这类框架能省掉大量重复造轮子的时间。
我的建议是，如果你只是个人用，不必一上来就上云方案，本地跑通、验证价值之后，再考虑迁移。先证明 skill 有用，再考虑怎么规模化，顺序反了容易做无用功。
8. 几个高频场景的 skills 设计思路
8.1 写论文类 skills：结构约束是核心
“codex 写论文的 skills”是搜索热词之一，说明需求真实存在。这类 skill 的设计重点不在“写得好”，而在“写得合规”。论文有固定的结构（摘要、引言、方法、实验、结论、参考文献），有格式要求（引用风格、字数、图表编号）。skill 要做的是把这些约束固化下来，让模型在框架内发挥，而不是自由创作。
实操上，我会把论文模板拆成多个部分，每个部分单独定义输入输出。比如“引言”部分要求输入研究背景和问题陈述，输出包含研究意义、现有不足、本文贡献三段。这样既保证结构完整，又给模型留了填充空间。
8.2 分镜类 skills：把视觉语言翻译成文字指令
“分镜 skills”面向的是内容创作场景。分镜的本质是把一段叙事拆成一个个镜头，每个镜头包含景别、角度、运动、时长、画面内容。这类 skill 的难点在于把抽象的文字描述转成具体的视觉参数。我的做法是内置一个镜头语言词典，把“紧张”映射到“特写 + 快速切换”，把“辽阔”映射到“远景 + 缓慢横移”。有了这层映射，输出的分镜才具备可执行性。
8.3 测试与挖洞类 skills：安全边界要写死
“agent skills 测试”“自动挖洞 skills”这类，属于高风险高价值场景。价值在于能自动化发现漏洞，风险在于操作不当可能影响真实系统。这类 skill 必须写死安全边界：只允许在授权环境执行、禁止对生产系统发起请求、所有操作留痕。我甚至建议在这类 skill 里加入“执行前二次确认”步骤，宁可慢一点，也不能越界。
9. 我个人的几条实操心得
折腾 skills 这段时间，有几条体会是文档里不会写、但实际很管用的。第一，先做减法再做加法。一开始别贪多，挑一个最痛的点做成 skill，跑顺了再扩展。我见过有人一口气装了二十个 skills，结果互相干扰，最后全卸了。第二，给 skill 写“使用说明”给自己看。过一个月你大概率会忘了这个 skill 的触发条件和注意事项，在目录里放一个 README 能省很多回忆时间。第三，定期做“技能审计”。每隔一段时间回顾一下哪些 skills 真在用、哪些已经过时、哪些有安全风险，该删的删，该更新的更新。
还有一点关于心态：skills 生态现在还在快速演化，今天的最佳实践明天可能就过时了。别追求一次做到完美，保持可迭代、可替换的结构，比追求某个“标准答案”更重要。我自己的 skills 目录里，有一半都改过至少三轮，改的过程本身就是理解加深的过程。
最后分享一个判断 skill 值不值得做的小测试：如果这个任务你要向一个新同事解释超过五分钟，那它就值得做成 skill。因为解释成本高，说明隐性知识多，而隐性知识正是 skills 最擅长固化的东西。反过来，一句话能说清的任务，提示词就够了。这个标准我用了很久，挺准的。
