最近MCP继续持续大火，我们前一篇文章 MCP 很火，来看看我们直接给后台管理系统上一个 MCP？ 简单提到了使用 HTTP/SSE 方式的远程服务调用方式，今天我们要讲的是 Function Calling 和 MCP 的区别。
Function Calling: 我先自我介绍啊
Function Calling (本文可能简称为 函数调用)，是部分大模型中内置的意图识别能力，能通过大模型分析用户输入的自然语言，识别关联到传入的工具列表的意图中去。
请注意，大模型本身自己是不会直接去调用这些函数的。
大模型会根据函数调用的意图，生成一个函数调用的指令，然后让模型的调用方去执行。
我们通过 天气查询 示例来演示大模型如何调用函数。
sequenceDiagram
participant User as 用户
participant Client as 客户端
participant Model as 大模型
participant Server as 天气服务器
User->>Client: 1. 重庆天气如何
Client-->>Client: 2. 封装请求包体(模型，参数，工具库)
Client-->>Model: 3. 请求大模型
Model--)Model: 4. 识别到意图 `getWeather`，参数 城市=重庆
Model-->>Client: 5. 返回结果(包含意图)
Client-->>Server: 6. 如果意图是查询天气，请求天气服务器
Server--)Client: 7. 返回天气查询结果
Client-)User: 8. 返回天气结果
好像并没有什么问题是吧。
可是，随着工具越来越多，我们需要在 客户端 上写各种各样工具的调用和声明代码，工具越来越庞大不说，而且也更难维护了。
MCP: 兄弟萌我来了
行，那就声明一种协议，用来解决掉这些问题：
MCP："都别动，我来先给你们起点名字。"
- MCP服务器：刚才的天气服务器
- MCP客户端：刚才的客户端
然后在分别给一些职责：
- MCP服务器：负责声明 MCP 工具，提供 工具调用 的功能
- MCP客户端：负责管理和连接若干的 MCP服务器，作为 大模型和 MCP服务器之间的桥梁
于是，交互逻辑变了：
sequenceDiagram
participant User as 用户
participant Client as 客户端(内置MCP客户端)
participant Model as 大模型
participant ServerA as 天气MCP服务器
participant ServerB as 文件MCP服务器
User->>Client: 1. 重庆天气如何
Client-->>ServerA: 2. 你有什么工具吗(tool/list)？
Client-->>ServerB: 2. 你有什么工具吗(tool/list)？
ServerA--)Client: 3. 我可以查天气
ServerB--)Client: 3. 我可以存文件
Client--)Client: 4. 我整理一下所有工具
Client-->>Model: 5. 帮我识别意图(tools: [查天气，存文件],用户: 重庆天气如何)
Model--)Client: 6. 用户意思是要查天气(tool: 查天气,city: 重庆)
Client-->>ServerA: 7. 调用天气服务(tool/call)
ServerA--)Client: 8. 天气服务返回(天气)
Client-->>Model: 9. 帮我整理一下，天气服务器返回数据太`JSON`了
Model--)Client: 10. 整理好了（哇，40℃，人家好热呀～）
Client-)User: 11. 哇，40℃，人家好热呀～
MCP: 知道我哪里最厉害吗？
在没有 MCP 之前，Function Calling 请求第三方往往需要在客户端内编写代码，如果需要对接的服务有很多，而且标准不统一，客户端往往需要写大量的代码。
通过 MCP 标准协议，客户端不再需要干这些活，而把函数声明和调用逻辑交给 MCP 服务器，MCP客户端只需要整理和执行调用即可。
解耦之后，约定了标准的大模型通信协议和接口，实现了声明和调用分离，这样，只要对方实现了 MCP 服务器，那就可以直接接入到支持 MCP 的客户端中来。
总结
今天用了两个对比图和简单的文字来总结了一下 Function Calling 和 MCP 的关系，如有错误，欢迎指正。
我们在 SPMS 项目中也实现了一部分 MCP 的工具，可以体验一下：
Github: github.com/s-pms/SPMS-...
Bye~