1. 从“skills”这个热词说起它到底是什么最近半年不管是在技术社区还是各种开发者群里“skills”这个词出现的频率高得离谱。很多人第一次看到“skills”这个词脑子里浮现的是招聘网站上的技能标签或者是简历里那一栏“专业技能”。但如果你最近在关注 AI Agent 这个方向你会发现大家嘴里的“skills”完全是另一回事——它指的是Agent Skills一种让 AI 智能体具备特定领域能力的模块化封装机制。简单来说Agent Skills 就是给 AI Agent 准备的“技能包”。你可以把它想象成给一个刚入职的新员工发的操作手册加工具箱这个员工本身很聪明学习能力很强但他不知道你们公司内部的报销流程、不知道你们代码仓库的规范、不知道你们客服话术的标准模板。你把这些东西整理成标准化的“技能包”交给他他就能立刻上手干活。Agent Skills 干的就是这件事——把特定领域的知识、流程、工具调用方式打包成一个可复用、可分发、可组合的模块让 AI Agent 在需要的时候加载并执行。这个概念的走红跟几个因素直接相关。一是 AI Agent 从“能聊天”进化到了“能干活”大家发现光靠一个大模型包打天下不现实你需要让它在不同场景下调用不同的能力二是各大平台开始推出自己的 Skills 规范和市场比如 Google Cloud 那边有相关的 Agent 生态布局各种 CLI 工具也开始支持通过npx直接安装和运行 skills三是社区里涌现了大量实战分享从“codex 写论文的 skills”到“自动挖洞 skills”从“分镜 skills”到“前端开发 skills”几乎每个垂直领域都有人在尝试把自己的经验封装成 skill。这篇文章适合谁看如果你是刚接触 AI Agent 的开发者想搞清楚 skills 到底怎么用、怎么装、怎么自己写一个那这篇内容就是给你准备的。如果你已经在用某些 AI 编程工具但还没试过 skills 机制那你可以看看别人是怎么玩的说不定能打开新世界。如果你是完全不懂技术的小白也没关系我会尽量用生活化的类比把原理讲清楚让你至少知道这个东西能干什么、值不值得关注。提示本文讨论的 skills 特指 AI Agent 领域的技能封装机制不涉及任何其他含义。文中提到的工具和平台均为技术开发用途请确保在合规环境下使用。2. Agent Skills 的核心设计思路拆解2.1 为什么需要“技能包”而不是“万能模型”很多人一开始会有个疑问现在的大模型已经这么强了为什么还要搞什么 skills直接让模型自己发挥不就行了吗这个问题我一开始也想过但实际用下来就明白了。大模型确实强但它的强是“通用能力强”不是“专业能力强”。举个例子你让一个通用大模型帮你写一个符合你们公司代码规范的 React 组件它写出来的东西大概率能跑但命名风格、目录结构、状态管理方式可能跟你们团队的习惯完全不一样。你每次都要在 prompt 里重复一遍规范费时费力还容易漏。Agent Skills 解决的就是这个“重复交代”的问题。它把领域知识从 prompt 里抽出来变成一个独立的、可版本管理的模块。你需要的时候加载不需要的时候不加载既节省了上下文窗口又保证了执行的一致性。这就像你不需要每次让新员工干活都重新讲一遍公司制度你给他一本员工手册就行了。另一个关键原因是组合性。一个复杂的任务往往需要多种能力配合比如“帮我分析这份销售数据并生成报告”这个任务涉及数据读取、数据清洗、统计分析、图表生成、文档撰写好几个环节。如果每个环节都写在一个巨大的 prompt 里维护起来就是灾难。但如果你把每个环节封装成独立的 skill就可以像搭积木一样组合使用哪个环节出问题就单独修哪个灵活得多。2.2 Skills 的典型结构长什么样虽然不同平台对 skills 的具体实现有差异但核心结构大同小异。一个典型的 skill 通常包含以下几个部分元信息名称、描述、版本号、作者、适用场景说明。这部分决定了 skill 怎么被找到和匹配。触发条件什么情况下应该激活这个 skill。可以是关键词匹配也可以是语义匹配还可以是显式调用。指令内容具体的操作指南、流程步骤、注意事项。这是 skill 的核心通常用自然语言写成因为最终是给模型看的。工具依赖这个 skill 需要调用哪些外部工具或 API。比如一个“发送邮件”的 skill 需要邮件服务的接口权限。示例输入输出的样例帮助模型理解预期行为。约束与边界什么能做、什么不能做、遇到异常怎么处理。你可以把它类比成一份“标准作业程序”SOP。工厂里每个工位都有一份 SOP上面写着这个工位要做什么、怎么做、注意什么、出问题了找谁。Agent Skills 就是 AI Agent 的 SOP只不过执行者从人变成了模型。2.3 为什么npx成了 skills 分发的热门方式最近热词里频繁出现npx比如“claude mcpservers npx”、“npx playwright install失败”。这说明很多人是通过npx这个命令来安装和运行 skills 相关工具的。npx是 Node.js 生态里的一个包执行工具它最大的好处是不需要全局安装就能直接运行某个包。你只需要npx some-package它会自动下载最新版本并执行用完就扔不污染你的全局环境。对于 skills 这种“按需加载”的场景来说npx简直是天然匹配。举个例子假设有一个 skill 叫>npx>name: js-code-review version: 1.0.0 description: 按照团队规范审查 JavaScript/TypeScript 代码 triggers: - 审查代码 - code review - 检查这个 PR tools: - file-reader - linter指令内容部分用自然语言写清楚审查步骤## 审查流程 1. 读取目标文件确认文件类型为 .js/.ts/.jsx/.tsx 2. 检查变量命名是否符合 camelCase 规范常量除外 3. 检查是否使用了 而非 4. 检查函数是否超过 50 行 5. 检查是否有未使用的 import 6. 检查 console.log 是否残留 7. 输出审查结果按严重程度分级第三步本地测试。在正式发布之前一定要用几个真实的代码文件测试。我一般会准备三类测试用例完全合规的代码、有明显问题的代码、边界情况的代码。看看 skill 能不能正确识别。第四步打包发布。根据目标平台的要求打包。如果是 npm 生态就发布成 npm 包如果是某个平台专属的 skill 市场就按照那个平台的格式提交。第五步版本管理与迭代。skill 不是写完就完了团队规范变了、发现了新的常见错误、模型能力升级了都需要更新 skill。所以版本号管理很重要建议遵循语义化版本规范。3.2 写 skill 指令内容的几个关键原则写 skill 跟写普通文档不一样你的读者是 AI 模型不是人。所以有些原则需要特别注意。原则一步骤要具体到可执行。不要说“检查代码质量”要说“检查函数是否超过 50 行”。不要说“确保命名规范”要说“变量名必须使用 camelCase常量必须使用 UPPER_SNAKE_CASE”。模型需要的是明确的判断标准不是模糊的方向。原则二给出正例和反例。光说“要怎样”不够最好配上“这样是对的”和“这样是错的”的代码示例。模型通过对比学习的效果比单纯看规则好得多。原则三处理异常情况。如果文件读取失败怎么办如果代码里有语法错误导致无法解析怎么办这些都要在 skill 里写清楚。不然模型遇到异常可能会卡住或者胡乱输出。原则四控制输出格式。如果你希望审查结果以表格形式呈现就在 skill 里明确写出来。不然每次输出的格式可能都不一样后续处理会很麻烦。原则五保持简洁。skill 的指令内容会占用模型的上下文窗口写得太长会挤占其他信息。能用一句话说清楚的就不要用三句。我一般建议单个 skill 的指令内容控制在 500-2000 字之间太短了不够用太长了浪费。3.3 工具依赖的配置与权限管理很多 skill 需要调用外部工具才能完成工作。比如一个“发送周报”的 skill 需要访问邮件服务一个“查询数据库”的 skill 需要数据库连接权限。这里有个很重要的原则最小权限原则。skill 只应该拥有完成它任务所必需的最小权限。一个只读的 skill 就不要给它写权限一个只需要访问特定目录的 skill 就不要给它整个文件系统的访问权。具体怎么配置取决于你用的平台。有些平台用配置文件声明权限有些平台用环境变量传递凭证有些平台有专门的权限管理系统。不管哪种方式核心思路是一样的明确声明、按需授予、定期审查。注意千万不要把敏感凭证硬编码在 skill 文件里。我见过有人在 skill 的 YAML 里直接写 API Key然后把这个 skill 分享出去了。这是非常危险的做法。正确的做法是用环境变量或者平台提供的密钥管理服务。4. 实操过程与核心环节实现4.1 环境准备Node.js 与 npx 的安装配置大部分 skills 工具链都依赖 Node.js 环境所以第一步是把 Node.js 装好。我推荐用 nvmNode Version Manager来管理 Node.js 版本这样不同项目可以用不同的 Node 版本互不干扰。Linux/macOS 下安装 nvmcurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash安装完成后重新打开终端然后安装 Node.js 18 或更高版本nvm install 18 nvm use 18验证安装node --version npx --versionWindows 用户可以用 nvm-windows或者直接下载 Node.js 安装包。安装完成后同样用node --version验证。这里有个细节npx是随 npm 一起安装的只要你装了 Node.jsnpx就有了。但有时候npx的版本太老会有兼容性问题可以用npm install -g npx更新到最新版。4.2 安装一个 skill 的完整命令与参数说明假设我们要安装一个社区里比较流行的 skill通常的命令格式是npx skill-name install或者npx scope/skill-name --install具体参数取决于 skill 的开发者怎么设计。但一般来说常见的参数包括参数作用示例--install安装 skill 到本地npx my-skill --install--list列出可用的 skillsnpx my-skill --list--run运行指定的 skillnpx my-skill --run review--config指定配置文件路径npx my-skill --config ./skill.yml--verbose输出详细日志npx my-skill --verbose--dry-run只模拟不实际执行npx my-skill --dry-run我个人的习惯是第一次安装某个 skill 的时候一定加--verbose看看它到底干了什么。有些 skill 安装的时候会下载额外的依赖或者修改配置文件你不看日志根本不知道。4.3 以 Playwright 为例浏览器自动化 skill 的安装与踩坑热词里出现了“npx playwright install失败”这个我太有发言权了。Playwright 是一个浏览器自动化工具很多跟网页交互相关的 skill 都会依赖它。但它的安装过程确实容易出问题。标准安装流程npx playwright install这个命令会下载 Chromium、Firefox、WebKit 三个浏览器的二进制文件加起来好几百 MB。如果网络环境不好很容易失败。我总结了几种常见的失败情况和应对方法情况一下载超时。表现是命令卡在某个百分比不动最后报 timeout。解决办法是设置更长的超时时间npx playwright install --timeout 120000情况二磁盘空间不足。浏览器二进制文件很大如果磁盘快满了就会失败。先检查磁盘空间df -h情况三权限问题。在某些系统上Playwright 默认的安装目录没有写权限。可以指定安装目录PLAYWRIGHT_BROWSERS_PATH./browsers npx playwright install情况四只装需要的浏览器。如果你只需要 Chromium没必要把三个都装了npx playwright install chromium这个技巧帮我省了很多时间和磁盘空间。大部分场景下 Chromium 就够了除非你要做跨浏览器兼容性测试。4.4 自己写一个 skill 并本地测试光用别人的 skill 不够过瘾自己写一个才能真正理解这套机制。我拿一个简单的例子来演示写一个“JSON 格式化与校验”的 skill。首先创建一个目录结构json-tool/ ├── skill.yml ├── instructions.md └── index.jsskill.yml定义元信息name: json-tool version: 1.0.0 description: 格式化、校验和转换 JSON 数据 triggers: - 格式化 JSON - 校验 JSON - JSON 转 CSV entry: index.jsinstructions.md写具体指令## 功能说明 本 skill 提供三个功能 1. 格式化将压缩的 JSON 转为缩进格式 2. 校验检查 JSON 是否合法报告错误位置 3. 转换将 JSON 数组转为 CSV 格式 ## 使用方式 - 格式化输入 JSON 字符串输出缩进后的 JSON - 校验输入 JSON 字符串输出校验结果 - 转换输入 JSON 数组输出 CSV 文本 ## 异常处理 - 如果 JSON 解析失败输出错误信息和出错位置 - 如果输入为空提示用户提供输入 - 如果 JSON 顶层不是数组转换功能报错index.js实现具体逻辑const fs require(fs); function formatJSON(input) { try { const obj JSON.parse(input); return JSON.stringify(obj, null, 2); } catch (e) { return 解析失败: ${e.message}; } } function validateJSON(input) { try { JSON.parse(input); return JSON 合法; } catch (e) { return JSON 非法: ${e.message}; } } function jsonToCSV(input) { const arr JSON.parse(input); if (!Array.isArray(arr)) { return 错误: 顶层必须是数组; } if (arr.length 0) return ; const headers Object.keys(arr[0]); const rows arr.map(obj headers.map(h obj[h]).join(,)); return [headers.join(,), ...rows].join(\n); } module.exports { formatJSON, validateJSON, jsonToCSV };本地测试的时候我一般会写一个简单的测试脚本const { formatJSON, validateJSON, jsonToCSV } require(./index); console.log(formatJSON({a:1,b:2})); console.log(validateJSON({a:1})); console.log(validateJSON({a:1})); console.log(jsonToCSV([{name:张三,age:30},{name:李四,age:25}]));跑一遍看看输出是否符合预期。确认没问题之后就可以发布到 npm 或者提交到 skill 市场了。5. 常见问题与排查技巧实录5.1 安装类问题速查表问题现象可能原因排查方法解决方案npx xxx报 404包名拼写错误或未发布去 npm 官网搜索包名确认包名检查是否在正确的 registry安装卡住不动网络问题或源不可达ping registry.npmjs.org切换 registry 或设置代理权限被拒绝没有写权限ls -la查看目录权限用sudo或修改目录权限版本冲突依赖的 Node 版本不匹配node --version用 nvm 切换到合适版本磁盘空间不足下载文件太大df -h清理空间或指定其他安装目录安装成功但运行报错缺少运行时依赖查看错误日志安装缺失的依赖5.2 Skill 运行时的典型故障与处理故障一Skill 没有被正确触发。你明明说了“帮我审查代码”但 Agent 就是没加载代码审查 skill。这种情况通常是触发条件写得太窄了。解决办法是在 skill 的 triggers 里多列几种可能的表达方式包括同义词、口语化表达、英文表达。故障二Skill 执行到一半卡住。可能是某个工具调用超时了也可能是指令里有歧义导致模型不知道该怎么做。排查方法是看日志找到卡住的那一步然后检查对应的指令是否足够明确。故障三输出格式不符合预期。模型没有按照你要求的格式输出。这通常是因为指令里对格式的描述不够具体。我的经验是与其用文字描述格式不如直接给一个输出示例。模型照着示例模仿的准确率比理解文字描述高得多。故障四多个 skill 冲突。同时加载了多个 skill它们的指令互相矛盾。比如一个 skill 说“输出用中文”另一个说“输出用英文”。解决办法是明确 skill 的优先级或者在设计 skill 的时候就避免功能重叠。5.3 我踩过的三个坑第一个坑skill 写得太“聪明”。我一开始写 skill 的时候总想让模型自己判断该怎么做指令写得很灵活。结果就是每次执行结果都不一样有时候对有时候错。后来我学乖了skill 的指令要“笨”一点把每一步都写死减少模型的自由发挥空间。灵活性留给模型本身的能力确定性留给 skill 的流程。第二个坑忽略了上下文长度限制。我写过一个数据处理 skill指令内容写了三千多字加上输入数据直接把模型的上下文窗口撑爆了。后来我把 skill 拆成了三个小 skill每个只负责一个环节问题就解决了。单个 skill 的指令内容真的不要超过 2000 字这是血泪教训。第三个坑没有做版本管理。我更新了一个 skill 的指令结果之前跑得好好的流程突然出问题了。查了半天才发现是新版指令跟另一个 skill 不兼容。从那以后我养成了习惯每次更新 skill 都打 tag生产环境用固定版本不用 latest。提示如果你在团队里推广 skills建议建立一个内部的 skill 仓库统一管理版本和权限。不要让大家各自从公开市场随便下载安全性和一致性都没法保证。6. 不同场景下的 Skills 应用思路6.1 开发场景从代码审查到自动修复开发场景是 skills 应用最成熟的地方。除了前面说的代码审查还有很多玩法。比如“自动生成单元测试”的 skill输入一个函数文件输出对应的测试文件。这个 skill 需要理解函数的输入输出、边界条件、异常情况然后生成覆盖这些情况的测试用例。再比如“依赖升级检查”的 skill扫描 package.json检查每个依赖是否有新版本评估升级风险生成升级建议。这个 skill 需要访问 npm registry对比版本号还要考虑语义化版本的兼容性规则。还有“代码迁移”的 skill把 Vue 2 的组件迁移到 Vue 3或者把 JavaScript 迁移到 TypeScript。这种 skill 的指令内容会比较长因为涉及大量的语法转换规则。但一旦写好批量处理的时候效率极高。6.2 内容创作场景分镜、文案与结构化输出热词里出现了“分镜 skills”这说明内容创作领域也在积极尝试 skills 机制。分镜 skill 的思路是这样的输入一个故事梗概或剧本片段输出分镜脚本包括镜号、景别、画面描述、台词、时长建议。这个 skill 需要理解影视语言的基本规则比如“远景交代环境、近景表达情绪、特写强调细节”。文案 skill 可以针对不同平台做适配同一个产品卖点输出小红书风格的种草文案、输出知乎风格的专业分析、输出抖音风格的短视频脚本。每个平台一个 skill互不干扰。结构化输出 skill 则专注于格式转换把会议记录转成待办事项列表把访谈录音转成问答对把长文章转成思维导图大纲。这类 skill 的核心是定义清楚输入输出的映射关系。6.3 学术研究场景论文写作与文献处理“codex 写论文的 skills”这个热词反映了一个真实需求研究人员希望 AI 能帮忙处理论文写作中的重复性工作。一个典型的论文写作 skill 可能包含这些功能根据实验数据生成结果描述段落、按照期刊格式要求调整参考文献、检查术语使用的一致性、生成图表标题和注释。文献处理 skill 则专注于从 PDF 中提取摘要和关键词、对比多篇论文的方法论差异、生成文献综述的初稿框架、追踪某个领域的最新进展。这类 skill 对准确性的要求极高因为学术写作容错率很低。我的建议是学术类 skill 的输出一定要人工复核不要让 AI 直接定稿。skill 的价值在于提高初稿效率不在于替代研究者的判断。6.4 安全测试场景自动化漏洞挖掘的边界热词里有个“自动挖洞 skills”这个需要特别谨慎地讨论。自动化安全测试本身是合法的技术领域但必须在授权范围内进行。一个合规的安全测试 skill 应该包含明确的授权检查步骤确认目标在授权范围内、确认测试时间窗口、确认允许的测试类型。skill 的指令里应该写清楚“如果目标不在授权列表内立即停止并报告”。技术层面这类 skill 通常结合了漏洞扫描工具、Payload 生成器、结果分析器。但核心不是技术多强而是流程多严谨。没有授权检查的自动化测试 skill 是危险的不管技术多厉害都不应该使用。7. Skills 生态的现状与个人观察7.1 当前生态的碎片化与整合趋势现在的 skills 生态有点像早期的手机应用市场——每个平台都有自己的格式和规范互不兼容。你在 A 平台写的 skill 不能直接拿到 B 平台用需要做适配。这种碎片化有好有坏。好处是竞争充分每个平台都在努力做好自己的工具链坏处是开发者需要学习多套规范重复劳动多。我观察到的一个趋势是社区正在自发形成一些“事实标准”。比如用 YAML 定义元信息、用 Markdown 写指令内容、用 npm 做分发。虽然不是官方标准但大家都这么做慢慢就成了默认约定。另一个趋势是 skill 的组合化。单个 skill 能做的事情有限但多个 skill 串联起来就能完成复杂任务。现在已经有人在尝试做“skill 编排”工具让你用可视化或者配置文件的方式把多个 skill 串成工作流。7.2 如何判断一个 skill 值不值得用面对市场上越来越多的 skill怎么筛选我一般看这几个维度看维护活跃度。最后一次更新是什么时候issue 有没有人回如果一个 skill 半年没更新了大概率已经跟不上平台的变化了。看文档完整度。好的 skill 会有清晰的说明文档告诉你它做什么、不做什么、怎么配置、有什么限制。文档写得含糊的用起来大概率会踩坑。看权限要求。一个简单的格式化 skill 要求访问你的整个文件系统这就不合理。权限要求越少越好越明确越好。看社区反馈。有没有人分享过使用体验有没有已知的严重问题这些信息比官方宣传靠谱得多。看代码质量。如果 skill 是开源的花五分钟看看代码。变量命名混乱、没有错误处理、硬编码敏感信息的直接跳过。7.3 我对 skills 未来走向的几个判断第一个判断skills 会从“可选”变成“标配”。就像现在开发 Web 应用默认要用框架一样未来开发 AI Agent 应用默认就要用 skills 机制。不用 skills 的 Agent 就像不用框架的 Web 应用能跑但效率低。第二个判断会出现专门的 skill 开发工具和调试工具。现在写 skill 基本靠手写 YAML 和 Markdown调试靠打印日志。未来会有可视化的 skill 编辑器、自动化的测试框架、性能分析工具。第三个判断skill 的质量评估会标准化。现在判断一个 skill 好不好全靠个人经验未来可能会有类似“代码覆盖率”的指标比如“指令明确度评分”、“异常处理完整度评分”、“输出稳定性评分”。第四个判断垂直领域的 skill 会越来越深。通用 skill 大家都能写竞争激烈。真正有价值的是那些深入某个行业、某个流程、某个工具的 skill写这种 skill 需要真正的领域专业知识不是随便一个开发者就能做的。我个人在实际操作中的体会是skills 这套机制最大的价值不是技术本身而是它提供了一种“把隐性知识显性化”的方法。很多老师傅的经验、很多团队的默契、很多行业的惯例以前只存在于人的脑子里现在可以通过 skill 的方式固化下来、传递下去。这件事的意义可能比我们目前看到的要大得多。最后分享一个小技巧如果你刚开始接触 skills不要一上来就写复杂的。从一个最简单的、你每天都要重复做的小任务开始把它封装成 skill。用上一周感受一下它到底省了你多少时间、有没有出过问题、哪里还可以改进。有了真实体感之后再逐步扩展。这比看十篇教程都管用。