“非常直觉”的比喻：

想象你在外卖平台点餐。

Function Calling 是什么？

它就像：

你在 App 里点击 “下单”，并填好地址、备注、支付方式。

也就是：“发起一次具体动作”。

比如你对模型说：“帮我查台北天气”，模型回答：

我要调用 get_weather(city="台北")

这就是 Function Calling：模型主动告诉系统：我想调用哪个函数、参数是什么。

---

MCP 是什么？

MCP 更像：

外卖平台让所有商家用统一格式上传菜单、营业时间、配送范围、价格。

也就是：“让很多工具能用统一方式接入系统”。

如果没有 MCP，你每接入一个商家都要手写一套代码对接。
有 MCP 后，商家只要按标准上架，平台就能自动认识它。

---

最核心的一句话

Function Calling 是“点餐”
MCP 是“商家如何上架到平台”

---

用更具体的例子（生活版）

你想让模型帮你完成三件事：

1. 查天气

2. 查快递

3. 查银行卡余额

---

只有 Function Calling 的情况（手动对接）

你需要先写好 3 个函数：

• get_weather

• get_express

• get_balance

然后告诉模型：你只能用这 3 个工具。

模型调用时大概像这样：

{"name": "get_express", "arguments": {"tracking_no": "123"}}

好处：简单
坏处：如果你再加 30 个工具，你就要写死 30 个函数、维护 30 套 schema，非常累。

---

MCP 的情况（工具能自动上架）

如果工具都按 MCP 标准提供服务：

• 天气工具：MCP server

• 快递工具：MCP server

• 银行工具：MCP server

你只要连接 MCP，就能“自动看到这些工具”。

好处：工具越多越省事
工具由别人更新，你不用改代码
坏处：一开始搭平台比 Function Calling 麻烦一点

---

你可以把它们理解为两层

1）MCP：工具接入层（商家上架）

• 负责：工具如何提供接口

• 负责：工具如何被发现

• 负责：工具怎么描述自己

• 负责：权限/认证/治理

2）Function Calling：调用层（具体点餐）

• 负责：模型决定调用哪个工具

• 负责：模型生成参数

---

关键：它们不是二选一，而是经常配合用

最常见的组合是：

MCP 负责让工具“可用”
Function Calling 负责模型“怎么用”

就像：

• MCP：把商家都拉进外卖平台

• Function Calling：你按下“下单”按钮

---

最简总结

Function Calling = 一次具体调用动作（模型→调用工具）
MCP = 工具接入规范（工具→接入模型）

---

一、简单来说：二者不是“竞争关系”

很多文章在讨论 MCP 和 Function Calling 时，会给读者一种错觉：
“MCP 会取代 Function Calling” 或 “Function Calling 不如 MCP”。

事实上，二者关系更像：

• Function Calling 是模型的调用机制（call mechanism）

• MCP 是工具的接入协议（tool integration protocol）

它们不是替代，而是互补：

MCP 把工具标准化接入，Function Calling 把工具标准化调用。
MCP 是工具的“USB-C接口”，Function Calling 是“按下开关”的动作。

---

二、一句话总结（建议记住这个版本）

Function Calling：模型如何“表达我要调用哪个函数、用什么参数”。
MCP：工具如何“被统一规范地暴露给模型发现、连接、调用、管理”。

---

三、从架构层级理解：它们解决的是不同层的问题

1）Function Calling 是“模型到工具”的请求格式

Function Calling 是 LLM 平台提供的一种能力：
让模型输出结构化 JSON，而不是自然语言，从而安全、可控地触发外部函数。

例如模型输出：

{
  "name": "get_weather",
  "arguments": {
    "city": "Taipei",
    "date": "2025-12-28"
  }
}

你的系统看到这一段 JSON，就可以执行：

get_weather(city="Taipei", date="2025-12-28")

这就是 Function Calling 的核心价值：

• 减少 prompt 注入风险

• 参数结构更稳定

• 减少正则解析/模板解析成本

它属于“模型输出层 / 交互层”。

2）MCP 是“工具生态到模型”的统一接入标准

MCP（Model Context Protocol）则更像一套工具接入协议，让工具像插件一样统一接入 LLM：

• 工具描述（schema）

• 工具目录发现（discovery）

• 权限和认证

• 资源管理

• 标准化请求/响应

它的核心价值：

• 工具提供方可以独立开发工具服务（MCP server）

• 模型侧可以动态发现工具（不需要写死工具清单）

• 工具规模大时，接入成本趋于稳定

它属于“平台层 / 工具治理层”。

四、最直观的对比表：10 秒看懂

对比项	Function Calling	MCP
本质	结构化的工具调用输出	工具/数据源接入模型的协议
解决问题	模型怎么表达“我要调用工具”	工具怎么以统一方式暴露给模型
工具数量	少量工具非常合适	工具多、跨团队、治理需求时优势明显
工具发现	通常写死在代码里	支持动态发现
权限/认证	由应用自己做	协议层支持更规范的模式
生态	依赖具体 LLM 平台实现	工具提供方可复用/跨平台

五、实际工程场景：你到底什么时候需要 MCP？

场景 A：只有 3~10 个固定工具（最常见）

比如：

• 查询天气

• 查订单

• 查数据库

• 调用支付系统

• 发邮件

这时直接 Function Calling 就够了：

tools = [query_db, send_email, get_weather]

优点：简单、快速、低成本
缺点：工具越多越难维护；工具更新需要修改应用代码

---

场景 B：工具数量持续增长、跨团队提供工具（典型企业）

比如你做一个内部 Copilot，接入：

• CRM

• ERP

• HR 系统

• 工单系统

• BI 报表系统

• DevOps 工具

• GitHub/Jira/Confluence

这时会遇到典型痛点：

1. 工具的 schema 描述散落在各处

2. 工具变更频繁，接入方需要不断更新

3. 权限与审计无法统一治理

4. 需要一个“工具目录”和“工具网关”

MCP 的价值开始显现：

统一工具接入
动态发现
治理与权限管理
扩展成本低

---

六、最关键的误区：为什么你会觉得它们“很像”？

因为MCP 常常以 Function Calling 作为模型侧的调用方式。

你可以理解为：

• MCP 提供 “工具 API（schema + endpoint + auth）”

• Function Calling 提供 “模型如何选择工具和生成参数”

在很多框架中，最终仍然会出现：

{"name": "some_tool", "arguments": {...}}

但区别在于：

• Function Calling 只负责生成这段 JSON

• MCP 负责：工具如何声明、如何被发现、如何被调用、如何管理

七、选型建议（非常实用）

你应该用 Function Calling，如果：

• 工具数量少（<20）

• 工具由同一个团队维护

• 工具变更少

• 没有太多权限/审计需求

一句话：快速落地，别搞复杂。

---

你应该上 MCP，如果：

• 工具数量持续增长

• 多团队/多系统接入

• 需要动态发现工具

• 需要统一权限、审计、治理

• 想要“工具市场”式能力

一句话：你要的是平台，而不是 demo。

---

八、最佳实践：把它们用对，效果才会好

1）用 Function Calling 时：强约束参数 schema

• 用 JSON Schema 约束参数结构

• 避免传自然语言

• 参数尽可能少，避免让模型乱填

2）工具多时：用 MCP 做 tool registry

• 工具必须可发现（discovery）

• 工具更新无须更新应用代码

• 统一处理认证、审计、限流

3）企业场景：工具调用必须可观测

无论 MCP 还是 Function Calling，最终都必须做到：

• tool call log

• trace id

• tool error + retry

• 权限校验

• 成本监控

---

九、未来趋势：MCP 为什么会越来越重要？

过去“工具调用”是工程师写死的：

tools = [...]

未来工具将像“插件生态”一样存在：

• 工具在运行时动态加载

• 工具由第三方或内部团队独立维护

• 工具有版本、权限、评分、风险等级

• 工具可以被组合成 workflow

这意味着：

LLM 的能力提升只是基础
工具生态的标准化 才决定 LLM 是否能真正进入生产系统

而 MCP 就是这个生态标准的候选之一。

---

结语：把它们放在正确的位置，才不会“用错力”

你可以用一句话结束这篇文章：

Function Calling 解决的是 “模型如何调用工具”
MCP 解决的是 “工具如何成为模型可用的能力资产”
前者是行为，后者是体系。