MCP 与 Function Calling 的区别是什么？
- 标签：大模型、AI、MCP、Function Calling
🏛 业务架构师
两者的核心区别在层次和复用模型：
- Function Calling 是模型能力：各厂商在自己 API 里定义"函数签名传入→模型返回调用意图"的机制，是闭源、厂商私有的。一个函数封装要在每家模型、每个应用里重复做。
- MCP 是开放协议：把"工具的定义、发现、调用、鉴权"标准化为跨应用跨厂商的协议。工具方实现一次，所有支持 MCP 的应用都能用。
打个比方：Function Calling 是"每辆车都有自己的专用接口"，MCP 是"统一了 USB-C 标准"。
业务视角的取舍：
- 简单场景 Function Calling 更轻：单一应用+单一模型，直接用厂商原生能力，延迟低、实现快，没必要为协议层增加复杂度。
- 多应用/多模型/需要生态时 MCP 必选：企业里 3 个以上 AI 应用共享工具，或工具要对外发布，MCP 的"一次实现、处处可用"开始摊薄成本，且不被任何模型厂商绑定。
- 两者不互斥：MCP Server 的工具最终仍通过模型的 Function Calling 能力被调用，MCP 是分发和治理层，Function Calling 是执行层。
我的建议：新项目直接按 MCP 标准建工具层，哪怕暂时只有一个应用——协议成本很低，但为未来留足了扩展和议价空间。
🏗 系统架构师
本质区别：Function Calling 是模型层能力（LLM 决定"调什么"），MCP 是集成层协议（系统标准化"怎么接"）。两者不是竞争，是不同层次的抽象。
Function Calling：
- 各厂商原生 API 能力：开发者把工具定义随请求发给模型，模型输出结构化调用意图（函数名+参数），由应用侧执行；
- 问题：工具定义和模型强耦合（每家 Schema 方言不同）、工具实现和应用进程耦合（换应用要重写集成）、无标准的发现/协商/生命周期机制。
MCP：
- 把"工具定义、发现、调用、结果回传"标准化为跨厂商协议；Server 一次实现、所有支持 MCP 的 Host 复用；
- 带完整的工程语义：能力协商、资源与提示原语、传输与鉴权、更新机制。
架构类比：Function Calling 像"每个应用自己写 JDBC 驱动"，MCP 是"定义了 JDBC 标准"。实际运行时 MCP 并不替代 Function Calling——Host 把 MCP Server 的 tools 转成模型可读的工具定义注入，模型用 Function Calling 机制选择调用，MCP Client 负责协议执行。分层理解：模型决策层（FC）+ 集成协议层（MCP），生产架构两者都要有。
💻 全栈开发专家
两者不在一个层面：Function Calling 是模型的能力（模型会输出「我要调这个函数+参数」），MCP 是生态协议（工具怎么被发现、描述、鉴权、传输）。
| 维度 | Function Calling | MCP |
|---|---|---|
| 定位 | 各厂商 API 的工具调用格式 | 开放标准协议 |
| 兼容性 | OpenAI/Anthropic/Google 格式各异 | 统一，一次封装处处复用 |
| 发现机制 | 每次请求手动传 tools 数组 | tools/list 动态发现 |
| 分发复用 | 代码级复制粘贴 | Server 独立进程/服务，跨应用共享 |
它们是配合关系：MCP Server 暴露的工具，Host 拉取后转换成当前模型的 Function Calling 格式传给模型；模型返回 tool call，Host 再经 MCP 协议转发给 Server 执行。MCP 没有替代 FC，而是把 FC 之上的工具生态标准化了。
我的选型：单个应用、固定几个工具——直接 FC，简单直接；工具要跨应用/跨团队复用、或想接入现成生态（GitHub、Postgres、浏览器都有官方 MCP Server）——用 MCP。注意 MCP 每个 tool 的 JSON Schema 都占上下文 token，挂 30 个 Server 会显著吃预算，工具多时要做工具检索（按需注入）。