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

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 请求长这样：

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

响应也很简洁：

{
  "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 文件。

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

weekly-report-skill/
├── SKILL.md                 # 核心指令
├── scripts/
│   ├── git_commits.py       # 从git拉取本周提交
│   └── format_markdown.py   # 格式化输出
└── templates/
    └── report_template.md   # 周报模板

2.1.2 SKILL.md 内容

---
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 询问用户补充信息

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

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

3. 生成周报

3.1 加载模板

读取 templates/report_template.md

3.2 填充内容

按照模板结构填充：

本周进展：从git记录提炼，每条不超过20字
技术分享：使用用户提供的补充信息
下周计划：使用用户提供的下周计划
思考与沉淀：如果有难点，写在这里

3.3 格式规范

使用二级标题（##）分隔主要章节
列表项使用短横线（-）
代码块标注语言

4. 输出与确认

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

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

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

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

Skill越来越“能干”：以前我们觉得AI必须通过API（MCP）才能干活。但现在，借助 Skill 里的 脚本执行，很多以前需要调API的事，现在写个Python脚本本地就跑了。比如处理PDF、批量重命名、代码分析，完全不需要MCP。
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 架构一定是两者结合的。

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

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

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

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

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

答案是否定的。

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

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

建议你从现在开始：

审视你的MCP清单：这个能力，本地脚本能替代吗？如果能，果断换成 Skill。
构建你的Skill库：把你和团队重复做的事（代码审查、周报生成、项目初始化）写成 SKILL.md，这是你沉淀的数字资产。
记住这个公式：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创建多个独立工作区，互不干扰

示例：

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

8.3 让AI主动调用Skill

Agent不调用Skill？三种解法：

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

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

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

方案二：显式激活

对话开头说一句：

接下来重构，请激活plan-with-files Skill