MCP 与 Function Calling 的区别
很多开发者刚接触 MCP 时会问：它和大模型 Function Calling（函数调用）是不是一回事？这篇文章用最直白的方式讲清两者定位，以及为什么在语音助手场景里它们其实是「上下游」关系。
Function Calling 是什么
Function Calling 是大模型推理时的一种能力：模型在回答前，先输出一个结构化的「函数调用意图」（函数名 + 参数 JSON），由你的程序执行真实函数后把结果回填给模型，模型再基于结果组织自然语言回答。
它的本质是「让模型能调用你预先定义好的函数」。OpenAI、Anthropic、通义等各家 API 都提供了类似机制，只是协议细节各不相同。
MCP 是什么
MCP 解决的是「工具怎么被描述、被发现、被调用」的标准化问题。一个 MCP Server 通过 JSON-RPC 暴露三类能力：tools（工具）、resources（资源）、prompts（提示词模板）。
MCP Client 可以动态地向 Server 拉取工具清单与 schema，而不需要在代码里写死每个函数的签名。这带来的最大改变是：工具可以热插拔，助手可以随时发现新能力。
两者的关系：MCP 是外挂工具箱，Function Calling 是手
可以这样理解：Function Calling 是模型「伸出手去调用」的动作能力，MCP 是「工具箱本身」以及工具箱的统一接口标准。
实际运行时它们通常串成一条链：助手（MCP Client）通过 MCP 协议发现并拿到工具 schema → 模型基于 schema 决定调用哪个工具并产出 Function Calling 参数 → 你的程序执行 → 结果经 MCP 协议返回。
所以二者不是二选一，而是互补：Function Calling 是模型侧能力，MCP 是工具侧标准。
为什么语音助手场景尤其需要 MCP 网关
语音助手（如小智）有几个特点：设备端上下文预算极其有限、工具数量可以很多、调用必须低延迟可审计。如果几十个工具的完整描述一次性塞给模型，对话质量会明显下降。
MCP Gateway 的做法是把「工具管理」集中到网关上：按租户分配应用、按需渐进披露技能、每次调用做鉴权与频控、全程留审计日志。助手侧只面对一个稳定端点，工具侧的增删改都不需要动设备端配置。