1.MCP和Skills都是什么

官方解释

MCP（Model Context Protocol，模型上下文协议）是由Anthropic推出的一个开源标准化协议，类似于AI领域的“USB-C接口”，其核心作用是让AI模型（如Claude）能够通过统一的方式连接和访问外部系统、工具、API、数据库或资源，实现即插即用式的外部交互，而无需为每个工具重新编写适配代码，它主要解决的是AI“连通外部世界”的基础设施问题。

Skills（也称Agent Skills或Claude Skills）则是Anthropic推出的模块化能力包，相当于给AI“装插件”或提供标准化操作手册，它将特定领域的专业知识、工作流程、SOP（标准作业程序）或任务指令打包成可复用、可按需加载的单元（如文件夹形式），通过渐进式披露和脚本执行机制，帮助AI更高效地执行内部任务、减少上下文消耗，提升准确性和专业性，而不依赖外部连接。

是不是感觉很乱，那看看下面的

MCP

简单说，MCP 就像给 AI 装了一个“通用 USB-C 接口”。它是一个开放标准，让 Claude 等 AI 能轻松、安全地连接外部数据（如文件、数据库）和工具（如搜索、CRM 系统），不用每次都重新写复杂的连接代码，一次对接就能到处用。核心是解决 AI “怎么连上外面世界”的问题。

Skills

Skills 就像给 AI “装插件”或“操作手册”。它是一个文件夹，里面打包了特定任务的指令、脚本、模板和流程（比如按公司品牌写报告、按标准分析数据）。AI 只在需要时动态加载，避免上下文太乱，能更专业、一致地完成重复性工作。核心是教 AI “具体怎么做这件事”。

2.有什么区别

在讨论A能否取代B之前，我们得首先了解他们的适用场景以及区别（这里分享一段grok的回答 https://grok.com/share/bGVnYWN5_99294216-211a-4a38-85d5-c0e4f9d0e10e）

调用方式

MCP

MCP是主动、显式调用。AI先看到所有连接的MCP服务器提供的工具列表（类似函数列表），当需要外部数据或操作时，会明确发出tool call请求，通过MCP协议发送给对应的MCP服务器执行，然后拿回结果。

Skills

Skills是自动或半自动加载。Agent启动时只能看到每个Skill的简短名称和描述（很省token），当用户查询匹配描述时，Claude会自动决定加载该Skill的完整指令（SKILL.md），直接注入上下文作为指导，让AI按流程执行。不需要显式“调用函数”，更像动态加载操作手册。

区别

MCP优点是能够确保支持工具调用的AI直接使用所有工具，缺点是浪费token（加载了所有工具占用上下文）
Skills的优点在于AI自动选择需要加载的工具在运行时才注入提示词，缺点是Skills不提供执行器需要额外实现（下面会讲）

环境要求

MCP

只需要客户端能够对话，支持MCP协议，能够链接MCP服务器就可以使用MCP的所有功能，实际后续执行功能全部由mcp服务器实现（例如在线的搜索&天气mcp/操作xx软件的mcp，对于ai来说只需要调用工具读取返回即可）

Skills

客户端除了对话，加载Skill的逻辑以外还需要能给确保提供给AI执行环境（比如各类cli agent，Claude Code/CodeX/Opencode/OpenClaw等等），否则只有不依赖执行环境的纯提示词Skills能够生效，并且工具调用情况取决于模型自身能力而不是Skills本身（同样是搜索&天气的场景，需要提供至少提示词的md文件+请求对应搜索/天气api的脚本，还要确保模型能够正确调用bash工具运行脚本，如果是python这类的还需要模型能自动处理好环境问题）

3.Skills能否取代MCP

结论：暂时无法取代，除非有更好的纯文本远程工具调用方案（比如优化下mcp的加载方式和skill一样由模型自己决定）

看到部分论坛/群聊内有人认为Skills可以取代MCP了 MCP已经淘汰了一类的论点，经过以上分析就知道至少目前是无法取代的

首先：真的更省上下文吗

可以从两个场景看：
1.Claude Code/CodeX/OpenClaw等Agent
这类场景含有大量系统提示词，且工具本身内置大量工具，往往需要接入很多第三方应用/链接很多网站等
此时例如处理PDF就可以只加载PDF相关工具脚本/命令的提示词，使用MCP如果不手动开关则需要加载很多其他无关功能的MCP占用提示词
此时使用Skills确实更省Token
2.CherryStudio/RikkaHub/ChatBox聊天
这类轻量场景下，提示词基本上只有：系统提示词+用户输入，且此类工具不带命令行执行环境（虽然部分支持编辑本地文件等）加入MCP只需要额外注入MCP的工具列表以及描述，而假如使用skills则需要额外的工具用于调用命令行，额外的读写文件工具，额外的安全审计，额外的环境安装（可以自行试试codex/cc/openclaw/nanobot+skills查天气和使用聊天软件+mcp查天气的消耗）
这种情况下用skill由于缺乏直接的调用，需要更多工具更多次调用，往往毫无疑问是更浪费token的

以下几点情况Skills无法取代MCP:

1.部分高安全/低权限/无命令行环境

• 缺乏Agent框架（嵌入式环境/冷门系统）
• 命令执行/命令行受限（例如web场景，虽然可以像openai那样真跑一个容器来解决但是对于小企业/个人过于复杂且成本无法控制）
• 部分环境缺失（例如：Alpine下无法使用很多需要glibc的软件）
  案例：WIFI开发板(比如ESP32)上的AI助手，通过云端API+MCP可以实现0本地占用调用云端天气/搜索/智能家居控制，而通过Skill/CLI调用则无法实现（FreeRTOS/裸机[虽然esp都是freertos]等嵌入式设备的环境根本无法运行python脚本和命令）
  2.需要大量工具频繁使用场景
• 上下文过长导致压缩/模型遗忘后无法快速定位工具完整功能，需要重新加载skills注入提示词或者重新看脚本/命令行工具的help
  3.部分应用操作
• MCP往往是以插件等形式附加在应用上随后提供一个http接口供mcp调用，Skills需要额外脚本/cli工具发送请求
  4.远程请求浪费token/时间
• 新闻/天气/搜索等固定接口场景 读取提示词+cli发请求获取接口数据可能花的时间和token还不如手动开一下mcp让模型直接调远端mcp完事手动关了来的快

临时“取代”方案

有看到将MCP转成CLI的方案，这样可以让MCP也实现和Skill一样的加载方式，可以直接节省MCP加载导致大量工具占用上下文的问题，配合搜索应该很好用，但是这个方案仍然需要命令行环境才能使用，对于轻量聊天环境是不现实的

小结

MCP和Skills目前适用场合以及所需环境/客户端开发难度都完全不同，仅仅是从能够实现的功能近似然后更省上下文就认为Skills可以取代MCP是完全错误的