从Function Call到MCP：大模型如何调用外部工具

大语言模型虽然拥有强大的生成和理解能力，但它本质上是一个「预训练」模型。

也就是说，它的知识来源是训练语料，而非实时数据。它对2023 年之后的事实、个人专属数据、动态数据库等缺乏了解。例如：

• 它不知道你上周提交的报销单现在审批到哪一步；

• 它无法直接读取某个法务系统中的案件明细；

• 它也没法查看最新的天气或股市数据。

而这些问题的答案，往往存在于「外部系统接口」中。于是，我们希望让模型在需要时，能像一个程序员一样，调用接口、获取数据、完成任务。

这正是Function Call 的价值所在。

例如在DeepSeek 等模型平台中，用户可以使用联网搜索插件获取实时资讯。这其实就是典型的 Function Call 实践：

1. 插件以 schema 的形式注册给模型（如：search_news）；

2. 模型根据用户问题判断是否需要搜索；

3. 发起联网接口调用，获取搜索结果整合至提示词中再继续生成回答。

调用外部工具的能力，也是构建Agent 应用中的核心能力之一：让智能体根据当前任务自主决定是否调用工具、调用哪个工具。

Function Call 是指大模型在回答用户问题时，根据内置的函数定义（Function Schema）判断是否需要调用某个外部工具，来获取实时或结构化数据。

例如：

用户问：“张三还有多少钱未还款？”

模型可能会调用一个`getLoanStatus(user_id)` 的函数，并传入“张三”作为参数，获取并整合接口返回的结果。

实现的关键在于：

1. 将所有支持调用的接口封装成 JSON 格式的 Function Schema；

2. 在系统提示词中注入这些 Schema；

3. 模型根据定义自动选择并传参发起调用。

PS：Schema可以简单理解为接口的说明文档，告诉模型：这个函数叫什么、是干什么的、需要哪些参数、返回什么结构。只不过这个说明文档是专门为大模型定制的格式，让模型能 "看懂" 并参与调用。

问题来了，如果有很多个接口怎么办？

一个真实的业务场景中，可能会涉及几十甚至上百个不同的接口，例如：数据库访问、联网搜索、OCR接入、地图服务、图表生成等

如果每个接口都要手动定义schema、注册给模型，不仅繁琐、重复度高，而且难以管理。

此外，如果这些接口还要被多个Agent 共享、或部署到多个平台中（如 Coze、dify、Fastgpt），就更需要统一标准、集中管理。而且，不同的大模型（如GPT、GLM、DS等）在函数调用格式可能存在差异，MCP还能作为适配层，让不同模型通过用同一套标准协议调用工具，实现模型与工具之间的解耦。

这正是 MCP 的价值所在。

MCP，全称 Model Context Protocol（模型上下文协议），本质上是一套协议规范，用于将多个外部工具/服务描述为大模型可识别、可调用的格式（即 Function Schema），并集中暴露出来供模型加载和使用。

你可以这样理解MCP 的作用：

把多个 API 自动打包成 Function Schema 形式；

暴露统一的插件服务入口；

供支持 MCP 协议的模型应用平台（如 Dify）加载；

MCP 不再需要每个工具都单独编写 schema，而是基于标准化的 OpenAPI 接口描述（如 swagger.json）生成统一格式，大大降低了工具管理和接入成本。

根据我最近使用dify的mcp功能的经验，推测这个机制的整体流程如下：

1. 研发写好接口（如RESTful API），采用符合OpenAPI 规范的文档格式（如 swagger.yaml 或 JSON）；

2. MCP Server 读取接口文档，自动将每个接口生成 Function Schema（即工具的调用描述）；

3. 支持MCP 协议的平台（如 Dify）作为 MCP Client，连接 MCP Server，加载所有工具的 Function Schema；

4. MCP Client（如 Dify）会将这些工具的 Schema 注入到大模型的提示词（Prompt）中；

5. 大模型收到用户问题后，判断是否需要调用函数，如果需要，生成符合工具参数要求的结构化请求；

6. MCP Client解析不同模型生成的函数调用请求格式，转换成符合MCP协议的标准格式，和MCP Server通信；
7. MCP Server通过执行相应的工具逻辑，并返回结果供大模型处理。

Function Call 是让大模型具备“工具使用能力”的关键机制。

MCP 是让这套能力变得“可管理、可扩展、可组合”的上下文协议标准。

它们协同工作，正逐步构建起以“智能体 + 工具链”为核心的智能服务生态。