MCP 会是 AI 世界的 USB-C 吗？和 Function Calling 到底差在哪

前两周我跟一个做 Agent 产品的朋友吃饭，他甩给我一句话：”MCP 不就是 Function Calling 换了个皮吗？我们已经有 tool use 了，整这个 MCP 协议是 Anthropic 在刷存在感吧。”

我当时嘴里正嚼着东西，差点呛住。这误解在开发者圈里太常见了，甚至连一些写过相关代码的人也会这么觉得。但如果你真的在生产环境里把两种方式都用过，就会明白它们差的不是一点半点——维度根本不一样。

Function Calling 是工具；MCP 是给工具定一个标准插口。你可以说螺丝刀和螺丝的规范是一回事吗？当然不是。

这篇我想把五个最本质的差异一条一条拆给你看，最后说说实际项目选型怎么想。

差异一：协议层 vs 应用层

这是最根本的一条，想通了这一点其它四条都顺了。

Function Calling 是 OpenAI 2023 年 6 月发的一个 API 特性，它的本质是：模型输出结构化 JSON，你的应用代码去执行。Anthropic、Google、阿里、智谱……现在都有自己的 tool use / function calling API，但注意——这是每一家自己 API 里的一个功能。你的代码和 xx 家模型的 API 深度耦合。

MCP（Model Context Protocol）不一样。它是 Anthropic 2024 年 11 月开源出来的一个通信协议，基于 JSON-RPC 2.0，规定了 Client 和 Server 之间怎么发现工具、怎么调用工具、怎么传递上下文、怎么处理流式响应。它本身不绑定任何模型、任何厂商。

打个比方：

• Function Calling 像每个品牌充电器的私有接口。苹果 lightning、华为 Type-C 以前的自家协议、早期安卓的 micro USB——每家自己一套
• MCP 像 USB-C。协议标准化之后，任何设备对任何设备都能用

USB-C 这个比喻最早是 Anthropic 官方自己提的，我一开始觉得有营销味，用多了之后发现还挺贴切。

差异二：有状态 vs 无状态

Function Calling 是一次性交易。你给模型一个 tools 数组，模型决定调哪个、给你返回 JSON，你执行完把结果再塞回对话。工具本身没有”会话”概念，每次调用都是独立的。

MCP Server 是一个长连接的服务。它可以：

• 维护一个数据库连接池，整个会话期间复用
• 缓存用户身份信息，不用每次鉴权
• 推送 notifications/resources/updated 告诉客户端”我这边的资源变了”
• 在多次调用之间保持工作目录、临时文件这些状态

举个最实际的例子：你要做一个”代码仓库分析”工具，让 Claude 能读取项目结构、打开文件、跑测试。

• Function Calling 版本：每次调用 read_file 都要把完整路径当参数传进去，模型要自己记住当前在哪个仓库
• MCP 版本：Server 启动时 cd 到仓库根目录，之后所有调用都是相对路径；Server 还可以主动推送”文件变更”事件让模型知道有新的 commit

这个差异在 Agent 长时任务里会被放大。任务跑 30 分钟、跨越 200 轮对话，有状态和无状态是两种完全不同的编程模型。

差异三：可发现 vs 硬编码

你有没有写过这种代码：

1
2
3
4
5
6

tools = [
    {"name": "search_web", "description": "...", "parameters": {...}},
    {"name": "send_email", "description": "...", "parameters": {...}},
    {"name": "query_db", "description": "...", "parameters": {...}},
]
response = client.messages.create(tools=tools, ...)

这就是 Function Calling 的典型写法——工具列表写死在客户端代码里。你想加一个工具？改代码、重新部署。你想让不同用户看到不同的工具？自己写权限过滤逻辑。

MCP 的核心 API 之一是 tools/list——客户端启动时问 Server：”你都有啥工具？”Server 返回一个动态列表。这意味着：

• 在 Server 侧加一个新工具，所有连接的客户端不用改任何代码就能用
• Server 可以根据当前用户、当前权限，返回不同子集的工具列表
• 工具的描述、参数 schema 都可以在运行时更新

我最近在做的一个内部项目，用 MCP 接了 6 个 Server：知识库、CRM、邮件、日程、Git、监控。运营同学的客户端能看到前 3 个，工程师能看到全部 6 个，运维只看到监控——都是同一份客户端代码，只是 Server 侧发的工具清单不一样。换 Function Calling 的话，光这套权限逻辑就得写几百行。

差异四：跨 LLM vs 单家绑定

这点对做产品的人尤其重要。

我之前做过一个客户项目，用 GPT-4 的 Function Calling 做了一整套工具集成。后来客户要改成 Claude——工具定义格式不一样（OpenAI 用 JSON Schema，Anthropic 用的是类似但不完全一样的格式），消息结构也不一样（OpenAI 的 tool_calls vs Anthropic 的 tool_use content block），全部代码重写一遍，花了一周。

MCP 协议本身是厂商中立的。只要客户端实现了 MCP 协议，它就能连任何 MCP Server；你的 Server 也可以同时服务给 Claude Desktop、Cursor、Cline、甚至某些支持 MCP 的 OpenAI 兼容 Client。

对 Server 开发者来说，写一次，所有生态都能用。这是真正的网络效应，也是为什么我判断 MCP 会比 Function Calling 活得久。

当然现在阶段 OpenAI 自家还没有正式支持 MCP（2026 年初还是这个状态），但第三方适配层已经有一堆了，转换成本比当年重写 Function Calling 低多了。

差异五：服务端自治 vs 客户端编排

这条比较抽象但很关键。

Function Calling 模式下，所有编排逻辑都在你的客户端代码里：什么时候调工具、调哪个、失败重试、结果怎么传回模型——这些都是你写的应用代码在决定。模型只负责”生成 JSON”，你负责”真正做事”。

MCP 下，Server 有更多自主权。它可以：

• 定义自己的 resources（只读数据源），让模型直接引用而不是通过工具调用
• 定义 prompts（预制的 prompt 模板），让用户直接选用
• 通过 sampling API 主动反向请求客户端帮它跑一次 LLM 推理（比如 Server 自己需要做一次翻译）
• 发送 progress 通知告诉客户端”我这个任务进度 30%”

这些能力是 Function Calling 完全没有的。说白了，Function Calling 把模型当大脑、把工具当手；MCP 把 Server 也当作一个有智能的参与方，大家是协作关系。

选型建议：什么时候用哪个

拆完差异，回到实际问题——你到底该选哪个？

选 Function Calling 的场景：

• 单次 API 调用能搞定的任务，比如”帮我写邮件时调一次日历查空闲”
• 快速原型、一次性脚本
• 只给自己或少数内部工具用
• 模型厂商锁定不是问题（比如你们公司就认 OpenAI）

选 MCP 的场景：

• 要给非开发者终端用户用（他们装 Claude Desktop / Cursor 就能用你的工具）
• 工具需要共享给多个应用，一次开发多处复用
• 有长时任务、需要状态和流式响应
• 在搞 Agent 产品，希望兼容未来更多客户端

真实世界里，我现在新项目几乎都走 MCP 了。开发成本没高多少（FastMCP 这种框架已经很顺手），但获得的可移植性和生态红利很可观。关于 FastMCP 的具体用法，我在 Tool与MCP 分类 下面那篇”30 分钟手搓 MCP Server”里有完整的代码示例可以参考。

如果你正在做 Agent 方向的产品，还可以去 Agent开发 分类 看看那边关于 Skills 和 Agent 架构的文章，跟 MCP 组合起来用会有更多想象空间。

最后说点我的个人判断

MCP 现在还在早期——协议版本还在迭代（最新是 2025-06-18 draft），生态工具链不算成熟，debug 也比 Function Calling 麻烦（多一层协议就多一层坑）。

但我的感觉是：这波标准化是挡不住的。Function Calling 这种”每家一套 API”的做法，在行业成熟度低的时候是必然现象，就跟早期移动端充电器一样；但当生态规模到了一定阶段，标准化协议一定会胜出。苹果最后也上了 Type-C，对吧。

做选型决策的时候，我现在的默认选项是 MCP；只有在”真的只需要一次性、工具很少、没有复用需求”的场景才退回 Function Calling。

这不是什么信仰，是算过账的——多花 20% 的开发成本，换来 3 年后不用大重构，这买卖稳赚。