Function Calling、Tool Calling 与 MCP：一次讲清三者的区别与关系

Function Calling、Tool Calling 与 MCP一次讲清三者的区别与关系这三个概念经常被混用但它们分属三个不同的维度。本文从定位、机制、架构三个层面彻底厘清它们的边界与协作关系。一、一句话定位概念本质定位谁定义的解决什么问题类比Function Calling历史术语 / 特定 APIOpenAI (2023)最早让 LLM 输出结构化 JSON 的专有 API 名称诺基亚时代的手机上网Tool Calling通用能力机制行业共识 / 各厂商LLM 识别意图并请求外部执行的通用范式智能手机的 App 调用机制MCP开放连接协议Anthropic (2024)AI 应用与工具/数据之间的标准化通信标准USB-C / HTTP 协议一句话总结Function Calling 是过去的名字Tool Calling 是现在的能力MCP 是未来的标准。二、逐一拆解2.1 Function Calling一个过时的专有名词起源2023 年 6 月OpenAI 在 GPT API 中首次推出functions参数让模型能在对话中输出结构化的函数调用请求。演变OpenAI 后来将其升级并重命名为tools支持 function、code_interpreter、retrieval 等多种类型。其他厂商Claude、Gemini也各自有不同的字段命名。现状现在说 “Function Calling” 通常是在泛指这类能力或者特指 OpenAI 早期的旧版 API。它不是一个行业标准而是一个历史产物。2.2 Tool Calling当前的通用能力范式定义指任何 LLM 通过微调或系统提示学会在对话中输出结构化工具调用请求不限于函数还包括搜索、代码执行、文件操作等的通用机制。本质它是模型侧的能力。无论叫什么名字OpenAI 叫toolsClaude 叫tool_useGemini 叫function_calling本质上都是 Tool Calling。地位它是当前所有 AI Agent 的基础是模型知道什么时候该用工具、怎么用的核心推理能力。2.3 MCP未来的基础设施标准定义Model Context Protocol一个独立于模型的开放协议。它不关心模型怎么调用工具只关心工具如何被标准化地描述、发现和连接。架构采用 Client-Server 架构。工具提供方只需实现一个 MCP Server任何支持 MCP 的 AI 应用MCP Client都能自动发现并使用该工具。解决的问题传统 Tool Calling 时代每个 AI 应用都要为每个工具单独写适配代码这是M×N 的紧耦合问题。MCP 将集成成本降为MN。类比就像 USB 标准出现之前每个外设都有专用接口MCP 就是 AI 工具生态的 USB-C。三、三者的关系链┌─────────────┐ 标准化工具定义 ┌─────────────┐ │ MCP Server │ ──────────────────────────► │ MCP Client │ │ (工具提供方) │ │ (AI 应用) │ └─────────────┘ └──────┬──────┘ │ 自动转换为对应格式 │ ▼ ┌─────────────────┐ │ Tool Calling │ │ (模型能力机制) │ └────────┬────────┘ │ ┌────────────────────┼────────────────────┐ ▼ ▼ ▼ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ OpenAI API │ │ Claude API │ │ Gemini API │ └────────────┘ └────────────┘ └────────────┘关系总结MCP 是协议层将标准化的工具定义传递给 AI 应用AI 应用MCP Client将其转换后通过Tool Calling机制发送给大模型Function Calling只是 Tool Calling 在 OpenAI 早期 API 中的历史名称。⚠️ MCP 并没有替代 Tool Calling而是封装和规范了它。底层依然依赖模型的 Tool Calling 能力。四、JSON 定义看似相同实则不同单看 JSON 的字段结构都有name,description,parameters它们确实几乎一模一样。但区别不在于JSON 长什么样而在于这个 JSON 是谁定义的、在哪里定义的、如何被消费的。4.1 传统 Tool Calling JSON硬编码在应用代码中# 写在你的 Python/JS 应用中随代码部署tools[{type:function,function:{# OpenAI 特有嵌套结构name:get_weather,description:Get current weather,parameters:{...}}}]responseopenai.chat.completions.create(toolstools,...)4.2 MCP Tool Definition JSON由 Server 动态返回// MCP Server 通过 tools/list 返回的标准响应 { tools: [ { name: get_weather, description: Get current weather, inputSchema: { ... }, // 扁平化、标准化的字段名 annotations: { // MCP 特有UI/UX hints title: Weather Check, readOnlyHint: true } } ] }4.3 关键差异对比特征传统 Tool Calling JSONMCP Tool Definition JSON定义位置硬编码在 AI 应用代码中动态由 MCP Server 提供字段风格各厂商私有function.parameters标准化扁平结构inputSchema更新方式修改需重新部署应用Server 端修改Client 自动感知额外语义仅函数签名支持资源绑定、Prompt 模板关联、annotations传输协议各厂商私有 HTTP API统一 JSON-RPC 2.0本质差异传统 Tool Calling 的 JSON 是静态配置MCP 的 JSON 是动态发现的服务契约。五、核心区别总结三个维度维度一定位不同——机制 vs 协议Tool Calling是大模型的一种推理机制解决模型如何表达意图、输出结构化参数的问题。MCP是一个应用层通信协议解决AI 应用如何标准化地连接外部工具和数据的问题。Tool Calling 是引擎MCP 是变速箱。维度二集成模式不同——M×N vs MN传统 Tool Calling每个 AI 应用 × 每个工具 M×N 个适配器紧耦合。MCPM 个应用 N 个 MCP Server MN即插即用解耦。维度三生命周期不同——静态 vs 动态Tool Calling 的工具定义通常是硬编码的修改需要重新部署。MCP 的工具定义是运行时动态发现的支持热更新、资源绑定、安全授权等高级特性。六、常见误区澄清❌ 错误说法✅ 正确理解“MCP 就是新版的 Function Calling”MCP 是 Tool Calling 之上的标准化协议层“用了 MCP 就不用 Tool Calling 了”MCP 底层依然依赖模型的 Tool Calling 能力只是做了标准化转换“它们 JSON 格式不一样所以是不同技术”核心 Schema 相似但 MCP 增加了动态发现和元数据语义“MCP 取代了 Function Calling”它们不在同一层无从取代七、面试回答模板这三个概念其实不在同一个层面上Function Calling是 OpenAI 2023 年推出的专有 API 名称现在已被业界泛化为对这类能力的统称但严格来说它是一个历史术语。Tool Calling是当前大模型的通用能力范式指模型识别意图并输出结构化调用请求的机制是所有 AI Agent 的基础。各家厂商实现不同但本质相同。MCP是 2024 年出现的开放连接协议位于 Tool Calling 之上。它不替代 Tool Calling而是将工具的定义和发现标准化让同一个工具能无缝接入任何支持 MCP 的 AI 应用解决了 Tool Calling 时代 M×N 集成碎片化的问题。简单说Function Calling 是过去的名字Tool Calling 是现在的能力MCP 是未来的标准。八、写在最后对于企业级 AI 开发而言短期理解 Tool Calling 机制是构建 Agent 的基本功。中期关注 MCP 生态发展评估是否将内部工具迁移为 MCP Server。长期拥抱 MCP 是解决工具碎片化、降低长期维护成本的必然选择。技术在演进但核心逻辑不变让模型更聪明地用工具是能力问题让工具更通用地被使用是工程问题。前者靠模型后者靠协议。最后更新2026-08-14