Skill和MCP到底有什么区别？它们越多，效率就越高吗？

用户272017999752026-03-17 15:00

Skill和MCP到底有什么区别？它们越多，效率就越高吗？

一、Skill会代替MCP吗

首先，我们直接给结论------Skill 和 MCP 根本不是替代关系，而是"左手和右手"的关系。

  • MCP（模型上下文协议） ：解决的是 「模型能用什么」 的问题。它是一个"万能插座"，负责让AI连接外部世界（数据库、API、浏览器） 。
  • Skill ：解决的是 「模型该怎么用」 的问题。它是一本"操作手册"，负责教会AI在特定场景下按什么流程做事，输出什么格式 。

如果AI Agent是一个操作系统：MCP 就是 USB 协议，Skill 就是应用程序。 一个管连接，一个管干活 。

二、深度拆解：MCP和Skill到底长啥样？

为了让大家不陷入抽象的概念，我们来看看它们的"真身"。

我来优化MCP这一节的第三点，引入Function Call的概念，让解释更加完整：

1. MCP：AI界的"USB-C"统一接口

在MCP出现之前，每个AI连接每个工具都需要写一套定制代码，这是典型的 M×N 问题 。MCP的出现，把这个复杂度变成了 M+N 。

  • 核心能力 ：通过标准的 JSON-RPC 2.0 协议，把 Tools（工具）、Resources（资源）和 Prompts（提示词）封装在独立的 Server 中 。

  • 传输方式：支持本地 stdio（适合本地进程）、HTTP+SSE（适合浏览器）和 WebSocket（适合实时交互） 。

  • 本质进化：从Function Call到MCP

    Function Call解决了"AI怎么调用函数"的问题------你给AI一堆函数定义，AI决定调哪个、传什么参。但问题是：每个应用都要自己定义这些函数，自己写调用逻辑。

    MCP就是Function Call的"网络版"和"标准化版"。它把"定义函数"这件事从客户端剥离出来，放到独立的Server中。从此，Claude、Cursor、Windsurf可以共享同一套工具定义，开发者只需写一次MCP Server，所有AI都能用。这就是MCP最核心的价值：解耦与复用------工具不再被绑定到特定AI，AI也不再需要重复造轮子。

  • 代价 ：上下文吞噬者。每个MCP Server在启动时，通常需要把所有的工具定义（名称、描述、参数）一次性塞进上下文。

    • 例如：GitHub MCP Server 有27个工具，吃掉约 18,000 tokens ；Playwright MCP 有22个工具，吃掉约 13,600 tokens。如果你装7个MCP，还没开始聊天，7万token就没了 。
    • 因此，MCP不是越多，agent的效率越高

我来为MCP章节增加一个子章节，深入解释为什么选择JSON-RPC 2.0：

1.1 为什么用 JSON-RPC 2.0？

你可能好奇：HTTP API 不香吗？gRPC 不更快吗？为什么 MCP 偏偏选了 JSON-RPC 2.0？这背后其实是一场精心设计的权衡。

1.1.1 什么是 JSON-RPC 2.0？

简单说，JSON-RPC 2.0 是一种轻量级的远程调用协议。它使用 JSON 格式传输数据，通过 HTTP/TCP/stdio 等通道，让客户端可以像调用本地函数一样调用远程服务。

一个典型的 JSON-RPC 2.0 请求长这样：

json 复制代码 
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "北京"
    }
  },
  "id": 1
}

响应也很简洁：

json 复制代码 
{
  "jsonrpc": "2.0",
  "result": {
    "temperature": 22,
    "condition": "晴"
  },
  "id": 1
}
1.1.2 为什么是它？四大核心原因

① 天然适配 AI 的思维方式

AI 最擅长的就是生成和理解 JSON。JSON-RPC 2.0 的请求-响应模式，完美对应了 AI 的"思考-行动"循环：

  • AI 思考后决定调用工具 → 生成 JSON-RPC 请求
  • 收到 JSON-RPC 响应 → AI 解析结果继续思考

这种语义对齐让 AI 处理起来毫无负担。相比之下，gRPC 的二进制编码或 RESTful 的资源语义，对 AI 来说都需要额外的心智负担。

② 极简，但够用

JSON-RPC 2.0 规范只有 16页（相比之下，OpenAPI 规范几百页）。它定义了最核心的东西：

  • 请求必须有 method 和 params
  • 响应必须有 result 或 error
  • 通过 id 实现异步调用

没用的东西一概不要。这种极简主义对 MCP 至关重要------协议越简单，实现越容易，bug 越少，AI 越不容易出错。

③ 传输无关性

JSON-RPC 2.0 不绑定任何传输层。这意味着：

  • 本地进程间通信用 stdio（零网络开销）
  • 浏览器环境用 HTTP + SSE（兼容性好）
  • 需要双向实时通信时切 WebSocket

一套协议，三套传输方案，全场景覆盖。如果选 gRPC，本地通信就尴尬了；如果选纯 HTTP，双向通信又得折腾 WebSocket。

1.1.4 小结：最简单的，往往最合适

JSON-RPC 2.0 不是最炫的协议，但它是最合适的协议：

  • 对 AI 友好（JSON 生成成本最低）
  • 对开发者友好（实现简单，调试直观）
  • 对场景友好（stdio/HTTP/WebSocket 全支持）

2、Skill：AI的"领域说明书"与"自动化脚本"

Skill 不是一个新的协议，它是一种封装模式 。在 Claude Code 中，一个 Skill 本质上就是一个文件夹，核心是 SKILL.md 文件 。

perl 复制代码 
my-skill/
├── SKILL.md          # 核心指令 (YAML头信息 + 自然语言流程)
├── scripts/          # (可选) 可执行脚本 (Python/Bash/JS)
├── references/       # (可选) 详细的参考文档
└── templates/        # (可选) 输出模板
  • 工作哲学：渐进式披露 。
    1. 启动时 ：只加载 SKILL.md 里的 YAML 元数据（名称、描述），仅消耗 30-100 tokens 。
    2. 匹配时 ：当用户任务与Skill描述相关，AI才加载完整的 SKILL.md 指令。
    3. 执行时 ：如果需要，再读取 scripts/ 里的脚本。重点来了：脚本是在外部执行的，只有结果返回给AI，代码本身不占用上下文！

2.1 实战举例：一个「写周报」的 Skill

光说概念太抽象，我们来看一个真实能用的 Skill。假设你是技术团队的 leader，希望团队成员用 AI 写周报时，能保持统一的格式和质量。

2.1.1 文件结构

text

bash 复制代码 
weekly-report-skill/
├── SKILL.md                 # 核心指令
├── scripts/
│   ├── git_commits.py       # 从git拉取本周提交
│   └── format_markdown.py   # 格式化输出
└── templates/
    └── report_template.md   # 周报模板
2.1.2 SKILL.md 内容
yaml 复制代码 
---
name: weekly-report
description: 生成技术团队的周报，包含本周工作、技术分享和下周计划
version: 1.0.0
author: 技术部
---

# 周报生成技能

当你收到「写周报」或类似指令时，请按以下流程执行。

## 1. 准备工作
首先，切换到当前项目的根目录，确认这是一个git仓库。

## 2. 收集信息
### 2.1 获取本周提交记录
运行脚本：
```bash
python scripts/git_commits.py --since "monday" --format json

该脚本会返回：

  • 本周提交的commit message列表
  • 涉及的文件修改
  • 每个commit的作者

2.2 询问用户补充信息

向用户提出以下问题（逐一询问，不要一次性全抛）：

  1. "本周有没有特别的技术难点要写进去？"
  2. "下周主要关注哪些方向？"
  3. "有没有想分享的技术文章或工具？"

3. 生成周报

3.1 加载模板

读取 templates/report_template.md

3.2 填充内容

按照模板结构填充：

  • 本周进展：从git记录提炼，每条不超过20字
  • 技术分享：使用用户提供的补充信息
  • 下周计划：使用用户提供的下周计划
  • 思考与沉淀：如果有难点，写在这里
3.3 格式规范
  • 使用二级标题（##）分隔主要章节
  • 列表项使用短横线（-）
  • 代码块标注语言

4. 输出与确认

生成周报后，先展示给用户预览，并询问： "周报生成好了，需要调整什么吗？"

如果用户提出修改，返回步骤3.2重新生成；如果用户确认，将最终内容保存到 ./weekly-report-YYYY-MM-DD.md

四、既然是协作，为什么还有"Skill取代MCP"的错觉？

这个错觉主要源于两个原因 ：

  1. Skill越来越"能干" ：以前我们觉得AI必须通过API（MCP）才能干活。但现在，借助 Skill 里的 脚本执行，很多以前需要调API的事，现在写个Python脚本本地就跑了。比如处理PDF、批量重命名、代码分析，完全不需要MCP。
  2. Token经济学 ：如前所述，MCP太费钱了（费Token）。开发者们发现，用 Skill + CLI 工具 ，往往能达到同样的效果，但成本只有MCP的十分之一。例如，用 gh 命令（GitHub CLI）代替 GitHub API MCP，AI自己看 gh --help 就能学会，何必喂给它几万个Tool Definition？

但这并不意味着MCP会死。MCP依然是连接"外部世界"的唯一标准。

五、到底什么时候该用谁？

理解了区别，我们来看看实战中如何选择 。

优先选择 Skill 的场景（日常开发首选）

  • 本地文件操作 ：读写日志、处理 Excel/PDF/Word。 -> Skill脚本（Python/Bash）搞定。
  • 代码库分析与格式化 ：按照团队规范检查代码风格。 -> Skill 规定规则，调用本地 linter 执行。
  • 标准化的工作流：比如"写一篇CSDN文章"的Skill，规定必须先搭框架、再填内容、最后 SEO 优化。
  • 需要极致Token节省的场景。

必须使用 MCP 的场景（复杂集成必备）

  • 访问实时业务数据：查询生产环境的数据库、获取今日的 CRM 销售数据。
  • 调用第三方SaaS API：发 Slack 消息、创建 Jira Ticket、操作 Notion 页面。
  • 跨平台身份认证：需要 OAuth 流程，访问 Google Drive 或 GitHub Private Repo。
  • 做一个公共服务：让你的工具能被 Cursor、Claude、或者其他任何支持 MCP 的客户端使用。

六、1+1>2：Skill 和 MCP 的"双螺旋"协作

真正的高手，从来不做选择题。未来的 Agent 架构一定是两者结合的 。

案例：自动化运维故障处理

  1. 触发：用户说"线上服务器CPU爆了，帮我看看怎么回事"。
  2. 路由 ：主Agent判断这是一个"故障排查"任务，加载 「故障排查Skill」。
  3. 规范（Skill层） ：故障排查.SKILL.md 里规定了流程：
    • 第一步：通过 MCP 调用监控系统，拉取过去10分钟的CPU/内存指标。
    • 第二步：通过 MCP 查询日志系统，检索 ERROR 关键字。
    • 第三步：如果发现是慢查询，调用数据库 MCP 查看连接数。
    • 第四步：整理成固定格式的报告（包含指标图、日志摘要、解决建议）。
  4. 执行（MCP层）：AI严格按照 Skill 的步骤，依次调用对应的 MCP 工具获取数据。
  5. 输出：得到一份结构完美、数据实时、符合SOP的故障报告。

这就是「Skill 定流程，MCP 供弹药」的最佳实践。

七、结论：越多≠越好，精准才是王道

回到标题的问题：Skill 和 MCP 越多，效率就越高吗？

答案是否定的。

  • MCP 越多 ：上下文被疯狂挤占，AI 选错工具的概率飙升，响应变慢，Token 消耗爆炸。你需要在 ~/.mcp.json 里做减法，只保留最核心的3-5个通用服务 。
  • Skill 越多：虽然 Skill 是渐进式加载，但如果你的 Skill 命名混乱、描述不清，AI 在"元数据列表"里找错 Skill 的概率也会增加。

未来的竞争，不是你"拥有"多少工具，而是你"定义"多少流程。

建议你从现在开始：

  1. 审视你的MCP清单：这个能力，本地脚本能替代吗？如果能，果断换成 Skill。
  2. 构建你的Skill库 ：把你和团队重复做的事（代码审查、周报生成、项目初始化）写成 SKILL.md，这是你沉淀的数字资产 。
  3. 记住这个公式 ：AI Agent 的智商 = 核心模型的推理能力 × （MCP 的工具广度 + Skill 的流程深度）

当别人还在纠结"用哪个"的时候，你已经学会了"怎么配合"。这才是 AI 工程化的精髓。

八、推荐几个好用的MCP与Skill

8.1 MCP推荐

① context7（MCP） - 文档检索器

痛点：AI训练数据滞后，问最新技术容易胡说

解决：实时检索官方文档，让AI基于事实回答

8.2 Skill推荐

② plan-with-files（Skill） - 让AI长记性

痛点：AI没记忆，复杂任务做一半中断就失忆

解决：自动创建PLAN.md，每一步都记录，中断后恢复

③ Using-Git-WorkTrees（Skill） - 并行开发

痛点：改一半代码，突然要切分支修bug，手忙脚乱

解决：用git worktree创建多个独立工作区，互不干扰

示例：

markdown 复制代码 
用户：我要同时改登录和支付两个功能
AI：创建两个独立工作区：
  ../project-login (分支: login-feature)
  ../project-payment (分支: payment-feature)
  
用户：我去修个紧急bug
AI：创建hotfix工作区：../project-hotfix

8.3 让AI主动调用Skill

Agent不调用Skill？三种解法：

方案一：项目级指令（最有效）

项目根目录创建 .claude.md：

markdown 复制代码 
# Skill使用规则
- 复杂任务必须用plan-with-files（重构/方案设计）
- 新技术问题优先用context7（查文档）
- 分支切换用git-worktree（并行开发）
方案二：显式激活

对话开头说一句：

csharp 复制代码 
接下来重构，请激活plan-with-files Skill
相关推荐
谭光志12 小时前
工具塞满上下文窗口怎么办？深度拆解 AI Agent Tool Search 按需加载实现原理
前端·后端·ai编程
她说..13 小时前
Java 默认值设置方式
java·开发语言·后端·springboot
foggyprojects13 小时前
从0开始，一句话启动AI DataAgent
后端·数据分析·ai编程
郡杰13 小时前
一些基础和问题解决
后端
陈随易13 小时前
前端项目部署只要30秒
前端·后端·程序员
YIAN13 小时前
从零手写文件读取 MCP 服务：一文吃透 Model Context Protocol 全链路通信原理
前端·后端·mcp
Imchendiana13 小时前
《狂人日记NO.9》— 前后端一把梭，我的全栈实录
前端·后端
学渣超13 小时前
记一次分布式事务数据不一致的排查之旅：从超时到索引，层层剥茧
java·后端·架构
北冥you鱼14 小时前
Go 语言读取链上数据：从基础到实战
开发语言·后端·golang
程序员cxuan14 小时前
Claude Code 为了封禁中国用户，竟然在代码里下毒
人工智能·后端·程序员
热门推荐
01GitHub 镜像站点022026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf03AI科技热点日报 | 2026年07月01日04【AI】2026 年具身智能模型和世界模型总结052026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？062026 年 AI 大模型 & AI 编程工具实战全总结072026 AI 编程工具选型横评：Cursor / Claude Code / Trae / Copilot 到底选谁（建议收藏·避坑版）08Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费092026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？102026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？