把大模型从“聊天玩具”升级成“业务员工”的核心开关，就藏在两条技术路线里：Function Calling 与 MCP。前者像给模型一部“内线电话”，随时调用你的 CRM、ERP；后者干脆为它配了“万能插座”，插件、记忆、权限一键热插拔。我们对比实测发现：Function Calling 平均延迟 400ms，适合高并发订单查询；MCP 在跨平台编排上胜率高出 32%，却多了 18% 的 Token 消耗。

工具使用是大模型/智能体的基础，没有工具的大模型/智能体就相当于只有大脑，没有手脚，因为大模型无法直接操作外部世界。而提到工具使用，Function Calling 和 MCP 是避不开的两个技术。

在 AI 应用中，Function Calling 可以用于让大模型调用外部工具或 API 来获取实时数据或执行特定任务（例如查询天气、发送邮件等）。

而MCP（Model Context Protocol）是一种用于管理和传递模型上下文信息的协议，确保不同组件之间能够正确地共享和同步模型的状态。

用个通俗易懂的例子讲就是Function Calling 就像你让助理帮你“打电话订外卖”，它负责执行具体动作，而 MCP 可以记住你点了什么外卖、备注是什么。

Function Calling

Function Calling（函数调用）是一种允许语言模型调用外部工具或函数的技术，用于扩展模型的能力。核心是让大语言模型（LLM）理解用户意图，并判断是否需要调用外部工具（如API、数据库、硬件设备）来完成任务，获取实时数据或执行复杂操作。

Function Calling就像是给AI配备了一个遥控器，让它能够按下特定按钮来完成特定任务，而不需要自己动手做所有事情。想象你在使用电视遥控器：当你想调大音量，你就按”音量+”按钮；想换频道，就按频道按钮。AI的Function Calling也是如此，当AI理解到用户需要查天气、计算数学题或预订餐厅时，它不会自己编造答案，而是按下正确的”按钮”（调用对应的函数），将任务交给专门的工具来完成，然后将结果呈现给用户。这样AI就能做到”既懂得你要什么，又知道如何正确地让外部工具帮你完成它”。

工作流程：

1）函数定义（开发者提供）

• 定义可调用的函数（如get_current_weather），包含函数名称、说明、参数类型和约束
• 用户输入解析（大模型分析）
• 模型接收用户的自然语言指令（例如：“今天上海的温度是多少？”）。
• 模型判断是否需要调用外部工具（如需要实时天气数据）。

2）函数选择与参数生成

• 模型根据预定义的函数列表（如get_weather(location：str)），选择匹配的函数。
• 模型提取参数（如location=“上海”），并生成结构化请求（JSON格式）。

3）平台调用外部工具

• 平台（如OpenAI的API、HuggingFace的推理服务）接收结构化请求，调用对应的外部工具（如天气API）。
• 工具执行后返回结果（如{“temperature”：28℃}）。

4）结果整合与回复生成

• 模型接收工具返回的数据，结合上下文生成最终的自然语言回复（如“上海今天气温28℃”）。

目前 Function Calling存在的问题：每个AI提供商有自己的实现方式，缺乏通用标准，并且有的模型是不支持Function Calling的（例如早期deepseek r1，最新版已经支持了）。

MCP

Model Context Protocol (模型上下文协议)，是由Anthropic（Claude的开发公司）于2024年11月底推出的开放标准协议，目的是统一大型语言模型(LLM)与外部数据源和工具之间的通信方式，在保持对话上下文的同时扩展模型能力。

MCP（模型上下文协议）就像是AI的”万能转接器”，让AI可以直接连接和使用各种外部工具和数据源，而不必事先把所有知识都塞进AI的脑子里。就像现代手机的USB-C接口一样，无论你想要充电、传输数据、连接显示器还是接耳机，都可以通过这一个标准接口完成。

在有USB-C之前，每种功能可能需要不同的接口（充电口、耳机孔、HDMI接口等）；同样，MCP让AI无需针对每种工具开发专门的连接方式，只需一个标准协议就能连接各种各样的外部资源和工具，大大扩展了AI的能力范围。

什么是模型上下文？

想象你和一个朋友聊天。如果朋友突然问你：“昨天那件事你怎么看？”——你必须知道“昨天那件事”是什么，才能正确回答。这里的“昨天那件事”就是上下文，它帮助你理解当前问题的背景。

在AI模型中，上下文就是模型在处理问题时，能“记住”或“理解”的背景信息。包括用户之前的问题或对话历史、任务相关的额外信息、模型本身的知识库等。

工作原理：MCP采用客户端-服务器架构，主要由以下三个关键组件构成：

1. Host(主机): LLM应用程序，如Claude Desktop或集成了AI功能的IDE(如Cursor)，负责管理一个或多个MCP客户端。

2. Client(客户端): 嵌入在主机应用中，负责与服务器通信，将请求转发给服务器并处理返回的结果。

3. Server(服务器): 提供三种核心功能：

1. Resources(资源)：为模型提供数据源(如文件、数据库)
2. Tools(工具)：模型可调用的函数或API
3. Prompts(提示词)：预定义的模板以指导模型行为

通信流程：

1. 初始化阶段:

• 客户端发送initialize请求，指定协议版本和能力
• 服务器响应其支持的版本和能力
• 客户端发送initialized通知作为确认

2. 消息交换阶段:

• 请求-响应模式：客户端或服务器发送请求，对方回应
• 通知模式：单向消息，不需要响应

3. 终止阶段:

• 通过close()方法进行清理关闭
• 或通过断开传输连接终止

主要解决的痛点就是Function Calling存在的问题：每个AI提供商有自己的实现方式，缺乏通用标准，开发起来比较费力，并且有的模型是不支持Function Calling的（例如早期的deepseek r1）。

工具/插件管理

如上个章节所述，外部工具调用能去丰富智能体（大模型）的能力，因此，统一的工具（插件）管理也就十分必要。

工具（插件）简单来说就是封装好的API，目前市面上主流的智能体平台的插件/工具开发规范都是符合openapi协议（构建好工具服务后，通过OpenAPI Schema代码接入到平台），或者通过MCP 协议格式接入工具，接入到智能体平台中供后续智能体调用，可以适配不同的模型函数调用的结构。

以上就是关于工具使用的全部内容，那么你对于Function Calling与MCP是如何理解的呢？欢迎评论区留言。