Agent skill怎么使用？

什么是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 ？一看就会，保姆级教学