近期，Anthropic 新推出的 Claude Skills 在社区内收获了相对一致的好评，被不少开发者视为「终于能直接拿来用」的能力；几乎同一时间，MCP 协议的「一周年纪念日」却在一片「寂静」中度过。实际上从发布以来，MCP 的「builder 多于 user」、只是「旧瓶装新酒」的质疑始终存在，而在 Skills 和 MCP 叠加演进的当下，我们又该如何重新看待 MCP 的真实定位、适用边界，以及它在基础设施层面的潜在价值？
01. 开发者多于用户，MCP 仅是「旧瓶装新酒」？
自 MCP 发布一年以来，业内关于其定位、适用场景和未来发展一直存在争议。
有分析认为，在技术栈层面，MCP 并非「AI USB」、不是 Function Calling 的简单升级版、也不是万能的 Agent 框架，其本质是 「客户端与服务端之间的通信协议 + 统一的工具访问方式」。
社区内有用户认为，MCP 的核心价值是为没有工具执行环境的 大语言模型 补充一层运行时，而这本应是 AI 应用开发者本来就需要实现的功能。枫清科技 Fabarta 合伙人、智能引擎事业部总经理谭宇也指出，从用户视角看，MCP 包含协议、多语言 SDK 和生态三个方面，而低延迟与高并发并非其 协议层 关注的重点。
关于 MCP 的存在意义，支持者视其为「大模型的 HTTP 时刻」，认为目前的 AI 已经开始从视觉信息（如 deepseek-ocr）和动作信息（如 seed game tars）上学习，类似 MCP 的协议将是下一阶段（掌握工具）的基础能力。
反对者则指出，MCP 在许多方面只是「旧瓶装新酒」，它沿用了传统的服务注册和路由方法，仅在工具调用层面做了协议化。更「AI 化」的做法可能是将所有工具描述嵌入向量空间，通过向量检索实现一步到位的精准匹配。也有观点认为，Function Calling 本身已在很大程度上规范了模型对工具的调用，MCP 只是将这一过程转化为显式协议，在当前生态下更像一个过渡方案。
此外，MCP 生态中「开发者数量超过实际用户」的现象也引发讨论。今年9月，有科技博主在 X 上称「MCP is probably the only piece of tech that has more builders than users」，浏览量已超28万。评论区观点各异，有人认为 MCP 目前更多是工程师自娱自乐的早期基础设施探索，也有人指出这其实是早期基础设施的常见现象。
相关统计数据显示，自 Anthropic 发布 MCP 以来，社区已上线超过6000个 MCP 服务器，活跃开发者约2000-3000人，而实际终端用户大约在5万至7.5万之间，平均每25个用户对应1个开发者。服务器关注度分布也极不均衡，排名前10的服务器吸引了近一半的用户关注，前10%的服务器获得了88%的星标。
有分析指出，目前除了少数面向开发者的 IDE（如 Cursor、Cline）支持 MCP，主流网页端 AI 应用并不直接提供 MCP 接入，普通用户难以感知或使用。同时，MCP 在实际使用中存在调用效率较低、资源消耗高和运行不够稳定等问题。在许多场景下，企业发现直接通过系统 API 访问比通过 MCP 协议调用更为便捷。因此，目前 MCP 生态更多停留在开发者技术实验和内部验证阶段，真正的用户场景较为有限。
对于 MCP 当前适用的业务场景，社区认为它更适合 B 端的「数据开放 + 工具复用」类型。例如：需要向第三方开放扩展的平台（如 Claude 桌面端插件生态）；需要在网页、桌面、移动等多终端复用同一套工具并进行版本管理；以及内部工具链尚未标准化时，使用 MCP SDK 来统一流程。然而，对于小型内部项目或一次性集成需求，使用 MCP 会增加不必要的复杂度；对于性能敏感的应用，MCP 协议层的抽象和基于 JSON-RPC 的通信格式也可能成为 后端架构 的效率瓶颈。
02. 非 Skills 对决 MCP，而是 Skills 与 MCP 协同？
今年10月 Anthropic 推出 Claude Skills 以来，社区内关于 Skills 和 MCP 定位与分工的讨论也日益增多。
有分析认为，Skills 更关注「如何做」，即业务流程和策略层面；而 MCP 则回归具体「执行层」，主要负责调用后端工具。具体来说，Skills 相当于「封装了领域知识和业务逻辑的可移植工具调用+子代理」；而 MCP 则属于远程调用运行在服务器上工具的机制。有用户认为，Skills 更像是「更节省上下文长度的 MCP，用来获取操作指令」。事实上，许多 MCP Server 内部也会为工具编写说明文档，起到了类似 Skills 提供任务指令的作用。
在组织形式上，Skills 的结构非常简洁。一个 Skill 通常由 YAML 头部、Skills.md 文档和可选的资源文件组成。YAML 头部包含技能名称和简要描述（通常不超过100个 token），主要说明和资源文件仅在实际调用该 Skill 时加载，从而有效节约 token。例如，可以为个人助手智能体创建多个 Skills：一个负责「会议管理」，调用 MCP Server 来获取邮件和日历信息以安排会议；另一个负责「会议准备」，调用 MCP Server 来收集过往会议记录、准备会议材料。
在 Skills 的定位上，有观点认为其发布目的就是替代 MCP，因为当 MCP 能实现的功能 Skills 也能做到时，开发者通常更倾向于使用对开发者更友好的 Skills。MCP 的创新在于将原本每个模型与每个工具需要做的 M×N 次适配问题，简化为模型和工具各自支持 MCP 后的 M+N 问题。但主要缺点是开发者需要编写大量代码来实现每个 MCP Server，集成成本高。
相比之下，Skills 允许开发者使用自然语言在 SKILL.md 中描述工具、资源和提示词，门槛更低。同时，Skills 可以在提示中直接为 LLM 提供业务流程指导，而 MCP 本身只是被动暴露工具接口，无法主动引导 LLM 的思维方式。从实用角度看，对普通开发者和用户来说，「拿来即用的 Skills 市场」 要比 「自己编写 MCP server」 更有吸引力。标准化和可共享的 Skills 能让普通用户和非工程师方便地复用已有成果，降低使用门槛。
但也有人认为，当前的状态应是「Skills 与 MCP 协同」，而非对决。Skills 可以负责封装和组织业务流程、调用顺序，而 MCP 则继续发挥其标准化接入数据和工具的作用。
03. 过去一年，围绕 MCP 的基础设施层格局是否逐渐清晰？
（此部分内容在原始材料中未充分展开，基于上下文推断，可能探讨 MCP 协议作为底层标准，其大规模落地依赖于像「微信小程序」那样强大的入口和生态的建立。这涉及到协议标准化、开发者工具链、运行时环境等基础设施的成熟过程。）
发表于 昨天 01:46
|
查看: 6|
回复: 0
