导读：在AI助手从“只会聊天”迈向“能真正办事”的关键拐点上，AI助手沟通能力成为了技术体系中不可回避的核心命题。无论你正面对企业级Agent系统设计，还是在准备面试中频繁出现的“工具调用”考点，理解Function Calling与MCP的关系与演进，都是通往代理式AI开发的必修课。本文将从痛点切入，通过概念拆解、对比分析、代码示例到面试要点，带你一次性打通这条知识链路。

一、痛点切入：为什么AI助手需要工具调用能力

大模型虽然能写出漂亮的文案、回答各种问题，但当遇到查询实时天气、读取本地文件、调用企业API等需求时，就会暴露出根本性的短板——它没有实时数据的入口，也无法主动执行任何操作。

在传统做法中，开发者往往通过提示工程来“引导”模型：在Prompt中告诉模型“你要调用某个API”，然后人工解析模型的输出文本，再手动执行函数并把结果拼回去。这种方式的代码通常长这样：

 传统方式：人工解析模型输出 + 手动执行
user_input = "北京天气怎么样？"
response = llm.generate(f"请输出JSON格式：{'city': '北京'}")
 人工解析JSON，手动调用API，再手动回填结果

这种方式至少存在三个致命缺陷：

• 耦合高：每个工具都需要单独编写解析逻辑，模型输出格式稍有变化就全线崩溃。

• 扩展性差：新增一个工具，意味着从Prompt到解析到执行的全链路改造。

• 维护困难：当工具数量增长到10个以上，维护成本呈指数级上升。

Function Calling（函数调用）正是为解决这些问题而生的技术方案。 它让模型能够以标准化的结构化格式输出调用指令，开发者只需注册工具定义，模型自动完成意图识别和参数填充，从“人解析”变成了“机器解析”。

当场景进一步扩大——跨多个模型、多个工具、需要统一管理和安全治理时，Function Calling的单模型绑定和碎片化问题又浮出水面。于是，MCP（模型上下文协议） 应运而生。

二、核心概念讲解：Function Calling

定义

Function Calling（函数调用） 是大语言模型的一项核心扩展能力，它允许模型根据用户的自然语言指令，自主判断是否需要调用外部函数，并以结构化的JSON格式输出调用请求（包括函数名和参数）。-60

简单来说，如果LLM是智能体的“大脑”，Function Calling就是它的“运动神经”——让AI跳出聊天框，真正实现“思考并行动”。-58

工作原理

Function Calling的核心是 “模型做决策，程序做执行” 的职责分离：-58

1. 注册阶段：开发者在请求中以结构化JSON格式向模型声明可用工具（函数名、描述、参数Schema）。

2. 推理阶段：模型分析用户问题，判断是否需要调用工具、调用哪个工具。

3. 调用阶段：模型返回一条包含function.name和function.arguments的结构化消息。

4. 执行与反馈：开发者程序执行该函数，并将结果以特定格式返回给模型。

5. 总结阶段：模型结合执行结果，生成最终的自然语言回答。

-5

典型场景

• 实时数据查询：天气、股票、航班信息

• 复杂计算处理：数学运算、数据统计

• 外部系统交互：调用企业API、操作数据库

• 多工具协同：结合、计算、文档处理完成复杂任务

-60

三、关联概念讲解：MCP（模型上下文协议）

定义

MCP（Model Context Protocol，模型上下文协议） 是一套用于“上下文交换”的标准协议，目的是让AI应用以统一方式连接不同的外部能力，把工具、数据、提示模板等上下文安全、结构化地提供给模型使用。-19

MCP由Anthropic于2024年11月开源发布，在2025年迅速被OpenAI、Google DeepMind和Microsoft等主流厂商采纳，已成为代理式AI领域的实质连接标准。-25

架构设计

MCP采用典型的Client-Server架构，包含三个核心角色：-19

• MCP Host：AI应用本体（如Claude Desktop、IDE插件），负责管理MCP Client。

• MCP Client：与MCP Server保持连接，获取上下文供Host使用。

• MCP Server：提供上下文与能力，可本地运行（Stdio，同机高性能通信）或远程运行（Streamable HTTP，跨网络支持鉴权）。

MCP定义了Server可暴露的三类核心原语：-19

• Tools（工具）：可执行函数，供AI调用以完成动作。

• Resources（资源）：提供上下文数据的数据源。

• Prompts（提示模板）：可复用的交互模板。

解决的问题

MCP解决了AI工具生态中著名的 “M×N集成问题” ：在没有标准化协议之前，3个模型 × 10个工具意味着30套自定义集成代码。每个模型与工具的配对都需要独立适配和维护。MCP用“一次开发、随处可用”的标准化协议替代了这些碎片化的点对点集成，就像USB-C统一了充电接口一样。-25

四、概念关系与区别总结

理解Function Calling与MCP的关系，关键在于认清它们是不同层次的技术方案：

-39

一句话概括二者的逻辑关系：

Function Calling是“模型怎么动起来”的技术手段，MCP是“工具怎么被统一接入”的架构协议。Function Calling解决的是“AI能不能动一下”的问题，MCP解决的是“AI如何以标准化方式接入所有工具”的问题。

核心差异在于：Function Calling中，模型只输出调用指令，执行由开发者完成；而在MCP中，MCP Client会自动发现并执行工具，开发者只需定义工具。-44

五、代码/流程示例演示

示例一：Function Calling完整代码（查询天气）

以下代码基于OpenAI API实现一个完整的天气查询Function Calling，涵盖工具定义、模型调用、执行与结果整合全流程。-9

import json
import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

 第一步：定义真实的工具函数（模拟天气API）
def get_weather(city: str) -> dict:
    """模拟第三方天气查询接口"""
    mock_data = {
        "北京": {"weather": "晴", "temp": "8~20℃", "wind": "微风"},
        "上海": {"weather": "多云", "temp": "10~22℃", "wind": "东风3级"},
    }
    return mock_data.get(city, {"weather": "暂无数据", "temp": "未知", "wind": "未知"})

 第二步：定义工具描述（给大模型看的元数据）
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询指定城市的天气信息",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "城市名称"}
            },
            "required": ["city"]
        }
    }
}]

 第三步：发起请求，让模型决策
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "北京今天天气怎么样？"}],
    tools=tools,
    tool_choice="auto"   让模型自动判断是否需要调用
)

 第四步：解析模型的调用指令并执行
tool_call = response.choices[0].message.tool_calls[0]
function_name = tool_call.function.name
arguments = json.loads(tool_call.function.arguments)

if function_name == "get_weather":
    result = get_weather(arguments["city"])
    print(f"天气查询结果：{result}")

关键流程标注：

• tools数组定义工具元数据 → 传给模型做决策依据

• tool_choice="auto"让模型自主判断是否需要调用

• tool_calls字段包含模型输出的function.name和function.arguments

• 开发者程序根据function_name执行对应函数，将结果返回给用户

示例二：MCP Server最小实现（Hello World）

以下代码展示如何用Node.js搭建一个最基础的MCP Server，将say_hello工具暴露给AI助手。-29

// 1. 导入依赖
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

// 2. 创建服务器实例
export const server = new McpServer({
    name: "my-mcp-server",
    version: "0.0.1",
});

// 3. 定义一个工具（Tool）
server.tool(
    "say_hello",                    // 工具名称
    {},                             // 输入参数（此处为空）
    async () => {
        return {
            content: [{ type: "text", text: "Hello, World! From my first MCP server!" }],
        };
    }
);

// 4. 启动服务器
async function main(): Promise<void> {
    const transport = new StdioServerTransport();
    await server.connect(transport);
}

main().catch(console.error);

与Function Calling的对比：在Function Calling示例中，开发者需要编写tools数组、解析tool_calls、手动调用函数。而在MCP示例中，开发者只需专注于定义工具（server.tool），MCP Client会自动完成发现、调用和执行，大幅降低了维护成本。

六、底层原理/技术支撑点

Function Calling的底层支撑

Function Calling依赖于两大关键技术：

1. 结构化输出（JSON Mode） ：模型在生成输出时，不再输出任意文本，而是严格按照预定义的JSON Schema生成结构化的函数调用参数。这要求模型在训练阶段就具备遵循格式约束的能力。

2. 意图识别与参数填充：模型需要从自然语言中识别出“用户想调用哪个工具”，并将关键信息（如城市名、日期）精准映射到函数参数的字段上。主流模型通过SFT微调显式学习工具调用格式来实现这一能力。-

MCP的底层技术

MCP的技术实现分为两层：-19

• 数据层（Data Layer） ：基于JSON-RPC 2.0的消息结构与语义，定义了生命周期管理（连接初始化、能力协商）、三大核心原语（Tools/Resources/Prompts）的发现与调用方法。

• 传输层（Transport Layer） ：定义了通信机制与通道，支持Stdio（本地进程间通信）和Streamable HTTP（跨网络远程调用）两种模式。

七、高频面试题与参考答案

题目1：什么是Function Calling？它与普通API调用有什么区别？

参考答案：

Function Calling是大语言模型的核心扩展能力，它允许模型根据用户自然语言指令，自主判断是否需要调用外部函数，并以结构化JSON格式输出调用请求（函数名+参数）。-60

与普通API调用的区别在于：

• 普通API调用：由开发者提前写好调用逻辑，模型只负责输出文本。

• Function Calling：模型参与决策——它自己判断何时需要调用、调用哪个工具、传入什么参数，开发者只负责执行。

踩分点：明确区分“模型做决策，程序做执行”的职责边界。-58

题目2：Function Calling和MCP的核心区别是什么？两者可以一起用吗？

参考答案：

Function Calling是模型侧的能力，解决的是“模型如何输出结构化调用指令”的问题；MCP是架构侧的协议，解决的是“工具如何被标准化接入、发现和调用”的问题。

两者可以一起用，且在实际生产环境中常常组合使用：MCP标准化工具的发现和调用流程，Function Calling负责模型侧的推理决策。Native Function Calling仍然处理模型侧的推断，MCP在此基础上提供了统一的管理层。-

踩分点：说清层次关系，避免“二选一”的错误理解。

题目3：MCP中的Tools、Resources、Prompts分别指什么？

参考答案：

MCP定义了Server可暴露的三类核心原语：-19

• Tools（工具） ：可执行函数，供AI调用以完成动作（如文件操作、API调用、数据库查询）。

• Resources（资源） ：提供上下文数据的数据源（如文件内容、数据库记录、API响应），属于“被动”供模型读取的数据。

• Prompts（提示模板） ：可复用的交互模板（如系统提示词、few-shot示例模板）。

踩分点：区分Tools（主动执行）和Resources（被动读取）的语义差异。

题目4：Agent工具调用失败时如何处理？

参考答案：

采用分级错误处理策略：-52

1. 网络问题（NETWORK_ERROR） ：采用指数退避重试，最多3次。

2. 限流问题（RATE_LIMIT_ERROR） ：等待限流窗口后重试。

3. 输入无效（INVALID_INPUT） ：请求用户修正输入。

4. 其他异常：降级到备选方案。

降级链设计：主API → 备用API → 缓存数据 → 请求人工介入。

踩分点：能讲出“降级链”概念，体现生产环境工程经验。

题目5：什么场景下选择Function Calling，什么场景下选择MCP？

参考答案：

• 选Function Calling：快速原型、单模型部署、工具数量少（5个以内）、项目复杂度低。-39

• 选MCP：企业级Agent系统、需要多模型兼容、工具数量多（10个以上）、需要统一安全治理和权限管理。-39

踩分点：给出明确的量化判断标准，而非模糊表述。

八、结尾总结

回顾全文核心知识点：

重点提示：面试中最容易被问穿的点不是背定义，而是能否说清Function Calling和MCP的层次关系，能否给出明确的场景选型理由。

预告：下一篇将深入Agent系统的核心——ReAct与多Agent协作架构，从单步工具调用走向多步骤自主推理，敬请关注。