Skills CLI vs MCP：2026年AI Agent 能力扩展的两条路线对比
约 14 分钟4186 字1 次阅读
Skills CLI vs MCP：2026年AI Agent 能力扩展的两条路线对比
引言
2026年，AI Agent 的军备竞赛已经从"模型本身"蔓延到了"工具链生态"。
两条路线逐渐清晰：
- Skills CLI 路线（以 Vercel
skills.sh为代表）——像给 AI 装"技能包" - MCP 路线（以 Anthropic Model Context Protocol 为代表）——像给 AI 装"USB接口"
它们看起来都在解决"让 AI 做事"的问题，但底层逻辑完全不同。本文深入解析两条路线的本质、差异、关系，以及如何组合使用。
一、它们各自是什么？
1.1 Skills CLI —— AI 技能的包管理器
Skills CLI（以 Vercel 开源的 skills.sh 为代表）是一个跨 Agent 的技能包管理工具。你可以把它理解为"AI 时代的 App Store 安装器"。
它的核心命令：
# 安装一个技能包
npx skills add <owner/repo>
# 安装指定技能
npx skills add owner/repo --skill frontend-design
# 安装到指定 Agent
npx skills add owner/repo -a claude-code -a opencode
# 列出可用技能
npx skills add owner/repo --list
# 全局安装
npx skills add owner/repo -g
Skills 的本质是：把某个领域的专业知识、prompt 模板、工作流规范，打包成一个可分发的"技能单元"。当 AI 加载这个 Skill 时，它不是在调用一个 API，而是在获得一套做某类事的"思维框架"和"操作指南"。
比如 ui-ux-pro-max 这个 Skill，包含了：
- UI/UX 设计的专业原则
- 配色方案的选取规则
- 组件库的选用建议
- 响应式布局的规范
当 AI 需要设计界面时，它不是查一下文档，而是按照这个 Skill 的专业框架来思考和行动。
1.2 MCP —— AI 与外部世界的连接协议
MCP（Model Context Protocol）由 Anthropic 于 2024 年末开源，是让 AI 与外部工具交互的标准协议。
你可以把它理解为"AI 的 USB 接口标准"——有了 MCP，任何 AI 都能调用任何外部工具，就像任何电脑都能用任何 USB 设备一样。
MCP 的三大核心原语：
| 原语 | 作用 |
|---|---|
| Tools | AI 可以调用的外部函数 |
| Resources | AI 可以读取的外部数据 |
| Prompts | 可复用的提示词模板 |
MCP 的本质是：定义 AI 与外部世界交互的接口规范。一个 MCP Server 就是一个工具的接口描述，AI 通过它调用真实世界的功能。
比如一个 Slack MCP Server，定义了：
send_message(to, content)方法- 输入输出格式
- 权限范围
AI 调用时，就是一个结构化的 API 调用，结果明确。
二、核心区别：不在同一个层次
这是理解两者关系最关键的地方：它们根本不是竞争关系，而是互补关系，在不同层次解决问题。
2.1 一个精妙的比喻
Reddit 用户 @d8d8d53c951e4861 的这个比喻非常准确：
MCP = 方向盘、踏板、仪表盘 Skills = 驾驶指南（"走101号公路，在第3个出口下匝道，左侧停车"）
MCP 解决的是"AI 能用什么工具"的问题——它提供了接口和连接能力。
Skills 解决的是"AI 怎么用好这些工具"的问题——它提供了使用策略和专业判断。
2.2 详细对比
| 维度 | Skills CLI | MCP |
|---|---|---|
| 定位 | 技能包 / 知识封装 | 接口协议 / 连接标准 |
| 作用层次 | 指令层（how to do） | 接口层（what to call） |
| 核心价值 | 专业判断和使用策略 | 工具发现和调用能力 |
| 内容形式 | prompt模板+规则+知识库 | API定义+数据结构 |
| 调用方式 | 自然语言理解后执行 | 明确的函数调用 |
| 可移植性 | 跨 Agent 复用 | 跨工具复用 |
| Token 消耗 | 取决于 Skill 大小 | 取决于 MCP Server 描述数量 |
| 执行确定性 | 依赖 LLM 理解，可能失败 | 确定性 API 调用 |
| 典型代表 | skills.sh / Vercel Skills | AWS MCP Servers / Anthropic MCP |
2.3 执行流程上的差异
MCP 调用流程：
用户需求 → AI 理解意图 → 选择 MCP Tool → 执行 API 调用 → 返回结果
这是确定性执行——一旦选择调用，工具行为完全可预测。
Skill 执行流程：
用户需求 → AI 理解意图 → 激活 Skill → AI 按 Skill 规则推理 → 可能调用多个 MCP Tools → 返回结果
这是引导式执行——Skill 提供推理框架，具体执行依赖 AI 对指令的理解。
三、为什么2026年 Skills 突然爆发？
3.1 MCP 的"上下文税"问题
MCP 很好，但它有一个显著缺点：当 MCP Server 太多时，上下文窗口会被大量消耗。
一个真实的场景：
某团队接入了 15 个 MCP Servers（S3、DynamoDB、Slack、GitHub、Notion、Salesforce……），每个 Server 的描述有 2000-3000 tokens，加起来就是 50,000+ tokens 的上下文开销——这在对话开始之前就消耗了，而且不管当前任务用不用得到，所有描述都在。
3.2 Skills 的解决思路
Skills 允许你只在当前任务相关时加载对应的技能。
一个 Skill 包含了什么情况下用什么工具、怎么用的策略。AI 不需要事先知道所有 MCP Server 的描述，而是在激活 Skill 后，按 Skill 的指引在需要时调用对应的 MCP。
这就解决了**"按需加载"的问题**——不是把 50 个工具描述全部塞进上下文，而是只在需要时加载相关的 1-2 个 Skill。
3.3 两者的组合效果
最好的架构是MCP + Skills 组合：
MCP Servers（工具层）：S3、Slack、GitHub、Notion...
Skills（策略层）：
- ui-ux-pro-max → 设计 UI 时使用 S3 + Figma MCP
- code-review-skill → 评审代码时使用 GitHub MCP
- data-analysis-skill → 分析数据时使用 S3 + BigQuery MCP
AI 在不同场景下激活不同的 Skill，Skill 再按需调用对应的 MCP——MCP 提供能力，Skills 决定什么时候用什么能力。
四、主流 Skills CLI 生态
4.1 Vercel Skills（skills.sh）
https://skills.sh 是目前最完整的跨 Agent Skills 市场。
核心特点：
- 支持 41+ 个 Agent 平台（Claude Code、OpenCode、Cursor、CoPilot 等）
npx skills add一键安装- 支持按 Agent 选择安装
- 社区驱动，持续有新 Skills 上架
代表 Skills：
ui-ux-pro-max— 专业 UI/UX 设计remotion-best-practices— React 视频生成frontend-design— 前端设计规范skill-creator— 教你创建新 Skill
4.2 OpenClaw 内置 Skills
OpenClaw 有自己独立的 Skills 系统，与 Vercel Skills 不完全兼容但定位相似：
- 60+ 内置 Skills，覆盖飞书、日历、设备控制、笔记等
- clawhub.ai 作为官方 Skills 市场
- skill-creator Skill 帮助用户创建自定义 Skills
4.3 Claude Skills（Anthropic 官方）
Anthropic 在 2025 年推出了 Claude Skills，并在年底将其开源为开放标准：
- 定位与 Vercel Skills 相似，但主要面向 Claude 生态
- 与 MCP 深度集成
- 企业级管理能力（Team/Enterprise 计划）
五、MCP 生态现状
5.1 MCP 的采用程度
截至 2026 年，MCP 已成为 AI 连接外部工具的事实上标准：
| 厂商 | MCP 支持 |
|---|---|
| AWS | 3000+ MCP Servers（S3、DynamoDB、CloudWatch 等） |
| Vertex AI Agent Builder 全面支持 | |
| Microsoft | Azure AI Agents 服务支持 |
| Anthropic | Claude 原生支持 |
| OpenAI | Agents SDK 支持 |
5.2 MCP 的局限性
MCP 并不是银弹，它有一些固有限制：
- Schema 驱动：每个 MCP Tool 的输入输出都需要明确定义，灵活性受限
- 无状态：MCP 协议本身不管理状态，多轮对话中需要外部状态管理
- 错误处理复杂：不同 MCP Server 的错误格式不统一
- 版本碎片化：各厂商的 MCP Server 实现质量参差不齐
六、实战：如何同时使用两者
6.1 场景：做一个 AI 播客制作助手
目标：让 AI 帮你完成播客制作全流程——写稿、录音、转写、发布。
MCP 层（工具能力）：
openai-whisperMCP — 语音转文字spotify-playerMCP — 播放参考音频feishu-im-readMCP — 读取飞书消息中的素材githubMCP — 存储项目文件
Skills 层（策略引导）：
podcast-script-skill— 播客脚本写作框架audio-editing-skill— 音频剪辑规范content-review-skill— 内容审核标准
协作流程：
用户：帮我制作一期关于AI Skills的播客
AI 激活 podcast-script-skill
→ 按 Skill 框架生成脚本结构
→ 调用 whisper MCP 转写录音
→ 调用 spotify-player MCP 播放背景音乐
→ 调用 feishu MCP 通知团队审核
→ 调用 github MCP 存储最终文件
6.2 常见错误：以为 Skills 能替代 MCP
很多人以为"我装了 Skill，就不需要 MCP 了"——这是错误的。
Skill 和 MCP 的关系是"指挥"和"执行"的关系：
- Skill 告诉你"什么时候、用什么、怎么做"
- MCP 负责"真正去执行"
没有 MCP，Skill 只能"纸上谈兵"；没有 Skill，MCP 只能"机械执行"。
七、两条路线的发展预测
7.1 短期（2026-2027）
MCP 继续扩张：
- 更多的 MCP Servers 出现（各垂直领域）
- MCP 协议本身可能分裂出多个方言版本
- 大厂开始推自己的"MCP Store"
Skills 生态爆发：
- skills.sh 类市场百花齐放
- 行业垂直 Skills 大量出现（法律、医疗、金融、制造）
- Skills 和 MCP 的边界逐渐模糊——好的 Skill 内置 MCP 集成
7.2 长期（2027+）
最终会出现一个融合：
- Skills 本身就是 MCP Servers 的智能包装器
- Skill 描述包含 MCP Server 的引用，激活时自动加载对应 MCP
- AI Agent 在运行时动态组装"技能+工具"的最优组合
这意味着：未来没有"选 Skills 还是选 MCP"的问题，只有"如何组合"的问题。
八、选型指南
8.1 什么时候优先用 MCP？
- 需要确定性执行的操作（如转账、数据写入）
- 工具调用频率高、逻辑简单的场景
- 需要完整的权限控制和审计（企业级需求）
- 与现有系统深度集成（如 Salesforce、Workday）
8.2 什么时候优先用 Skills？
- 需要专业判断和策略的任务（如代码评审、UI 设计）
- 多工具协作的复杂工作流
- 需要领域专业知识加持的场景
- 团队经验沉淀和复用（把最佳实践编码成 Skill）
8.3 什么时候组合使用？
大多数生产环境都建议组合使用：
- 日常办公场景：Skills（策略）+ MCP（执行）
- 企业自动化：Skills（流程）+ MCP（系统集成）
- 开发工作流：Skills（编码规范）+ MCP（代码仓库）
总结
MCP 和 Skills 不是对手，是搭档。
- MCP = 工具的接口标准（让 AI 能调用外部能力）
- Skills = 能力的编排策略（让 AI 知道什么时候用什么能力）
理解两者层次上的差异，就明白了为什么 2026 年 AI Agent 生态会同时在这两条线上爆发：单靠任何一条，都无法构建真正强大的 AI Agent。
最佳实践： 用 MCP 构建工具层，用 Skills 构建策略层，让 AI 在正确的时间调用正确的工具，完成正确的工作。
参考资料：LlamaIndex 博客、Reddit r/ClaudeCode 讨论、GitHub vercel-labs/skills、LushBinary 技术博客、Heyuan110 AI 指南
标签：#Skills #MCP #AIAgent #OpenCode #ClaudeCode #Vercel #skills.sh #技术对比