（来源：机器之心）

引言：近期，Anthropic 新推出的 Claude Skills 在社区内收获了相对一致的好评，被不少开发者视为「终于能直接拿来用」的能力；几乎同一时间，MCP 协议的「一周年纪念日」却在一片「寂静」中度过。实际上从发布以来，MCP 的「builder 多于 user」、只是「旧瓶装新酒」的质疑始终存在，而在 Skills 和 MCP 叠加演进的当下，我们又该如何重新看待 MCP 的真实定位、适用边界，以及它在 infra 层面的潜在价值？

目录

01. builder 比 user 还多，MCP 仅是「旧瓶装新酒」？

一年过去，社区对于 MCP 的定位仍有争议？平均 25 个用户对应 1 个开发者，MCP 目前更多是开发者自娱自乐的产物？...

02. Not Skills vs MCP,  but Skills with MCP? 

「人如其名」，Skills 真是来 kill MCP 的？MCP 能做但 Skills 不能做的，现在也没什么用？...

03. 过去一年，围绕 MCP 的 infra 层格局逐渐清晰？

MCP 大规模落地还得看下一个「微信小程序」入口的出现？...

builder 比 user 还多，MCP 仅是「旧瓶装新酒」？

1、自 MCP 发布一年以来，业内关于其定位，适用场景和未来发展等一直存在争议。

2、有分析认为，在技术栈层面 MCP 不是「AI USB」、不是 Function Calling 升级版、也不是万能 Agent 框架，而是「client 和 server 之间的通信协议 + 统一工具访问方式」。[2-1]

① 社区内有用户认为，MCP 的最大价值是给没有工具执行环境的大模型补一层运行时，这本应是 AI 应用开发者本来就要实现的功能。[2-2]

3、枫清科技 Fabarta 合伙人、智能引擎事业部总经理谭宇也指出，从用户视角来看，MCP 包括协议、多语言 SDK 和生态三个方面，低延迟与高并发不在协议关注的范围内。[2-3]

4、而关于 MCP 存在意义的话题，支持者认为 MCP 是「大模型的 HTTP 时刻」，且目前的 AI 已经开始从视觉信息（deepseek-ocr）和动作信息（seed game tars）上学习，类似 MCP 的协议将是下一阶段（掌握工具）的基础能力。[2-4]

5、反对者则指出目前 MCP 在很多方面只是在用「旧瓶装新酒」的方式解决问题，它沿用了传统的服务注册和路由方法，仅在工具调用层面做了协议化，更「AI 化」的做法应该是将所有工具描述嵌入向量空间，通过向量检索找到最合适的工具，实现一步到位的匹配。[2-5]

① 也有观点认为 Function Calling 本身已经在一定程度上规范了模型对工具的调用方式，MCP 所做的只是将这一过程转换成显式协议，在当前互联网生态下更像一个过渡方案。[2-6]

6、此外，目前 MCP 生态中「builder 比 user 多」的现象也存在不少争议。今年 9 月中旬一名科技博主在 X 上发表了「MCP is probably the only piece of tech that has more builders than users」的言论，截至目前浏览量已超 28 万。[2-7]

① 评论区内有观点认为 MCP 目前更多是工程师自娱自乐的产物，处于早期基础设施探索的阶段；也有人指出这其实是早期 infra 的常见现象。

7、相关统计数据也显示，自 Anthropic 发布 MCP 以来社区已上线超过 6000 个 MCP 服务器，活跃开发者人数为 2000-3000，而实际使用这些服务的终端用户人数只有大约 50000 -75000，平均 25 个用户对应 1 个开发者。[2-8]

① 服务器中的关注度分布也不均匀，排名前 10 的 MCP 服务器吸引了近一半的用户关注，前 10%的服务器获得了 88%的星标。

8、有分析指出，目前除了少数面向开发者的 IDE（如 Cursor、Cline 等）支持 MCP，主流网页端 AI 应用并不直接提供 MCP 接入，普通用户难以感知或使用 MCP 接口。[2-9]

9、且目前 MCP 在实际使用中存在调用效率较低、资源消耗高和运行不够稳定等问题。在很多场景下，企业发现直接通过系统 API 访问比通过 MCP 协议调用更为便捷。因此，目前 MCP 生态更多停留在开发者技术实验和内部验证阶段，真正的用户场景较为有限。[2-10]

10、而对于目前 MCP 真正适用的业务场景，社区有用户认为 MCP 目前更适合于 B 端的「Data Open + 工具复用」类型。包括需要向第三方开放扩展的平台、需要跨多端复用同一套工具并进行版本管理以及内部工具链尚未标准化时使用 MCP SDK 来统一流程。[2-6][2-11]

① 例如，如果一个平台需要向第三方开发者开放扩展接口（如 Claude 桌面端的插件生态、微信开始支持 MCP 等），MCP 可以作为统一的接入协议。

② 如果需要在网页版、桌面端、移动端等多种终端环境中复用同一组工具，MCP 的版本管理和能力协商机制也会很有帮助。

③ 另外当一个组织内部没有自研的 Agent 标准时，直接采用 MCP SDK 作为统一规范也是一种选择。

11、但对于小型内部项目或一次性集成需求，使用 MCP 会增加不必要的复杂度；对于性能敏感的应用，MCP 协议层的抽象和基于 JSON-RPC 的通信格式也可能成为效率瓶颈。[2-11]

Not Skills vs MCP,  but Skills with MCP? 

1、今年 10 月 Anthropic 推出 Claude Skills 以来，社区内对于 Skills 和 MCP 的定位和分工问题也引发了部分业内人士的讨论。

2、有分析认为 Skills 更关注「如何做」，也就是更关注业务流程和策略层面，而 MCP 则回到具体「执行层」，主要负责调用后端工具。[2-12]

① 具体来说，Skills 相当于「带知识的可移植工具调用+子代理」，封装了领域知识和业务逻辑；而 MCP 则属于远程调用运行在服务器上的工具的机制。

② 有用户认为 Skills 更像是「更省 context 的 MCP，用来获取 how-to 指令」。事实上，许多 MCP Server 内部也会为工具编写说明性文档，类似 Skills 给出任务指令的作用。

3、在具体组织上，Skills 的结构非常朴素，一个 Skill 通常由 YAML 头部、Skills.md 文档和可选的资源文件组成。YAML 头部包含技能名称和简要描述（通常不超过 100 个 token），而主要说明和资源文件仅在实际调用该 Skill 时加载，从而有效节约 token。[2-13][2-14]

① 例如，可以为一个个人助手智能体创建多个 Skills，一个负责「会议管理」，用于获取邮件和日历信息以安排会议；另一个负责「会议准备」，用于收集过去会议记录、准备会议材料。而访问邮箱、日历、Notion 等外部系统的操作，仍然通过 MCP Server 来完成。

4、在 Skills 的定位问题上，有观点认为 Skills 发布的目的就是替代 MCP，因为当 MCP 能做到的事情 Skills 也能够实现时，开发者通常更倾向于使用更友好的 Skills；而 MCP 能实现的事情例如通过 API 实现动态更新功能，目前没有太大作用。[2-15]

① 具体来说，MCP 的创新之处在于把原本每个模型与每个工具需要做 M×N 次适配的问题，简化为只需模型和工具各自支持 MCP 后的 M+N 问题。但 MCP 的主要缺点是开发者需要编写大量代码来实现每个 MCP Server，增加了集成成本。

② 相比之下，Skills 允许开发者使用自然语言在 SKILL.md 中描述工具、资源和提示词，对开发者更友好。

③ 同时，Skills 可以在提示中直接给 LLM 提供业务流程指导和思路，而 MCP 本身只是被动暴露工具接口，无法主动控制 LLM 的思维方式。

5、此外也有一些用户从实用角度出发，认为对普通开发者和用户来说「拿来即用的 Skills 市场」 要比 「自己写 MCP server」 更有吸引力。[2-16][2-17]

① 标准化和共享的 Skills 可以让普通用户和非工程师方便地复用已有的工作成果，降低使用门槛。

② 同时，MCP 工具描述往往非常耗费 token（官方的 GitHub MCP 接入就需要消耗上万 token），部分团队可以通过让 LLM 直接调用 CLI 工具或其他轻量方法来替代部分 MCP 流程，来提高效率。

6、但也有人认为目前的状态是「Not Skills vs MCP， but Skills with MCP」，Skills 可以负责封装和组织业务流程、调用顺序，而 MCP 则继续发挥接入数据和工具的作用。[2-14][2-18]...

 关注👇🏻「机器之心PRO会员」，前往「收件箱」查看完整解读