Function Call与MCP：大模型能力扩展的两条路径对比
随着大模型在各类应用中的普及，人们发现仅仅依靠模型本身的知识与推理能力，往往无法满足复杂业务场景的需求。于是，如何让大模型安全、有效地调用外部工具，成为了关键问题。
目前业界有两种主要的解决方案：Function Calling 和 MCP
目录
什么是Function Calling?
原理
作用
什么是MCP？
原理和特点
架构与组件
使用方式
两者各维度的对比
思考：现在已经有了MCP还需要Function Calling么？
什么是Function Calling?
原理
-
开发者在模型接口中定义一组函数（包括名称、参数、描述）。
-
当用户提问时，大模型会根据需求，自动决定是否调用某个函数。
-
平台会将模型生成的参数传递给函数执行，返回结果后再交给模型继续处理。
作用
-
让模型具备“外挂技能”，突破其静态知识库的限制。
-
模型不必事先知道所有信息，而是通过函数实时获取外部数据。
什么是MCP？
MCP，全称 Model Context Protocol，由Anthropic推出，是一种更通用的模型上下文扩展协议。它不仅仅是“调用函数”，而是提供一整套标准化、安全化的工具调用框架。
原理和特点
-
MCP 定义了一种标准化协议，让外部工具以“能力插件”的方式暴露给模型。统一的协议格式，不依赖于某个模型厂商。
-
大模型通过 MCP，可以发现、选择并调用这些工具。
-
所有调用过程都有权限控制和上下文管理，保证安全性和透明度。
架构与组件
MCP 采用客户端-服务器（Client-Server）架构，核心组件包括：
-
MCP Host：运行 AI 模型的环境，如 Claude Desktop、Cursor IDE 等。
-
MCP Client：嵌入在 Host 中的组件，负责发起请求并与 MCP Server 通信。
-
MCP Server：轻量级服务，提供特定功能（如数据查询、API 调用、文件访问等），供 AI 模型调用。
使用方式
-
直接使用已有集成：可以直接调用现成MCP，具体可参考Modelscope的MCP广场。通过在支持MCP的系统中（例如cursor, vscode, cherrystudio）配置mcpserver参数即可。
-
自定义扩展：如果要接入企业系统或专有 API，需要自己编写并运行 MCP Server，通过协议暴露能力。
两者各维度的对比
| 维度 | Function Calling | MCP (Model Context Protocol) |
|---|---|---|
| 定位 | 模型厂商提供的私有接口（如 OpenAI、Qwen），一种功能（函数)。 | 开放协议，类似 HTTP/USB-C，旨在统一不同模型与外部工具的交互方式。 |
| 扩展性 | 需要为不同模型单独适配，缺乏通用标准 | 一次开发可跨模型兼容，降低开发与迁移成本 |
| 复杂性 | 适合简单、单次的API调用任务（如获取天气、调用数据库一次查询） | 支持多轮对话、复杂上下文管理，能 orchestrate工具调用链 |
| 生态依赖 | 强依赖特定模型生态（如 GPT-4 的 Function Call 只能在 OpenAI 环境下使用） | 跨模型、跨平台支持（如 Claude、Cursor、OpenAI、Qwen 等） |
| 安全性 | 主要依赖云端 API Key 来控制调用权限 | 支持本地化部署和数据控制，更适合隐私与合规要求高的场景。 |
| 应用场景 | 适合快速接入某个模型的工具调用（如小应用、单一任务型 Agent） | 适合需要长期维护、跨模型可移植、复杂系统级别的 Agent/应用集成 |
思考：现在已经有了MCP还需要Function Calling么？
答案是需要的。
-
Function Call：适合简单、原子化或特定任务，比如查询天气、计算数学公式。优势是：
-
开发快捷，无需配置 MCP Server。
-
单次请求响应，低延迟，没有额外协议开销。
-
-
MCP：适合复杂、企业级、多系统集成的场景，比如AI助手需要同时访问内部数据库、文件、API等。优势是：
-
协议统一，方便规模化接入。
-
安全可控，符合企业合规要求。
-
未来，两者并非对立关系，而是互补共存。在本地函数调用上，用Function Call 就够。在复杂业务和企业环境里，MCP 将成为主流方案。