MCP vs Function Calling，该如何选？

Luga Lee

发布于 2025-04-21 17:05:49

1K10

代码可运行

文章被收录于专栏：架构驿站架构驿站

运行总次数：0

代码可运行

Hello folks，我是 Luga，今天我们来聊一下人工智能应用场景落地 - 如何为 LLM 集成选择合适的策略？

众所周知，大型语言模型（LLMs）已经彻底改变了企业自动化、客户交互以及决策制定的方式，其强大的语言生成能力为各行业带来了前所未有的机遇。然而，要充分发挥 LLMs 的潜力，仅仅部署一个预训练模型是远远不够的。企业需要在实际应用中将 LLMs 无缝集成到现有系统中，确保其在释放创造力的同时，能够保持输出的可控性；在提供灵活性的同时，兼顾结构的严谨性；在推动创新的同时，确保系统的稳定性和可靠性。

然而，这种集成并非易事。LLMs 的输出通常具有一定的随机性和不可预测性，如何在满足业务需求的同时对其进行有效控制和结构化，成为企业在实际部署中面临的最大挑战之一。

随着技术的发展，两种主流的解决方案逐渐浮现：函数调用（Function-Calling）和模型上下文协议（Model Context Protocol，简称 MCP）。这两种方法虽然都旨在提升 LLMs 的可预测性和生产就绪状态，但它们在设计理念、实现方式和适用场景上有着显著差异。深入理解这些差异，不仅有助于企业在集成 LLM s时做出明智的技术选择，还能为构建更高效、更可靠的智能系统奠定基础。

—01 —

如何理解 Function Calling ？

众所周知，LLMs 本质上是一种生成式技术，其核心优势在于能够生成富有创意且高度契合上下文的输出。这种特性使得 LLMs 在诸多任务中表现出色，例如，进行生成代码片段，或是参与开放式的对话互动。无论是用于提升工作效率还是优化用户体验， LLMs 的创造力都展现了巨大的潜力。

然而，在企业环境中，这种生成能力却往往是一把双刃剑。企业通常需要的是可预测、结构化的输出，以确保其与特定的业务流程、监管要求或品牌规范保持一致，而 LLMs 的自由生成特性可能难以完全满足这些需求。

那么，该如何理解“函数调用（Function-Calling）”？

本质上而言，无码可以一句话概括：为特定任务提供结构化输出。

通常而言，函数调用是一种广受欢迎的 LLM 集成方法，其核心在于通过定义明确的函数签名，约束模型生成符合预设接口的结构化响应。通过这种方式，LLMs 的输出可以被精确地引导，从而更轻松地融入现有的企业系统，满足业务场景对一致性和规范化的要求。

作为一种更直接的机制，通常嵌入在大型语言模型（LLM）内部，Function Calling 用于在模型生成响应时动态调用外部函数或 API。其主要涉及如下组件：

用户：发起查询。
大型语言模型（LLM）：直接解析查询，决定是否需要调用函数，并生成响应。
函数声明：预定义的外部函数接口（如天气API的调用方式）。
外部API：提供具体数据或服务。

以下是一个 OpenAI 函数调用的 JSON 定义示例，用于获取指定地点的当前天气信息，具体可参考如下：

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "获取指定地点的当前天气信息",
    "parameters": {
      "type": "object",
      "properties": {
        "location": {
          "type": "string",
          "description": "城市名称，例如：香港、台北"
        },
        "unit": {
          "type": "string",
          "enum": ["celsius", "fahrenheit"],
          "description": "温度单位"
        }
      },
      "required": ["location"]
    }
  }
}

在实际的业务场景中，在函数调用的框架下，开发者首先需要创建一组具有明确输入和输出参数的函数。当用户与 LLM 进行交互时，模型会根据用户的输入内容，智能地识别出需要调用的函数，并生成符合该函数预期格式的响应。例如，函数可能要求返回一个特定的数据类型（如字符串或 JSON 对象），而 LLM 则被限制在这一范围内生成输出。

因此，此种方法特别适合那些需要精确、结构化数据的任务，例如数据提取、分类或外部 API 调用等相关场景。

—02 —

如何理解 Model Context Protocol (MCP) ？

尽管函数调用（Function-Calling）在处理结构化任务时表现出色，但模型上下文协议（Model Context Protocol，简称 MCP）则采用了完全不同的设计思路。

作为一种分层式技术，通过系统性地组织上下文和提示，MCP 为大型语言模型（LLM）提供更加灵活且可控的交互方式。相较于函数调用的刚性约束，MCP 更擅长处理复杂、多步骤的对话场景，尤其是在需要维持上下文连贯性和动态适应用户需求的场景中，其优势尤为明显。

通常情况下，MCP 的设计更偏向于模块化和分布式系统，强调清晰的流程控制和中间状态管理。其主要涉及如下核心组件：

用户：发起查询（如“香港的天气如何？”）。
MCP Client：接收用户查询，协调工具选择和任务分配。
MCP Server：执行具体的工具调用（如调用天气API）。
LLM（大型语言模型）：处理自然语言，生成最终输出。
工具（Tools）：外部 API 或其他功能模块（如天气API）。

以下是一个使用 MCP 框架实现的简易服务器示例，用于获取指定地点的天气信息，具体代码可参考如下：

from mcp import MCPServer, Tool, Parameter

# 初始化MCP服务器
server = MCPServer()

@server.tool
class WeatherTool(Tool):
    """用于获取指定地点天气信息的工具"""

    @server.function
    def get_weather(self, location: Parameter(description="城市名称"), 
                   unit: Parameter(description="温度单位", default="celsius")):
        """获取指定地点的当前天气"""
        # 调用天气API的实现（此处为模拟数据）
        return {"temperature": 22, "condition": "晴天", "humidity": 45}

# 启动服务器
server.start()

在实际的场景中，MCP 的核心在于通过分层的方式分解和组织交互过程。每一层上下文都为 LLM 提供了特定的指令、约束条件或背景信息，从而在模型生成响应时，既能保持其创造性，又能确保输出与业务目标高度契合。

具体来说，MCP 的每一层可能包含不同的信息模块，例如任务目标、用户背景、业务规则或历史对话记录。模型在生成响应时，会综合考虑所有上下文层的信息，确保输出的准确性和相关性。这种分层设计不仅为模型的行为提供了清晰的引导，还避免了过度限制其生成能力，使得 LLM 能够在复杂场景中展现更高的灵活性和智能性。

—03 —

MCP & Function Calling 设计理念差异性解析

1、MCP 设计理念：模块化、分布式与可控的智能任务执行框架