在人工智能领域，大模型的交互和应用一直是技术发展的关键。近期，MCP（Model Calling Protocol）作为一种新兴的标准化交互协议，迅速吸引了全球技术圈的关注。从OpenAI到谷歌，各大AI巨头纷纷投入MCP的怀抱，试图通过这一协议实现大模型间的无缝交互。本文将深入剖析MCP的起源、核心价值、与现有技术的对比，以及它对未来技术生态的潜在影响，探讨MCP是否真的有可能成为“AI界的HTTP”。
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时代的交互事实标准还有多远？。
//章节速览
从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通过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应用难以规模化。
先说结论，颠覆不好说，但会把“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像当年的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规范派系
AI专用框架派系
从这里面找一个潜在对手，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 注入新工具，效果恐更不理想。」
一些现实的挑战是：
开放式的讨论并没有给出答案，就像Langchain在x上发起的投票一样。将近500位投票者，其中有40% 参与者支持 MCP 成为未来标准，并没有取得压倒性的胜利。
对了，Speakeasy Batchu对此也有看法——“我相信，一段时间内会出现一些模式之争，直到最终形成像 OpenAPI 这样的标准”。
此时，Batchu还不知道十几天后OpenAI和谷歌都宣布支持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对交互层的解耦：
这种转型或许正在重构人机交互的底层逻辑。就像iPhone用触摸屏取代键盘，MCP协议通过统一的功能调用标准，使自然语言成为连接用户意图与系统能力的“终极接口”。
MCP的崛起标志着AI发展进入生态竞争新阶段。正如HTTP协议奠定互联网基石，MCP正在构建智能时代的“数字神经系统”。其价值或许不仅在于技术规范本身，更在于开创了开放协作的新范式——让模型、工具、数据在统一协议下自由流动。
MCP是否能一统天下尚未可知，但这显然让我们离AGI又近了一步。
本文由人人都是产品经理作者【鹅厂技术派】，微信公众号：【鹅厂技术派】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。