MCP,给AI一个通用的万能接口

MCP,给AI一个通用的万能接口

MCP(Model Context Protocol)是AI世界的USB-C,解决了模型和工具之间N×M碎片化问题。这篇文章从USB-C类比讲起,带你理解这个正在重塑AI生态的开放协议。

发布于 2026/06/23
更新于 2026/06/23
14 分钟阅读
3 次阅读

上一篇文章结尾,我留了一个钩子。

我说Function Calling让AI学会了「动手」,但每家模型的接口都不一样,搞出了一个N×M的碎片化问题。然后我说,有一个叫MCP的协议正在试图解决这件事。

今天就来兑现这个承诺。

MCP,全称Model Context Protocol,模型上下文协议。 2024年11月Anthropic发布的一个开放标准。一年多之后的今天,它已经从一家公司的提案变成了整个AI行业的基础设施。OpenAI支持它,Google支持它,Microsoft支持它,它被捐给了Linux基金会,成为了中立治理的开源项目。

这个速度有多快呢?从一家公司发布到全行业采用到进入基金会,只用了13个月。业内有人说这是技术标准史上最快的收敛周期之一。

但我今天不想从「它有多牛」开始讲,我想从一个很具体的痛点开始。

你还记得上一篇文章里我说的那个场景吗?如果你是一个工具提供方,做了一个很好用的数据库查询服务,想让所有AI都能调用它。那你就得给OpenAI写一个适配、给Claude写一个适配、给Gemini写一个适配、给Llama写一个适配。。。

反过来也是一样。如果你是一个AI应用的开发者,想让你的产品能连接各种外部工具,每接一个新工具你都得写一套新的集成代码。

N个AI平台,M个工具,N×M个适配。

我跟你说,这不是假设性的问题。2024年到2025年初,整个行业真的就是这么干的。每一个AI创业公司的工程师都在做这种重复的苦力活,写一堆几乎一模一样但又因为接口细节不同所以不能复用的胶水代码。

这种情况你见过吗?见过。

手机充电器。

2010年之前,每个手机品牌都有自己的充电口。诺基亚一种、三星一种、摩托罗拉一种、索尼爱立信一种。你出门得带一书包充电器。后来USB统一了充电接口,再后来USB-C统一了所有设备的接口。你现在出门带一根线就够了。

MCP就是AI世界的USB-C。

MCP就是AI世界的USB-C:从混乱到统一

它在AI应用和外部工具之间定义了一个通用的通信协议。任何AI只要实现了MCP的客户端,就能连接任何实现了MCP服务端的工具。N×M变成了N+M。

让我把这个架构说清楚。

MCP的架构其实很简洁,只有三个角色。

第一个角色,Host。 就是AI应用本身。比如Claude桌面版、ChatGPT、VS Code里的Copilot、Cursor这些。Host是发起连接的那一方,也是用户直接交互的那一方。

第二个角色,Client。 是Host内部的一个通信模块。每个Client跟一个特定的MCP Server保持一对一的连接。你可以把它理解成一个翻译官,负责把Host的请求翻译成MCP协议的格式发出去,再把Server的回复翻译回来。

第三个角色,Server。 这是真正干活的那一方。MCP Server是一个轻量级的服务,它把某个具体的工具或数据源「包装」起来,对外暴露出标准的MCP接口。比如一个GitHub的MCP Server,它内部调用GitHub的API,但对外提供的是统一的MCP协议接口。一个数据库的MCP Server,它内部跑SQL查询,但对外看起来跟GitHub Server的接口格式是一样的。

整个通信过程基于JSON-RPC 2.0,一个非常成熟的远程调用协议。

你看,核心的设计思路就一句话,把「AI怎么跟工具说话」这件事标准化。

我觉得可以用一个更生活化的比喻来理解这三个角色的关系。

Host就像一个大老板,他有各种需求(查数据、发邮件、操作系统)。Client就像老板的秘书,秘书知道怎么联系各种服务商。Server就是各种专业服务商(会计事务所、快递公司、律师团队),每个服务商提供不同的能力,但他们跟秘书之间的沟通方式是统一的,都是打电话+发传真(MCP协议)。

老板不需要知道会计事务所内部用什么系统、快递公司内部怎么调度,他只需要跟秘书说「帮我查一下上个月的账目」「帮我给张三寄一份合同」,秘书自己知道该找谁、该怎么说。

MCP三角色架构:老板、秘书、服务商

这个类比还有一层意思。老板可以随时换(换一个AI平台),秘书的工作流程不变。服务商也可以随时换(换一个数据库),只要新服务商也能接电话发传真就行。 这就是标准协议的力量,解耦。

好了,你可能会问,这听起来也就是一个接口标准而已,为啥整个行业都这么激动?

我觉得有三个原因。

第一个,时机太对了。 MCP出现的时候,正好是AI Agent爆发的前夜。所有人都在做Agent,所有Agent都需要调用外部工具,所有人都被N×M问题折磨得快疯了。你在这个时间点提出一个解决方案,大家恨不得抱着你哭。

第二个,Anthropic很聪明地选择了开源。 如果MCP是Anthropic的私有协议,OpenAI和Google打死都不会用。但Anthropic一上来就把它开源了,而且在2025年12月直接捐给了Linux基金会。成立了一个叫Agentic AI Foundation的中立组织来治理这个协议,Anthropic、OpenAI、Block是联合创始方,Google、Microsoft、AWS、Bloomberg、Cloudflare是白金赞助商。

你看明白了吗?竞争对手们坐在了同一张桌子上。这在AI行业是极其罕见的事情。

第三个,生态爆发的速度太快了。 到2026年中的数据,活跃的MCP Server超过10000个,SDK的月下载量接近1亿次。Claude本身就有75个以上的官方Connector(底层就是MCP)。VS Code、Cursor、ChatGPT这些主流工具都原生支持MCP。一个开发者写一个MCP Server,立刻就能被所有支持MCP的AI应用使用。这种「写一次、到处用」的体验,让开发者社区疯狂涌入。

坦率的讲,我觉得这个速度已经可以跟Docker和Kubernetes的早期生态增长相提并论了。

说到这里,可能有人会问,MCP跟上一篇讲的Function Calling是什么关系?是替代还是互补?

答案是互补。

Function Calling解决的是「模型怎么决定调用什么工具」的问题。模型根据用户的问题和工具清单,生成一个结构化的调用请求。这个能力是模型自身的能力,跟任何协议无关。

MCP解决的是「调用请求发出去之后,怎么到达工具、怎么执行、怎么返回结果」的问题。它是连接层,是管道。

打个比方。Function Calling就像一个人决定「我要打电话给张三」然后拨号。MCP就像电话网络本身,负责把信号从你的手机传到张三的手机。没有电话网络,你拨号也没用。没有拨号的能力,电话网络放在那里也没意义。

模型决策用Function Calling,通信传输用MCP。两个加在一起,才构成一个完整的AI工具调用体系。

Function Calling vs MCP:决策层与连接层的配合

我自己觉得这是理解MCP最容易搞混的地方。很多科普文章把这俩混在一起讲,搞得人以为MCP是Function Calling的替代品。不是的,它们是不同层级的东西。

接下来聊一个我觉得很多人会关心的问题,MCP的安全性。

这玩意让AI能连接到你的各种系统和数据,听起来就很吓人对吧?万一有人写了一个恶意的MCP Server怎么办?万一AI通过MCP做了不该做的操作怎么办?

坦率的讲,这些担忧是对的。MCP的安全模型确实还在不断完善中。

目前MCP的安全设计有几个关键点。第一,认证基于OAuth 2.1,这是一个非常成熟的授权框架。第二,权限控制遵循最小权限原则,AI能做什么不能做什么,由Server端来定义和限制。第三,人类在环(human-in-the-loop),关键操作需要用户确认,不是AI说干什么就干什么。

但说实话,目前最大的风险不在协议本身,而在供应链安全。MCP Server谁都可以写,但你怎么确保你装的那个Server不是恶意的?这就跟npm包一样,npm协议本身没问题,但你随便装一个不知名的包可能就中招了。

2025年已经出现过几起MCP Server的安全事件,有人在一个热门的MCP Server里藏了后门,用户一连接就会泄露token。这促使了MCP社区开始建设官方的Server注册中心和安全审计机制。

我自己的判断是,MCP在安全方面还有不少路要走,但方向是对的。

好了,最后把MCP放到我们整个系列的大图景里收个尾。

这个系列从Fine-tuning开始,到Function Calling,到今天的MCP,其实讲的是一个完整的故事。

Fine-tuning让AI学会了「成为某个特定的人」。 通过微调,模型有了自己的性格、专业知识、行为模式。

Function Calling让AI学会了「动手干活」。 模型不再只是嘴上说说,它能决策要调用什么工具、传什么参数来完成任务。

MCP让AI学会了「跟整个世界连接」。 通过标准化的协议,模型可以连接到任何工具、任何数据源、任何服务,而不用每次都写一个新的适配器。

三个加在一起,你得到的是什么?

一个有专业能力、能动手干活、还能触达各种系统和数据的AI。 说到底,这就是2025到2026年所有人在追求的那个东西,AI Agent。

我自己回头看这三篇文章,觉得有一个贯穿的底层逻辑是这样的。AI这个领域,从来不是一项单一技术能解决所有问题。它是一整套互相配合的技术栈,每一层解决一个具体的问题,叠在一起才能构成一个真正好用的系统。

就像盖房子。Fine-tuning是打地基,决定了房子的基本形态。Function Calling是装水电,让房子有了功能。MCP是把水电接入市政管网,让房子能跟外部世界连通。缺了哪一层,房子都住不了人。

完整的AI系统:地基+水电+市政管网

如果你是一个想在业务中落地AI的人,我的建议是,这三个东西都值得了解,但不需要全部自己搭。 大部分场景下,用现成的平台和工具就够了。但你得知道它们各自在做什么,这样在技术选型的时候才不会被忽悠。

永远对世界保持好奇。

以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~
谢谢你看我的文章,我们,下次再见。

延伸阅读

  • Function Calling,让AI学会动手干活的技术:AI什么都知道却什么都做不了?Function Calling让大模型从只会说话变成能动手干活。这篇文章用大白话聊透这个让AI Agent成为可能的核心技术。
  • Fine-tuning,让AI学会「成为某个人」的技术:微调到底是什么?跟RAG和prompt有什么区别?LoRA和QLoRA又是什么?这篇文章用大白话聊透Fine-tuning,从概念到成本到实际应用场景。
  • RAG,一个让AI学会翻书的技术:之前一直听说过RAG但没有深入了解过,今天花了一整天时间研究,用大白话聊透它的概念、原理、使用场景和最新进展。如果你跟我一样对RAG只停留在听说过的阶段,这篇应该能帮到你。
  • AI Agent,当AI学会自己搞定一整件事:AI Agent是Fine-tuning、Function Calling、MCP三大技术的集大成者。这篇文章从聊天机器人和Agent的本质区别讲起,拆解Agentic Loop的工作机制,坦诚讨论复合错误率的现实挑战,最终回答一个问题:当AI学会独立完成任务,什么能力变得更重要了?

评论区

欢迎留下你的看法,支持匿名评论。

你的评论会公开展示,建议填写便于交流的昵称,并尽量提供有信息量的反馈。