1. 从“skills”这个热词说起它到底指什么最近一段时间不管是在技术社区还是各种开发者群里“skills”这个词出现的频率高得离谱。很多人第一次看到它脑子里冒出来的可能是“技能”这个通用含义但在当下的语境里它已经变成了一个相当具体的概念——Agent Skills也就是给 AI 智能体AI Agent挂载的一套可插拔能力包。你可以把它理解成给一个刚入职的实习生配工具箱。这个实习生本身脑子不笨能理解你说的话也能做推理但他不知道你们公司内部的数据长什么样不知道你们的代码规范更不知道怎么调用你们那套部署脚本。Agent Skills 干的事情就是把这些“公司内部知识”和“操作流程”打包成一个个标准化的模块让智能体在需要的时候自己取用。从热词列表里能看出来围绕 skills 的讨论已经形成了好几个明显的分支有人关心怎么安装skills安装包下载、reasonix如何安装新skills有人关心去哪里找skills下载平台有哪些、skills大全、find skills有人关心具体场景怎么用codex写论文的skills、分镜skills下载、自动挖洞skills还有人直接进入了开发环节skills开发、agent skills测试。这些搜索词背后其实是同一件事大家已经意识到光有一个聪明的模型不够真正让它在实际工作里产生价值的是那些被精心设计过的能力模块。这篇文章想做的事情很明确把 Agent Skills 这个东西从概念到落地讲透。不管你是刚听说这个词想搞清楚它是什么还是已经准备动手写自己的第一个 skill或者正在为团队搭建一套 skills 管理体系下面这些内容应该都能给你一些可以直接用的东西。我会尽量少讲空话多讲实际操作中会遇到的问题和对应的解法。2. Agent Skills 的运行机制为什么它不是简单的提示词2.1 从“一次性对话”到“可复用能力”的转变很多人第一次接触 Agent Skills 的时候会有一个疑问这不就是把提示词prompt包装了一下吗我直接写一段详细的系统提示不就行了这个疑问很合理但答案是否定的。普通的系统提示词和 Agent Skills 之间有一个本质区别系统提示词是常驻的、全局的而 skill 是按需加载的、局部的。举个例子。假设你有一个负责代码审查的智能体。如果你把“如何审查 Python 代码”“如何审查 JavaScript 代码”“如何审查 SQL 注入风险”“如何检查依赖漏洞”全部写进系统提示词里那这个提示词会变得极其臃肿。每次对话模型都要把这几千字的规则从头读一遍既浪费上下文窗口又容易让模型在无关的规则上分心。Agent Skills 的做法不一样。它把这些能力拆成独立的模块每个模块有自己的描述、触发条件和执行逻辑。当用户的问题涉及 Python 代码审查时智能体才会去加载对应的 skill涉及依赖漏洞时再加载另一个。这种按需加载的机制才是 skills 真正的价值所在。从技术实现上看一个 skill 通常包含几个核心部分元信息名称、描述、适用场景这部分是智能体用来判断“要不要用这个 skill”的依据指令内容具体的操作步骤、规则、示例这部分是真正被加载进上下文的内容附属资源可能包括脚本、模板、参考文档等智能体可以按需读取或执行这种结构和传统的函数调用function calling有相似之处但更灵活。函数调用通常需要严格的参数格式而 skill 更像是一份“操作手册”智能体可以理解其中的意图并根据实际情况灵活调整。2.2 渐进式披露skills 设计的核心原则Anthropic 在推出 Agent Skills 的时候反复强调了一个概念叫“渐进式披露”progressive disclosure。这个词听起来有点学术但道理很简单不要一次性把所有信息都塞给模型而是分层级、分阶段地给。具体来说一个设计良好的 skill 通常分三层第一层是元数据也就是 skill 的名称和简短描述。这部分始终对智能体可见用来判断当前任务是否需要这个 skill。比如一个叫“pdf-processing”的 skill描述可能是“处理 PDF 文件的提取、合并、拆分和表单填写”。智能体看到用户说“帮我把这个 PDF 拆成每页一个文件”就会知道该调用这个 skill。第二层是核心指令也就是 skill 的主体内容。只有当智能体决定使用这个 skill 时这部分才会被加载进上下文。它通常包含具体的操作步骤、注意事项和示例。第三层是附属资源比如参考文档、脚本文件、模板等。这些内容不会自动加载而是当智能体在执行过程中需要时才会去读取。比如一个处理 Excel 的 skill 可能附带一个 Python 脚本智能体在需要执行复杂计算时才会去调用它。这种分层设计的妙处在于它让智能体可以在有限的上下文窗口里管理大量的能力。你完全可以给一个智能体挂载几十个 skill而不会让它的上下文爆炸因为大部分 skill 在大部分时候只占用一行描述的空间。2.3 和 MCP、function calling 的关系与边界热词里出现了claude mcpservers npx这样的组合说明很多人会把 Agent Skills 和 MCPModel Context Protocol放在一起讨论。这两者确实有关系但解决的问题不一样。MCP 解决的是“智能体怎么和外部系统通信”的问题。它定义了一套标准协议让智能体可以连接数据库、调用 API、读取文件系统。你可以把 MCP 理解成智能体的“手和脚”让它能够触达外部世界。Agent Skills 解决的是“智能体怎么知道该做什么、怎么做”的问题。它更像是一本本操作手册告诉智能体在特定场景下应该遵循什么流程、注意什么细节。你可以把它理解成智能体的“经验和知识”。两者是互补的。一个智能体可以通过 MCP 连接到数据库但如果没有相应的 skill它可能不知道该怎么写查询语句、该怎么处理敏感数据、该怎么格式化输出。反过来一个 skill 可以描述“如何生成月度报表”但如果没有 MCP 提供的数据库连接它也无法真正执行。至于 function calling它更偏向底层的技术机制是模型调用外部函数的接口。Agent Skills 可以包含 function calling 的使用说明但它的范围更广还包括了流程指导、规则约束、示例参考等内容。3. 安装与获取 skills 的几条实际路径3.1 官方市场和社区仓库从哪里找到可用的 skills目前获取 skills 主要有几个渠道。最直接的是官方市场比如 Claude 的 skills 市场里面有一些官方维护的基础 skill覆盖了文档处理、数据分析、代码审查等常见场景。这些官方 skill 的好处是质量有保障文档齐全适合作为起点。另一个渠道是社区仓库。GitHub 上已经出现了不少专门收集和分享 skills 的仓库有些是个人开发者整理的有些是团队开源的。这些仓库里的 skill 质量参差不齐但往往能覆盖一些官方没有涉及的细分场景。比如热词里提到的自动挖洞skills这种安全测试相关的 skill 在官方市场里不太可能出现但在社区里能找到。在选择社区 skill 的时候有几个点需要特别注意看更新频率一个半年没更新的 skill很可能已经跟不上模型版本的变化了看文档完整度好的 skill 应该有清晰的使用说明、适用场景和限制条件看依赖项有些 skill 依赖特定的 MCP 服务或外部工具如果这些依赖你没法满足skill 就没法用看权限要求涉及文件系统操作、网络请求的 skill 要格外小心确认它的行为符合你的安全预期3.2 手动安装的完整流程与常见报错处理热词里npx playwright install失败和reasonix如何安装新skills这两个搜索词说明安装环节确实是很多人的痛点。这里以最常见的命令行安装方式为例把流程和可能遇到的问题梳理一遍。假设你要安装一个 skill 包通常的流程是这样的# 第一步确认运行环境 node --version npm --version # 第二步通过 npx 执行安装命令 npx skills-cli install skill-name # 第三步验证安装结果 npx skills-cli list看起来很简单但实际操作中经常会在第二步卡住。最常见的报错是网络超时因为很多 skill 仓库的服务器在境外国内访问不稳定。这时候可以尝试配置镜像源npm config set registry https://registry.npmmirror.com如果报错信息里出现EACCES或permission denied说明是权限问题。在 Linux 或 macOS 上不要直接用sudo运行 npm 命令那样会导致后续权限混乱。正确的做法是修复 npm 的默认目录权限mkdir -p ~/.npm-global npm config set prefix ~/.npm-global export PATH~/.npm-global/bin:$PATH还有一种情况是依赖冲突。有些 skill 依赖特定版本的 Node.js 或 Python如果你的环境版本不匹配安装过程会失败。这时候需要先确认 skill 的依赖要求必要时用 nvm 或 pyenv 切换版本。提示安装任何 skill 之前建议先在一个隔离环境里测试。可以用 Docker 起一个干净的容器或者用虚拟环境避免污染主开发环境。3.3 安装之后的验证怎么确认 skill 真的生效了装完不等于能用。很多人装完 skill 之后直接就开始用结果发现智能体根本没有调用它或者调用了但行为不对。这时候需要做几步验证。第一步是确认 skill 被正确注册。不同的平台有不同的查看方式有的用list命令有的在配置文件里查看。确认 skill 的名称、版本、状态都正常。第二步是做一个最小化测试。找一个明确会触发这个 skill 的任务看智能体的行为是否符合预期。比如你装了一个“代码格式化”的 skill就给它一段格式混乱的代码看它会不会按照 skill 里定义的规则来整理。第三步是检查日志。如果智能体没有调用 skill日志里通常会有线索。可能是 skill 的描述不够清晰导致智能体没有识别出适用场景也可能是触发条件设置得太窄实际任务没有匹配上。4. 自己动手写一个 skill从需求到落地4.1 先想清楚什么场景值得做成 skill不是所有东西都值得做成 skill。我见过有人把“回答用户问候”也写成一个 skill这就属于过度设计。一个场景值得做成 skill通常满足几个条件重复性高这个任务会反复出现每次的流程基本一致有明确的规则不是完全靠临场发挥而是有相对固定的步骤和标准容易出错如果没有明确的指导智能体容易漏掉关键步骤或犯常见错误需要外部知识涉及公司内部规范、行业标准、特定工具的使用方法举个例子“生成周报”就是一个典型的适合做成 skill 的场景。它每周都要做有固定的格式要求需要从多个数据源汇总信息而且很容易漏掉某些必填项。把这些规则写成一个 skill智能体每次生成周报时就会自动遵循。反过来“回答用户关于产品功能的问题”就不太适合做成 skill因为每个问题都不一样很难用一套固定的流程来覆盖。4.2 skill 文件的结构与编写要点一个标准的 skill 通常是一个目录里面包含一个主文件通常是SKILL.md或skill.yaml和若干附属资源。主文件的结构一般包括--- name: weekly-report-generator description: 根据本周的工作记录生成结构化周报包含完成事项、进行中事项、风险和下周计划 --- # 周报生成器 ## 适用场景 当用户要求生成周报、工作总结或项目进展报告时使用此 skill。 ## 操作步骤 1. 收集本周的 commit 记录、任务管理系统中的状态变更、会议纪要 2. 按照以下结构组织内容 - 本周完成列出已关闭的任务附上简要说明 - 进行中列出仍在处理的任务标注当前进度 - 风险与阻塞列出遇到的问题和需要协调的事项 - 下周计划根据当前进度推断下周重点 3. 检查是否遗漏了以下必填项 - 每个完成事项是否有对应的产出物链接 - 风险项是否有明确的负责人 - 下周计划是否与季度目标对齐 ## 输出格式 使用 Markdown 格式一级标题为“周报 - [日期范围]”二级标题为上述四个板块。 ## 注意事项 - 不要编造没有记录的工作内容 - 如果某项信息缺失明确标注“待补充”而不是猜测 - 语气保持客观避免过度修饰这个结构看起来简单但有几个关键点需要注意。描述要精准。description字段是智能体判断是否调用这个 skill 的主要依据。它应该包含触发关键词和适用场景但不要写得太宽泛。比如“处理文档”就太宽了“从 PDF 中提取表格并转换为 Excel”就具体得多。步骤要可执行。不要写“分析数据”这种模糊的指令要写“读取 CSV 文件检查是否有缺失值如果有则用中位数填充”。智能体需要的是明确的操作指引而不是抽象的目标描述。示例要真实。如果 skill 涉及输出格式最好附上一个完整的示例。智能体通过模仿示例来学习格式比通过文字描述理解格式要准确得多。边界要清晰。明确写出这个 skill 不做什么比写出它做什么同样重要。比如“此 skill 不负责发送邮件只负责生成内容”可以避免智能体越界操作。4.3 测试与迭代怎么判断一个 skill 写得好不好写完 skill 只是开始真正的功夫在测试和迭代上。我自己的经验是一个 skill 从初稿到稳定可用通常需要经过三到五轮调整。第一轮测试关注的是“能不能触发”。用几个不同的表述来问同一个任务看智能体是否都能正确识别并调用 skill。如果有些表述触发了、有些没触发说明 description 写得不够全面需要补充触发词。第二轮测试关注的是“步骤对不对”。让智能体完整执行一次任务逐步检查它的操作是否符合 skill 里定义的流程。常见的問題包括跳过了某个检查步骤、顺序搞反了、在某个环节卡住了。第三轮测试关注的是“输出质量”。同样的任务用 skill 和不用 skill 各跑一次对比输出结果的差异。如果用了 skill 之后输出质量没有明显提升那这个 skill 的价值就值得怀疑。第四轮测试关注的是“边界情况”。故意给一些模糊的、不完整的、有冲突的输入看智能体怎么处理。好的 skill 应该能引导智能体在信息不足时主动询问而不是强行编造。注意测试 skill 的时候一定要用真实场景的数据不要用精心构造的“完美输入”。真实数据里的脏乱差才是检验 skill 鲁棒性的试金石。5. 不同场景下的 skills 实战案例拆解5.1 代码审查场景把团队规范固化进 skill代码审查是 skill 应用最成熟的场景之一。很多团队都有自己的代码规范但问题是这些规范往往写在文档里审查的时候没人会逐条对照。把规范做成 skill智能体在审查代码时就会自动检查这些点。一个典型的代码审查 skill 可能包含以下内容--- name: python-code-review description: 按照团队规范审查 Python 代码检查命名、类型注解、异常处理、日志记录和测试覆盖 --- # Python 代码审查规范 ## 命名规范 - 变量和函数使用 snake_case - 类名使用 PascalCase - 常量使用 UPPER_SNAKE_CASE - 私有方法以单下划线开头 ## 类型注解 - 所有公开函数的参数和返回值必须有类型注解 - 复杂类型使用 typing 模块中的泛型 - 避免使用 Any除非有明确理由 ## 异常处理 - 不要捕获裸 Exception - 捕获异常后必须记录日志或重新抛出 - 自定义异常继承自项目的基础异常类 ## 日志记录 - 使用项目统一的 logger 实例不要直接用 print - 日志级别使用规范DEBUG 用于调试信息INFO 用于关键流程WARNING 用于可恢复问题ERROR 用于需要关注的错误 ## 测试覆盖 - 新增函数必须有对应的单元测试 - 测试文件命名遵循 test_*.py 模式 - 边界条件必须覆盖这个 skill 的价值在于它把散落在各个文档里的规范集中到了一处并且用智能体可以理解的方式表达出来。审查代码时智能体不仅会指出问题还会引用具体的规范条款让开发者知道为什么这样写不对。实际使用中我发现这种 skill 最大的好处是减少了审查中的主观争论。以前说“这个命名不太好”现在说“根据团队规范第 3.2 条变量名应该用 snake_case”沟通效率高了很多。5.2 内容创作场景分镜脚本生成的 skill 设计热词里出现了分镜skills下载说明内容创作领域也在积极应用 Agent Skills。以分镜脚本生成为例这个场景的特点是有固定的格式要求需要遵循一定的叙事逻辑而且不同项目之间的风格差异很大。一个分镜 skill 的设计思路是这样的--- name: storyboard-generator description: 根据剧本或故事大纲生成分镜脚本包含镜头编号、画面描述、景别、运镜方式、时长和对白 --- # 分镜脚本生成器 ## 输入要求 - 故事大纲或完整剧本 - 目标时长可选默认 3 分钟 - 视觉风格参考可选 ## 生成规则 1. 每个镜头必须包含镜头编号、画面描述、景别远/全/中/近/特、运镜方式、预估时长 2. 对话场景优先使用过肩镜头和正反打 3. 情绪高潮处使用特写或推镜头 4. 转场方式标注在镜头之间 5. 总时长控制在目标时长的 ±10% 以内 ## 输出格式 使用表格形式列包括镜号、景别、运镜、画面内容、对白/音效、时长 ## 示例 | 镜号 | 景别 | 运镜 | 画面内容 | 对白/音效 | 时长 | |------|------|------|----------|-----------|------| | 1 | 远 | 固定 | 城市天际线黄昏 | 环境音 | 3s | | 2 | 中 | 推 | 主角站在天台边缘 | 无 | 2s |这个 skill 的关键在于把分镜的“隐性知识”显性化了。什么是隐性知识比如“对话场景优先用过肩镜头”这条规则有经验的导演知道这是为了保持空间关系但新手可能不知道。把这些规则写进 skill智能体就能生成更专业的分镜。5.3 学术写作场景codex 写论文的 skill 配置热词里codex写论文的skills这个搜索词很有意思说明有人已经在尝试用智能体辅助学术写作。这个场景的挑战在于学术写作有严格的格式要求需要引用规范而且不同期刊的要求还不一样。一个学术写作 skill 通常需要覆盖以下几个方面结构规范摘要、引言、方法、结果、讨论、结论的标准结构引用格式APA、MLA、Chicago 等不同格式的转换规则语言风格学术写作的正式语气避免口语化表达图表规范图表的标题位置、编号方式、引用方式伦理要求避免抄袭、正确标注引用、声明利益冲突实际配置的时候我建议把不同期刊的要求做成独立的 skill而不是写一个“万能”的学术写作 skill。因为期刊之间的差异太大了一个 skill 试图覆盖所有情况结果往往是对哪个都不够精准。6. 把 skills 用好的几个关键认知6.1 skill 不是越多越好管理复杂度的方法刚开始用 skills 的时候很容易陷入“收集癖”——看到什么 skill 都想装结果装了几十个真正用到的没几个。更糟糕的是skill 之间可能会冲突或者智能体在多个相似 skill 之间反复犹豫反而降低了效率。我的经验是个人使用的 skill 数量控制在 10 到 15 个比较合适。这些 skill 应该覆盖你日常工作中最高频的场景而不是所有可能的场景。对于那些偶尔才用一次的任务临时写提示词反而更灵活。如果是团队使用可以分层管理基础层所有成员都需要的通用 skill比如代码规范、文档模板、会议纪要格式角色层按职能划分的 skill比如前端开发、后端开发、数据分析、产品设计项目层特定项目专用的 skill项目结束后可以归档这种分层的好处是每个人只需要加载自己相关的 skill不会被他人的 skill 干扰。6.2 版本管理与团队协作中的注意事项Skills 本质上是代码和文档的结合体所以也需要版本管理。我见过团队把 skill 直接放在共享文档里结果改来改去最后没人知道哪个版本是最新的。推荐的做法是把 skill 纳入 Git 管理和代码一样走 Pull Request 流程。每次修改 skill都要说明改了什么、为什么改、影响范围是什么。这样当智能体的行为发生变化时可以追溯到是哪次 skill 修改导致的。另外skill 的命名也很重要。建议采用领域-功能-版本的命名方式比如frontend-code-review-v2。这样在多个 skill 共存的时候不容易混淆。提示团队协作中建议指定一个 skill 维护者负责审核新的 skill 提案、协调 skill 之间的冲突、定期清理过时的 skill。没有这个角色skill 库很容易变成一团乱麻。6.3 安全边界哪些操作不应该交给 skill 自动执行Agent Skills 让智能体有了更强的执行力但这也带来了安全风险。有些操作一旦自动化后果可能很严重。我认为以下几类操作不应该完全交给 skill 自动执行不可逆的删除操作删除文件、删除数据库记录、删除云资源涉及资金的操作转账、下单、支付对外发布的操作发送邮件、发布文章、推送代码到生产环境涉及敏感数据的操作读取用户隐私数据、导出客户信息对于这些操作skill 可以负责准备和检查但最终的执行应该由人来确认。比如一个“部署”skill 可以生成部署清单、检查配置、运行测试但在真正执行部署命令之前应该暂停并等待人工确认。这种“人在回路”human-in-the-loop的设计是在享受自动化便利的同时守住安全底线的关键。7. 关于 skills 的一些个人体会用了大半年的 Agent Skills最大的感受是它改变了我对“提示词工程”的理解。以前我觉得写提示词就是琢磨怎么把话说清楚现在我觉得更重要的是设计一套让智能体能够自主运作的机制。Skill 就是这个机制的核心组件。另一个体会是好的 skill 是迭代出来的不是设计出来的。我写的第一个 skill 自认为考虑得很周全实际用起来发现到处都是漏洞。后来学乖了先写一个最小可用的版本然后在实际使用中不断补充规则、修正流程、增加示例。经过几轮迭代之后skill 才真正变得可靠。还有一个容易被忽视的点skill 的文档不仅是给智能体看的也是给人看的。当团队新成员加入时他们可以通过阅读 skill 来了解团队的工作流程和规范。从这个角度看写 skill 的过程也是在梳理和沉淀团队知识。最后分享一个小技巧如果你不确定某个任务该不该做成 skill先手动做三次。如果三次的流程基本一致那就值得做成 skill如果每次都不一样那可能更适合保持灵活处理。这个简单的判断方法帮我避免了很多过度设计。