本文从为什么需要Function calling和MCP、分别如何实现的、二者有什么关系三个角度来分析。Function calling传统的大模型本质上只是一个聊天机器基于喂给她的训练知识对用户提出的问题进行预测但无法感知周围环境的变化也无法改变周围环境比如操作文件、数据等为了把后端能力和大模型结合起来人们设计的初步方案是硬编码后端根据正则匹配判断需要调用的函数基于字符串匹配提取调用参数但是这种硬编码的方式很容易误判而这个匹配和提取这种功能正好是LLM所擅长的所以提出将这部分任务前置给LLM由模型判断调用什么函数、提取的参数是什么并直接告诉后端如何去操作后端只需要负责执行就ok。在该部分有两个阶段的设计1、基于提示词的Function Calling想象一下我们刚开始与大模型进行交互的时候那时候大得多的教程都是“每次对话开始前你需要给定你的大模型一个角色以便他给你更准确地的回复”其实这就是prompt的口语化的使用方式实际开发者在设计时会写一个system prompt会基于用户提供的这些内容提取关键信息并作为后续给后端发送命令的参考。System Prompt 示例 # 你的角色 你是一个函数调用助手我将提供多个函数的定义信息... # 你的任务 - 根据用户的输入判断是否需要调用某个函数 - 如果需要请严格按照以下格式输出 {name: 函数名, arguments: {参数名: 参数值}} # 函数定义信息 1. get_weather - 作用查询指定城市的天气 参数city (string) - 城市名称 2. get_time - 作用查询指定城市的当前时间 参数city (string) - 城市名称 存在的问题但是其一这个system prompt的模板是开发者自行编写的很难避免遗漏关键信息或者调用格式不准确的问题其二即便提示词写的很完美大模型也可能出现幻觉问题编造原本不存在的函数名或者格式其三为了尽可能保证准确设计prompt时可能需要加入大量规则说明这些加入到后续的对话中可能造成很大的冗余占用大量上下文空间。2、基于API的Function Calling针对可能出现幻觉的问题大模型提供商通过有监督微调supervised few shot SFT和强化学习RL提高模型本身的准确率针对由开发者编写prompt可能带来的问题在API层面设置了专门字段统一规定函数描述格式和调用格式。API 调用示例 json { messages: [ {role: user, content: 广州今天天气如何} ], functions: [ { name: getWeather, description: 获取指定城市的天气, parameters: { type: object, properties: { location: {type: string, description: 城市名称}, date: {type: string, description: 日期} }, required: [location, date] } } ] } 存在的问题各家大模型提供商API格式不统一切换大模型时需要重新适配所以出现了“MCP”。MCP官方定义MCP 是一个开放协议用于标准化应用程序向大语言模型LLM提供上下文的方式。你可以把 MCP 想象成 AI 应用的 USB-C 接口——正如 USB-C 提供了一种将设备连接到各种外设和配件的标准化方式一样MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。MCP的出现不是为了解决function calling的问题的幻觉提取不准确等问题依然可能出现而是为了解决针对多家API格式不统一导致的适配问题。基于function calling的方式工具的执行在AI应用程序的后端每次接入新的别人开发的工具都需要重新写适配代码——补充工具描述、工具代码。但是实际开发可能面临代码开发冗余代码跨语言开发商不提供源码等问题可以看到这些问题都是由于copy源码时带来的问题所以想到将这个工具/源码包装起来将其当作一个黑盒而无需考虑代码语言等的差异对外暴露一个统一的接口AI应用后端能自动获取工具的描述信息、定位工具调用入口并执行调用。工具调用分为两类本地将代码拉到本地另起一个进程执行AI应用通过socket返回标准化返回结果适合工具开发者提供安装包/源码的情况远程工具开发者将工具独立部署封装为标准化APIAI应用只需传入参数并解析返回结果即可得到标准返回结果适合企业级工具不暴露源码。完整架构如下组件1、Host——承载MCPClient的AI应用程序例如Claude Desktop、Cursor、自定义Agent2、client——Host内部实例化负责与Server交互每个Client与一个Server1:1连接3、server——工具提供方独立运行的服务文件系统服务、数据库服务、Web搜索服务等。传输协议1、本地——基于stdio协议传输通过管道标准输入输出stdin/stdout零网络开销进程与本机同步简单高效但是不能多客户端共享每个host要fork一个子进程。2、远程——httpssestreamable http。一个MCP可以服务于多个客户端。httpsse的模式下针对同一个客户端上行和下行时两套独立的消息流网络抖动时无法匹配streamable http在同一个逻辑断电可以post也可以get便于追踪调试。二者区分Function calling主要解决AI应用与LLM之间的交互解析出更规范的调用指令明确工具调用的需求MCP主要解决AI应用与工具之间的交互主要针对工具开发商提供的API不统一、开发语言不统一导致的问题。维度Function CallingMCP关注点AI应用与大模型的交互AI应用与工具的交互能力解决如何返回调用指令如何执行指令定位模型侧模型基础设施侧 FunctionCalling与MCP：大模型交互与工具执行的标准化
本文从为什么需要Function calling和MCP、分别如何实现的、二者有什么关系三个角度来分析。Function calling传统的大模型本质上只是一个聊天机器基于喂给她的训练知识对用户提出的问题进行预测但无法感知周围环境的变化也无法改变周围环境比如操作文件、数据等为了把后端能力和大模型结合起来人们设计的初步方案是硬编码后端根据正则匹配判断需要调用的函数基于字符串匹配提取调用参数但是这种硬编码的方式很容易误判而这个匹配和提取这种功能正好是LLM所擅长的所以提出将这部分任务前置给LLM由模型判断调用什么函数、提取的参数是什么并直接告诉后端如何去操作后端只需要负责执行就ok。在该部分有两个阶段的设计1、基于提示词的Function Calling想象一下我们刚开始与大模型进行交互的时候那时候大得多的教程都是“每次对话开始前你需要给定你的大模型一个角色以便他给你更准确地的回复”其实这就是prompt的口语化的使用方式实际开发者在设计时会写一个system prompt会基于用户提供的这些内容提取关键信息并作为后续给后端发送命令的参考。System Prompt 示例 # 你的角色 你是一个函数调用助手我将提供多个函数的定义信息... # 你的任务 - 根据用户的输入判断是否需要调用某个函数 - 如果需要请严格按照以下格式输出 {name: 函数名, arguments: {参数名: 参数值}} # 函数定义信息 1. get_weather - 作用查询指定城市的天气 参数city (string) - 城市名称 2. get_time - 作用查询指定城市的当前时间 参数city (string) - 城市名称 存在的问题但是其一这个system prompt的模板是开发者自行编写的很难避免遗漏关键信息或者调用格式不准确的问题其二即便提示词写的很完美大模型也可能出现幻觉问题编造原本不存在的函数名或者格式其三为了尽可能保证准确设计prompt时可能需要加入大量规则说明这些加入到后续的对话中可能造成很大的冗余占用大量上下文空间。2、基于API的Function Calling针对可能出现幻觉的问题大模型提供商通过有监督微调supervised few shot SFT和强化学习RL提高模型本身的准确率针对由开发者编写prompt可能带来的问题在API层面设置了专门字段统一规定函数描述格式和调用格式。API 调用示例 json { messages: [ {role: user, content: 广州今天天气如何} ], functions: [ { name: getWeather, description: 获取指定城市的天气, parameters: { type: object, properties: { location: {type: string, description: 城市名称}, date: {type: string, description: 日期} }, required: [location, date] } } ] } 存在的问题各家大模型提供商API格式不统一切换大模型时需要重新适配所以出现了“MCP”。MCP官方定义MCP 是一个开放协议用于标准化应用程序向大语言模型LLM提供上下文的方式。你可以把 MCP 想象成 AI 应用的 USB-C 接口——正如 USB-C 提供了一种将设备连接到各种外设和配件的标准化方式一样MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。MCP的出现不是为了解决function calling的问题的幻觉提取不准确等问题依然可能出现而是为了解决针对多家API格式不统一导致的适配问题。基于function calling的方式工具的执行在AI应用程序的后端每次接入新的别人开发的工具都需要重新写适配代码——补充工具描述、工具代码。但是实际开发可能面临代码开发冗余代码跨语言开发商不提供源码等问题可以看到这些问题都是由于copy源码时带来的问题所以想到将这个工具/源码包装起来将其当作一个黑盒而无需考虑代码语言等的差异对外暴露一个统一的接口AI应用后端能自动获取工具的描述信息、定位工具调用入口并执行调用。工具调用分为两类本地将代码拉到本地另起一个进程执行AI应用通过socket返回标准化返回结果适合工具开发者提供安装包/源码的情况远程工具开发者将工具独立部署封装为标准化APIAI应用只需传入参数并解析返回结果即可得到标准返回结果适合企业级工具不暴露源码。完整架构如下组件1、Host——承载MCPClient的AI应用程序例如Claude Desktop、Cursor、自定义Agent2、client——Host内部实例化负责与Server交互每个Client与一个Server1:1连接3、server——工具提供方独立运行的服务文件系统服务、数据库服务、Web搜索服务等。传输协议1、本地——基于stdio协议传输通过管道标准输入输出stdin/stdout零网络开销进程与本机同步简单高效但是不能多客户端共享每个host要fork一个子进程。2、远程——httpssestreamable http。一个MCP可以服务于多个客户端。httpsse的模式下针对同一个客户端上行和下行时两套独立的消息流网络抖动时无法匹配streamable http在同一个逻辑断电可以post也可以get便于追踪调试。二者区分Function calling主要解决AI应用与LLM之间的交互解析出更规范的调用指令明确工具调用的需求MCP主要解决AI应用与工具之间的交互主要针对工具开发商提供的API不统一、开发语言不统一导致的问题。维度Function CallingMCP关注点AI应用与大模型的交互AI应用与工具的交互能力解决如何返回调用指令如何执行指令定位模型侧模型基础设施侧