随着 AI 原生应用的兴起，MCP（Multi-step Calling Protocol）与 Function Calling 正在成为连接模型能力与业务逻辑的关键桥梁。本文将带你深入理解 MCP 的设计理念与 Function Calling 的底层机制，结合典型应用场景，厘清它们在智能体架构中的角色分工与协同路径。
随着大语言模型（LLM）的浪潮奔涌而至，我们不再满足于其潜能被禁锢在简单的问答模式中。我们渴望它能像人类一样，执行更复杂的现实任务。然而，一个根本性的问题浮现眼前。
无论是基于训练数据还是外接知识库，LLM在本质上都是一个“静态的缸中大脑”。它与人类在执行任务时有着许许多多的的区别，而在这些区别中有一个影响模型能力的关键区别——与真实世界的实时交互能力。
设想一个场景：当被问及“今天上海天气如何？”，我们不会基于过去的记忆去推断，也不会想去查阅一本记录着历年上海天气的“指南”，而是会立即打开天气应用，获取一个实时的、准确的答案，也就是说，我们能用恰当的行动，链接起来物理世界（被问到的问题）和数据世界（天气预报中记录的实时信息）。
那么，如何让“缸中大脑”也能像我们一样，拥有“打开天气预报”这种执行能力？这便是我们今天要探讨的核心技术：Function Calling与MCP。
由于这些名词Function Calling、MCP都是海外创造的词汇，我们需要对这些词汇先有个简单的理解对齐。
什么是Function Calling?
我们知道，大语言模型的能力本质上就是在接收文本序列、生成文本序列，也就是一台Sequence to Sequence的机器，因此要让大模型具备与真实世界独立交互的能力，我们只能在文本的层面做一些改造。这种改造分为两个方面：首先要让模型理解它能够和哪些真实数据交互，即它能够使用哪些工具获取实时数据。其次就要让它知道它如何正确“打开”这个工具。这两项能力组合起来，就是Function Calling的能力。
让我们结合一个如何实现FunctionCalling的例子来进一步对齐：
我们现在有一个能够语义理解的模型，还有一张表格，里面存放着世界上所有地区的实时天气情况。
我们在不给予模型任何额外背景的情况下，它是一台能够根据已有知识对用户输入产生合理输出的机器，如果我问它：“今天上海天气怎么样？”，这个问题会转化成向量，在模型大脑中一通计算，最后给出一个模型已有知识中它认为最能回答这个问题的答案，它可能是“还不错”，也可能是“我的门口有两棵树，一棵是枣树，另一棵还是枣树”，它的回答内容，取决于我们用了什么“静态数据”训练它，以及提供了什么“静态”知识库供它访问，它没有获取实时信息的能力。
那么，我们如何让它去打开那张实时更新的表格，并从里面查信息呢？你肯定已经想到了，我们可以将查表格的能力抽象成一个接口，由模型来向接口发送请求并携带对应参数来获取数值，也就是这么做：
这一次，在我们问出“今天上海天气怎么样”的时候，同步给模型一个“静态知识”：你可以调用一个工具，叫做get_weather来获取天气，这个工具的描述如下：
也就是说，模型收到的输入如下：
而当我们的模型接收到问题输入的时候，它会经过分析，判断出需要调用get_weather这个工具，并且从工具列表中判断得到它需要一个location参数，于是输出一个型如下的格式请求：
到这一步Function Calling也就结束了。也就是说，什么是Function Calling其实可以用下面一句话描述清楚：
Function Calling就是指模型根据用户提供的工具列表，分析用户的问题需要调用什么工具，并且按照符合工具列表的要求生成对应工具请求的输出的能力。也就是判断工具选型、生成工具请求两项能力。
什么是MCP？
MCP，我们都知道它是一个“协议”。而它究竟有什么用、和我们刚刚讲的Function Calling有什么关系呢？请看下图：
在我们开始分析这张图之前，我们需要明晰一件事：MCP和Function Calling有什么关系？
我们知道Function Calling指的是模型根据用户问题，拆分问题、生成工具请求的能力。我们可以将Fucntion Calling理解为一种能力，而MCP则是“施展这种能力的舞台”。
MCP，全称是模型上下文协议（Model Context Protocol），我们不去讲MCP到底是如何实现的，但是我们需要知道它是如何在Function Calling的基础上搭建并工作的。
MCP的核心是MCP Server，它是一个装载着大量工具的服务，能够提供给模型工具列表（Function Calling中提到的那种），也能够接收模型生成的请求并且获得结果返回给模型。也就是图中的红色核心。
这么讲可能还是无法理解MCP是什么，没关系，我们用例子来讲明，代码预警。
如何搭建MCP Server?
当我们有一个模型，我们想给它提供实时与股票市场交互的能力，我们可以构建一个获取股票价格的MCP Server如下：
如果你不会python，也没关系，你只需要注意到我们定义了一个工具get_stock_price，并且将其添加在一个名为stocks_server的MCP Server中即可。
到这一步，也就相当于我们给MCP Server中添加了查询股票价格的接口，接下来就是将MCP Server和调用模型的客户端进行绑定：
当我们做到这一步，成功将MCP Server注入给模型之后，我们需要做的就是询问模型股票价格，模型便可以自动调用工具获取实时信息了，整个过程看起来好像和Function Calling没有关系，但是其实MCP的实现正是基于Function Calling实现的。
整体回顾
让我们再次回到起点。一个被禁锢在“缸中”的语言模型，如何才能与真实世界交互？
答案，是一个优雅的分层协作架构。
首先，我们依赖模型与生俱来的天赋能力——Function Calling。它让模型能够读懂“工具说明书”，并将我们的自然语言指令，转化为精确的、机器可以理解的“行动计划（JSON）”。这是“决策生成”的环节，完全由模型的认知智能驱动 。
其次，我们构建了一个标准化的执行舞台——MCP (模型上下文协议)。通过编写MCP Server，我们为模型的能力搭建了一个稳定、可靠且可扩展的外部环境 。它负责提供工具、执行指令、处理反馈，将模型的“计划”转化为真实世界的“行动”。这是“决策执行”的环节，由我们开发者的工程能力保障。
能力（Function Calling）与舞台（MCP）的分离，正是这套架构的精髓所在。它让AI回归其最擅长的认知与推理，让开发者专注于构建稳定可靠的工具与服务。这种清晰的职责划分，最终共同成就了一个真正强大且有执行力的AI Agent。
本文由 @石耳叫Ria 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
