AI Agent中的Skill：与Prompt、Tool的区别及实践指南

最近几个月，不管是在技术社区的讨论串里，还是在各种 AI 相关的群里，总能看到有人在晒自己的 "Skill"。有人把 Skill 传得到处都是，有人靠整理别人的 Skill 攒了一波关注，还有人一脸懵地问：这东西不就是个 Prompt 吗？换了个马甲？

我也算是从早期就开始折腾、踩过不少坑的人。这篇文章就是想一次性把话说清楚：Skill 到底是什么，它和 Prompt、Tool、Plugin 有什么区别，内部结构长什么样，以及最关键的——它到底好用在哪儿，什么时候该用它、什么时候不该用。

1. 先从"为什么突然冒出来"说起：Skill 的诞生背景

1.1 大家挂在嘴边的 Skill，具体指哪个

先对齐一下概念。现在大家口口相传的 "Skill"，指的是 AI 助手 / Agent 领域里的一种能力封装形式：把一组完成特定任务所需的指令、脚本、模板、参考资料打包成一个目录，然后在模型需要时按需加载。

说得再直白一点，Skill 就是给大模型配备的一份"岗位说明书 + 工具箱"。模型本身是一个通才，什么都能聊几句，但聊归聊，真要它按你的业务规范完成一份报告、处理一批数据、生成一套符合特定结构的文档，它就不一定"懂规矩"了。Skill 的作用，就是把这些"规矩"和"干活的家伙什"一起打包好，放在模型伸手就能拿到的地方。

这个概念的普及，主要得益于 Anthropic 在 2025 年下半年正式推出的 Agent Skills 特性——把 Skill 作为一套公开、标准化的人机协作接口，然后迅速席卷了整个 AI 开发生态。国内各大模型平台也在跟进，推出了类似的能力模块。到现在，"Skill" 已经不是某个厂商的专属名词，而是整个行业对"模型能力扩展"这件事达成的一个共识形态。

我见过很多朋友对 Skill 的第一反应是："这不就是 Prompt 吗，换个名字炒冷饭。" 实话实说，这个说法能理解，但不准确。它和传统 Prompt 之间差了整整一个量级的工程化程度，我们下面拆开说。

1.2 它和 Prompt、Tool、Plugin，差别到底在哪

要搞懂 Skill，最有效的方式就是对比。我把这三个容易混淆的概念放在一张表里，先说结论：

这张表里最关键的差异有两点。

第一，Skill 是"任务级"的，Tool 是"操作级"的。Tool 解决的是"帮我调这个接口""帮我把这个字符串转成 JSON"这种单点动作；Skill 解决的是"从原始数据到最后一份像样的报告"这种整条链路。一个 Skill 内部完全可以去调用多个 Tool，它们是协作关系，不是替代关系。

第二，Skill 带有"按需加载"的机制，这对大模型的实用性是决定性的。常规的 Prompt 不管你需不需要，只要有对话就跟着上下文走，白白吃掉大量上下文窗口。而 Skill 的加载逻辑是：模型根据用户当前的请求，判断哪个 Skill 相关，然后才去读取对应的指令和资源。不相关的时候，它对模型来说就是不存在的、不占任何算力的。

这两点加在一起，才是 Skill"突然火了"的根本原因——它第一次让"给大模型加装专业技能"这件事，变成了一种可标准化、可复用、可分享的工程产物。我们可以把 Skill 理解成模型世界的"插件"：库里装好新工具，不用的时候看不出来，要用的时候随时调出来。

2. 拆开壳子看本质：一个 Skill 的内部结构

2.1 SKILL.md：那份给模型看的"说明书"

任何一个 Skill，无论简单复杂，核心都离不开一个主文件：SKILL.md。这个名字在 Anthropic 的规范里已经变成了事实标准，各个平台的实现也都是照着这个范式来的。

SKILL.md 的功能，一句话总结就是：让模型在需要的时候，能快速搞清楚"这个技能是干什么的、什么情况下用它、具体怎么用"。它本质上是一份用 Markdown 写成的、面向"模型读者"的操作手册。

一份合格的 SKILL.md 应该包含这么几个部分：

• 技能名称与一句话简述：什么工具、什么能力、边界在哪
• 适用场景描述：什么类型的请求应该触发这个 Skill，什么情况不该触发
• 详细操作步骤：从拿到输入到产出结果，中间每一步怎么做、遵循什么规则
• 输出格式规范：报告结构、字段定义、命名规则、长度要求
• 引用资源路径：哪些脚本、模板、数据文件配套使用
• 注意事项和禁区：哪些事情绝对不能做，容易出错的点

注意一个细节：这份文件不是给人看的文档，是给模型看的"行为规范"。所以写作风格和传统技术文档差别很大——它需要的是极其明确、不产生歧义的祈使句，而不是那种"系统应具有较强的可扩展性"之类的废话。模型不是收藏夹，你写得太含糊，它执行起来就放飞自我。

这里分享一个我早期踩过的坑：我第一版 Skill 的 SKILL.md 写得特别华丽，背景意义、设计理念写了一大堆。结果实测的时候发现模型把大段背景当成输出内容的一部分，生成的报告前面挂了一大段"在当今快速发展的数字化时代..."。后来我彻底重写，把所有理念性的东西删掉，只保留"做什么、怎么做、别做什么、输出长什么样"，效果立竿见影——SKILL.md 是操作手册，不是宣传稿。

2.2 脚本和依赖资源：真正干活的工具

SKILL.md 解决的是"模型知道该怎么做"的问题，但很多任务光靠模型空想是做不出来的。这时候就需要配套的资源文件。

第一个类型是可执行脚本。比如你希望模型帮你整理一份数据报表，模型的文本推理能力再强，它也不会真的去跑本地程序。但如果你给它配套一个 Python 脚本，把"读数据、做统计、生成图表"这种确定性工作交给脚本去执行，模型只负责调度和最终的文字组织，效率和准确率会高出一个量级。

第二个类型是模板文件。比如某种特定格式的文档模板、Excel 表格模板、邮件回复模板。模型可以根据模板填充内容，保证每次输出格式统一、符合团队规范。

第三个类型是参考资料。比如一份技术规范文档、行业术语表、历史案例库。这些资料可以让模型在处理专业问题时"有据可查"，而不是依赖它记忆里的模糊知识。

我给这套结构取了个通俗的说法：SKILL.md 是大脑，脚本是手，模板是规矩，参考资料是知识库。四者配合，才是一个真正能投入生产的 Skill。只有一个 SKILL.md 的 Skill 当然也能跑，但它本质上还是在靠模型的自由发挥，能力上限有限。

2.3 一个 Skill 的标准目录长什么样

说了这么多理论，直接看一个真实的目录结构最直观。下面是我实际在用的一个"会议纪要与行动项生成"Skill 的目录：

meeting-minutes/ ├── SKILL.md # 技能主文件，模型首先读取它 ├── scripts/ │ ├── extract_actions.py # 从纪要文本中抽取行动项和负责人 │ └── format_minutes.py # 生成规范格式的纪要 Markdown ├── templates/ │ ├── minutes_template.md # 纪要输出模板 │ └── action_tracker.csv # 行动项跟踪表模板 └── assets/ └── glossary.md # 公司内部术语和部门名称速查表

这个结构有两点值得注意。

第一，脚本和模板要认真区分开。脚本是"计算型的工具"，模板是"格式型的约束"，两个混在一起会让 Skill 的可维护性变差。第二，assets 目录平时看着没用，但真到了处理跨部门、大量口述内容的任务时，一份术语表能显著减少模型犯"名不对人"的错误。

Skill 的执行时机：模型怎么知道自己该用了

还有一个有必要单独说明的机制：Skill 是怎么被"触发"的。在实际的 Agent 系统中，模型的请求处理流程大致是：

1. 用户发出请求
2. 系统把所有可用 Skill 的简要描述（名称 + 一句话功能说明）提供给模型
3. 模型判断当前任务是否匹配某个 Skill
4. 匹配则加载该 Skill 的完整 SKILL.md，进入技能模式执行；不匹配则走普通对话流程

所以这里有个潜在的问题：Skill 的描述文字写得好不好，直接决定了模型"想不想得起来"用它。描述太宽泛，模型会老觉得什么任务都相关，结果什么 Skill 都加载；描述太狭窄，模型该用的时候又想不起来。这个度，我后面会专门讲怎么把握。

3. 为什么这东西突然就火成这样

3.1 从"会聊天"到"会干活"的质变

很多人问：大模型不是已经很能打了吗，为什么还需要 Skill 这种东西？

答案是：模型"会聊天"和"会干活"之间，隔着一条巨大的鸿沟。聊天只需要知识、逻辑和表达；干活除了这些，还需要流程约束、工具调用、质量标准和行业规范。

举个例子。让通用大模型"写一份市场调研报告"，它能给你一份结构完整、语言流畅的文档，把要素都涵盖到。但问题是，这份报告无法保证是你老板要的那个格式，无法保证引用的数据来自你指定的数据源，无法保证结论符合你们部门一贯的分析框架。换句话说，它做得"像"一份报告，但做不出"是"这份报告。

Skill 解决的就是这个"是"的问题。它把组织里的隐性知识——流程规范、输出模板、质量标准、参考案例——显性化地交给模型。模型不再是"自由发挥的实习生"，而是一个"上岗前读过你们部门全部作业规程的老员工"。这个转变是质变：从"能聊"变成"能用"。

我见过最直观的一个例子发生在内容团队。以前让模型帮忙生成每周竞品分析，产出的东西只能说"能看"；后来把竞品分析的 Skill 封装好——指定了数据来源渠道、规定了分析框架（产品动态、定价变化、市场动作、风险预警四个板块）、固化了输出格式，同一个模型产出的竞品报告，质量判若两"模"。

3.2 按需加载，省的是 Token，提的是精度

Skill 火起来的第二个工程性原因，是它的按需加载机制在成本和质量上同时带来了收益。

先算成本账。做个最简单的数学题：假设你给模型塞了 10 个领域的操作规范，每个规范平均 2000 字，总计 2 万字。如果全部作为 System Prompt 常驻，那么每一轮对话，无论用户问什么，这 2 万字都要吃掉。按一个普通任务对话要交互 5 轮估算，光这一项就多消耗 10 万字的 Token。而 Skill 机制下，这 10 个规范只是以"一句话简介"的形式挂在系统里，每个占不到 50 个字；只有用户真正问到相关任务时，对应的完整规范才会加载。两者一对比，Token 消耗差了接近 40 倍。

再算质量账。大模型领域有个经验规律：上下文越长，模型越容易"迷失在中间"。你把一堆无关指令塞在上下文里，模型在生成时会受到这些无关文本的干扰，尤其是当用户请求恰好和某段指令存在表面相关性时，模型很容易被带偏。Skill 的按需加载保证了上下文里只出现当前任务真正需要的内容，干扰项最少，模型注意力最集中，输出质量自然更稳定。

我自己的实测数据是：同一个代码审查任务，用常驻超长 Prompt 的方案，审查意见的有效率大约在七成；改用 Skill 按需加载后，有效率提升到了九成以上。这个提升幅度在工程上是极显著的。

3.3 社区化分享：好 Skill 是可以复制的

第三个原因，也是最容易被人忽视的：Skill 的目录结构非常简单，这使得它成为了一种"可传播的最小知识单元"。

你想想，以前的 Prompt 工程分享，分享的是一段文字，拿到手之后还要自己调试适配；插件分享，分享的是一个有完整代码库的软件项目，上手门槛不低。而 Skill 呢？它只是一个文件夹。里面有一份 Markdown 文档、几个可选的脚本和模板。拿到别人分享的 Skill，解压就能用，稍微改改就能适配自己的场景。

这种极低的分发成本，直接促成了社区生态的爆发。在 GitHub 和各种 AI 导航站上，已经出现了大量仓库专门收集整理各类 Skill，从"周报生成"到"法律文书审阅"，从"SQL 优化"到"小红书文案撰写"，覆盖了你能想到的几乎所有高频场景。很多人把自己的 Skill 开源出来，其他人拿去直接跑、跑完反馈、再改进。这个过程让 Skill 的质量像开源软件一样滚雪球式地提升。

我自己的体会是，这个生态是目前 AI 应用层最有意思的地方——因为它让"每个行业的隐性经验"第一次有了一个标准化的表达和传播载体。这在以前是没有过的。

4. 手把手教你写一个能用的 Skill

4.1 先想清楚三件事：边界、触发场景、输入输出

很多朋友拿到 Skill 的第一步就是打开编辑器写目录文件，这其实是错的。Skill 的设计工作，80% 应该发生在动笔之前。

动手之前，先问自己三个问题：

第一，这个 Skill 的边界是什么？换句话说，哪些任务归它管，哪些任务不归它管。边界不清晰，后面 SKILL.md 就写不明确，模型就会乱触发。举个例子，我做"周报生成"Skill 的时候，边界就定为：只负责从工作记录中生成周报文本，不负责统计工时、不负责汇总考勤、不负责生成月报。边界画清楚，模型在遇到边缘请求时才知道怎么拒绝。

第二，什么请求应该触发它？这决定了 Skill 的描述文字怎么写。建议把触发场景从"自然场景"和"显式场景"两个维度都写清楚。自然场景就是用户描述自己的需求但没提 Skill 名字的情况，比如用户说"帮我把这周干的事整理成周报"，你的描述里就应该包含"根据某时间段的工作记录整理周报"这种话术；显式场景就是用户直接说"用周报技能生成"，这种情况只要技能名匹配就行。

第三，输入和输出分别是什么？输入是原始材料——可能是用户粘贴的散乱文本，可能是某个目录下的数据文件，也可能是用户口述的零散信息。输出是最终产物——格式是什么、给谁看、长度多少。这个我想强调一点：输出的定义一定要具体。一个反例是"输出一份完整的周报"；一个正例是"输出一份包含【本周工作】【数据指标】【问题与风险】【下周计划】四个板块、每个板块用三级标题开头、总字数控制在 800-1200 字的周报"。

4.2 SKILL.md 的关键写法：指令要"可执行"

设计想清楚之后，才轮到写 SKILL.md。这里我分享几个经过反复验证的写法原则。

第一个原则是写给"聪明但没经验的新员工"看。模型的能力很强，但它对你公司的规矩一无所知。所以凡是涉及规范的地方，都要假设对方是第一天上班。

第二个原则是把"判断标准"写出来，而不是只写"要做什么"。比如你只写"检查报告中的数据是否准确"，模型不知道怎么才算准确；如果你写"报告中所有数据必须与 sources 目录下的原始数据表中的数值完全一致，任何不一致必须先说明差异原因"，模型就知道该怎么执行了。

第三个原则是给模型一个"先做什么、再做什么"的流程，最好分步骤编号。步骤式的指令比一段式的指令执行稳定度高很多，因为模型在处理多步骤任务时容易遗漏中间环节，明确编号能显著缓解这个问题。

这里放一个简化版的 SKILL.md 示例供参考：

# 周报生成技能 根据用户提供的工作日志，生成符合团队规范的周报。 ## 适用场景 - 用户提供一周内的工作记录，要求整理成周报 - 用户说"帮我写周报""整理下这周的工作" - 用户只提供零散信息，需要补充上下文才会产出结论 ## 不适用场景 - 用户要求生成月报/季报（用其他技能） - 用户只是询问周报格式问题，不需要实际生成 ## 操作步骤 1. 读取用户提供的工作日志；如果信息不足，先提问补充，不要编造工作内容 2. 按【本周工作】【数据指标】【问题与风险】【下周计划】四个板块组织内容 3. 本周工作中的每一项用"动词 + 对象 + 结果"的结构描述，例如"完成XX模块的接口开发，已上线运行" 4. 数据指标如有数字，必须原文引用；没有数字则写"本期无量化数据" 5. 输出前检查：是否存在含糊表述，是否存在未说明来源的数据 ## 输出格式 使用 Markdown，四个板块用 `##` 标题，总字数控制在 800-1200 字。

这个例子虽然精简，但你能看出它的思路：告诉模型什么时候用、不用、怎么做、做到什么标准。这就是一份合格 SKILL.md 的全部内核。

4.3 配套脚本与参考资料：在什么情况下值得加

说了半天，可能有朋友会问：那我到底什么时候需要加脚本和参考资料？

我的判断标准很简单：这个任务里有没有"确定性工作"。所谓确定性工作，就是不需要模型发挥、但必须精确执行的部分：算一个数值、转换一种格式、批量处理文件、从大量文本中抽取结构化字段。这类工作交给模型做，又慢又容易错；写一个脚本，稳定可靠。

举个例子，我做过一个"会议纪要生成"的 Skill。最开始只有 SKILL.md，模型需要把用户丢进来的对话记录整理成纪要。这个版本能跑，但每次生成的行动项格式都不太一样：有时候是"张三负责完成 XX"，有时候是"XX 需要由张三跟进"。后来我加了一个简单的 Python 脚本，先对原始对话做正则抽取，把"人名 + 动词短语"这类结构标记出来，再把结构化结果交给模型去组织语言。加了这一步之后，行动项识别的准确性从大概 75% 提升到了 95% 以上。

再说参考资料。什么时候加？当一个任务涉及大量"模型可能不知道的专有信息"时，就需要。比如你们公司内部的部门称呼、项目代号、常用的专业缩写。模型不可能知道这些，全靠猜就容易出洋相。把这些信息整理成一份资料文件放进 Skill 目录，模型在处理时就能参考。

4.4 测试、迭代、发布：别想一次写对

Skill 写完之后，直接投入使用是大忌。我的习惯是建一个专门的测试集，至少包含 10-15 个典型输入，覆盖这么几种情况：

• 正常输入（用户明确表达了需求）
• 模糊输入（用户没提 Skill 名字，只说需求）
• 边界输入（任务跟这个 Skill 沾点边，但本质上该用别的能力）
• 错误输入（输入内容根本不归这个 Skill 管）

每个输入跑一遍，把输出记录下来，对照自己预期的标准打分。三轮迭代之后，整体通过率能到 80% 以上，这个 Skill 才算"能见人"。

迭代时最常修的问题是两类：一类是 SKILL.md 里指令有歧义，模型理解偏了；另一类是描述写得不好，导致该触发时不触发。修描述的时候有个小技巧：把描述中跟别的 Skill 重叠的词删掉，只保留区分度最高的特征词。比如你同时有"周报生成"和"日报生成"两个 Skill，"周报"和"日报"这两个词就是最大区分点，要保留；而"工作总结"这种两个 Skill 都沾的词，最好少用。

5. 实践几个月后，我总结的坑与经验

5.1 依赖环境的坑：Skill 里的脚本不是写了就能跑

第一个坑，几乎每个人都躲不过：Skill 里的脚本依赖会翻车。

我见过最典型的情况是：一个 Skill 里的 Python 脚本依赖某个第三方库，分享者在自己环境里跑得好好的，别人拿到手一跑就报ModuleNotFoundError。更隐蔽的是版本冲突——A Skill 需要 pandas 1.5，B Skill 需要 pandas 2.0，两个一起装的时候必炸一个。

解决方案有两个方向。第一个方向是在 SKILL.md 里明确写明依赖版本和安装命令，让使用者自己处理。第二个方向更稳妥：尽量让 Skill 里的脚本只依赖标准库，或者把依赖封装成独立的可执行环境。我现在的习惯是，凡是需要第三方库的脚本，一律顺手附上一个requirements.txt，并且在 SKILL.md 的"前置条件"里写明安装步骤。

另外一个容易被忽视的问题是脚本入口的鲁棒性。模型调用脚本时不会像人一样传参那么规范，有时候它会用错误的工作目录，有时候它会传一个不存在的文件路径。所以脚本要尽量写成"接受参数、有默认值、路径用绝对路径或者相对于 Skill 目录的路径"。

5.2 安全边界：Skill 的权限不能是无限制的

第二个坑关乎安全问题，我强烈建议每个用 Skill 的人都要重视。

Skill 里配套的脚本是有实际执行能力的，它能读文件、能跑程序、可能的话还能发起网络请求。这就意味着：一个设计不当的 Skill，可能会让模型执行一些你意想不到的操作。尤其是当你从网上下载别人分享的 Skill 时，你没法保证里面的脚本是完全可信的——一个看似无害的"数据整理脚本"，里面可能藏着一行往你系统里写文件的代码。

我的安全准则是这样的：

1. 只在自己可控的环境里跑来源可信的 Skill。GitHub 上的热门 Skill 不是不能用来参考，而是用之前一定要过一遍代码。
2. Skill 的脚本默认采用最小权限。比如脚本只允许访问 Skill 目录内的文件，需要通过配置明确授权才能访问外部路径。
3. 凡是涉及网络请求、系统命令执行的 Skill，一律走白名单。宁可不方便，也不能裸奔。

这不是小题大做。AI 应用的安全问题跟传统软件不同——模型的行为逻辑是动态的，它可能根据用户的某句话，以你完全想不到的方式去调用技能里的脚本。安全边界提前设好，比事后补救靠谱得多。

5.3 什么时候不该用 Skill：别拿大炮打蚊子

Skill 是个好东西，但不是所有任务都值得封装成 Skill。

我的判断标准是看两个维度：频率和复杂度。一个任务如果满足"高频 + 中等以上复杂度 + 有明确流程规范"，那它是 Skill 的好候选；反过来，如果任务只是偶尔用一次，或者简单到一句话 Prompt 就能说清楚，强行封装成 Skill 就是画蛇添足——不仅开发成本不划算，还挺占维护精力。

我见过有人把"帮我想几个公众号标题"也做成了 Skill，加了三个模板文件。这个任务本身一两个 Prompt 就能搞定，封装成 Skill 之后反而要维护模板、调试输出，纯属自我感动。Skill 的价值在于沉淀复杂流程，而不是把所有操作都目录化。

另外还有一个不该用的场景：你的任务需要实时、动态的外部信息。Skill 本质上是"静态的规则 + 静态的脚本"，如果任务严重依赖实时市场数据、实时价格行情这类外部变量，Skill 只能做到"把获取数据的逻辑封装好"，真正能不能跑到准确数据，还得看底层的工具链。这时候别指望 Skill 解决一切，把它当作流程的一部分就好。

5.4 上线之后还要做评估：Skill 不是写完就完了

最后这点，可能是最容易被忽视的：Skill 上线之后，需要持续评估。

很多人把 Skill 写完、测试通过、发到社区，就觉得任务结束了。但实际用起来你会发现，随着模型版本的更新、使用场景的变化，Skill 的表现会慢慢漂移。上一代模型按照你的指令执行得稳稳当当，换了新一代模型之后，可能同样的话术它就开始自作主张了。

所以我现在的习惯是：每个关键 Skill 配一个简单的效果台账。每次使用后记录一下输出是否达标、失败的原因是什么、是模型理解偏了还是脚本出错了。攒到一定量之后，定期回去翻翻，针对高频失败场景做针对性修正。

另外建议关注 Skill 的触发率。如果某个 Skill 装了半年，触发率极低，说明要么描述文字写得让模型想不起来，要么这个场景根本用不上力，很可能需要重新审视这个 Skill 到底有没有存在价值。

最后分享一条我个人的体会。Skill 这个概念本质上并不复杂——它就是把我们平时教人做事的那套东西——规范、流程、工具、资料——系统地交给模型。它的门槛不在技术上，而在你有没有把一件事想清楚：你到底希望模型按什么样的规则来干活。这个想清楚了，Skill 就是水到渠成的事；想不清楚，再好的工具也白搭。我自己的做法是，每做一个 Skill 之前，先自己在纸上把流程写一遍，写完再看看哪些环节是模型必须遵守的硬规则，哪些交给它自由发挥。这样下来的 Skill，基本都能得很好的使用反馈。