咱们从这两项技术出现的背景以及解决了什么问题出发看问题
正文
MCP
解释一下：LLM(大语言模型)只能对文字进行分析和思考得出结论，至于说想处理外部事物，比如查询天气、操作文件，LLM是做不到的，所以由LLM通过Function Calling来决定调用哪个工具，但是AI应用那么多，每个都有自己调用Function Calling的方式方法，这对于社区发展来说是非常不利的，所以就有了MCP这个开源标准。本质上就是你写了一个工具函数，然后按照MCP这套标准化的接口协议进行接入，没了。所以MCP只是协议，本身不具备能力。
如果想上手学习MCP，推荐百度地图的MCP，结构清晰明了，咱们就拿这个进行说明
对，没错，就这么简单，配置一下，然后实现你的工具函数，然后发布到npm上，完事了
所以MCP解决的是什么问题：统一了AI应用调用第三方工具的标准协议。注意，是AI应用，而不是大模型，这个涉及到AI应用，也就是Agent的原理和构成，这个等下次聊Agent的时候再详细说明。
Skills
可以看到，Skills是结合了专业知识的工作流，是为了工程化而出现的东西。这时候我不得不又得掏出《前端架构设计》里的那句名言了：
前端架构是一系列工具和流程的集合，旨在提升前端代码的质量，并实现高效、可持续的工作流。
前端架构是工程架构的一个缩影，核心点是工作流的搭建。所以Skills就是在搭建项目的工作流。
说到这里，可能有人会联想到SubAgent，SubAgent不也可以处理一系列事物。
我觉得没毛病，其实我认为Skills和SubAgent都是Context Engineering的实现方案，这里简单介绍一下Context Engineering：
Context Engineering是通过设计输入信息来优化LLM性能的一项技术，具体可分成四种方式：
- 缓存Context
- 选择Context
- 压缩Context
- 隔离Context
我们都知道Skills是渐进式披露的，也就是如果LLM识别到了需要某个Skills的时候才会将Skills的全量内容加载到上下文中，所以Skills是属于“选择Context”这个优化策略的。
而我们都知道SubAgent的上下文是跟MainAgent隔离的，是属于“隔离Context”。所以应用场景取决于是否需要隔离上下文以及跟主线上下文的耦合性高不高。
skills.sh是Skills的插件市场，里面有很多skill，但我的建议是，可以参考借鉴。项目中的skill最好还是根据自身项目规范进行定制，定制的方法也很简单，让IDE帮你生成skill，把你的要求告诉IDE，IDE会根据项目的上下文出一份贴合你项目的skill，然后你再实践中进行微调
总结
- 背景不同：MCP是为了标准化AI应用与工具函数的协议，Skills是为了标准化工作流
- 实现不同：MCP必须代码实现，Skills可以纯文本实现，也支持引入脚本
了解技术出现的原因，就知道它们的区别了
