我还清晰记得上半年大家对MCP（模型上下文协议）的狂热，几乎逢人便会与我讨论这个话题。然而从实际应用层面来看，情况似乎并非如此。社区中流传着这样一句话：MCP是一项开发者数量远超使用者的功能。那么，MCP真的是本世纪最大的技术泡沫吗？
如果你是一名AI工具的终端用户（而非开发者），本文或许能提供一个全新的视角：为何MCP声量如此之大，实际使用体验却常感"鸡肋"？或许Skills（技能）才是你真正需要的解决方案。
一、MCP：开发者的盛宴，用户的迷思
MCP（模型上下文协议）于2024年底由Anthropic正式推出，被誉为AI领域的"USB-C"接口——旨在通过标准化协议实现AI与各类外部工具的无缝对接。
愿景固然美好，但现实却是社区中充斥着对MCP的戏谑，甚至有人称之为"最大技术骗局"。
[MCP可能是唯一开发者数量超过用户的技术]
[开发者为何集体吐槽MCP协议？]
这背后折射出怎样的现状？
大量开发者投入MCP技术研究，但真正可供终端用户使用的成熟工具却凤毛麟角。
SDK月下载量突破9700万次，注册中心增长率高达407%——这些数据无不彰显开发者的高涨热情。然而当普通用户打开Claude或Cursor平台，试图寻找实用的MCP工具时，结果往往令人失望。
这种现象并非MCP技术本身的缺陷，而是由其底层设计逻辑所决定的必然结果。
二、协议的「基因」决定了谁受益
为何 MCP 对终端用户不够友好？答案或许就隐藏在协议的设计基因之中。
我们不妨对比 MCP 与 Skills（Agent Skills）两种协议的技术规范：
| 维度 | MCP | Skills |
|---|---|---|
| 协议规范对象 | 开发者如何编写工具 | AI 如何运用能力 |
| 规范内容侧重 | API 接口、数据结构、SDK 集成 | Markdown 描述、指令说明 |
| 开发者入门门槛 | 需掌握 JSON Schema 与 SDK 使用 | 只需会编写 Markdown 文档 |
MCP 协议的核心是规范「开发者如何编写工具」——包括 API 接口定义、数据传递结构、SDK 集成方式等。这些技术细节对开发者至关重要，却与普通用户的实际需求相距甚远。
Skills 协议则着重规定「AI 如何运用能力」——涉及能力加载时机、指令解析逻辑、任务执行流程等，这些要素直接决定了终端用户的使用体验。
即便对开发者而言，Skills 的入门门槛也显著低于 MCP。部分简易 Skills 甚至支持用户在使用过程中无缝切换为开发者角色，实现边使用边优化的流畅体验。
核心差异在于：MCP 以开发者为导向，着力优化开发体验，却在智能体如何运用这些工具层面缺乏明确指引；Skills 以使用者为中心，注重优化使用体验（包括成本控制），并为智能体运用工具提供了详尽的操作指导。
协议的设计初衷，已然决定了其真正的受益群体。
三、Skills 的制胜法宝：渐进式披露
除了设计目标存在差异，Skills 还具备一项技术优势：渐进式披露（Progressive Disclosure）。
如何理解这一概念？我们可以通过一个形象的比喻来说明：在图书馆查找资料。
MCP 的做法：图书管理员将整个书架的书一次性全部搬到你的面前。结果往往是：信息过载，难以抓住重点 📚📚📚
Skill 的做法：管理员首先递给你一份目录，你指明需要哪一本，他再为你取来。结果是：精准高效 📋→📖
人工智能的“脑容量”是有限的（受限于上下文窗口）。
- 传统方式：在启动时一次性加载所有工具的定义。假设有 100 个工具，可能会占用数十万的 tokens。
- Skill 方式：启动时仅加载工具的元数据（名称和描述，每个 Skill 约 100 tokens）。当需要某个特定工具时，才加载其详细的指令。
- 元数据层：每个 Skill 约 100 tokens
- 完整指令：建议控制在 5000 tokens 以内
这意味着什么？对于 100 个 Skills，启动时仅需约 10,000 tokens 的元数据开销，而非一次性塞入数十万 tokens 的完整信息。
这带来的好处是：
- AI 不会被无关信息干扰，决策更智能
- 系统响应速度更快
- 能够支持集成更多的工具
四、两者并非竞争，而是互补
阐述了 Skills 的诸多优点，是否意味着 MCP 就失去了价值？并非如此。
MCP 和 Skills 旨在解决不同层面的问题：
- MCP = 工具箱：定义了“能够连接什么”——例如数据库、API、文件系统、第三方服务。
- Skills = 使用手册：定义了“如何智能地使用这些工具”——包括工作流程、最佳实践以及按需加载机制。
两者甚至可以结合使用：
利用 Skills 的渐进式披露机制来高效管理 MCP 提供的工具。
简而言之，MCP 负责“连接能力”，Skills 负责“运用智慧”。将两者结合，往往能形成更优的解决方案。
五、给用户的建议
- 避免盲目追随 MCP 的热潮。虽然超过 22000 个仓库数量可观，但真正能投入实际应用的又有多少呢？
- 密切关注 Skills 生态的发展。如果你正在使用 Claude Code 等工具（近期 Kwaipilot 也将提供支持），Skills 或许能比 MCP 更直接地提升你的使用体验。
- 两者兼顾，长远布局。从长期来看，MCP 与 Skills 的组合可能是一个明智的选择。MCP 负责提供连接能力，而 Skills 则贡献使用智慧。
- 展望 2026 年：渐进式信息揭示与动态上下文管理必将成为 AI 工具的标准配置。近期我的一个实践案例——基于 20 万字的规格说明书，让智能体实现一个 10 人日的需求——正是通过逐步披露规格细节来实现的。Cursor 对此已有精辟阐述。
结语
MCP 是场巨大的骗局吗？并非如此。它同样是一个出色的开发者协议。
Skills 是救世主吗？对于终端用户而言，现阶段或许确实如此。
协议的设计初衷，决定了最终的受益者。 MCP 旨在降低开发者构建工具的门槛，而 Skills 则致力于提升用户使用工具的便捷性。
如果你是一名用户，不必再困扰于 MCP 为何“不够好用”。不妨将目光转向 Skills。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
