5000 字深度长文：详解科技圈爆火的 MCP

发表于 更新于 分类于 本文字数： 5.9k 阅读时长 ≈ 5 分钟
本文深入分析MCP协议为何能在短时间内引爆科技圈，从技术本质、与Function Call的关系、生态竞争格局三个维度全面剖析。文章追踪MCP从Anthropic发布到OpenAI、Google相继支持的演进历程，探讨其能否成为AI界的HTTP事实标准，以及与LSP、OpenAPI等协议的差异化竞争策略。

To MCP or not to MCP?

在 OpenAI 宣布支持 MCP 之后，谷歌也没犹豫太久。4 月 4 日，Gemini 宣布在官方 API 文档中添加了使用 MCP 的范例。至此，OpenAI、谷歌、Anthropic 等 AI 巨头全部投入这个「大模型 USB-C」的怀抱。

作为大模型间标准化交互的尝试，MCP 被寄予 “AI 界的 HTTP” 厚望，但 AI 领域从来不乏 “核弹级技术”。其爆火究竟是走向共识还是昙花一现？对于技术决策者而言，MCP 能否真正跨越概念到落地的鸿沟或许更加值得关注。

MCP 爆火一个月后，本文从关键问题切入：为何这项技术能引发巨头争夺？它距离定义 AI 时代的交互事实标准还有多远？。

// 章节速览

  • MCP 是怎么火起来的？

  • MCP 是什么，本质解决了什么核心矛盾？

  • MCP 能否撼动甚至颠覆 Function Call 的地位？

  • 目前跟 MCP 类似的大模型协议有哪些？MCP 离成为 “事实标准” 还有多远？

  • MCP 对现有的技术生态有什么影响？

一、MCP 是怎么火起来的？

从 Github 的 Star History 和 Google 搜索趋势上看，MCP 的确是全球范围内 AI 新贵，尤其是两个观测不同热度指标的曲线，竟然呈现出高度相似的增长态势，这代表 MCP 在同时吸引圈内人和圈外人的关注。

MCP 的爆火大概有三个阶段。

去年 11 月由 Anthropic 发布以来，MCP 迅速吸引技术极客与开源社区开发者，其核心价值在于解决 AI 工具集成的 “最后一公里” 问题。开发者通过封装 Slack、Notion 等工具构建 MCP Server，验证协议在各种场景的可行性。这个阶段的局限性在于，多数实践聚焦于个人效率工具，尚未触及企业级复杂场景。例如 BlenderMCP 项目通过自然语言操控 3D 建模工具，虽在 GitHub 三天斩获 3.8k 星标，但主要服务于独立开发者群体。

第一次破圈在于 3 月上旬，主要来源于 “标准之辩” 和“Manus 发布”。3 月 11 日。LangChain 联合创始人 Harrison Chase 与 LangGraph 负责人 Nuno Campos 围绕 MCP 是否就成为未来 AI 交互事实标准展开激辩，虽然没有结论，但很大程度上激发了大家对 MCP 的想象空间。这场辩论的同时，LangChain 还在网上发起了投票，40% 参与者支持 MCP 成为未来标准。

第二天，Manus 框架发布。Manus 虽未直接采用 MCP 技术，但其引发的 “3 小时复刻开源” 事件，客观上推动更多团队关注协议标准化价值。另一方面，Manus 展现的多 Agent 协同能力精准契合了用户对 AI 生产力的终极想象。当前 LLM 的主流交互形态仍以 ChatBot 为主，虽然其 Function Call 机制已展示了连接外部数据的可能性，但由于需要复杂的技术对接，实际应用始终存在门槛。

当 MCP 通过聊天界面实现 “对话即操作 “的革新体验——用户亲眼见证输入框指令直接触发文件管理、数据调取等系统级操作时，那种 “AI 真的能帮我动手干活” 的认知革命才真正爆发。正是这种颠覆性体验的反向赋能，使得 Manus 的发布成为了带火 MCP 的关键推手。

随后，OpenAI 的官宣下场，让大家看到了 “AI 界 HTTP” 成为现实的可能。当这个占据全球 40% 模型市场份额的巨头宣布支持协议，意味着 MCP 开始具备类似 HTTP 的底层基础设施属性，MCP 正式进入大众视野，热度持续走高，指数级飙升。

二、MCP 是什么，本质解决了什么核心矛盾？

MCP 通过 Client、Host、Server 将大模型与外部交互抽象成了 “客户端 - 服务器” 架构。任何支持 MCP 的 AI 应用（MCP Host）均可直接配置并使用应用市场的 MCP Server（官方、三方），无需预编码适配，类似于 USB 设备插入即用。当 LLM 需要完成特定任务时，可以像 “即插即用” 般调用这些模块，实时获得精准的上下文支持，从而实现能力的弹性扩展。

在更广阔的视角看待，MCP 其实是 Prompt Engineering 发展的产物。大模型是 AI 应用的大脑，Prompt 则负责给大模型指引和参考资料。使用 Prompt Engineering 加速大模型应用的落地是如今的主流做法。具体而言，结构化的 Prompt 可以给大模型提供：

  • 额外的参考资料，如使用 RAG、联网搜索来增强大模型的回复。

  • 调用工具的能力，从而实现 Agent。如提供文件操作工具、爬虫工具、浏览器操作工具（Manus 使用的 Brower Use）。

回顾 Function call 或者 RAG，都需要手工地执行工具检索、手工地将信息加入到 prompt 中，prompt 本身也需要精心地手工设计。尤其是不同大模型的 Function call 遵循不同的调用结构和参数格式，彼此之间基本无法互通。

MCP 的爆发源于它击中了 Prompt Engineering 的核心矛盾——动态意图理解与静态工具调用之间的割裂。传统开发模式下，Function call 需要开发者预先编写工具调用逻辑、设计 Prompt 模板、手动管理上下文，这一过程不仅效率低下，还导致 AI 应用难以规模化。

三、MCP 能否撼动甚至颠覆 Function Call 的地位？

先说结论，颠覆不好说，但会把 “Function Call 们” 卷起来。

Function Call 本质上是某些大模型（如 GPT-4）提供的专有能力，允许 AI 通过结构化请求调用外部工具（例如查询天气、执行计算）。宿主应用收到请求后执行操作并返回结果。其核心是模型厂商内部的功能扩展接口，无统一标准，实现依赖特定厂商。

MCP 的核心优势在于统一了各家大模型原本差异化的 Function Calling 标准，形成通用协议。它不仅支持 Claude，还能兼容市面上几乎所有主流大模型，堪称 AI 领域的 “USB-C 接口”。基于标准化通信规范（如 JSON-RPC 2.0），MCP 解决了模型与外部工具、数据源间的兼容性问题，开发者只需按协议开发一次接口，即可被多模型调用。

也是由于两者都能实现与外部数据的联动，MCP 在刚问世时，开发者常纠结 “它是 Function Call 的简化版，还是 AI 交互的 HTTP 标准？” 但随着生态发展，MCP 相比 Function Call 的开放性优势逐渐被认知的更加清晰：

Function Call 的 “私有协议困局”，类似手机厂商的私有快充协议，主流 AI 厂商各自定义封闭的调用协议（JSON Schema、Protobuf 等），导致开发者为不同平台重复开发适配逻辑。切换 AI 服务商时，工具调用体系需 “推倒重来”，跨平台成本高企，拖慢 AI 能力的规模化落地。

MCP 通过统一通信规范和资源定义标准，MCP 让开发者 “一次开发，全平台通用”——同一工具可无缝适配 GPT、Claude 等不同模型。这如同 AI 世界的 “书同文、车同轨”，终结 “重复造轮子” 的窘境。

但 Function Call 仍是高频轻量任务的 “王者”：它像模型的 “贴身助手”，也是 MCP 协议链接各方的基础，运行时直接调用（如快速计算、简单查询），响应极快。

而 MCP 则擅长 “复杂任务外包”：模型像 “指挥官” 下达需求（如抓取网页），MCP Server 作为 “快递员” 按需响应，通过 HTTP/SSE 协议“送货上门”，全程无需开发者手动干预。

可以预见的是，MCP 短期内不会颠覆 Function Call，但会倒逼其进化 。当模型自带工具的丰富度追上 MCP，开发者还需要费力搭建专用 Server 吗？答案或许是不一定。但至少，MCP 的出现让 Function Call 们不得不 “卷” 起来——推动工具调用更标准化、更便捷。

Function Call 是 AI 的 “即时小助手”，MCP 是 “按需响应的快递员”——两者更好的模式是协同发展。

Function Call 代表 “代码控” 思维：开发者需精细控制工具细节；而 MCP 转向 “意图派” 模式：开发者只需定义能力边界，具体执行由大模型动态决策。两者并存，让开发者既能享受高频任务的高效，又能解锁复杂场景的灵活性。

四、目前跟 “MCP” 类似的大模型协议有哪些？MCP 离成为 “事实标准” 还有多远？

都说 MCP 像当年的 HTTP 协议，其实上一个和 MCP 这么像的还是 LSP——语言服务器协议。

在 2016 年 LSP 发布之前，开发工具生态可以用 “各自为政” 来形容。在传统开发范式下，集成开发环境（IDE）与主流代码编辑器（如 VSCode、Sublime、VIM 等）必须为 Java、Python、C++ 等不同编程语言重复开发语法解析、代码补全、调试支持等核心功能，这不仅造成巨大的资源浪费，更导致开发者体验的割裂。而 LSP 的革命性突破，在于创建了编辑器前端与语言后端解耦的标准化通信架构——通过定义 JSON-RPC 规范下的跨进程交互协议，使得语言智能服务能够以可插拔的方式适配任意编辑器，听着是不是和 MCP 异曲同工？

可以说，MCP 的设计灵感很大程度上来源于 LSP，两者的理念非常相似，都将 M*N 的难题简化成了 All in One。

LSP 毕竟是解决编程语言和编程环境交互的，除此之外与 MCP 类似的技术协议大致可分为两类，各自代表不同技术路径，但对比 MCP 都呈现一定的劣势。

传统 API 规范派系

  • OpenAPI/Swagger：通用 API 描述标准，需开发者手动定义接口与逻辑，缺乏 AI 原生设计。

  • GraphQL：灵活的数据查询协议，但需预定义 Schema，动态上下文扩展能力不足。

  • 企业私有协议：如 OpenAI Plugins、Google Vertex AI 工具链，封闭性强，生态割裂。

AI 专用框架派系

  • LangChain 工具库：提供 500 多个工具集成，但依赖开发者编码适配，维护成本高。

  • Zapier 式低代码平台：通过可视化流程连接工具，但功能深度受限，难以满足复杂场景。

从这里面找一个潜在对手，OpenAPI 似乎能掰掰手腕。

但事实上， OpenAPI 作为 API 定义的事实标准，为 MCP 提供了基础架构而非竞争关系。

在 API 管理公司 CEO Speakeasy Batchu 看来：“从 OpenAPI 规范到 MCP 的跨越非常小——前者本质上是 MCP 所需信息的超集，我们只需将其与 LLM 专用参数（如语义描述、调用示例）封装为实时服务。” 这种设计差异揭示了二者本质区别：OpenAPI 是静态接口说明书，而 MPC 是动态执行引擎。当 AI 代理通过 MCP 服务器发起请求时，其实时交互能力可动态适配上下文变化，例如自动补全参数缺失的 API 调用，这种 “活的规范” 特性解决了传统集成中模型无法理解 API 架构信息的致命缺陷。

前文的提到的 “标准之辩” 也深入探讨了各种可能性。

正方的观点主张：「MCP 的核心价值在于：让用户为不可控的 Agent 添加工具。例如在使用 Claude Desktop、Cursor 等应用时，普通用户无法修改底层 Agent 的代码，但通过 MCP 协议就能为其扩展新工具。」

核心的技术支撑是：MCP 提供标准化的工具描述框架、支持通过提示词 (prompt) 引导工具调用，以及基础模型的工具调用能力本身也在持续进化

反方认为，「现有模型在专为特定工具集优化的 Agent 中，工具调用正确率仅 50%。若强行通过 MCP 注入新工具，效果恐更不理想。」

一些现实的挑战是：

  • 工具描述与 Agent 系统提示词需深度耦合

  • 当前 MCP 需要本地部署服务，使用门槛高

  • 缺乏服务端部署能力，难以应对规模化需求

  • 权限验证等安全问题尚未解决（MCP 在 H1 的计划中准备解决）

开放式的讨论并没有给出答案，就像 Langchain 在 x 上发起的投票一样。将近 500 位投票者，其中有 40% 参与者支持 MCP 成为未来标准，并没有取得压倒性的胜利。

对了，Speakeasy Batchu 对此也有看法——“我相信，一段时间内会出现一些模式之争，直到最终形成像 OpenAPI 这样的标准”。

此时，Batchu 还不知道十几天后 OpenAI 和谷歌都宣布支持 MCP。

五、MCP 对现有的技术生态有什么影响？

MCP“万能插头” 优势让开发 AI 应用进一步解耦，大大降低了技术门槛，让 “人人都是 AI 开发者” 变得触手可及。

对 AI 厂商而言，技术重心从工具适配转向协议兼容。MCP 协议如同 AI 领域的 “通用插座”，使得模型厂商只需确保与协议标准的兼容性，就能自动接入所有 MCP 生态工具。例如 OpenAI 通过支持 MCP 协议，其模型无需单独开发接口即可调用 GitHub、Slack 等数千种工具服务。这种转变让大模型厂商能够专注于核心算法优化，而非重复开发工具适配层。

对工具开发者而言，MCP 实现了 “一次开发、全生态通用” 的技术普惠。开发者将功能封装为 MCP Server 后，就能被所有兼容协议的 AI 应用调用。如 PostgreSQL 官方开发的数据库 Server 已被 500 多个 AI 应用集成，而无需针对每个模型单独适配。这让所有应用都找到了快速 AI 化的路径，就像十几年前 “所有行业都值得用互联网重做一遍” 一样；现在，所有产品都值得做一次 MCP 适配改造。

(几天之前，MCP server 的总体数字还是 6800)

对应用开发者而言，MCP 打破了技术能力的边界，并加速交互范式从 GUI（图形界面）向 LUI（语言界面）的跃迁 。通过协议标准化，开发者无需理解底层技术细节即可组合各类资源：教育机构用自然语言指令调用多语种资料库生成定制教案，零售企业通过语音指令整合 ERP 系统和 AI 模型管理库存。MCP 的协议兼容性使得自然语言交互可直接映射到具体功能实现，例如腾讯地图 MCP Server 支持用户用 “找附近人均 200 元的川菜馆” 等口语化指令完成复杂搜索，替代传统 GUI 中的多级菜单操作。这种转型在制造业尤为显著——某工厂工程师通过语音指令调度 MCP 连接的设备集群，响应速度比传统工控界面提升 5 倍。

LUI 开发效率的革命性提升也得益于 MCP 对交互层的解耦：

  • 传统 GUI 困境：需为不同平台（Web/iOS/Android）开发独立界面组件，维护成本占开发资源的 60%；

  • MCP+LUI 优势：开发者只需用自然语言描述功能需求（如生成周报图表），MCP 自动匹配数据库查询、可视化工具等 Server，并通过协议标准化输出结果。

这种转型或许正在重构人机交互的底层逻辑。就像 iPhone 用触摸屏取代键盘，MCP 协议通过统一的功能调用标准，使自然语言成为连接用户意图与系统能力的 “终极接口”。

MCP 的崛起标志着 AI 发展进入生态竞争新阶段。正如 HTTP 协议奠定互联网基石，MCP 正在构建智能时代的 “数字神经系统”。其价值或许不仅在于技术规范本身，更在于开创了开放协作的新范式——让模型、工具、数据在统一协议下自由流动。

MCP 是否能一统天下尚未可知，但这显然让我们离 AGI 又近了一步。