MCP 和 Function Calling 区别的核心在于：Function Calling 是大模型 API 内置的「决定调用哪个工具」的能力，MCP 是一套开放协议，解决「工具如何被描述、发现和跨应用复用」——两者是分工关系，不是替代关系。
Function Calling：模型 API 里的函数调用机制
Function Calling（各家叫法不同，Anthropic 称 tool use）是大模型厂商在 API 层提供的能力：开发者在每次请求里静态传入工具的名称、描述和 JSON Schema 参数定义，模型判断需要时输出结构化的调用指令（工具名 + 参数 JSON），由你的应用执行后把结果回传给模型继续推理。它的特点很明确：
- 工具列表写死在应用代码里，加一个工具就要改代码、重新发版；
- 每家厂商的格式各不相同，换模型意味着适配一遍；
- 能力边界只有「函数调用」这一件事，传输、鉴权、发现机制都得自己做。
想看它在真实业务里怎么落地，可以读这篇 OpenAI Function Calling 实战。
MCP：一次开发、多端复用的开放协议
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月开源的标准协议，官方比喻是「 AI 应用的 USB-C 接口」。它采用客户端-服务器架构：宿主应用（Host，如 Claude Desktop 、 Cursor 、 VS Code）内置 MCP Client，与独立的 MCP Server 进程通过 JSON-RPC 通信，支持 stdio（本地进程）和 HTTP（远程服务）两种传输方式。 Server 对外暴露三类能力——Tools（可执行操作）、 Resources（只读数据）、 Prompts（提示模板），客户端在运行时通过 tools/list 动态发现工具。关键优势是：
- 模型无关：任何支持工具调用的模型都能用，2025 年起 OpenAI 、 Google 也先后兼容；
- 一次封装、处处可用：写好一个 server，Claude Desktop 、 Cursor 等所有 MCP 客户端都能直接连；
- 动态发现 + 统一鉴权与错误格式，工具可以独立测试、部署、热更新。
一张表看懂两者怎么配合
| 对比维度 | Function Calling | MCP |
|---|---|---|
| 本质 | 模型 API 的能力 | 客户端-服务器开放协议 |
| 解决的问题 | 模型决定调用什么、传什么参数 | 工具如何被发现、路由和执行 |
| 工具定义 | 每次请求静态传入 | 运行时动态发现（tools/list） |
| 复用范围 | 绑定单个应用，跨端要重写 | 一次开发，所有 MCP 客户端可用 |
| 厂商绑定 | 各家格式不同 | 模型无关的开放标准 |
| 传输方式 | 无标准协议 | stdio / HTTP（JSON-RPC 2.0） |
实践中两者是结合使用的
很多人把两者对立起来，这是个误区。在典型的 MCP 架构里，链路是这样的：MCP Client 从 server 拉取工具列表 → 合并进模型的工具注册表 → 模型用 Function Calling 机制发出 tool_use 调用 → 应用拦截调用并路由到对应 MCP Server 执行 → 结果回传。也就是说，Function Calling 负责「决策」，MCP 负责「交付」。不用 MCP 时模型也能调用你内联定义的工具；但只要第二个客户端需要同一批工具，MCP 的价值立刻显现。工程实践中两者几乎总是同时出现，Agent 体系里更是如此，可进一步阅读 OpenAI Agents API 和 多智能体怎么编排 了解完整链路。
选型建议：按工具消费方数量决定
- 只有 3~5 个工具、单应用、单模型、快速原型：直接内联 Function Calling，省掉多进程管理成本，上 MCP 纯属过度设计。
- 工具要给多个客户端用、需要动态注册、跨厂商模型：封装成 MCP Server，性价比最高。
- 生产级 Agent：两者结合——模型侧靠 Function Calling 决策，工具分发靠 MCP，再在 Server 层统一做权限白名单和审计日志。
理解了边界之后，动手实践是最好的消化方式：可以照着 MCP Server 自己搭建教程封装一个自己的 server，或从 好用的 MCP 服务器推荐清单里挑几个现成的接入体验，再对照 Function Calling 的写法感受两者的分工。
评论 (0)