深度解析MCP与Skills：AI能力扩展的核心与实战案例

最近阅读了一篇来自Anthropic官方的长文：《Skills explained: How Skills compares to prompts, Projects, MCP, and subagents》。这篇文章也解答了许多人心中的疑惑：Claude Skills 与 MCP、Project 之间到底有何区别？

我们将重点探讨MCP和Skills，力求从本质层面将它们阐述清楚。首先从MCP开始。

MCP：连接AI与外部世界的协议

模型上下文协议（Model Context Protocol, MCP）是由Anthropic提出的一种开放标准协议，它使得AI模型能够与外部数据源和工具进行交互。

它与HTTP协议类似，是一种被广泛接受的约定标准，只要各方遵循即可实现互联互通。

MCP诞生的原因非常直接：大模型若要真正解决问题，必然需要与各类外部接口交互，例如浏览器、数据库、文件系统等。

在MCP出现之前，我们是如何获取外部信息的呢？答案是高度定制化。

我们需要编写一个中间层程序，由它直接调用大模型API以获取用户请求，解析后再去调用相应的数据库读写API，或者根据大模型返回的参数执行其他API调用。简而言之，用户实际访问的是这个中间程序，由它弥合了大模型能力与外部世界的鸿沟。

但这种做法引发了不满：有人质疑这种“中间程序”存在的必要性。于是，一种新思路出现了：在模型底层直接实现固定格式的API调用能力。这样一来，用户可以直接与大模型对话，而大模型能够自动调用预设的API来完成诸如数据库读写等操作。

随着文件读写、浏览器控制等需求的涌现，为了提升效率，业界沿用了这一标准化思路。最终发现这套方法行之有效，便逐渐演变为一个正式协议。

MCP的出现，为AI与外部世界的交互建立了统一规范，使得AI应用能够无缝集成各种外部数据源和工具。

以上是相对概括性的描述。若想深入探究其架构，可以参考下图：

MCP是智能体（Agent）技术发展过程中的必然产物，尤其是在当前这个早期阶段。 如何理解这一点呢？

大模型发展已近三年，从去年开始，无论是推理能力还是上下文长度都得到了显著增强，确实达到了所谓“L2”级别的能力。因此，以Manus等框架为代表的智能体架构开始流行起来：

这种架构得以流行的前提，一方面是新技术的突破（模型能力增强），另一方面是互联网多年积累的丰富生态，大量现成的小工具和服务正等待被调用。例如，在微信与朋友聊天时：

1. 朋友询问最近的天气，我无需额外查询，AI可以直接给出答案；
2. 朋友发来一篇论文，我只需在微信中表达翻译或解读的意图，微信便能自动完成对论文的翻译或解读。

智能体架构或模型本身无法穷尽用户的所有意图，但它可以提供一系列有限的服务。当用户的某个意图恰好匹配到某项服务时，系统便会调用该服务，从而带来贴心的体验：

这里提到的无限意图与有限实现，也是我个人在开发智能体项目时的一个重要心得。我并不太关心智能体在开放场景下的泛化聊天能力，但如果用户的意图命中了我预设的服务范围，那么服务的质量就必须得到严格保障。

举一个实际工作中的案例。一家业务正常的公司通常会有BI（商业智能）数据看板，但老板往往缺乏耐心仔细阅读数据。善于“面向老板编程”的我们，可以预先实现许多MCP服务，静待老板提出各种意图时调用：

老板BI案例分析

首先是传统的工作模式：

老板想了解：“上月华东区销售额排名前三的产品是什么？”
→ 员工打开BI系统 → 选择日期范围 → 筛选华东区域 → 按销售额排序 → 查看前三名
→ 整个过程耗时5-10分钟
→ 缺乏耐心的老板可能因此不满。

采用MCP模式后：

老板直接询问AI：“上月华东区销售Top 3产品是什么？”
→ AI自动调用【BI工具.查询销售排行(区域=华东， 时间=上月， 数量=3)】服务
→ 10秒后给出清晰答案
→ 老板获得高效反馈，团队工作顺畅。

接下来看看简单的实现思路。首先需要预制MCP工具包（相当于告诉AI，它拥有以下可用的工具）：

# 这些工具在后台静待被老板“召唤”
老板专用工具包 = {
    “销售分析”: {
        “区域销售排行”: “按区域查询Top N产品”，
        “同比分析”: “对比同期销售数据”，
        “趋势预测”: “预测下月销售情况”
    }，
    “客户分析”: {
        “大客户清单”: “找出消费额最高的客户”，
        “流失预警”: “识别有流失风险的客户”
    }，
    “运营分析”: {
        “库存预警”: “检查库存不足的产品”，
        “成本分析”: “分析各类产品的成本结构”
    }
}

正因为“服务员提供了这份菜单”，AI在完成意图识别后，会自行进行工具匹配，并生成相应的调用指令：

{
    “tool”: “sales_analysis.regional_ranking”，
    “parameters”: {
        “region”: “华东”，
        “time_period”: “last_month”，
        “top_n”: 3
    }
}

# 每一个MCP服务都附有详细的“说明书”：
销售分析工具 = {
    “功能”: “分析销售数据”，
    “能回答的问题”: [
        “哪个区域销售业绩最好？”，
        “排名前N的产品是哪些？”，
        “同比增长或环比增长了多少？”
    ]，
    “需要的参数”: [“区域”， “时间范围”， “产品类别”]
}

AI在微调训练阶段，专门学习过如何理解和使用这类工具描述，知道什么工具能解决什么问题，包括执行最简单的关键信息提取任务：

用户输入：“上月华东区销售Top 3产品”
↓ AI提取出 ↓
区域 = “华东”
时间 = “上月”
数量 = 3

最终，这些信息会被组装起来供AI使用。例如：

# 老板提问：上月华东区销售Top 3产品？
# MCP服务返回数据
{
    “data”: [
        {“product”: “iPhone 15”， “sales”: 12500000， “growth”: 0.15}，
        {“product”: “MacBook Pro”， “sales”: 9800000， “growth”: 0.08}，
        {“product”: “AirPods Pro”， “sales”: 5600000， “growth”: -0.05}
    ]，
    “period”: “2024-05”，
    “region”: “east_china”
}

接下来AI如何分析和呈现这些数据，就是它自己的任务了。具体的服务器端实现（即API调用）此处不展开，其核心就是AI帮助抽取参数并调用接口。

接下来，我们谈谈另一个主角：Skills。

Skills：赋予AI专业执行力的技能包

在实际使用MCP的过程中，大家或许已经发现了一个问题：其中存在一个“黑盒”。

MCP虽然能够返回所需的数据，但大模型具体如何解读和使用这些数据，这个过程其实是不可控的。

并且，这其中天然存在一个难以调和的矛盾。模型或智能体是我的核心产品，而MCP服务可能由多方提供。我怎么可能将模型底层的调用逻辑和业务规则完全暴露给外部？这里涉及核心知识产权和安全问题！

为了弥补这一缺失，Skills应运而生。两者的定位也因此变得清晰：

1. MCP解决“触达”问题。 MCP的定位是让AI能够与互联网上庞大的现有工具库和数据源进行交互。
2. Skills解决“使用”问题。 Skills不关心数据是如何获取的，它关注的是获取数据后，应按照何种逻辑、规范和流程进行处理。

因此，甚至可以调侃一句：Skills的诞生，最初就是为了填补MCP留下的空白。 具体而言：

Skill = 一份可反复调用的专业标准作业程序（SOP）与说明书，由模型根据任务需要自行加载。

Anthropic对Skill的定义是：一个包含说明文档、脚本和资源的文件夹。Claude在执行任务时，会先扫描所有可用的Skills，判断哪些对当前任务有帮助，然后将选定Skill的完整内容加载到上下文中使用。

你可以将Skill理解为：为“AI员工”编写的一本岗位说明书 + 培训手册；无需你每次在提示词中“从零开始复述”所有要求。

以上就是Skills出现的原因。再补充一点：在没有Skills的时代，我们教导模型完成特定任务，完全依赖于在提示词（Prompt）上做文章：

从现在开始，你是一位XX行业专家。遇到文案任务时，需按照A/B/C三种格式撰写，禁止使用某某词汇，优先引用公司白皮书内容……

撇开一套提示词难以适配多种应用场景的工程问题，以及长上下文带来的成本增加问题，最关键的是这种方法过于粗放，AI的表现往往不尽如人意。Skills的出现，正是为了将这些需要反复使用、专业性高、逻辑成体系的知识，从冗长的提示词或项目配置中剥离出来，封装成一个个可灵活组合的“技能包”。

解释清楚其定位和成因后，我们通过几个简单案例来进一步理解。

Skills的工作原理

官方提出了一个概念叫渐进式加载（progressive disclosure），其流程大致如下：

每个Skill都附有一段非常简短的描述（meta信息），例如：

品牌写作技能：指导你如何按照XX公司的品牌规范撰写公众号文章和活动文案。

Claude在接到一个任务时，会首先利用这些meta信息进行“技能检索”：评估当前任务与哪些Skills相关，并只选中那些匹配度高的技能。

最终，只有被确认相关的Skills，其完整的instructions.md文件、示例乃至附带的脚本，才会被加载到上下文中。

因此，你可以为模型装备大量技能，而不用担心上下文窗口被撑爆。它主打“按需加载”的理念。

Skills的典型结构

抽象来看，一个Skill的目录结构大致如下（非官方严格格式）：

brand_style_skill/
    meta.json          # 简短的技能简介 & 适用场景说明
    instructions.md    # 详细的写作规范、SOP、负面示例
    examples/          # 正反例、少样本学习（few-shot）范例
    scripts/           # 可选：例如用于检查用词规范的小脚本
    assets/            # 品牌色卡、Logo使用规范等资源文件

其中，meta.json 的内容会被优先加载识别：

{
    “name”: “brand_style_cn”，
    “description”: “按照XX品牌规范撰写中文营销文案，保持统一的语气、结构和禁用词要求。”，
    “good_for”: [
        “公众号推文”，
        “电商详情页”，
        “活动落地页”
    ]
}

当你提出请求：“帮我写一篇双十一活动的主推文案，品牌是XX。”

Claude在内部大致会执行两步操作：

1. 分析当前任务内容 → 判断其与“品牌写作”相关；
2. 在所有Skills的meta信息中搜索到 brand_style_cn → 决定加载这个Skill的完整说明；

随后，Skill中定义的各种“套路”就会生效，例如：

1. 标题必须包含的要素；
2. 开头100字需要解决的问题；
3. 哪些词汇属于品牌禁用词；
4. 有哪些可复用的模块化段落结构；
5. ……；

让我们再次回到老板BI的案例，看看Skills如何发挥作用：

老板BI案例的Skills应用

在前面的MCP部分，我们解决的是基础问题：让AI能够“触及”BI系统、数据库和报表API，这属于能力打通和接入层面。

但你很快会发现，仅仅将BI系统接入AI还远远不够。因为追求高效和精准的老板对答案质量要求很高，如果回答不佳，体验依然会打折扣。

因此，为了让模型或智能体表现得更加出色，就需要引入Skills。它提供了中间关键的一层：业务分析套路 / 标准操作流程（SOP） / 高层汇报规范。

在之前的MCP案例中，AI最终输出的可能只是一堆原始文字，这显然体验不佳。理想的输出应该是结构化的表格、清晰的要点或图表。此时，我们可以新增一个名为 boss_bi_briefing_cn 的Skill：

boss_bi_briefing_cn/
    meta.json          # 技能身份与触发场景定义
    instructions.md    # 核心SOP：分析步骤、优先级、禁忌
    templates.md       # 输出结构模板：标题格式、要点归纳、行动建议框架
    examples/          # 优秀汇报示例 & 不佳汇报示例
    checklists.md      # 风险排查清单（例如：毛利率、库存、客户投诉…）

首先，meta信息告诉模型该技能在何时被触发使用：

{
    “name”: “boss_bi_briefing_cn”，
    “description”: “当用户身份为业务负责人，提问涉及销售、区域、产品、客户等经营指标时，启用此技能。按照「高层经营汇报」的风格与结构来组织BI分析结果。”，
    “good_for”: [
        “按区域/产品/渠道查看Top N排名”，
        “询问上月/上季度的经营状况”，
        “询问‘哪里出了问题’或‘存在什么机会’”
    ]
}

例如，当老板提问：“上月华东区销售Top 3产品是哪些？顺便说说有没有什么异常情况需要关注？”

Claude内部会进行两步判断：

1. 解析用户语句，发现关键词：上月 / 华东 / 销售 / Top3 / 异常 / 机会 → 判定这属于“经营分析”意图；
2. 在所有Skills的meta信息中检索，发现 boss_bi_briefing_cn 高度相关 → 加载这个Skill的完整内容；

其次，instructions.md 文件需要清晰地定义“BI分析的标准套路”（这有点类似于工作流定义）：

# 使用场景
当用户是公司老板或高层管理者，询问特定时间段、区域、产品或渠道的经营情况时，请启用此技能。

# 总体原则
- 回答结构固定为：【一句话结论】→【关键数据点】→【原因与拆解】→【风险与机会】→【建议行动】。
- 避免单纯罗列数据，必须包含明确的「好/坏」判断和业务洞察。
- 优先采用「经营者视角」而非「纯数据分析师视角」。

# 分析步骤（示意）
1. 明确用户核心意图
   - 是「查看排名」？「定位问题」？「寻求决策依据」？如果意图模糊，应在不打断用户的前提下做出合理推断。

2. 必查核心指标
   - 销售额、销售数量
   - 毛利额、毛利率
   - 同比增速、环比变化
   - 重点区域或重点客户的贡献度

3. MCP 工具调用建议
   - 使用 sales_analysis.regional_ranking 获取指定区域Top N产品
   - 同时调用 sales_analysis.yoy_growth、sales_analysis.trend 获取同比数据及趋势信息
   - 如涉及库存波动，调用 inventory.check_warning 检查是否存在缺货或积压风险

4. 输出格式规范
   - 首先用一句话概括「整体情况」并点明「是否存在显著异常」
   - 接着用3～5个要点列出关键数据（必须包含同比/环比及毛利率）
   - 对排名第一或异常波动的项进行原因推测（需明确标注为「推测」）
   - 最后提供2～3条具体、可执行的建议

5. 风险与禁忌
   - 禁止使用绝对化词汇：如“一定”、“必然”。
   - 避免只报喜不报忧，必须提示潜在风险。
   - 当数据不足以支撑确定结论时，必须说明“当前信息有限”。

接下来的步骤就比较直接了：调用MCP服务并接收返回的数据。

{
    “tool”: “sales_analysis.regional_ranking”，
    “parameters”: {
        “region”: “east_china”，
        “time_period”: “2024-05”，
        “top_n”: 3
    }
}

# MCP返回数据
{
    “data”: [
        {“product”: “iPhone 15”， “sales”: 12500000， “growth”: 0.15}，
        {“product”: “MacBook Pro”， “sales”: 9800000， “growth”: 0.08}，
        {“product”: “AirPods Pro”， “sales”: 5600000， “growth”: -0.05}
    ]，
    “period”: “2024-05”，
    “region”: “east_china”
}

然后，Skills开始发挥作用，解决了AI输出格式随意、缺乏业务深度的问题。应用了Skill的AI可能会生成如下汇报：

【一句话结论】
上月华东区整体销售表现稳健，Top3产品中有两款保持增长，但AirPods Pro出现小幅下滑，需关注其库存与渠道策略。

【关键数据点】
1.  iPhone 15：销售额1250万元，同比增长15%，毛利率约32%，增长主要来源于线下经销渠道的扩张。
2.  MacBook Pro：销售额980万元，同比增长8%，毛利率28%，客单价提升是主要驱动因素。
3.  AirPods Pro：销售额560万元，同比下滑5%，毛利率25%，在华东部分城市（如苏州、无锡）出现库存周转放缓迹象。

【风险与异常】
- AirPods Pro在部分城市的库存周转周期已达3–4周，超出健康水平，当前促销策略效果有限。
- 华东区整体毛利率略低于全国平均水平，主要因iPhone系列促销活动较为频繁。

【建议行动】
1.  针对AirPods Pro库存较高的城市，可考虑设计针对性促销或与其他产品进行捆绑销售，并酌情控制后续补货节奏。
2.  评估iPhone频繁促销对整体毛利的长期影响，尝试在部分门店推行高毛利配件搭售方案，以平衡利润。
3.  建议后续每月对华东区Top10产品增加“库存健康度+毛利率”的联合监控看板，实现异常预警前置。

在BI汇报场景中，Skill可以根据老板的偏好预先固化许多规则，例如：

1. 在instructions中硬性规定，所有回答必须先给出“一句话结论”；
2. 当某个产品的毛利率显著低于公司平均值时，自动在汇报中插入注意风险标签；
3. 针对老板提出的模糊问题（如“最近怎么样？”），预先定义好默认的分析维度和时间范围；
4. ……；

以上便是关于Skills的一些核心阐述，希望能帮助大家理清概念。

总结

经过前面的详细探讨，大家应该已经对MCP和Skills有了比较清晰的认识。在此做一个简要的总结。

Anthropic近年来创造了不少新名词，有时也让人感到困惑，以至于官方不得不发布长文来解释自己的“发明”……

但如果你将今天讨论的这些概念，对应到传统软件世界中的老朋友，理解起来就没那么复杂了：MCP更像是对远程服务调用的封装协议，而Skills则更像是本地化、模块化的能力包或插件。

在真实应用场景中，MCP与Skills的界限有时并不那么泾渭分明。一个Skill内部会指导AI去调用哪些MCP工具；而一个MCP服务的描述本身，也可能包含部分使用逻辑。

记住“MCP管接入（Access），Skills管用好（Application）”这个核心分工即可。目前，真正能充分发挥二者优势的最佳实践范式可能仍在探索之中。

另外，MCP目前几乎已成为AI与工具交互的事实标准。而Skills这类“技能包”方案，各大基础模型厂商是否会跟进推广，还存在不确定性。因为这对模型本身的意图识别能力提出了较高要求，若识别不准，很容易适得其反。