大家好，这段时间已经被MCP轰炸，很多小伙伴在问。今天，打算用最最最简单的话来聊一聊MCP的原理，帮助大家理解和跟进这项技术。
工具调用简史
最早大模型刚出现的时候，只能完成对话功能。这也是为什么到了2025年的今天，你还能看到大模型有chat和非chat之分。新发布的模型，基本上都不再以chat命名。
第一阶段：Function Calling
2023年时，openAI发布了Function Calling功能，这个功能的目的是让AI可以实现与实时信息对接。例如查天气、联网搜索。
让我们来想象这样一个场景。
我们写了一个函数：
function getWeather(city) {
....
}
现在，我们把这个函数丢给用户，希望用户在想要查天气的时候，调用这个函数。
现在，我们把视角切换到拿到getWeather函数的用户这一侧。如果我们是会写代码的程序员，我们可能会这样：
if (keyword === 'weather') {
return await getWeather(params[0]);
}
然而，如果却是我们是普通不会写代码的人，我们只会这样：
帮我查一下北京今天的天气情况。
这两个看似毫无关系的写作方式，却在查天气这个场景下，本质完全相同。也就是说，对于不会编写代码的人而言，下面这段文字描述，完全等价于上面的代码，文字描述=函数调用。
作为开发者而言，如何把“帮我查一下北京今天的天气情况。”这句话，转化为await getWeather这段代码来执行呢？在传统编程中，我们几乎做不到。然而，到了AI时代，借助Function Calling，却可以顺利完成。这也就是我们以前讲的“自然语言编程”。
那么，Function Calling是怎么起作用的呢？下面我们来聊一聊其具体原理。
对于开发者而言，在提交对话请求到大模型的API时，如果按照普通方式提交，就是完成一次与大模型对话的过程。但是，如果传入`tools`参数，则不是对话，而是工具选择。tools参数里面是一个列表，列表的具体细节我们可以暂时忽略。当这个请求被发送到API之后，大模型不再是直接补全对话，而是根据用户提示，返回一个特定的JSON结构数据。这个数据包含了从tools列表中筛选出来的，需要被调用的工具列表。
你看，Function Calling从开发者的视角，就是一个智能化替代if...else的超级工具而已。
当开发者们拿到这个JSON之后，就可以根据这个JSON的信息，在本地执行某段程序。而JSON中，其实包含了用户输入的某些内容，例如查天气时，用户输入的城市和时段信息。
例如，我们以前写这样一个固定死的函数调用逻辑：
function determineByInput(data) {
switch (data.type) {
case 'weather':
return getWeather(...data.params);
case ...
}
}
现在我们修改为：
async function runByInput(text) {
const callings = await function_calling(text);
const outputs = await Promise.all(callings.map({ name, arguments: args }) => {
return tools[name](args);
});
const result = await request_llm(text, outputs);
return result;
}
你看，我们通过一小段代码就实现了“自然语言编程”的效果。我们再做一个UI，就可以让用户输入自然语言，然后操作某些逻辑，并最后返回用户自然语言的结果。
具体数据流程我们可以用下面这张图总结：
总结一下，使用Function Calling要求开发者自己在本地已经写好一大堆函数，并通过请求大模型API来决定调用哪些函数，并再次把执行函数的结果一并发给大模型，最终总结出给用户的答案。
第二阶段：插件阶段
Function Calling还是立足于开发者执行函数的原子层面，帮助了开发者，但对openAI建立生态没太大帮助，于是它搞了一个GPT插件。与Function Calling的差别在于，GPT插件是把函数代码托管在服务端，并通过配置文件交给openAI，让openAI调用你的服务端代码。
大模型插件虽然是基于Function Calling的，但是其商业感就强非常多了，且插件开发者需要承担自己的成本，于是大家坐上了一条船。
第三阶段：MCP到来
GPT插件体系让openAI一家吃独食，而对于插件的开发者们而言，其实更想让利益最大化，让自己的功能可以被任何大模型调用。虽然openAI很抵触这种想法，但是作为其竞争对手的claude大模型母公司Anthropic可不这么想，他们更愿意让开发者们融入自己的大模型中。
Anthropic提出了MCP协议。简单讲，MCP就是定义如何与大模型进行信息交换。你看，其实Function Calling不是早就规定了如何与大模型进行信息交换吗？但是架不住人家是Protocol，是协议呀，一下子就是产业级的词汇，而你还是代码块级的词汇。没办法，这个世界有时候就是命名学主导的。
在MCP的基础上，开发者们就可以完全脱离Function Calling在代码层面的束缚了。他们只需要调用MCP工具包的接口，而不需要思考数据流过程，因为数据流过程已经被封装在MCP工具包里面了，这样，开发者们的思想负担就极具降低了。
MCP的工具调用原理
Anthropic提出了MCP协议并得到了社区的响应，说明他们选对了方向。普通开发者们在实际开发中，并不会直接接触MCP协议本身，而是调用MCP的工具组合包（主要含MCP-Client和MCP-Server）。
无论是从普通用户的视角，还是一个第三方功能的开发者的视角，MCP工具组合包主导了整个信息流动，但是对于与大模型交互的表象来说，与原来的交互形式没有任何差别。终端用户感受不到MCP的存在。
那么MCP到底是怎么工作的呢？我们通过一张图来详细解释。
在这张图中，我们可以发现，其实整个信息流上，和前面一张Function Calling的图大差不差，核心思想不能说完全一样，只能说毫无不同。只不过增加了一些特定角色进来而已。因此，我就不对图中的信息流向做过多解释了。
整个生态会有如下的角色参与：1.用户；2.APP应用开发者；3.大语言模型服务商；4.软件或应用服务商；5.MCP工具组合包的维护人员。
对于用户而言，他们对技术变化无感，以前怎么用，以后还怎么用。
对于APP开发者而言，他们需要在APP中接入MCP工具组合包，并配置好MCP-Server的连接信息。
对于大语言模型服务商，需要对模型进行适配优化，以适应MCP协议，在MCP-Client询问应该调用什么工具时，准确的回答调用工具。
对于软件或应用服务商，需要开发自己的MCP-Server，并改造自己的软件（在APP所在的本地机器上运行）或服务（通过接口远程调用），以适配MCP-Server的开发。或者，软件或服务提供公开的接口，让开源社区的开发者们来帮助软件或应用开发MCP-Server。
对于MCP工具组合包的维护人员，基本没事干。
为何MCP会突然火爆？
作为2025年的头牌，MCP可能会撬动亿级市场。虽然
Anthropic也并不受很多人推崇，但是不得不承认的是，目前市场上已经有很多公司开始入局MCP，前有编码工具cursor、cline，后有游戏工具unity，开发者们更是前仆后继的投入其中。我们很难说清楚为什么MCP会被认可，即使openAI一开始也很抵触，但是现在也松开说会跟进MCP。我们不得不承认一个规律，即当越来越多的人参与这个生态的时候，它会最后成为事实上的标准。就像曾经的docker、github的模式、openAI的API接口，但凡人们聚集，它就成为事实上的唯一选择。
MCP的破局
在此之前，我们几乎所有人都会有一个疑问：有了Function Calling，为什么MCP还会火？现在我们逐渐意识到，这是必然趋势。
有一个不争的事实，MPC不依赖Function Calling.
Function Calling需要大模型端支持，而deepseek-r1等模型是不支持Function Calling的。MCP则不需要模型支持在API中传tools，而是通过提示词的方式，将server和tool_name携带过去，并通过特殊的来标记。而通过提示词的方式，可以极大的增强灵活性，即使不支持Function Calling的大模型，也可以被接入到MCP生态中，这使得大模型成为旁路，也就是说，在整个应用体系中，大模型是可以被插拔替换的，就像为一个“人”随时替换“大脑”一样，需要它使用高智能的时候，替换一个贵一点的“大脑”，需要它性能快的时候，替换一个参数量小的“大脑”。
基于这一点，以前围绕大模型来进行的Agent设计方式，现在不需要了。这对应用侧而言，是一个莫大的提升。也就是说，应用的开发对大模型的依赖减少，从而可以在实际功能的实现上投入更多。这就为AI应用的爆发提供了非常好的条件。
也正是如此，我冒昧的预测，很快，Agent的开发将会以MCP为内核，依赖MCP完成Agent的开发，大模型成为Agent接入的很小部分，这意味着，Agent的爆发会更有可能。
另外，各类公司入局MCP也为应用开发者们创造了条件。我们可以通过调用这些头部App厂商们提供的MCP服务器来实现将自己的智能体接入美图、携程等等这类生活服务型的功能，使智能体更贴近真实生活场景。
我之前讲，toA编程，也就是具体功能服务的开发者们，将来不仅要提供可供用户们使用的UI、可供开发者调用的API，甚至还要提供可供MCP-Client调用的MCP-Server，这三者缺一不可，也就是toC、toB、toA需要全覆盖。
结语
这篇文章通过两张图向你解释了爆火的MCP究竟是怎么回事。通过把以前的数据流形成固有模式，并且通过一些提示词语法的方式，形成MCP协议，从而做到了无论什么大模型，都可以简单的接入到应用中作为智力支持，看似没有什么大的创新，却又撬动了巨大的市场。这就是MCP，未来Agent可能依赖的核心协议。
2025-04-02 73
