不想再折腾 MCP 了?试试用Skills
通过自然语言在几分钟内创建出原本需要通过 MCP(Model Context Protocol)实现的工具——比如一个数据库连接或是一个网络搜索功能——这种“轻量级”的体验,让我不禁发问:在很多场景下,我们真的还需要那个“过重”的 MCP 吗?
最近,我在使用 Claude Code 开发的过程中,几次不经意的尝试,引发了我对 AI Agent 能力扩展范式的一些新思考。通过自然语言在几分钟内创建出原本需要通过 MCP(Model Context Protocol)实现的工具——比如一个数据库连接或是一个网络搜索功能——这种“轻量级”的体验,让我不禁发问:在很多场景下,我们真的还需要那个“过重”的 MCP 吗?
一个“意外”的发现:两分钟创建一个数据库Skill
近期在一个开发项目中,我需要让 AI 读取本地 MySQL 数据库的数据来辅助调试。按照传统思路,这通常需要配置一个 MCP 服务器来暴露数据库接口。但当时我灵机一动,随口对 Claude Code 说:“帮我创建一个连接本地 MySQL 数据库的 skill”。
结果令人惊喜:不到两分钟,AI 就生成了一个可用的 Python 脚本和相应的 Skill 配置文件。 我几乎没写一行代码,也没用任何调试工具,重启会话后,这个新的数据库 Skill 就可以直接使用了。后来,我又用类似的方式,快速创建了一个基于 Kimi 的网络搜索 Skill (kimi的搜索比较特殊,搜索结果返回密文,还需要调用kimi大模型进行解读,我给了大模型kimi的官方文档让claude code给我实现),还实现了一个获取当前时间的 Skill。
这三次成功的实践,让我深刻感受到了 Skill 这种新范式的力量:极致的简洁、敏捷和易用性。这也促使我对过去一年里 AI Agent 领域的主流集成方案——MCP,进行了重新的审视。
两种范式:重工业的MCP vs. 手工作坊的Skill
为了理解 Skill 带来的变革,我们有必要先回顾一下 MCP 的发展和其技术本质。
MCP:AI世界的“USB-C”标准
MCP,由 Anthropic 在2024年底提出,旨在成为 AI 与外部世界连接的“万能接口”。它的核心是一种客户端-服务器(Client-Server)架构,通过一个标准化的中间层,解耦了 AI 模型与千差万别的外部工具。在2025年,它获得了几乎所有主流大模型厂商的支持,迅速成为事实上的行业标准。
然而,正如大家的感受,MCP 也是“过重”的。对于简单的任务,比如连接本地数据库,你需要启动和维护一个独立的服务器进程,这带来了额外的资源消耗和通信开销,显得“不太环保,也不太低碳”。此外,它的配置门槛对非专业开发者也相对较高。
Skill:革命性的“渐进式披露”
与 MCP 的“重”形成鲜明对比的是 Skill 的“轻”。随 Claude Code 推出的 Skill,其技术核心是一种名为渐进式披露(Progressive Disclosure)的三层信息架构。当我查看 Skill 的 .md 文件时,我直观地理解了这一点:
- 元数据层(Metadata)
文件头部由
---分隔的 YAML 部分,只定义了名称和描述。AI 启动时仅加载这里,用极低的 Token 成本感知到“哦,有这样一个工具”。 - 核心指令层(Core Instructions)
当 AI 决定要用这个 Skill 时,才会加载这部分 Markdown 正文,里面包含了核心的调用方法和脚本路径。
- 参考资源层(Reference Materials)
用于存放更详细的文档或边缘案例,只有在 AI 遇到困难时才会去查阅。
我意识到,这种设计正是 Skill 如此高效的关键。它避免了将所有信息一股脑塞进上下文,实现了 Token 效率和功能深度的精妙平衡。更重要的是,它将工具的创建门槛降到了“说一句话”的程度,这是一种范式级的提升。
全方位对比:我的个人视角
基于我的实践经验和对两种技术的理解,我总结了下面这张对比表:
|
维度 |
Claude Skills (我的体感) |
MCP (传统方案) |
|---|---|---|
| 架构复杂度 |
极其简单:一个文件夹,几个文本文件 |
相对复杂:客户端-服务器架构 |
| 部署方式 |
无需部署,就是本地文件 |
需要启动和维护一个服务器进程 |
| 开发体验 | “对话式创建”
,自然语言驱动,几乎零门槛 |
需要专业开发知识,配置繁琐 |
| 资源消耗 |
极低,按需加载,非常“低碳” |
较高,服务器需持续运行 |
| 核心优势 |
易用性、敏捷性、零成本、高效率 |
标准化、生态系统、跨平台能力 |
| 适合场景 | 个人开发、快速原型、轻量级任务 |
企业级集成、复杂系统、多模型协同 |
我的结论:大部分MCP,都可能被Skill替代
经过这一系列的实践和思考,我得出了一个明确的结论:对于我们日常开发中的绝大部分工具调用场景,Skill 完全有潜力替代 MCP。
Skill 将原本需要系统集成才能实现的能力,用一种更自然、更轻量的方式融入了 AI Agent。它的出现,让“为AI添加新能力”这件事,从一项需要专业技能的“工程”,变成了一次可以随手完成的“对话”。
当然,这并不意味着 MCP 将被淘汰。在需要跨平台、跨模型、高度规范化的企业级应用中,MCP 的标准化优势依然不可替代。它将继续作为构建大型、复杂、健壮的 AI Agent 系统的“重工业”基石。
但对于像我这样的开发者而言,未来的工作流可能会是这样:优先使用 Skill 快速解决 80% 的日常问题,只有在遇到需要重度集成的 20% 场景时,才会考虑引入 MCP。
最终,我认为 Skill 和 MCP 将会长期共存,互为补充。一个走向“手工作坊”的极致灵活,一个走向“工业生产”的极致规范。
我是架构师刘7,专注AI和软件领域,如果您能读到这里,说明我们是同路人,诚邀您关注我,让我们一起走进AI时代。
更多推荐



所有评论(0)