🧠 图解记忆： Function Calling 决定怎么叫函数，MCP 规定能力如何被发现、连接和调用。
💡 答案要点
核心区别：
| 维度 | MCP | Function Calling |
|---|---|---|
| 定位 | 标准化协议，连接整个工具生态 | 模型能力，单次工具调用 |
| 范围 | 协议层，跨模型/跨应用 | 模型层，单模型内置能力 |
| 发现机制 | Server注册→Client发现 | Prompt描述→模型推断 |
| 安全 | 协议级安全、权限控制 | 应用层自行实现 |
| 状态管理 | 支持有状态会话 | 无状态每次调用 |
| 生态 | 已有数千个Server | 需要每个工具单独实现 |
Function Calling工作原理：
传统Function Calling流程：
用户请求 → 模型识别需调用工具 → 生成函数名+参数 → 执行 → 返回结果 → 模型生成回复
# 模型输出（推断）
{
"tool_calls": [{
"name": "get_weather",
"arguments": {"city": "北京"}
}]
}
→ 开发者解析输出 → 调用实际函数 → 拼回上下文
问题：
- 每个工具需要单独开发适配代码
- 安全检查、权限控制由应用自行实现
- 切换模型需要改适配代码MCP工作原理：
MCP流程：
用户请求 → MCP Client发现可用工具 → 模型选择工具 → MCP Server执行 → 返回结果
优势：
- 工具注册一次，任何兼容MCP的模型都能用
- 安全、权限、超时由协议统一管理
- 工具开发者只需实现一次MCP Server架构对比图：
Function Calling（应用各自实现）：
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 模型A │────▶│ App代码 │────▶│ 工具1 │ ← 每个模型+工具组合单独适配
│ │ │ 适配层 │ └──────────┘
└──────────┘ └──────────┘ ┌──────────┐
│ 工具2 │ ← 安全、权限、超时全在App层
└──────────┘
MCP（标准化协议）：
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 模型A │────▶│ MCP │────▶│ MCP │ ← 工具只需实现一次MCP Server
│ │ │ Client │ │ Server │
└──────────┘ └──────────┘ └──────────┘
│ ┌──────────┐
│ │ 工具1 │
│ ├──────────┤
│ │ 工具2 │ ← 安全、权限、超时在协议层
│ └──────────┘
│
┌──────────┐ ┌──────────┐
│ 模型B │────▶│ MCP │ ← 切换模型不需要改工具代码
│ │ │ Client │
└──────────┘ └──────────┘选型决策：
| 场景 | 推荐 | 原因 |
|---|---|---|
| 单模型+少量工具 | Function Calling | 简单、直接 |
| 多模型共享工具 | MCP | 一次实现，多模型复用 |
| 工具生态集成 | MCP | 已有数千个现成Server |
| 快速POC | Function Calling | 5分钟跑起来 |
| 企业生产 | MCP | 标准化、安全可控 |
面试话术：
"MCP和Function Calling是不同层次的东西：Function Calling是模型的能力（模型'知道'怎么调工具），MCP是工具的协议（工具'知道'怎么被调）。Function Calling简单直接，单模型少工具够用；MCP适合多模型共享工具生态，企业里Cursor/Claude Code/GitHub Copilot都能用同一套MCP Server，不需要重复开发。类比的话，Function Calling像是'每款手机自带USB口'，MCP像是'统一USB协议，所有设备都能用'。"