MCP（Model Context Protocol）和Function Calling（函数调用）都是让“大模型能用外部能力”的机制，但设计目标、使用方式、抽象层级都有明显区别。下面从「是什么」「怎么用」「适合什么场景」三个层面给出一个工程向对比。

一句话先区分

Function Calling：
👉“模型按你给的函数签名，返回结构化参数，由你来执行函数”

MCP：
👉“模型通过统一协议，自主发现、选择并调用外部工具/资源/服务”

一、Function Calling 是什么 & 怎么用

1️⃣ 核心思想

• 模型不真正调用函数

• 只做一件事：生成符合 schema 的 JSON

• 宿主程序（你）负责：

  1. 解析 JSON
  2. 调用真实函数
  3. 把结果再喂回模型

2️⃣ 使用方式（典型流程）

用户输入 ↓ LLM（看到你注册的函数 schema） ↓ LLM 输出： { "name": "get_weather", "arguments": { "city": "北京" } } ↓ 你调用 get_weather("北京") ↓ 把结果再发给 LLM

3️⃣ 特点总结

✅ 优点

• 简单、可控
• 易调试
• 非常适合单体应用 / API 网关

❌ 局限

• 强耦合

  • 函数 schema 写死在 prompt / 请求里

• 无发现能力

  • 模型只能用你“提前告诉它的函数”

• 不适合跨进程、跨语言、跨服务

二、MCP 是什么 & 怎么用

1️⃣ MCP 的本质

MCP 是一个协议，不是一个模型能力

它定义了：

• 模型 ↔ 工具 / 服务 之间
• 如何发现、描述、调用能力

你可以理解为：

“给大模型用的 USB / HTTP + OpenAPI”

2️⃣ MCP 能暴露什么

一个 MCP Server 可以暴露三类能力：

模型可以：

• 动态发现
• 自主选择
• 多步调用

3️⃣ 使用方式（概念流程）

LLM 启动 ↓ 连接 MCP Server ↓ 发现可用 tools/resources ↓ 根据任务自主决定： - 调哪个 tool - 用什么参数 - 是否链式调用

模型并不是“被动等你塞函数定义”，而是：

像一个 agent，在一个工具生态里工作

三、关键差异对比（重点）

四、什么时候用哪个？

✅ 选 Function Calling，如果你：

• 在做：

  • 后端 API
  • Chatbot
  • Web 应用

• 工具数量少（<10）

• 希望强控制、低复杂度

👉80% 产品都应该从 Function Calling 开始

✅ 选 MCP，如果你：

• 在做：

  • AI Agent
  • IDE / Copilot
  • 内部工具平台

• 工具来源复杂

• 希望：

  • 插件化
  • 热插拔
  • 跨语言 / 跨团队

👉MCP 是“AI 工具生态”的基础设施

五、一个直观类比（非常重要）

六、是否“互相替代”？

❌不是替代关系

实际上：

MCP Server 内部，通常还是用 function calling 或普通代码实现的

可以理解为：

Function Calling = 单机函数调用能力 MCP = 分布式、标准化的函数/资源调用体系