随着大模型在各类应用中的普及，人们发现仅仅依靠模型本身的知识与推理能力，往往无法满足复杂业务场景的需求。于是，如何让大模型安全、有效地调用外部工具，成为了关键问题。

目前业界有两种主要的解决方案：Function Calling 和 MCP

目录

什么是Function Calling?

原理

作用

什么是MCP？

原理和特点

架构与组件

使用方式

两者各维度的对比

思考：现在已经有了MCP还需要Function Calling么？

---

什么是Function Calling?

原理

1. 开发者在模型接口中定义一组函数（包括名称、参数、描述）。

2. 当用户提问时，大模型会根据需求，自动决定是否调用某个函数。

3. 平台会将模型生成的参数传递给函数执行，返回结果后再交给模型继续处理。

作用

• 让模型具备“外挂技能”，突破其静态知识库的限制。

• 模型不必事先知道所有信息，而是通过函数实时获取外部数据。

什么是MCP？

MCP，全称 Model Context Protocol，由Anthropic推出，是一种更通用的模型上下文扩展协议。它不仅仅是“调用函数”，而是提供一整套标准化、安全化的工具调用框架。

原理和特点

1. MCP 定义了一种标准化协议，让外部工具以“能力插件”的方式暴露给模型。统一的协议格式，不依赖于某个模型厂商。

2. 大模型通过 MCP，可以发现、选择并调用这些工具。

3. 所有调用过程都有权限控制和上下文管理，保证安全性和透明度。

架构与组件

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 将成为主流方案。