自Anthropic公司推出MCP（Model Context Protocol）以来，关于其与Function Calling关系的讨论不绝于耳。其中流传最广、也最常见的一种说法是：MCP统一了Function Calling的协议，因此Function Calling未来将不再有存在的必要，甚至会被MCP取代。乍一看，这种说法似乎言之有理，毕竟两者都涉及工具调用，而MCP听起来更"标准"。然而，事实果真如此吗？

今天，我们将深入探讨Function Calling与MCP的真正关系，揭示它们在大模型领域所处的不同地位和扮演的独特角色。本文将基于最新的技术洞察和DeepChat项目的实际实现，为您详细阐述Function Calling的核心概念、运作机制、底层协议，并最终揭示它与MCP之间互补而非替代的深刻联系，甚至在同一链路中同时发挥价值的可能性。

一、Function Calling：大模型连接世界的"超能力"
首先，让我们从Function Calling的概念说起。在通常情况下，一个大型语言模型（LLM）一旦训练完成，其知识库就基本固定了。这意味着对于超出其训练数据范围的问题，模型往往无法给出令人满意的答复，要么回复"不知道"，要么"胡言乱语"。举个经典的问答例子：用户询问模型"上海明天的天气怎么样？"。如果模型只能从自身知识库中寻找答案，它显然无法回答这个实时性问题，因为它的知识可能截止于某个时间点（比如今年1月份）。

但如果模型拥有一种能力，能够调用外部的天气接口，获取上海最近几天的天气信息，那它是不是就能回答这个问题了呢？没错，这正是Function Calling所提供的核心能力。简单来说，Function Calling指的是模型与外部工具（或称函数）交互的一种能力。这些外部工具可以是多样的：有些可以用于查询天气，有些可以用于查询新闻，甚至有些可以用于发送邮件。本质上，这些"工具"就是编程语言中的函数。例如，查询天气工具可能对应着一个名为get_forecast的函数，你传入地区的经纬度，就能获取对应的天气预报结果。

所以，Function Calling的本质就是模型调用函数的一种能力。当模型调用函数并拿到返回结果后，它就可以从这个结果中总结出答案，并告诉用户，例如"上海明天的天气是阵雨，气温28度"。

重要澄清：Function Calling这个名字具有一定的误导性。虽然字面意思上是"函数调用"，但它本身并没有规定对应的函数到底是如何被调用的。它与实际的函数调用过程（例如通过HTTP接口或SDK函数执行）几乎没有关系。

Function Calling的核心作用在于，模型能够从可用的函数列表中"挑选"出它认为需要调用的函数，并解析出调用该函数所需的参数，以及后续能够解析该函数的执行结果。对于像GPT-4o这类闭源模型，我们无法直接与其交互，只能通过其API间接使用。因此，在大多数情况下，我们通常将Function Calling的概念延伸为"模型API调用函数的能力"。模型API与模型之间仅有一些转换逻辑，所以如果模型具有Function Calling能力，其对应的模型API也必然具备。

二、Function Calling的实际运作链路（DeepChat示例解析）
为了更具体地理解Function Calling的运作流程，我们以DeepChat项目为例进行深入剖析。DeepChat是一个开源的AI 智能体平台，支持多种云端和本地大语言模型，具备强大的搜索增强和工具调用能力。假设用户在DeepChat中输入"上海明天的天气怎么样？"。整个过程大致如下：

1. 用户发起请求
用户的问题首先发送给DeepChat桌面端。作为一个桌面AI助手应用，DeepChat在这里扮演了中间服务器的角色，负责协调用户与各种AI模型之间的交互。

2. DeepChat与模型API的首次交互
DeepChat接收到用户问题后，会将用户的问题（作为历史消息的一部分）和一份可用的工具列表（例如，weather_search工具，用于天气查询）一同发送给配置的模型API（可能是OpenAI、DeepSeek、Anthropic等任一支持的提供商）。

这个请求体中包含的关键字段有：
model: 指定要使用的模型，例如GPT-4o或DeepSeek-V3。
messages: 消息列表，第一次请求时通常只包含用户的查询。
tools: 这是重点！ 这是一个列表，其中包含了所有可用的工具的定义。每个工具定义包括工具名称（如weather_search）和parameters字段。parameters是一个JSON Schema，用于详细描述工具的输入参数。JSON Schema本质上是对另一个JSON结构（即函数参数）的描述，它规定了参数的类型（如string）、是否必须（required）等。例如，weather_search工具可能有一个location参数，类型为string，表示需要查询天气的地点。
stream: 根据DeepChat的配置决定是否需要流式返回内容。

3. 模型API的决策与工具使用请求
模型API接到请求后，会评估用户的问题。它"知道"自己无法直接回答实时天气问题，但发现tools列表中有一个weather_search工具。于是，模型决定使用这个weather_search工具。但请注意，模型本身没有能力直接调用工具。模型API会向DeepChat返回一个工具使用请求。这个请求的核心内容就是告诉DeepChat："我想调用weather_search工具，参数是location: '上海'。"

这个返回结果的核心部分通常包含在choices字段下的message中，明确指明了模型想要调用的函数名（function.name）和其对应的参数（function.arguments）。

4. DeepChat执行工具
DeepChat收到模型API的工具使用请求后，会调用对应的实际函数。根据DeepChat的架构，这里有几种可能的执行方式：
内置工具执行：如果是DeepChat内置的工具（如网络搜索、文件操作等），会直接执行相应的内部函数。
MCP工具执行：如果配置了MCP服务，DeepChat会通过其MCP客户端调用相应的MCP服务器上的工具。
外部API调用：直接调用第三方API获取数据（如天气API、新闻API等）。

在天气查询的例子中，DeepChat可能会调用天气API或者通过MCP服务获取上海的天气信息。

5. DeepChat与模型API的第二次交互
工具执行完毕后，DeepChat会拿到工具的返回结果（例如，上海明天的天气预报信息）。为了让模型能够基于这个结果生成最终答案，DeepChat会再次请求模型API。
这次请求的关键在于messages字段。它不再只包含用户的原始问题，而是会额外包含两部分重要信息：
模型之前选择的工具信息：即模型曾请求调用的工具名称和参数。
工具的执行结果：这是模型生成最终答案的关键信息。

tools列表通常仍然会包含在请求中，但模型在第二次响应中通常不会再选择使用工具。

6. 模型API生成最终答案
模型API在第二次接到请求时，从messages历史消息中获取到工具的执行结果。模型依据这个结果，结合用户问题，总结出一个最终的答案（例如，根据天气数据告知用户上海明天的天气情况）。

7. DeepChat返回答案给用户
模型API将最终答案返回给DeepChat，DeepChat通过其精美的界面将答案呈现给用户。根据DeepChat的特性，支持完整的Markdown渲染，还支持渲染图片、Mermaid图表、React代码、HTML等多模态内容，为用户提供丰富的交互体验。这个循环展现了Function Calling的强大之处：模型通过其"选择工具、请求工具、解析结果"的能力，实现了知识库的扩展和实时信息的获取。

三、MCP：统一的工具发现与调用协议
那么，MCP又是什么呢？它的作用环节在哪里？
MCP（Model Context Protocol）本质上是一套函数（工具）的发现与调用协议。它主要作用于服务器（或中间人）和实际的函数之间。

MCP规定了服务器如何发现可用的函数，以及如何标准化地调用这些函数。例如，它可能定义了一套统一的接口来查询有哪些天气查询服务，以及如何以统一的方式调用这些天气查询服务。MCP本身其实与模型并没有直接关系。它不关心模型是如何决定要调用哪个工具的，也不关心模型如何解析工具返回的结果。它只专注于工具的注册、发现和执行。

在DeepChat的实现中，具备出色的MCP支持，完整支持MCP协议中Resources/Prompts/Tools三大核心能力，支持StreamableHTTP/SSE/Stdio协议传输，内置Node.js运行环境，支持inMemory服务等。

四、Function Calling与MCP：互补而非替代的"天作之合"
现在，我们可以清晰地看到Function Calling和MCP之间的关系了。Function Calling作用在模型/模型API与中间服务器之间，它关注的是模型的"智能"部分：模型如何理解用户意图，如何从众多工具中"选择"出最合适的工具，如何解析工具执行结果并整合到最终答案中。它是模型"思考"和"决策"调用哪个工具的能力，以及与调用者之间传递工具信息的协议。

MCP作用在中间服务器与实际的函数之间，它关注的是工具的"执行"部分：如何标准化地发现这些工具，以及如何以统一的方式去调用它们，无论这些工具是HTTP接口、外部程序还是SDK函数。它是对工具生态系统和调用方式的标准化。它们在大模型处理链路中处于完全不同的环节，发挥着各自不可替代的价值。Function Calling是大模型的"大脑"，决定了要使用哪个"手脚"；而MCP则是"手脚"的"操作系统"，确保这些"手脚"能够被统一、高效地"驱动"。

五、DeepChat中的完美结合：同一链路中的协同工作
最能证明它们互补关系而非替代关系的是它们可以"同时出现"在同一个链路中，而DeepChat就是这种完美结合的绝佳例子。在DeepChat的实际运行中，我们可以看到这样的协同场景：
场景：用户请求执行代码分析
假设用户在DeepChat中询问："帮我分析一下这段Python代码的性能问题"，并上传了一个代码文件。
Function Calling层面的工作：
.模型API接收到请求，发现需要代码分析工具
.模型智能地选择code_analysis工具
.模型解析出需要的参数：文件路径、分析类型等
.模型请求DeepChat调用该工具

MCP层面的工作：
.DeepChat收到工具调用请求后，通过其MCP客户端连接到相应的MCP服务器
.MCP服务器可能是一个专门的代码分析服务，通过MCP协议标准化地暴露其能力
.DeepChat内置的Node.js运行环境可以直接执行代码分析工具，或连接到外部的MCP服务
.MCP协议确保了工具调用的标准化和可靠性

协同效果：
.Function Calling确保了模型能够智能地理解用户需求并选择合适的工具
.MCP确保了工具能够被标准化、可靠地执行
.最终用户获得了准确、详细的代码分析结果

通过这种方式，我们实现了在同一链路中同时使用Function Calling和MCP的效果。Function Calling负责模型层面的智能决策和协议交互，而MCP负责工具层面的统一管理和调用执行。它们协同工作，共同赋能大模型更强大、更灵活地与真实世界互动。

六、DeepChat的技术优势：两个协议的完美融合
DeepChat作为一个成熟的开源项目，展现了Function Calling与MCP协同工作的最佳实践：
统一的多模型支持
DeepChat支持几乎所有主流的大语言模型，包括OpenAI、DeepSeek、Anthropic、Gemini等云端模型，以及Ollama等本地模型。无论使用哪种模型，Function Calling的机制都是一致的，而底层的工具执行则通过MCP进行标准化管理。

丰富的工具生态
通过MCP协议的支持，DeepChat能够轻松集成各种工具：
.网络搜索工具（支持多种搜索引擎）
.代码执行环境
.文件操作工具
.外部API接口

这些工具通过MCP的标准化接口暴露给DeepChat，而模型则通过Function Calling机制智能地选择和使用这些工具。

用户友好的配置界面
DeepChat提供了极其用户友好的配置界面，美观清晰的工具调用显示，详细的工具调用调试窗口，自动格式化工具参数和返回数据。这些特性让用户能够清楚地看到Function Calling和MCP是如何协同工作的。

七、结语
因此，那种认为"MCP统一了Function Calling协议，Function Calling将没有存在必要"的说法是不准确的。Function Calling和MCP并非互相替代的关系，而是互补关系。它们在大模型领域所处的地位完全不同，在未来很长一段时间内，Function Calling和MCP都将同时存在，各自发挥自己的独特价值。DeepChat项目的成功实践充分证明了这一点。作为一个集成了两种协议优势的开源项目，DeepChat不仅展现了技术上的可行性，更体现了这种协同工作模式的实用价值。

理解了这一点，我们才能更清晰地把握大模型技术栈的全貌，并更有效地利用这些工具来构建强大的AI应用。希望今天的分享能帮助您彻底搞清楚Function Calling和MCP之间的关系，以及它们如何共同构建大模型与外部世界交互的"超级接口"。如果您对这个话题感兴趣，不妨去体验一下DeepChat项目，亲身感受Function Calling与MCP协同工作的魅力。相信您会对这两个协议的互补关系有更深刻的理解。