先给一个通俗回答
很多人一听到 Skill,就以为它只是“把一段 Prompt 保存起来,下次继续用”。这个理解太浅了。
更准确地说,Agent Skill 是一个可复用的能力包:里面有任务说明、操作流程、脚本、模板、参考资料。Agent 看到任务后,可以自己判断要不要用它,真正需要时再把里面的内容加载进来。
所以 Skill 更像“新人入职手册 + 工具箱 + 输出模板”的组合。Prompt 是你临时说一句话;Skill 是把一类工作沉淀成标准流程,让 Agent 每次都能按同一套方法做。
1. 为什么不能只靠 Prompt?
单人使用 AI 时,复制一段 Prompt 好像也能解决问题。但只要任务变复杂、使用频率变高、团队人数变多,问题就会暴露。
比如代码审查。你希望 AI 检查安全漏洞、性能问题、边界条件,还要按固定格式输出。如果每次都靠你手动贴 Prompt,就会遇到三个问题:
容易漏:复制时少了一条规则,结果就会变。
难统一:团队里每个人写的 Prompt 不一样,输出标准不一样。
难维护:流程更新后,有人还在用旧版本,结果质量不可控。
Skill 要做的事,就是把这些“反复用、容易漏、需要统一”的流程固化下来。Agent 不需要你每次重新教,它会根据任务自己去找合适的 Skill。
2. Skill 的结构长什么样?
一个 Skill 通常就是一个文件夹。最核心的是 SKILL.md,旁边可以放脚本、参考文档、模板和素材。
code-review/ ├── SKILL.md# 核心指令文件,必须有├── scripts/# 可选:可执行脚本│ └── check_security.py ├── references/# 可选:团队规范、接口文档、术语表│ └── review_standards.md └── assets/# 可选:报告模板、配置模板、示例文件└── report_template.md这里最重要的是 SKILL.md。它不是随便写一段话,而是要告诉 Agent 三件事:什么时候用这个 Skill、按什么步骤做、用到资料或脚本时去哪里找。
--- name: code-review description: Review codeforbugs, security issues, performance risks, and output a structured report. Use when the user asksforcode review. ---# 代码审查 Skill## 执行步骤1. 先阅读变更文件,理解业务目的。2. 检查功能正确性、安全风险、性能风险和边界条件。3. 如果需要,运行 scripts/check_security.py。4. 使用 assets/report_template.md 输出结构化审查报告。## 输出要求- 必须列出风险等级。 - 必须给出修改建议。 - 不确定的问题要标记为“需要人工确认”。3. Skill 最聪明的地方:按需加载
Skill 不是把所有内容一次性塞给模型。它采用的是按需加载思路,只有真正用到时才展开内容。
第一层,Agent 启动时只看到所有 Skill 的 name 和 description,相当于看目录。
第二层,用户任务匹配某个 Skill 后,Agent 才读取这个 Skill 的 SKILL.md 正文。
第三层,执行过程中需要脚本、模板、参考资料时,再去读取对应文件。
这套机制很重要,因为 Agent 的上下文窗口再大也不是无限的。如果一次性加载几十个 Skill 的全文,用户真正的问题和业务资料反而会被挤掉。
4. Skill、Prompt、Slash Command、MCP Tool 的区别
这几个概念经常混在一起。可以用一句话区分:Prompt 是临时指令,Slash Command 是手动触发的固定指令,Skill 是可自动发现的工作手册,MCP Tool 是真正访问外部系统的工具接口。
举个例子:
你说“帮我看看这段代码有没有问题”,这是 Prompt。
你输入 /review,让 AI 按预设模板审查,这是 Slash Command。
Agent 自动发现 code-review Skill,并按团队规范审查,这是 Skill。
Agent 调 GitHub API 读取 PR 文件,这是 MCP Tool 或 Function Calling 工具。
5. Agent 运行时怎么用 Skill?
从运行过程看,Skill 不是突然“魔法生效”。它大致经历五步。
第一步,用户提出任务。第二步,Agent 根据 Skill 的 description 判断是否匹配。第三步,加载对应的 SKILL.md。第四步,根据里面的流程去读模板、跑脚本、调用工具。第五步,按 Skill 规定的格式输出结果。
如果 description 写得很模糊,比如“帮助处理文档”,Agent 就很难判断什么时候该用;如果写得很具体,比如“用于把会议纪要整理成周报,并按公司固定模板输出”,触发就会更稳定。
6. Skill 和 MCP 是互补关系
Skill 不是 MCP 的替代品。MCP 让 Agent 能连接外部系统,比如读文件、查数据库、调用 API;Skill 则告诉 Agent 拿到这些能力后,应该按什么流程完成任务。
例如做一次代码审查:
Skill 规定审查维度:安全、性能、边界条件、代码规范。
MCP Tool 负责读取 GitHub PR、获取 CI 日志、查询项目文档。
Function Calling 负责把模型要调用的工具和参数结构化输出。
所以真正的生产级 Agent,往往不是只用一个概念,而是 Skill + Tool + MCP + 权限控制一起配合。
7. 怎么写一个好 Skill?
Skill 写得好不好,主要看它能不能让 Agent 稳定完成一类任务。不要写成空泛的“请遵循最佳实践”,而要写成清晰的步骤、边界和输出模板。
几个实用建议:
description 要写清楚触发场景,不要只写“帮助处理代码”。
正文要写步骤,不要只写原则。
复杂资料拆到 references/,不要把 SKILL.md 写成大杂烩。
重复、机械、容易出错的步骤可以放到 scripts/。
输出格式固定的任务,把模板放到 assets/。
下面是一个更像生产环境的 description 写法:
description: Review backend pull requestsforJava/Spring projects. Use when the user asks to review a PR, patch, or changed files. Focus on security, transaction boundaries, SQL performance, exception handling, and backward compatibility. Do not useforfrontend-only changes.这段描述比“帮我做代码审查”好得多,因为它明确了适用对象、触发词、检查重点和不适用场景。
8. 什么时候适合做成 Skill?
不是所有任务都应该做成 Skill。判断标准很简单:如果一类任务经常重复出现,流程稳定,团队希望统一标准,就值得做成 Skill。
比如文档排版、代码审查、测试报告、数据分析周报、投研报告模板,这些都很适合。因为它们不是一次性闲聊,而是有固定流程、有标准输出、需要反复复用的工作。
但如果只是“帮我想一个标题”“查一下今天上海天气”,直接 Prompt 或工具调用就够了,没必要专门做 Skill。
9. 安全问题不能忽略
Skill 可能包含脚本,也可能引用参考资料。它一旦被 Agent 自动加载,就会影响 Agent 的行为。所以 Skill 不能随便安装,更不能把危险动作写成默认步骤。
几个必须注意的点:
只安装可信来源的 Skill,团队内部 Skill 要走代码审查。
能执行脚本的 Skill,要限制文件、网络和系统命令权限。
涉及删除文件、发消息、转账、修改生产配置等高风险动作,必须让用户确认。
记录 Skill 版本、输入、工具调用和输出,方便追踪问题。
参考资料也要审查,因为恶意指令可能藏在长文档或脚本注释里。
一句话:Skill 是能力放大器。好 Skill 能让 Agent 更稳定,坏 Skill 也可能把风险放大。
10. 面试时怎么回答?
如果面试官问“Skill 是什么”,不要只回答“保存好的 Prompt”。可以这样说:
Agent Skill 是一种可复用能力包,通常以文件夹形式存在,核心文件是 SKILL.md,里面包含元数据和任务指令,也可以带脚本、模板、参考资料。Agent 会先通过 name 和 description 自动发现它,需要时再加载正文和资源。它解决的是复杂流程复用、团队标准统一和上下文节省问题。
它和 Prompt 的区别是:Prompt 是一次性的临时指令,Skill 是可维护、可复用、可自动加载的工作流模块。它和 MCP Tool 的区别是:MCP / Tool 提供外部系统访问能力,Skill 提供如何完成任务的流程和规范。