学习资料 / AI基础

MCP 与 Function Calling

创建 更新

这篇是对视频 《MCP 与 Function Calling 到底什么关系》 的整理版。视频的核心观点很明确：MCP 和 Function Calling 不是替代关系，也不是同一层东西；Function Calling 更靠近模型，MCP 更靠近工具接入。

如果只记一句话：

核心结论

Function Calling 解决的是“模型如何用结构化方式提出工具调用”；MCP 解决的是“应用如何用标准协议发现、连接和调用外部工具”。它们可以单独使用，也经常组合使用。

视频封面：MCP 与 Function Calling 到底什么关系

一、为什么大家容易把它们混在一起？

因为两者都出现在“让大模型使用工具”的语境里。

当用户问一个模型：“帮我查天气”“帮我读文件”“帮我查数据库”时，模型本身并不能直接访问天气 API、文件系统或数据库。真实世界的动作必须由应用代码来完成。于是就出现了两个问题：

  1. 模型怎么表达“我要调用哪个工具、参数是什么”？
  2. 应用怎么找到这些工具，并用统一方式调用它们？

第一个问题对应 Function Calling。第二个问题对应 MCP。

MCP 与 Function Calling 的分层关系

这也是视频里最重要的纠偏：不要把 MCP 看成 Function Calling 的升级版，也不要把 Function Calling 看成 MCP 的简化版。它们处在不同边界上。

二、Function Calling 到底是什么？

Function Calling 可以理解为模型和应用之间的一种结构化约定。

普通聊天里，模型输出自然语言；Function Calling 场景里，模型可以输出一段结构化数据，告诉应用：“我认为现在应该调用某个函数，参数是这些。”

关键点是：模型不执行函数，应用才执行函数。

完整链路大概是这样：

Function Calling 的完整链路

以“查询天气”为例：

  1. 开发者先把工具说明传给模型，比如 get_weather(city)。
  2. 用户问：“上海今天适合出门吗？”
  3. 模型判断需要查天气，于是返回工具名和参数，例如 get_weather + city=上海。
  4. 应用代码解析这段结构化输出，真正调用天气 API。
  5. 应用把 API 返回结果放回上下文。
  6. 模型再基于工具结果生成自然语言回答。

所以 Function Calling 的价值不是“多了一个函数调用语法”，而是让模型输出从不可控的自然语言，变成应用更容易解析、校验和执行的结构化调用意图。

三、MCP 到底是什么？

MCP，全称 Model Context Protocol。它关注的不是模型输出格式，而是外部能力怎么被标准化暴露出来。

可以把 MCP 看成一套“AI 应用连接外部世界”的协议。一个 MCP Server 可以告诉应用：我这里有哪些工具、资源、提示模板；应用里的 MCP Client 再按统一协议去发现和调用它们。

MCP 的 Client 与 Server 模型

MCP 常见的三类能力是：

类型解决什么问题例子
Tools可以执行的动作查数据库、读文件、调用接口、发请求
Resources可以读取的上下文资源文档、仓库文件、数据记录、配置
Prompts可复用的提示模板固定分析流程、代码审查模板

它真正想解决的是“工具生态碎片化”的问题。

没有 MCP 时，每个应用都要自己写一套接入逻辑：这个应用接数据库用一种方式，那个应用接文件系统又是一种方式。MCP 把这些能力包装成统一协议后，新的 AI 应用只要支持 MCP Client，就能接入已有的 MCP Server。

四、二者的关键区别

可以从四个角度理解：

对比项Function CallingMCP
所在边界模型 ↔ 应用应用 ↔ 工具 / 资源
关注重点模型如何表达工具调用意图工具如何被标准化发现和调用
谁执行动作应用代码执行函数MCP Server 对接真实系统
典型价值结构化、可校验、便于回填上下文可复用、可扩展、跨应用接入

最容易误解的一点是：Function Calling 不是“工具系统的全部”，它只是让模型说清楚自己要调用什么。MCP 也不是“模型调用工具的全部”，它不决定模型什么时候该调用工具。

五、它们可以怎么一起用？

视频最后强调了一个很实用的组合方式：模型通过 Function Calling 决定调用哪个工具；应用通过 MCP 去发现并执行这个工具。

Function Calling 与 MCP 同时使用

组合后的流程可以这样理解：

  1. 应用从 MCP Server 获取可用工具列表。
  2. 应用把这些工具描述整理成模型可理解的 Function Calling schema。
  3. 用户发起任务。
  4. 模型返回某个工具调用和参数。
  5. 应用把这个调用转发给对应的 MCP Server。
  6. MCP Server 执行真实动作并返回结果。
  7. 应用把结果交回模型，模型生成最终回答。

这样一来，Function Calling 负责“模型侧决策表达”，MCP 负责“工具侧标准接入”。两者配合时，边界反而更清楚。

六、什么时候用哪个？

不要从名词出发，而要从工程边界出发。

什么时候用 Function Calling，什么时候用 MCP

如果你的应用只有两三个自己写死的工具，比如查订单、查库存、查用户信息，直接用 Function Calling 就够了。工具少、边界清楚、调用逻辑都在应用内部，没必要额外引入协议层。

如果你要让多个 AI 应用复用同一批外部能力，比如文件系统、GitHub、数据库、公司内部 API，那么 MCP 的价值就开始出现。它把“怎么接工具”沉淀成可复用的 Server。

如果你在做更像 Agent 的系统，既需要模型根据任务动态选择工具，又希望工具来自一个可扩展生态，那就很适合把两者组合起来。

如果需求只是固定流程，比如用户点按钮后跑一个确定的后端任务，可能两者都不需要。普通代码、普通 API、普通工作流会更简单。

七、这支视频的技术启发

这支视频最有价值的地方，不是介绍了两个名词，而是提醒我们按“协议边界”理解 AI 工程：

  1. 模型边界：模型负责理解任务、选择动作、生成结构化意图。
  2. 应用边界：应用负责保存状态、校验参数、执行编排、处理权限。
  3. 工具边界：工具负责连接真实世界，比如文件、数据库、浏览器、业务 API。

把边界分清后，很多争论会自然消失。MCP 和 Function Calling 不是谁取代谁，而是分别标准化不同的一段链路。

更直白一点：Function Calling 是模型开口说“我要做什么”的格式；MCP 是工具对外说“我能做什么、你怎么调我”的格式。

八、面试 / 实战速记

如果在面试或技术讨论中被问到它们的关系，可以这样回答：

MCP 和 Function Calling 都服务于 LLM 使用工具，但层级不同。Function Calling 是模型到应用的结构化输出机制，让模型返回工具名和参数；MCP 是应用到外部工具的标准接入协议，让工具、资源、提示模板以统一方式暴露。真实系统里，应用可以先通过 MCP 获取工具，再把工具 schema 暴露给模型做 Function Calling，最后把调用转发给 MCP Server 执行。

再压缩成一句：

Function Calling 解决“模型怎么叫工具”，MCP 解决“工具怎么接进来”。

参考资料