坤哥看了都能懂的MCP和Function Calling异同
MCP和Function_Calling
最近跟朋友们进行交流,发现很多人面试都被问到了 MCP和Function_Calling的区别,我听到我就疑惑了,这俩本质上区别其实并不大,怎么还能成为热点问题?
因此写下这篇文档,尝试用举例子的方式说明这两者的异同。
场景
场景:你是老板,你想喝一杯咖啡。
Function Calling(函数调用)
就像你点咖啡的时候,直接告诉咖啡机:
“做一杯美式,参数:大杯,加冰,不加糖。”
咖啡机(模型)就调用了 make_coffee(size="large", iced=True, sugar=False) 这个函数。
它的职责很直接:把参数塞给指定函数,然后返回结果。
- 优点:快速,直接。
- 缺点:咖啡机只会做咖啡,点披萨它完全懵逼。
MCP
这个就像你雇了一个万能助理(MCP Agent),他手里有“餐饮黄页”一样的目录,里面不仅有咖啡机,还有披萨店、打印机、日历……
当你说:
“我想开个下午茶,帮我安排一下,有咖啡、有小点心。”
MCP 助理会去翻目录:
- 找到“咖啡机”的接口 → 下单咖啡
- 找到“点心店”的接口 → 下单点心
- 然后把结果组合起来反馈给你。
它的职责是:帮模型动态发现、组织和调用各种“工具/服务”,而不仅仅是调用一个固定的函数。
- 优点:灵活、可扩展,能协调多个服务。
- 缺点:系统设计更复杂,需要事先约定协议。
看到这里是不是还有些懵逼,你或许还想问:“ Function Calling 不也可以传入多个工具方法么? ” 很好,你说到点子上了,我再用上面的例子举例:
Function Calling
就像你桌子上放了几台“专用小机器”:
- 咖啡机
- 披萨机
- 打印机
当你说“我要咖啡”,模型只会在桌子上的这些机器里挑一个来按按钮。
它的“工具列表”是你预先硬编码传进去的,模型并不知道“外面还有什么别的工具”。
MCP
就像你给了助理一个“万能黄页 + 打电话协议”:
- 工具不必一次性全摆在你桌上
- 助理知道去哪里查 目录,再去调用需要的服务
- 工具可以不断扩展:今天新增了“买花服务”,助理就能自动发现
换句话说:
- Function Calling 的世界是:一堆函数装在盒子里,模型只能在盒子里选。
- MCP 的世界是:模型能打开一扇门,门外是一整片“服务市场”,还会动态更新。
所以:Function Calling 也能处理多个工具,但 MCP 的关注点是“动态发现 & 通信协议”,而不仅仅是调用几个函数。
补充
Function Calling 的详细调用步骤
-
发起第一次模型调用
应用程序首先向大模型发起一个包含用户问题与模型可调用工具清单的请求。 -
接收模型的工具调用指令(工具名称与入参)
若模型判断需要调用外部工具,会返回一个JSON格式的指令,用于告知应用程序需要执行的函数与入参,你在代码里循环处理这段结果进行代码调用。若模型判断无需调用工具,会返回自然语言格式的回复。
-
在应用端运行工具
应用程序接收到工具指令后,需要运行工具,获得工具输出结果。 -
发起第二次模型调用
获取到工具输出结果后,需添加至模型的上下文(messages),再次发起模型调用。 -
接收来自模型的最终响应
模型将工具输出结果和用户问题信息整合,生成自然语言格式的回复。
MCP的详细调用步骤
-
发起模型调用请求
应用程序向大模型发起请求,告知用户问题,同时提供 MCP 服务端地址所有查询出的包含的所有工具。 -
模型生成工具调用意图
模型判断用户问题是否需要调用工具,如果需要,会生成一个工具调用意图(包含工具名称和参数),但不会在本地执行函数。 -
通过 MCP 协议发送请求到远程服务
应用程序将模型生成的调用意图,通过 MCP 协议(HTTP、WebSocket 等)发送给远程 MCP 服务端。 -
远程服务端执行工具
MCP 服务端接收到请求后,运行对应的工具方法,生成执行结果,并返回给调用端。调用端无需知道方法实现细节,只负责接收结果。
-
模型接收工具输出结果生成最终响应
模型在上下文中使用远程工具返回的结果,整合用户问题,生成自然语言格式的最终回复。
更多推荐



所有评论(0)