综合来看，只有在【连接外部服务】时才让 MCP 有那么一点点优势。其他的方方面面，skills 会做的更好。
⚠️
本文的完整版全文原文地址：https://www.ccgxk.com/codeother/627.html
新手要学，肯定更优先推荐学习 skills ！暂时可以先忘掉 MCP。
额.... 另外，2026年了还在手写大段 prompt 甚至 坚持「初心」、古法编程的兄弟们，真的该醒醒了。
两者的本质
MCP 和 skills 这两个，其实本质上不太一样。skills 会更原始一点，大多数情况下，你用不完它的功能，它解决的问题更精钻一点。MCP 则更简洁。虽然都是 markdown 吧，自然语言写工作流、AI执行工作流....
或者说，MCP 是个 USB，skills 是一个 APP（@宝玉 给出的定义）
skills 的初衷一般是一个特定的领域，给特定人使用的，或者说自己用的，优化一下自己的工作流程，而 MCP 的初衷则类似于开源，给全世界人一个简单的 url 接口，让全世界人都能用我的服务！
换言之，这两个 工具 的发明需求是不一样的，skills 的颗粒度更细一点，且设计理念更先进。
MCP 怎么来的
就好像是2010+ 这个年代很流行的多头充电器，大家对它们还有印象吗？
在 MCP 出现（2024.11）之前，AI 大模型读取其他应用，是需要各自写一套对接代码的。查谷歌、操纵 wordpress、查 github、增删查改数据表、发邮件..... 每个都要写一套。
单看好像也不是很复杂，但一个应用是有多层的，多层叠加，复杂度就是成倍增加，当时，开发个初级智能体非常复杂，人人都在重复造轮子。
然后致力于砸破全世界人饭碗的 Anthropic 就发起开源了 MCP 协议。从此，在大模型界，type-c 一统江湖。所有 AI 都可以像 USB 一样即插即用和任何 工具 链接了~ 开发成本断崖级下降。
但是，MCP 并不是很完美的，当它连接到 AI 时，会一次性将 MCP 的所有工具名称、描述、参数、示例一次性塞进上下文里，一下子几个 k 甚至几十个 k 的token 就被燃烧了~
这就是 MCP 的副作用，很烧 TOKEN！
比如下面的这些 MCP（正常体积大小）。
mcp-omnisearch 一下子烧掉 14k 个 token。
GitHub MCP Server 一下子烧掉 18k 个 token。
Playwright MCP Server 一下子烧掉 13k 个 token。
要知道 claude opus 4.5 的读取价格 3 美元/ 100k ，这仅仅一加载就 2 人民币没了。
当然，我们的真实 AI 应用里面一般还搭配好几个 MCP，所以你应该能明白 MCP 烧钱有多夸张。
还不只是烧钱，你还要知道 大模型 处理数据时，数据量越大，错误率也会越大，如果你里面有多个 MCP ，那么里面的很多细节就会被 大模型搞混淆。
解决 MCP 的劣势和 skills
So，这个问题亟需解决。俩月后的 2025.1 ，Anthropic 又推出了 Tool Search 。
这个 Tool Search 实现了【按需加载 MCP 工具】、【需要某工具，先搜索再加载】。根据统计数据，能减少项目里 80% 的 token。
但 Tool Search 并没有在根本上解决这个问题（并非真正意义上按需加载）。只是委婉的加载了全文而已。实际上我们真正的项目用不到那么多 MCP 工具。于是 SKills 来了，实现了真正的按需加载。
简单的比喻：MCP 的做法是把全文全塞给你。skill 的做法是，只给你一个目录和简短说明。
这个 skills 在启动时，加载名称和简短描述，这个体积占比会小很多。
之后，当 AI 执行任务时，发现某任务需要某个 skill 时，此时才读取完整的 skill.md。
这个按需读取，不仅包括更详细的 提示词指令 prompt，也包含 API 文档、技术周边知识、示例代码等等。一环套一环，理论上可以有无限的内容（这些内容只要我们的任务不需要，就永远用不上）。
（Agent Skills 是个被低估的功能。很多人还停留在“和 AI 聊天”的阶段，没意识到可以把自己的工作流程、领域知识“教”给它，让它变成真正懂你业务的助手）
这还没完，在 skills 里，它还可以自带 py bash JavaScript 脚本等内容（放在 scripts）！这个脚本可不是当做文档去使用的，它不会被写入上下文，而是会直接执行。是的，直接执行！这样，如果你提前写好了一大堆脚本，放入 skill 里，那么 AI 就无需自己调用算力为你实时生成代码了！超级省 token，结果也确定，成功享受「知识」的复利。
换言之，这就是一个 APP 了，里面东西都是现成的！
这个 Skills 是 AI 时代面向 LLM 的“代码库”（类似 npm 或 pip Library，只不过由 markdown 完成，交付给 LLM 而不是 node runtime）——它拥有“知道边界”的能力，是被拆解成可以被设计、被组合、被替换的单元；即便填充越来越多的能力，但行为仍旧在可预测之内。
审视两者，如何抉择
好好好，现在我们重新审视这两者，然后对比一下！
MCP 的优点：接入简单（URL 就可以）、支持网络访问、服务来源于外部。
MCP 的缺点：烧 token、对小体积要求高
Skill 的优点：更专业、能无限大、可内置脚本
Skill 的缺点：无法通过网络访问（只能下载到本地）
那两者的应用场景呢？MCP 是可以通过 Url 访问的，因此更适合作为「超级 API」，而 skills 则可以视为一个独立的 APP，下载下来就能直接给你办事，领域专家嘛，适合作为团队、内部流程优化、超级工具。
Skills 描述工作流程，MCP 提供执行引擎。但很多时候，操作系统自带的引擎就够用了。
一个对外（mcp），一个对内（skill），你使用的 skills 里面可能 99% 的项目你都从没用过，所以 skills 对特定领域很有用。而 MCP 则是一个对外提供的服务。
相对而言，skills 的实用程度会更高。
其实，我们并不需要很多 MCP，未来我们只需要几个通用 MCP Server 处理远程连接（数据库、云 API、SaaS 集成）就够了。而 skills 与我们的工作流绑定会更密切，会更实用。
比如 @宝玉 老师的这张图，就写的很好！
一般如果没有特别说明，需要给外部人员使用，那 Skills 就 OK ，如果需要留接口给外面，则要考虑 MCP 。
mcp 的最优先考虑优势，只有【方便外部链接】。
