MCP 是通信协议（管连接），Skill 是能力封装（管做事），二者不在同一层级，常搭配使用。

一、核心定义

• MCP（Model Context Protocol）：LLM 与外部工具 / 服务通信的标准化协议，统一接口格式，解决 “怎么连”。
• Skill（技能）：Agent 可执行的功能单元，含工具调用、提示词、业务逻辑，解决 “能做什么、怎么做”。

二、关键区别（一目了然）

对比维度	MCP	Skill
本质	协议 / 规范（基础设施）	能力模块（应用层）
核心作用	统一接入、互操作	封装能力、编排逻辑
是否含实现	否（仅接口定义）	是（含完整执行逻辑）
稳定性	高（标准长期不变）	低（随业务快速迭代）
类比	USB‑C 接口（统一连接）	设备功能（如 “充电”“传数据”）

三、通俗理解

• MCP 是 “高速公路”：规定车道、信号、互通规则，让不同车辆（工具）都能跑。
• Skill 是 “货车 + 运输方案”：货车（工具）+ 路线（工作流）+ 货物（业务逻辑），完成具体任务。

四、关系与协作

• 非替代，是互补：Skill 可基于 MCP 构建，用 MCP 连接外部系统，自身封装业务能力。
• 典型流程：Agent 调用 Skill → Skill 通过 MCP 调用工具 → 工具返回结果 → Skill 处理并回复 Agent。

五、示例

• MCP：定义 “调用天气 API” 的标准接口（入参：城市；出参：温度、天气）。
• Skill：“出行规划” 技能 → 调用 MCP 天气接口→ 查路况 → 生成方案 → 发送邮件。

可skill没出来前，都是通过MCP协议封装函数实现了工具的效果，我理解这和现有skill本质是一个东西，只是现在不知道谁把这个概念明确单独领出来了

你说得非常准：Skill 不是全新能力，而是把原来混在 MCP / 工具里的 “业务流程 + 知识约束” 单独拆出来，做了标准化、工程化的一层。下面把这个 “从混用到拆分” 的来龙去脉讲清楚。

---

一、你说的完全对：早期 MCP ≈ 现在的 Skill（功能上）

在 Skill 概念出来前（2025 年 10 月前）：

• 大家就是用 MCP 协议封装函数 / 工具，把 “查天气、发邮件、跑 SQL” 等能力暴露给 LLM。
• 为了让工具好用，必须在 MCP 的工具描述（JSON Schema）+ System Prompt 里硬写业务逻辑、步骤、约束、异常处理。
• 结果就是：一个 MCP 工具 ≈ 现在的一个 Skill—— 都能完成 “查天气 + 规划出行” 这种端到端任务。

本质上是同一个东西：都是 “工具调用 + 业务逻辑” 的封装。

---

二、那为什么要把 Skill 单独拎出来？（核心原因：工程化痛点）

随着工具变多、流程变复杂，把 “连接协议” 和 “业务知识” 混在 MCP 里，暴露出 3 个致命问题：

1. 上下文爆炸（最痛）

• MCP 设计是 “把所有工具定义全塞给 LLM”，几十上百个工具的 JSON Schema 动辄几万～几十万 token。
• 后果：成本极高 + LLM 注意力被稀释，选工具、传参数反而更容易错。

2. 业务逻辑散、乱、难管理

• 所有流程、规则、最佳实践都写在 System Prompt 或工具描述里，没有版本、没有评审、无法复用。
• 改个规则就要改 Prompt，不可控、不可审计、不可沉淀。

3. MCP 只解决 “连接”，不解决 “怎么做对”

• MCP 是集成层协议：只规定 “怎么连、怎么调”，不管 “先调哪个、参数怎么填、结果怎么处理”。
• 复杂任务（如代码评审、数据报表）需要专业知识 + 固定 SOP，这些 MCP 管不了。

---

三、谁把 Skill 明确单独领出来的？（答案：Anthropic，2025 年 10 月）

• MCP：2024 年 6 月，Anthropic 推出，定位 “AI 的 USB‑C 接口”—— 统一工具连接标准。
• Skill（Agent Skill）：2025 年 10 月，Anthropic 正式发布，定位 “知识 / 流程层”—— 把原来混在 MCP/Prompt 里的业务 SOP、领域知识、工具组合逻辑拆出来，做成标准化文件夹结构（含 SKILL.md、脚本、资源）。

一句话：Anthropic 为了解决 MCP 的工程化痛点，把 “工具连接” 和 “业务能力” 做了分层，把后者命名为 Skill。

---

四、现在的关系：MCP 是 “手”，Skill 是 “会用手的人”

层级	角色	核心	类比
MCP（集成层）	工具连接协议	能连、能调、安全	给你一把锤子（只有工具）
Skill（知识层）	业务能力封装	怎么做、做对、做好	教你用锤子盖房子（SOP + 知识）

实际流程：

1. Skill（含 SOP）告诉 LLM：先查天气（调用 MCP 天气工具）→ 再查路况（调用 MCP 地图工具）→ 最后生成方案。
2. MCP 只负责：把 Skill 的调用请求转发给工具，再把结果返回给 Skill。

---

五、总结（完全呼应你的理解）

• 功能上：现在的 Skill = 早期 “MCP 工具 + 硬编码 Prompt 逻辑”，本质是同一个东西。
• 架构上：Skill 是把原来混在 MCP 里的业务知识 / 流程拆出来，单独标准化、工程化。
• 目的：解决 MCP 的上下文爆炸、逻辑散乱、无法沉淀问题，让复杂任务更可控、更省钱、更专业。
• 提出者：Anthropic（Claude 背后公司），2025 年 10 月正式定义 Skill 标准。

一句话：Skill 不是新能力，是旧能力的 “架构重构 + 标准化命名”，为了工程化。

两种写法对比，一眼看懂：你理解的完全没错

前提：

• 旧方案：纯 MCP，所有逻辑、步骤、限制全部塞在工具描述 + 大模型自主决策
• 新方案：MCP + Skill 分层，MCP 只提供原始函数，Skill 固化业务流程

---

一、老式：纯 MCP 模式（Skill 出现之前）

1. MCP 直接暴露原始函数

// MCP 工具列表，直接喂给大模型
[
  {
    "name": "query_weather",
    "desc": "查询城市天气，用于出行判断，**必须先查天气再规划行程**",
    "params": {"city": "string"}
  },
  {
    "name": "query_traffic",
    "desc": "查询路况，天气差时优先规避拥堵路段"
  }
]

2. 所有业务规则硬写在系统提示词

你需要自主完成出行规划：
1. 第一步必须调用 query_weather
2. 根据天气结果，决定是否调用 query_traffic
3. 雨天必须增加备选路线
4. 最终整合结果输出文案

本质

• 没有 Skill 概念
• MCP 工具 + 提示词约束 = 现在的 Skill
• 逻辑全靠大模型 “悟性”，容易乱调用、漏步骤、乱参数

---

二、新式：MCP + Skill 分层模式（现在的架构）

1. MCP 层：只保留最原始、最小原子能力

只做纯粹函数封装，不带任何业务流程、业务规则

// MCP 原始工具（纯能力，无业务逻辑）
[
  {"name": "query_weather", "desc": "获取指定城市天气"},
  {"name": "query_traffic", "desc": "获取道路拥堵情况"}
]

2. Skill 层：把「步骤、规则、编排」单独封装

Skill 是一个独立能力单元，固化执行链路：

# 出行规划 Skill
## 执行SOP
1. 固定调用 MCP.query_weather(目标城市)
2. 解析天气结果：
   - 雨天/暴雪：强制调用 MCP.query_traffic
   - 晴天：可选跳过路况查询
3. 统一聚合两份数据，按固定模板生成出行建议

## 入参限制
- 城市名不能为空
## 异常处理
- 天气接口失败：直接返回「天气查询异常，建议延后出行」

调用链路

Agent → 调用【出行规划 Skill】→ Skill 按固定流程 → 按需调用底层 MCP 工具

---

三、核心总结（对应你最初的观点）

1. 功能等价老式「MCP 工具 + 提示词 SOP」= 新式「Skill」做的事完全一样，没有新增神奇能力

2. 只是架构拆分 & 概念私有化

• MCP：回归本职 → 传输协议 + 原子工具暴露
• Skill：把散落在 Prompt 里的流程、规则、边界、异常，单独抽成可管理、可复用、可版本化的模块

1. 谁炒火的这个概念国内各大 AI 应用 / Agent 平台（豆包、通义、Coze、Dify）统一对齐造词：

• 底层统一用 MCP 做工具互联
• 上层复杂组合能力，统一命名为 Skill / 技能属于工程包装 + 产品概念拆分，不是底层技术革新。

---

四、极简一句话概括

以前：我把工具和使用规则揉在一起塞给大模型，靠模型自己领悟怎么用

现在：MCP 只给工具，Skill 写好「使用说明书 + 固定步骤」，模型只需要调用技能，不用自己排流程。

反思：
为什么我在使用过程中没有总结到这些痛点？没有工程化、标准化、提出解决方案的思路？
为什么25年10月的概念，我在26年4月才开始了解，之前第一次听到skill时没有进一步了解呐？
现在有了AI可以通俗的答疑我的问题和沟通，没有AI时就得靠自己去看官方文档的晦涩文字，AI给了人可以随时"不愤不启，不悱不发"。
MCP的提出解决了接口标准问题，同时skill的出现暴漏了MCP中存在的“坑”（痛点），这也体现了新技术早期容易发表专利、树立里程碑的机会。