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 可以暴露三类能力：

类型	举例
Tools	发邮件、查数据库、跑代码
Resources	文件、日志、数据库记录
Prompts	复用 Prompt 模板

模型可以：

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

---

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

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

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

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

---

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

维度	Function Calling	MCP
抽象层级	低	高
是否协议	❌	✅（标准协议）
工具发现	❌ 手写	✅ 动态
执行位置	宿主代码	MCP Server
跨语言	❌	✅
多工具协作	麻烦	原生支持
Agent 场景	一般	非常适合

---

四、什么时候用哪个？

✅ 选 Function Calling，如果你：

• 在做：

  • 后端 API
  • Chatbot
  • Web 应用

• 工具数量少（<10）

• 希望强控制、低复杂度

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

---

✅ 选 MCP，如果你：

• 在做：

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

• 工具来源复杂

• 希望：

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

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

---

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

类比对象	Function Calling	MCP
驱动方式	写死函数	即插即用
USB 之前	每个设备单独驱动	❌
USB 之后	❌	✅
HTTP vs RPC	RPC	HTTP + OpenAPI

---

六、是否“互相替代”？

❌ 不是替代关系

实际上：

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

可以理解为：

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