StreamSparkAI

概览/核心摘要 (Executive Summary)

本视频的核心论点是，Function Calling 与 MCP (Model-centric Protocol) 并非相互替代的技术，而是互补关系，它们在大型模型应用链路中扮演着截然不同的角色。讲者（马克）旨在纠正“MCP将取代Function Calling”这一普遍存在的错误观点。

Function Calling 被定义为一种使模型能够根据用户问题，从预定义的工具列表中选择合适的工具并生成调用参数，然后解析工具的执行结果以形成最终答案的能力。讲者强调，这本质上是模型的内在能力，但在实践中（尤其是对于闭源模型），开发者通过模型API来间接使用，因此它通常被理解为模型API的一项核心功能。它构成了模型与应用服务器之间的“决策”和“理解”层。

MCP 则是一套工具的发现与调用协议，它作用于应用服务器与外部工具（函数）之间，旨在标准化工具的调用方式，与模型本身没有直接关系。

结论是，Function Calling 负责“决定调用哪个工具以及如何调用”，而 MCP 负责“如何标准化地执行这个调用”。在一个完整的应用链路中，两者可以无缝结合：模型通过 Function Calling 能力决定调用某个工具，应用服务器随后通过 MCP 协议去执行该工具。视频最后通过一个代码演示，成功地在同一流程中集成了这两种技术，验证了它们的互补性。

核心观点：Function Calling 与 MCP 是互补而非替代关系

讲者开篇即明确指出，将 MCP 视为 Function Calling 的替代品或统一协议是一种广泛流传但错误的看法。

• 普遍误解：认为 MCP 作为更标准化的协议，会自然取代 Function Calling，使其失去存在价值。
• 讲者核心论点：
  > "function calling和mcp并不是互相替代的关系，而是互补的关系，他们在大模型领域所处的地位完全不同，在未来很长的一段时间里，function calling和mcp都将同时存在，各自发挥自己的价值。"
• 根本区别：两者在AI应用链路中所处的位置和发挥的作用完全不同。
  • Function Calling：与模型直接相关。讲者强调，其本质是模型的一种内在能力，但在实际应用中，开发者通过模型API来间接使用，因此也常被视为模型API的一项功能。
  • MCP：与工具调用相关，是应用服务器与外部工具之间的通信协议，与模型无直接关联。

Function Calling 的概念与工作链路解析

为了厘清概念，讲者详细解释了 Function Calling 的定义及其在实际应用中的工作流程。

• 基本概念：

  • Function Calling 指的是模型与外部工具（本质上是编程语言中的函数）交互的一种能力，旨在解决模型知识库固化、无法回答范围外问题的局限。
  • 重要澄清：模型本身不直接执行函数调用，而是依赖一个“中间人”（通常是应用服务器）来完成。因此，Function Calling 的名字具有一定的误导性。

• 工作链路拆解 (以查询天气的场景为例)：

  1. 用户提问：用户向应用（如ChatGPT）提问：“纽约明天的天气怎么样？”
  2. 第一次模型交互（决策阶段）：
     • 应用服务器将用户问题和一份可用工具列表（如网络搜索工具）发送给模型API。
     • 模型评估后，判断自身知识无法回答，决定使用“搜索网络”工具。
     • 模型API返回一个工具使用请求，包含要调用的工具名称和具体参数（如 {"query": "纽约明天的天气"}）。
  3. 工具执行：
     • 应用服务器接收到模型的工具使用请求后，实际调用对应的网络搜索函数，并获得返回结果（如天气数据）。
  4. 第二次模型交互（总结阶段）：
     • 应用服务器将上一步获得的工具执行结果再次发送给模型API。
     • 模型接收并理解该结果，结合原始问题，总结出最终的自然语言答案。
  5. 返回答案：应用服务器将模型生成的最终答案呈现给用户。

• Function Calling 的作用域：

  • 讲者强调，Function Calling 并非指应用服务器实际执行函数（上文第3步）的过程。
  • 其真正作用域是模型API与应用服务器之间的交互部分，即模型如何选择工具、生成参数，以及如何解析工具返回结果。
  • 相比之下，MCP 的作用域正是应用服务器与工具之间的调用过程。

  "从这里就可以看出，mp与function col[ling]分别作用在链路的两个环节发挥的作用各不相同，根本就没有互相替代这一说。"

Function Calling 协议深度分析

讲者通过自建的“Mark Chat”应用截获并分析了与模型API交互的完整日志，揭示了 Function Calling 的协议细节。

• 第一次API调用（请求模型决策）

  • 请求体 (Request Body):
    • model: 指定使用的模型，如 "gpt-4o"。
    • messages: 消息列表，此时仅包含用户的原始问题 (role: "user")。
    • tools: 核心字段，一个包含所有可用工具定义的列表。每个工具包含：
      • name: 工具名称，如 "search"。
      • parameters: 一个 JSON Schema 对象，用于精确描述该工具所需的输入参数、类型和是否必需。
    • stream: false，表示非流式返回。
  • 响应体 (Response Body):
    • 响应的核心是 tool_calls 字段，表明模型决定调用工具。
    • tool_calls 是一个列表，包含要调用的工具ID、名称（如 "search"）和具体的参数（如 {"query": "纽约明天的天气"}）。

• 第二次API调用（请求模型总结）

  • 请求体 (Request Body):
    • messages 列表被扩展，现在包含三个部分：
      1. 用户的原始问题 (role: "user")。
      2. 第一次API调用的返回结果，即模型的工具调用决策 (role: "assistant", 包含 tool_calls）。
      3. 工具的实际执行结果，以一个新消息的形式加入 (role: "tool")。
    • tools 列表通常会再次提供，尽管模型此次可能不会再选择调用工具。
  • 响应体 (Response Body):
    • 响应中不再包含 tool_calls。
    • 核心是 content 字段，包含了模型根据工具结果总结出的最终文本答案。

实践演示：在同一链路中结合使用 Function Calling 与 MCP

为了证明两者的互补性，讲者在代码层面演示了如何将它们集成。

• 集成点：修改应用服务器中负责执行工具的函数（在示例代码中为 execute_tool）。
• 修改逻辑：
  • 原逻辑可能是直接调用一个本地函数或HTTP API。
  • 修改后的逻辑 (execute_tool_with_mcp) 则是启动一个 MCP Client。
  • 这个 MCP Client 按照 MCP 协议，去发现并调用一个作为 MCP Server 运行的外部工具。
• 演示结果：
  • 应用成功运行，并返回了由 MCP Server 提供的数据。
  • 返回信息中明确标识了结果来源于 MCP Server，验证了链路的成功。

    "这样呢我们就实现了在一个链路里面同时使用mp和function calling的效果。"

• 开源代码：为方便观众理解和实践，讲者已将本次演示所用的全部代码开源至其 GitHub 仓库。

核心结论总结

1. 角色分工明确：Function Calling 是模型的一种决策与理解能力，作用于模型与应用服务器之间；MCP 是一套工具调用与发现的标准化协议，作用于应用服务器与工具之间。
2. 关系是互补：两者在AI应用的不同环节各司其职，共同构成一个完整的、功能强大的系统，不存在谁取代谁的问题。
3. 实践可行性：通过修改工具执行层，可以非常自然地将 MCP 集成到使用 Function Calling 的工作流中，实现两者的协同工作。