很多人第一次听到 Agent Skill，会把它理解成“高级提示词”或“MCP 的另一种叫法”。这两个理解都容易跑偏。
更准确地说，Skill 是一个装着 `SKILL.md` 的文件夹。Agent 在需要时读取它，按照里面写好的流程、规则和检查清单完成任务。
Agent Skill 的实际含义
从文件结构看，一个最小 Skill 可以只有一个文件：
restore-drill/
└── SKILL.md
复杂一点的 Skill 还可以带上参考资料、脚本和模板：
restore-drill/
├── SKILL.md
├── references/
│ └── retention-policy.md
├── scripts/
│ └── verify_snapshot.sh
└── assets/
└── report-template.md
其中 `SKILL.md` 是核心。它通常包含两部分：上方的元数据，告诉 Agent 这个 Skill 叫什么、什么时候用；下方的正文，告诉 Agent 具体怎么做。
name: restore-drill
description: Run a restic restore drill and report what was recovered. Use when the user asks to test backups, verify a restore, or check that a snapshot is readable.
1. Run `restic snapshots` and pick the newest snapshot for the host in question.
2. Restore it into a scratch directory, never over live data.
3. Compare the restored file count and total size against the snapshot summary.
4. Report the snapshot ID and anything that failed to restore.
对小白来说，可以先记住一句：Skill 就是 AI 的专项操作手册。
它不是直接替你运行某个服务，而是告诉 Agent：遇到这类任务时，应该按什么流程判断、使用哪些材料、输出什么结果、遇到风险时在哪里停下来。
为什么 Skill 不等于一个大提示词
很多团队一开始会把所有规则塞进一个超长提示词里。这样做有一个明显问题：不管这次任务需不需要，这些规则都会一直占用上下文。
Skill 的设计思路更像“按需加载”。
Agent 启动时，通常只看到每个 Skill 的 `name` 和 `description`。只有当用户请求和描述匹配时，Agent 才会读取完整的 `SKILL.md` 正文。`references/` 里的长文档、`scripts/` 里的代码，也只在需要时才读取或执行。
这就是所谓的渐进式披露。
平时：
Agent 只看到 name + description
需要时：
Agent 读取 SKILL.md 正文
更需要时：
Agent 再读取 references/ 或运行 scripts/
这也是 Skill 比“一个巨大提示词”更适合长期使用的原因：它把常用能力拆成小块，需要哪块再打开哪块。
不过也要注意：Skill 一旦在当前会话里被加载，正文通常会继续留在上下文里。所以 `SKILL.md` 不应该写成百科全书。真正长的材料，应该放进 `references/`，让 Agent 按需读取。
Skill 不是工具调用
工具调用，也常被叫作 function calling，是模型可以调用的外部能力。比如搜索、读文件、查数据库、发请求、运行脚本。
工具解决的是“执行动作”。
Skill 解决的是“如何判断和编排动作”。
可以这样理解：
工具：给 Agent 一把锤子
Skill：告诉 Agent 什么情况下该用锤子，先敲哪里，敲完怎么检查
Skill 本身不会像工具那样接收参数、返回结果。Agent 只是读取 Skill 的说明，然后用已有工具去完成任务。
如果某个步骤每次都必须得到确定结果，比如解析 CSV、计算总数、校验文件哈希，最好写成脚本或工具。
如果某个步骤需要经验判断，比如判断哪条新闻更适合直播、哪些表述可能有风险、报告应该先写结论还是先写背景，更适合写进 Skill。
Skill 不是 MCP 服务器
MCP 是 Model Context Protocol，用来把 Agent 连接到外部系统。MCP Server 通常是一个正在运行的进程，它向 Agent 提供工具，例如读数据库、访问 GitHub、查询知识库、调用公司内部系统。
Skill 则是一个文件夹，没有进程、端口或协议。
两者的区别可以这样看：
| 对比项 | Skill | MCP |
| — | — | — |
| 本质 | 操作手册 | 连接协议和工具服务 |
| 形态 | 文件夹 + `SKILL.md` | 运行中的服务或工具接口 |
| 解决问题 | 应该怎么做 | 能连接什么系统 |
| 是否需要凭据 | 通常不需要 | 经常需要 |
| 是否直接执行动作 | 不直接执行 | 可以提供可调用工具 |
| 适合内容 | 流程、规范、判断标准 | 数据库、API、文件系统、业务系统 |
最好的配置往往不是二选一，而是一起用。
举个例子：你要让 Agent 生成一份论坛运营周报。
MCP 负责连接数据：
读取论坛帖子
读取评论数据
读取访问量
读取 GitHub 或飞书资料
Skill 负责规定流程：
先统计本周新增帖子
再找高互动主题
再归纳用户问题
再输出下周选题建议
最后列出需要人工确认的数据
MCP 给 Agent 接上系统，Skill 教 Agent 按你的业务方法使用这些系统。
Skill 也不是 AGENTS.md 或系统提示
`AGENTS.md`、`CLAUDE.md`、系统提示和 Skill 都可能是 Markdown 指令，所以很容易混淆。
判断标准很简单：
如果这条规则适用于所有任务，放进 AGENTS.md 或项目规则。
如果这条规则只适用于某一类任务，做成 Skill。
例如：
· 项目的构建命令、代码风格、分支命名规则，适合放在 `AGENTS.md`。
· 每月发布检查清单、直播选题流程、PDF 审核流程，适合做成 Skill。
当某段常驻规则越来越像“1、2、3、4”的流程时，通常就是它该迁移成 Skill 的信号。
一个完整的最小 Skill 示例
假设你想创建一个“备份恢复演练 Skill”，目录可以这样放：
~/.claude/skills/
└── restore-drill/
└── SKILL.md
`SKILL.md` 可以这样写：
name: restore-drill
description: Run a restic restore drill and report what was recovered. Use when the user asks to test backups, verify a restore, or check that a snapshot is readable.
1. Run `restic snapshots` and pick the newest snapshot for the host in question.
2. Restore it into a scratch directory under `/tmp`, never over live data.
3. Compare the restored file count and total size against the snapshot summary.
4. Report the snapshot ID and anything that failed to restore.
If `restic snapshots` prints `Fatal: unable to open config file`, the repository path or the password is wrong. Stop and report that instead of guessing.
这就是一个完整 Skill。它并不华丽，但有三个关键点：
· 描述里写清楚什么时候触发。
· 正文里写清楚执行步骤。
· 发生错误时要求停止并报告，不让 Agent 猜。
什么时候该把 Skill 改成脚本
不是所有东西都应该写进 `SKILL.md`。
如果一个步骤每次都只有一个正确答案，就更适合写成脚本。
比如：
解析 CSV
计算总数
校验文件数量
检查 JSON 格式
批量重命名文件
这些任务让模型每次重新推理，容易出现细小差异。写成脚本更稳定。
更好的分工是：
脚本：负责确定性计算和处理
Skill：负责说明什么时候运行脚本、如何解释结果、遇到异常怎么报告
Agent：负责按任务目标把流程跑完
这也是高质量 Skill 和普通提示词最大的区别之一：好 Skill 不是什么都写成自然语言，而是知道哪些事情应该交给脚本。
为什么我的 Skill 从来不触发
最常见原因是 `description` 写得太空。
不好的写法：
description: 处理数据库工作
这种描述太泛，Agent 不知道什么时候该用。
更好的写法：
description: 针对 staging 数据库运行 schema migration。用户要求迁移表、添加列、更改 schema 或验证迁移结果时使用。
好的 `description` 要包含用户真实会说的话，比如：
写周报
整理会议纪要
检查论坛帖子
生成直播选题
处理 PDF
分析 Excel
迁移数据库
另一个问题是过度触发。
不好的写法：
description: 用于本项目中的任何代码更改
这会让 Skill 在太多任务里被加载，反而占用上下文，还可能干扰正常任务。
写 description 的核心原则是：具体、可匹配、不抢活。
这是某个产品的专有格式吗
不完全是。
Agent Skills 最早由 Anthropic 推动，后来作为开放规范托管在 agentskills.io。现在 Claude Code、Cursor、OpenAI Codex、Gemini CLI、GitHub Copilot、VS Code、Goose、OpenHands、opencode 等工具都开始支持或参考类似的 `SKILL.md` 格式。
不同客户端的区别主要在两点：
· Skill 文件夹放在哪里。
· 支持哪些额外 frontmatter 字段。
但核心思路是相通的：用一个带描述的 Markdown 文件，让 Agent 在合适的时候按需读取专业流程。
新手应该先写什么 Skill
不要一上来规划一个庞大的 Skill 库。
最好的起点是：你已经第三次复制粘贴同一段指令。
比如：
· 每周都要写周报。
· 每天都要筛 AI 新闻。
· 每篇论坛帖都要做发布前检查。
· 每次都要把会议纪要整理成待办。
· 每次都要把 Word、Excel、PDF 转成固定格式。
这些才是值得做成 Skill 的任务。
如果一个流程你自己都没跑顺，不建议先封装成 Skill。先用普通提示词跑几次，稳定后再沉淀。
安装第三方 Skill 前要检查什么
Skill 看起来只是 Markdown，但不要太轻视它。
因为 Agent 会按照 Skill 里的指令行动，Skill 里也可能包含脚本。
安装第三方 Skill 前，至少检查四件事：
· `SKILL.md` 是否要求读取隐私、密钥、Cookie、Token。
· `scripts/` 里有没有删除、上传、联网、执行未知命令的逻辑。
· `description` 是否过于宽泛，可能导致频繁触发。
· 仓库是否注明来源、许可证、维护状态和使用边界。
简单说：安装 Skill，要像安装陌生软件一样谨慎。
FAQ
1. Agent Skill 和 MCP Server 有什么区别？
MCP Server 是运行中的服务，给 Agent 提供外部工具。Skill 是一个文件夹，告诉 Agent 怎么按流程完成任务。MCP 解决连接问题，Skill 解决方法问题。
2. Skill 只能给 Claude Code 用吗？
不是。Claude Code 是最早推动 Skill 的生态之一，但现在 OpenAI Codex、Cursor、Gemini CLI、GitHub Copilot、VS Code、opencode 等工具也在支持或采用类似格式。不同工具的安装目录可能不同。
3. 安装很多 Skill 会不会影响性能？
会有影响，但主要取决于 `description` 数量和质量。闲置 Skill 通常只暴露名称和描述；如果描述过长、过泛、互相重叠，就会影响匹配效果。
4. 什么内容应该放进 Skill，什么内容应该放进 AGENTS.md？
所有任务都要遵守的规则放进 `AGENTS.md`。只有某一类任务才需要的流程，做成 Skill。
5. 一段提示词可以算 Skill 吗？
不一定。只有当它被整理成可复用流程，并放进规范的 Skill 文件结构里，才更接近 Skill。单纯一段“你是专家”的提示词，更适合作为提示词素材，而不是 Skill 内容。
总结一下：
Agent Skill 的本质，是让 Agent 在正确时机读取一份可复用操作手册。
它和提示词的区别在于：提示词偏一次性表达，Skill 偏长期复用。
它和工具调用的区别在于：工具负责执行动作，Skill 负责指导怎么判断和编排动作。
它和 MCP 的区别在于：MCP 负责连接外部系统，Skill 负责规定怎么使用这些系统。
它和 AGENTS.md 的区别在于：AGENTS.md 常驻生效，Skill 按需生效。
对 Skill 工坊来说，真正值得发布的不是一段长提示词，而是一个清楚的场景、一套可复用流程、一份能触发的 `description`，以及可验证的结果。