MCP 和 function calling 是什么关系：别当成二选一

2026-07-28

数据截至 2026-07，价格与限额以各官网为准。

MCP 和 function calling 不是同一层的东西，也就谈不上二选一：function calling 是模型侧的能力——模型读懂工具描述后吐出一个结构化的调用意图；MCP 是模型之外的连接协议——规定你的应用怎么发现工具、怎么把调用送到工具提供方、怎么把结果拿回来。一次完整的工具调用里，这两件事是前后接力关系，绝大多数真实系统同时用到它们。

这里有个流传很广的误解值得先纠正：不少人以为”上了 MCP 就不用 function calling 了”，理由是 MCP 帮你把工具都接好了。实际上恰恰相反——你把 MCP server 挂上去之后，客户端做的第一件事，仍然是把 server 声明的工具列表翻译成模型能理解的工具定义，然后交给模型去做 function calling。MCP 没有替掉这一步，它替掉的是你自己手写胶水代码去对接每一个外部系统的那一步。

先把两个词各自锁死在自己的层上

function calling（也叫 tool use）解决的是”模型怎么表达它想调用什么”。 你在请求里附上一组工具定义——名字、用途描述、参数结构（通常是 JSON Schema）——模型根据对话内容判断需不需要用工具、用哪个、参数填什么，然后返回一个结构化的调用请求。注意模型本身不执行任何东西，它只是产出一个”我想调用 search_order，参数是这些”的意图。真正去执行的永远是你的代码。

MCP（Model Context Protocol）解决的是”这些工具从哪来、调用请求往哪送”。 它定义了一套 client 与 server 之间的通信规范：server 那头把自己能提供的工具、资源、提示模板按统一格式声明出来，client 这头去发现、去调用、去接结果。它不关心你用哪个模型，甚至不关心你到底用不用大模型。

把这两句话摆在一起，关系就清楚了：function calling 管的是模型和你的应用之间那一段，MCP 管的是你的应用和外部工具之间那一段。中间那个把两段接起来的角色，是你写的 client 代码。

把一次真实调用拆开，看谁在什么时候做什么

用一个具体场景走一遍——用户问”帮我查一下订单 A1023 到哪了”，你的应用挂了一个物流系统的 MCP server：

应用启动/连接阶段：client 连上 MCP server，请求它的工具清单。server 返回若干工具声明，比如 query_shipment(order_id: string)，带用途描述和参数结构。这一步是 MCP 的活。
组装请求阶段：client 把这些 MCP 工具声明转成模型 API 要求的工具定义格式，塞进这次请求的 tools 字段里，连同用户的话一起发给模型。这一步是 client 的翻译工作。
模型决策阶段：模型读完用户的话和工具描述，决定要调 query_shipment，参数 order_id="A1023"，返回一个结构化的调用块。这一步就是 function calling，全程发生在模型侧。
执行阶段：client 收到调用意图，按 MCP 的协议把这个调用转发给对应的 server，server 真去查物流系统，把结果返回给 client。这一步又回到 MCP。
回填阶段：client 把工具结果作为一条工具结果消息追加进对话，再发一次请求，模型据此生成给用户看的自然语言回答。

看清楚了：第 3 步是 function calling，第 1、4 步是 MCP，第 2、5 步是你的胶水层。抽掉哪一段，链路都断。

三种真实组合，对号入座

组合一：只有 function calling，没有 MCP。 你在代码里手写几个函数，手写它们的 JSON Schema，模型返回调用意图后你用 if/elif 分发到对应函数。这是最经典也最常见的做法，工具少的时候完全够用，没有任何额外依赖。

组合二：function calling + MCP。 工具不再由你手写，而是来自一个或多个 MCP server（可能是第三方的、可能是你自己写的、可能是别的团队维护的）。client 动态拉工具清单、动态翻译、动态分发。工具的增删由 server 那边决定，你的应用代码不用改。这是目前大多数 agent 产品的形态。

组合三：只有 MCP，没有模型参与。 这种情况被忽略得最多——MCP client 完全可以是一段脚本、一个后台任务，直接按名字调用某个 server 的工具，中间没有任何模型做决策。协议本身不要求必须有大模型在场。理解这一点有助于你想明白：MCP 是一层基础设施，不是模型的附属品。

反过来，“只有 function calling 但完全不写执行代码”这种组合是不存在的，因为模型不会自己执行任何东西。

什么时候只用 function calling 就够

不要为了架构好看而提前引入协议层。以下情况建议先老老实实手写：

工具数量少且稳定，比如就三五个内部函数，半年也不会加。手写 Schema 加分发的成本，远低于跑一套 client/server。
工具全在你自己进程里，没有跨语言、跨团队、跨机器的诉求。MCP 的价值很大一部分来自”跨边界复用”，你没有边界要跨，价值就打折。
调用链路对延迟极敏感，每多一跳都要计较。进程内直接调函数肯定比走一层协议快。
原型验证阶段，你还在确认这个功能到底该不该做。

什么时候该上 MCP

反过来，出现下面这些信号，就该考虑把工具层抽出来：

同一批工具要被多个应用复用。你有一个客服机器人、一个内部知识助手、一个自动化脚本都要查同一套业务系统，手写三遍分发逻辑是纯粹的重复劳动。
工具由别的团队或第三方提供。他们维护 server、你只做 client，接口契约由协议保证，双方不用互相读代码。
要接现成的生态。官方注册表 registry.modelcontextprotocol.io 提供 server 发现、文档和 API 参考，由 modelcontextprotocol 的 GitHub 组织社区驱动维护；路线图里还有 MCP Server Cards——通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不用真去连接就能发现一个 server 有哪些能力。按官方与行业公开资料的口径，目前有超过一万个公开 MCP server 跑在生产环境，SDK 月下载量在九千七百万量级以上；这类生态数字是汇总口径，不宜当成精确统计，但足以说明”接现成的”这条路是通的。
你要换模型。工具层挂在 MCP 上时，换模型只影响第 2 步的翻译格式，工具本身一行不用改。

关于 MCP 本身的概念铺垫，可以先看MCP 是什么？为什么说它是 AI 的 USB 接口。

2026-07-28 的新规范，对这个选择有什么影响

有件事必须说清楚：MCP 在 2026-07-28 发布了新规范，官方称这是自协议发布以来最大的一次修订，兑现了 2026 路线图，此前已放出过 release candidate。改动分六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，外加一套正式的弃用策略。

其中跟”要不要上 MCP”这个决策最相关的是两条。

第一条是协议层的无状态化。 这一块由 6 个 SEP（Specification Enhancement Proposal）共同实现，落地了此前 “The Future of MCP Transports” 里的计划。实际影响很直接：以前需要粘性会话、共享 session 存储、网关做深度包检测才能跑起来的远程 server，现在可以直接放在普通的轮询负载均衡后面，按 Mcp-Method 头做路由。协议层不再要求会话追踪。 如果你之前是因为”远程部署太麻烦”而放弃 MCP、选择手写 function calling，这个理由现在弱了很多。

这里要防一个误读：无状态说的是协议层不再要求会话追踪，不是说你的 server 从此不能有任何状态。应用层的状态是另一回事，该存的业务状态照存。相关辨析可以看关于 MCP 的几个常见误解，尤其是”无状态”。

第二条是授权加固。 同样有 6 个 SEP，目的是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署，其中包括要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。对要接企业内部系统的场景来说，这块的成熟度往往是能不能立项的关键。

另外，用于长时间运行操作的 Tasks 特性，已经从核心协议移到 extension；用户也可以自建 extension，和官方认可的 extension 并存。如果你正打算靠 MCP 承载长耗时任务，实现路径跟旧版本不一样了。

破坏性变更：不是加个字段那么简单

这一节请务必读完。维护者 David Soria Parra 把这次改动称为自加入授权以来最实质的变更，原话是 “A lot of things that made MCP are gone.”

具体到工程上意味着两件事：

2026-07-28 版本的 server 可能无法与旧 client 协同工作，反之亦然。 不要默认新旧混用能跑通。
弃用机制给旧版本留了 12 个月的窗口。 有缓冲，但不是无限期。

所以如果你现在正处在”要不要引入 MCP”的岔路口，判断顺序建议是：先按前面两节的信号判断你到底需不需要协议层；确认需要之后，按当前规范版本从头做，而不是照着网上的旧教程搭一套很快就要重做的东西。已经有线上 server 的，重点不是研究新特性，而是排一张迁移时间表——可以参考MCP 版本兼容与升级检查清单这两篇。

顺带说一句生态归属：2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，它现在是厂商中立、社区治理的标准；OpenAI、Google、Microsoft、AWS 都已把它接进各自的 agent 栈。这意味着”选 MCP 会不会被某一家绑死”这个顾虑，跟一年前不是同一个性质了。

诚实说局限

几点需要摆在明面上：

MCP 不能让模型变聪明。 工具描述写得含糊、参数设计得反直觉，模型照样会调错。工具选得准不准，最终还是取决于你的工具描述质量和模型能力，跟用不用协议层无关。
多接一层就多一层故障面。 server 挂了、协议版本对不上、授权配置错了，都会变成”AI 突然不会用工具了”的表象，排查链路比手写函数长。
这篇写在新规范发布当天。 时效性极强，中文资料几乎还没跟上，具体的 SEP 编号、字段名、迁移细节请以官方博客和规范文档的当前版本为准。网上有些站点还把更早的版本号列为当前稳定版，那类信息已经过期，别照着抄。
本文不涉及具体模型的工具调用字段名。 各家 API 在 tools 字段、工具结果消息的结构上有细节差异，以你所用平台的官方最新说明为准。

小结

MCP 和 function calling 分处两层：一个是模型表达调用意图的能力，一个是应用连接工具提供方的协议，一次真实调用里两者接力出现，不存在替代关系。工具少、全在自家进程里、还在验证阶段，先手写 function calling 就好；工具要跨应用复用、来自外部团队、或者你想接现成生态，再引入 MCP 才划算。2026-07-28 的新规范把协议层做成无状态、把授权向真实 OAuth 部署对齐，降低了远程部署的门槛，但同时带来了新旧可能互不兼容的破坏性变更，旧版本有 12 个月窗口。真要动手，从当前规范版本起步，别照着过期教程搭一套注定要重做的东西。