MCP 与 Function Call 的本质区别：从单轮调用到协议化语义交互

最新推荐文章于 2025-10-26 07:30:00 发布

原创最新推荐文章于 2025-10-26 07:30:00 发布 · 1.2k 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#microsoft #人工智能 #数据库

我们常常把 Function Call 当作大模型连接外部工具的“标准做法”，但随着 MCP 的出现，开发者开始意识到，Function Call 也有它的天花板——它并不是万能胶，更不是一个真正可拓展的交互协议。

当 Function Call 是“函数调度语法糖”，MCP 则是“任务型系统的上下文骨架”。

本文将试图梳理：这两者到底差在哪儿？什么时候选 Function Call？什么时候上 MCP？你又是否准备好了构建一个真正多智能体协作的 LLM 系统？

1. Function Call：一次性任务调用的美丽幻觉

Function Call 在 OpenAI 推出时，开发者是激动的，它确实解决了一个关键问题：让模型在对话中能调用外部函数，获取它自己得不到的“真相”。

你定义一个 schema，模型生成一个 JSON，后端执行，再把结果返回给模型。

在单轮对话中，这是完美的。

但你很快就会遇到这些问题：

函数一多，schema 管理混乱，接口难以复用；
多轮推理中，函数状态不透明，模型难以追踪执行路径；
上下文丢失，用户问“刚才那个结果怎么算的？”模型一脸懵；
多函数协同难，函数 A 要基于 B 的结果生成调用参数，这逻辑很难靠 prompt 写清楚；
最致命的是：Function Call 没有「协议」，没有版本管理、能力协商，模型跟服务端像是在玩“你猜猜我是谁”。

Function Call 像是一种速食产品：适合简单需求，但撑不起复杂结构。

2. MCP：不是更复杂，而是更系统化

MCP（Model Context Protocol）并不是来取代 Function Call 的，而是让“函数调用”变成一个有身份、有记忆、有协商的上下文通信协议的一部分。

最直观的不同，是 MCP 长这样：

{
  "jsonrpc": "2.0",
  "method": "callTool",
  "params": {
    "tool": "searchDocuments",
    "args": {
      "query": "合同编号1234对应的PDF"
    }
  },
  "id": "8e013b..."
}

你会发现这不是单纯一个“function_call”字段，而是一次标准化的“方法调用请求”。

更重要的是，MCP 建立了一个完整的模型-客户端-服务端三者之间的语义通信协议，支持：

能力协商（Capability Negotiation）：模型可以知道 MCP Server 支持哪些资源、函数、数据结构；
上下文感知（Context Exchange）：MCP 不是一次性调用，而是状态持久的对话，有会话 ID、有历史任务记录；
任务复合执行（Recursive Execution）：MCP 支持函数之间的编排与链式推理，服务端也可以反向调用模型，让模型继续思考；
日志、取消、重试、进度追踪等附属协议，让它不仅是调用，而是一个“API 层调度器”。

你可以理解成：Function Call 是“模型说话+你翻译+你执行”，而 MCP 是“模型与系统使用统一语言进行协同”。

3. 本质区别：Function Call 是调用，MCP 是协作

让我们用一张概念图【图示：MCP 与 Function Call 对比图】来总结核心区别：

项目	Function Call	MCP
核心形式	Prompt 中嵌入函数意图	JSON-RPC 协议交互
状态管理	无状态，单轮执行	有状态，任务上下文可追踪
资源发现	无资源管理能力	支持工具、提示、资源目录
调度能力	模型侧编排，受限	服务端可调度、可代理模型行为
扩展性	每加一函数需重构 schema	工具和资源注册后即复用
标准化程度	不同平台各自为政	开放协议，支持多模型与平台互通