关于Function Calling 和 MCP 必须对普通AI程序员和普通人说清楚的事

背景

这几天，团队里的同学在一个项目中使用了LLM的能力。他突然告诉我，现在有一个MCP很牛逼，可以让大模型直接进行各种调用，提高性能…………

看到这里，其实就感觉出问题了：
1、 MCP本质上是Function Calling的标准化
2、Function Calling本质上不是“大模型直接进行各种调用”（关键在这个调用的主体上）

Function Calling的解释

Function Calling的执行主体
Function Calling的实际执行是由调用LLM的客户端或业务系统完成的，而非LLM本身。LLM仅负责决策过程，包括判断是否需要调用函数、选择合适函数以及解析参数，但不会直接执行函数调用。

也就是说，不管你是写代码，还是用dify等，你必须做的事情是：

• 【你的代码】向【LLM】发送用户查询prompt和函数描述
• 【LLM】根据查询prompt和函数描述，返回的JSON格式的，适合这个问题的决策结果——也就是函数描述中，哪个函数最合适
• 【你的代码】执行这个函数决策结果对应的真正函数（具体是本地调用还是远程调用，LLM并不知道）
• 最后，【你的代码】将函数结果连同前面的messages一起，发送【LLM】进行最终的自然语言组织

这里咱们都不用画图了，文字很清楚，可以看到上面过程中，有两次“发送”，所以：

• Function Calling不是LLM帮你执行，是你自己执行
• 使用Function Calling增强，你和LLM至少交互两次

Function Calling这个术语应当重新定义

从技术本质来看，"Function Calling"这个术语存在概念误导性，更精确的定义应该是 “LLM-Assisted Function Invocation”（大模型辅助函数调用）或 “Do Function Calling With LLM”。这个命名更符合以下技术事实：

1. 执行主体错位
   传统编程中的"calling"隐含执行动作，但LLM仅生成调用指令而非执行。
   例如当用户问"北京天气如何？“时：
   LLM输出：{“function”:“get_weather”,“params”:{“location”:“北京”}}（决策）
   业务系统执行：weatherAPI.get(” 北京")（真实调用）
   更准确的类比是函数调用规划器而非调用者

2. 行业术语修正建议
   为避免混淆，建议以后大家用以下术语分层表述：

层级	更合理的术语	会导致误导的表述
决策层	LLM辅助工具调用规划	Function Calling
执行层	业务部分执行函数	LLM执行函数

关于MCP

使用MCP协议，并不会减少业务端与模型之间的基础调用次数，因为无论是原生Function Calling还是MCP，都需要至少两次模型交互（首次请求生成工具调用指令，二次请求整合结果）。其核心差异在于协议标准化程度，而非调用次数优化。MCP通过统一接口降低了多工具集成的开发成本，但未改变底层交互范式。

响应速度的影响因素
终端响应速度主要受以下因素制约，MCP无法直接优化：

1. 网络延迟：工具调用仍需通过客户端中转；
2. 模型推理时间：生成工具调用指令和最终响应仍需模型计算；
3. 工具执行耗时：如调用慢速API或本地复杂计算。

MCP的潜在优势在于减少开发阶段的适配时间，而非运行时性能。

MCP的真正价值场景

1. 跨模型兼容性：避免为不同模型重写Function Calling逻辑；
2. 复杂任务编排：通过标准化协议更稳定地协调多工具调用（如同时查询天气+航班+酒店）；
3. 安全控制：本地MCPServer可隔离敏感数据，避免直接暴露给模型厂商。

这些特性对长期维护成本和系统扩展性更有意义。