什么是Skill?
大模型本身依赖上下文完成推理,但上下文长度始终是有限的,而真实世界的任务往往是长期、连续、可演进的。
Agent Skill 的作用,是把"一次性的 Prompt"外化为可复用、可持久的能力模块,将关键信息、行为模式和操作规则从上下文中解耦出来,使模型不再依赖不断膨胀的对话历史,而是通过 Skill 在不同阶段反复调用,从而突破上下文上限的限制。
随着任务复杂度提升,系统设计的瓶颈不再是模型推理能力,而是上下文管理能力 。Agent Skill 通过外部状态、工具调用和行为封装,把上下文压力从模型内部迁移到系统层 ,这是从"Prompt Engineering "走向"Agent Engineering"的关键一步。
Agent Skill 的可执行,指的是模型不再只是生成建议,而是能够通过受控的工具接口触发真实动作,并基于执行结果继续决策。这使得模型从一次性文本生成,升级为具备行动闭环的智能体,从而支持长期任务、错误纠正和复杂流程自动化。
特点:
- 渐进式披露
- 减少对token的消耗
- 可执行
bash
my_program
├─ skills
├─ skill-name1 #技能名称
│ ├─ SKILL.md #元数据+指令
│ ├─ scripts/ #可执行脚本
│ │ └─ main.py
│ ├─ references/ #补充文档
│ │ └─ doc.md
│ └─ assets/ #图片/模板
│ └─ pic.png
└─ skill-name2
元数据(必须加载)
指令(按需加载)
资源(按需加载)
- 可执行脚本文件
可执行脚本文件存储于scripts,脚本文件只会被执行,不会作为上下文内容发送给大模型的。 - 补充文档
大模型根据skill中的指令加载文档,这里是按需加载,将文档作为上下文内容发送给大模型。
项目的skills与全局的skills
skills既可以作为项目也可以作为全局的。
skills的调用过程
- 用户输入问题到Agent(claude code)中
- Agent会扫描全部skills的SKILL.md文件,提取它们的原始数据,形成一个技能列表
- 将用户的提问和技能列表发送大模型
- 大模型来判断使用什么样的skill,然后Agent加载skill指令细节(SKILL.md中除了原始数据的其他部分内容)---提示词按需加载,渐进式披露
- 最后大模型综合所有的信息,回答用户的问题
Skill和Prompt的对比
| 维度 | 普通 Prompt | Claude Skill |
|---|---|---|
| 能力 | 只生成文本 | 可执行动作 |
| 是否能读代码 | 片段级 | 整个项目级 |
| 是否能操作文件 | ❌ | ✅ |
| 是否有状态 | 基本无 | 有长期上下文 |
| 使用场景 | 问答、写作 | 工程、自动化、Agent |
Skill和MCP的对比
| 侧重点 | 类比 | token消耗 | 核心主体 | 编写难度 | |
|---|---|---|---|---|---|
| Agent Skills | 提示词 | 带目录的说明书 | 低 | Markdown文件 | 低 |
| MCP | 工具调用 | 标准化工具箱 | 高 | 软件包 | 高 |
Skill 和 MCP 都具备可执行性,但关注点不同。MCP 是一种底层协议,用于规范模型如何安全、可靠地调用外部工具;而 Skill 是智能体层的能力抽象,负责决定在什么场景下、以什么顺序调用哪些工具,并基于执行结果进行决策和迭代。可以理解为 Skill 负责"怎么做事",MCP 负责"怎么把事情做出去"。
Skill能不能替代MCP
Skill 不能替代 MCP,就像"应用程序"不能替代"操作系统"。它们不是解决同一层的问题
MCP 解决的是 "执行世界的问题"
-
工具怎么被发现
-
工具怎么被安全执行
-
状态是否持续
-
多模型是否共享同一执行环境
这是"运行时基础设施层"
Skill 解决的是 "任务抽象的问题":
-
把多个 tool call 组合成一个语义动作
-
封装一段可复用的执行策略
-
降低 Agent 的决策复杂度
这是"能力抽象层 / 业务逻辑层"
MCP 让模型"能执行",Skill 让模型"会做事"。 可以让Skill 与 MCP相互配合工作。skill复杂披露提示词,MCP负责调用工具。
Skill 本身不执行任何真实动作。Skill 没有「上下文托管能力」
Skill和工作流的对比
Skill 看起来像工作流,但它关注的是"能力",而不是"流程本身"。
工作流是"事情怎么被安排",Skill 是"Agent 会干什么"。
从现象层来看,Skill ≈ 工作流,两者确实有大量重叠点。
| 共同点 | 说明 |
|---|---|
| 都是多步骤 | 都不是一次性行为 |
| 都可执行 | 都能真的跑动作 |
| 都有顺序 | 步骤之间有依赖 |
| 都能失败重试 | 都不是"跑一次就完" |
关键差异
- 工作流关注的是「流程确定性」:流程事先定义好,步骤固定,顺序固定,更像"自动化脚本"。
- Skill 关注的是「能力与决策」:一种可被 Agent 调用的能力,但 不强制流程固定。行为由 Agent 决策,内部流程是"可变的"。
Skill能代替工作流吗?
- Skill 不能代替工作流,但在简单场景下,Skill 可以"退化成"工作流的最小形态。
- Skill ⊂ Workflow(在某些场景下)
- Skill = 单一语义目标的可复用任务能力
- Workflow = 多个 Skill / Tool 的有序协作 + 控制流
- Skill 的设计目标是"稳定复用",不是"流程变化"
工作流是"人设计流程,系统照着跑";Skill 是"人给能力,Agent 自己决定怎么用"。
Skill 关注"如何完成一个语义动作",而 Workflow 关注"多个动作如何按规则推进";Skill 可以作为 Workflow 的基本构件,但无法替代 Workflow 的流程控制与全局编排能力。
从「分层架构」看三者的位置
MCP 是执行通道层,Skill 是能力抽象层,Workflow 是流程编排层;Agent 位于其上做决策。
bash
┌──────────────────────────┐
│ Agent │ ← 决策层(Why / When)
│ (Planner / Reasoner) │
└───────────▲──────────────┘
│
┌───────────┴──────────────┐
│ Skill │ ← 能力层(What / How)
│ (Task Capability) │ (任务能力封装)
└───────────▲──────────────┘
│
┌───────────┴──────────────┐
│ Workflow │ ← 编排层(Order / Control)
│ (Optional Orchestration) │
└───────────▲──────────────┘
│
┌───────────┴──────────────┐
│ MCP │ ← 协议 / 执行通道层
│ (Tool Invocation) │ (执行环境 + 上下文 + 能力托管)
└───────────▲──────────────┘
│
┌───────────┴──────────────┐
│ OS / API / DB │
└──────────────────────────┘
从架构上看,MCP 位于最底层,负责规范模型对外部系统的可执行访问;Workflow 位于中间层,用于描述和治理确定性的执行流程;Skill 则位于智能体能力层,将工具调用和流程封装为面向任务的能力接口,供 Agent 在决策过程中动态选择和组合。
参考资料:
Agent Skills (Claude Skills) 详细攻略,一期视频精通
什么是Agent Skills ?一看就会,保姆级教学