MCP vs Function Calling：工具调用该选谁

可视化演示

Function Calling是大模型原生的工具调用能力，MCP是更上层的标准协议，两者什么关系？这篇从调用... 切换模式查看不同维度。

工具调用演进

老张的餐厅一开始没有菜单，顾客只能口头描述“来点那个有汤的、你拿手的”，全凭伙计的悟性和运气——这正是早期“提示词时代”的写照：开发者把工具说明、调用格式、示例输出全部写进 prompt，指望模型“发挥悟性”按格式输出。语义稍一复杂，模型就频繁翻车，输出的 JSON 十个有八个缺字段。老张被折磨得不轻，直到印刷厂送来精装菜单，点菜才从自由发挥变成结构化动作。

菜单的本质是“结构化约束”：顾客从固定列表里选菜、填忌口、下单。对应到技术世界，这就是 Function Calling 诞生的逻辑——开发者在请求里传入工具定义（名称、描述、参数 JSON Schema），模型不再自由发挥，而是输出结构化的函数调用意图：工具名 + 参数对象。后端拿到这个结构体，按名执行。可菜单一旦付印就固定了：新菜要等下一版印刷（代码重新发版），食材下架菜单也不能及时改，这就是“静态定义”的先天痛点。

连锁集团给老张的方案是统一服务台标准。这个服务台就是 MCP（Model Context Protocol，模型上下文协议）：它不替代菜单，而是定义了一套“门店—供应商—档口”之间的对接规范。工具提供方按标准接口把自己的能力暴露出来，使用方通过标准流程发现和调用，协议层面统一了传输格式、发现方式、错误处理。至此，从提示词到函数调用再到协议标准化，工具调用的“基础设施”完成了三级跳。

从喊单到菜单再到服务台，本质是“门槛越来越低、标准越来越高”的演进史。工具调用早就不再是“模型能不能输出对格式”的问题，而是“整个系统能不能以标准化方式接入和扩展”的问题。

核心原理对比

印刷菜单的最大特点是：一旦付印就改不了了。新菜要等版本更新，供应不上的食材菜单上照样印着，顾客点了只能尴尬地说“不好意思今天没有”。而服务台的平板是实时数据：后厨有什么、哪个档口开着、供应商今天送来什么，一目了然。这两者的差别，就是 Function Calling 与 MCP 在“调用方式”上的核心分野。

Function Calling 是模型服务商在 API 层提供的内置能力：开发者把工具 schema 随请求发给模型，模型经推理后输出“该调哪个工具、传什么参数”。工具集在对话开始时就被“印死”在一次请求里，属于静态预定义。如果中间要增加、修改或下架工具，只能改代码重新发版。它解决的问题是“模型如何结构化地表达调用意图”——这是它的主场。

MCP 则把视角拉高了一层：它不关心模型怎么输出意图，只规范“客户端与服务端之间如何发现和调用工具”。一个 MCP Client 可以连接多个 MCP Server，每个 Server 暴露自己的工具集，Client 在运行时查询、按需调用。工具集不再是封闭的固定集合，而是所有 Server 上报内容的动态并集。架构上，FC 是模型厂商的私有 API 行为，MCP 是开放的应用层协议，二者不在同一层，谈不上取代，只有配合。

菜单付印即固定，服务台实时即所见——“静态定义”与“动态发现”最朴素的差别就在于此。理解了这一层，后面所有维度的对比都有了锚点。

动态发现能力

服务台的平板之所以厉害，在于它“长在”后厨的数据上：厨师长早上备了什么菜，平板就显示什么；下午新增甜品档口，平板立刻多一行。这种“能力即插即用”的体验，就是 MCP 动态发现能力的直观体现。新工具上线，不需要重新印菜单，也不需要通知所有顾客换新版——打开平板就在那里。

MCP 实现动态发现的钥匙是 tools/list 方法。客户端随时可以向服务端发起 tools/list 请求，服务端返回当前支持的全部工具清单（含名称、描述、参数结构）。新增工具时，只需在 Server 端注册新函数，客户端下一次 list 就能看到它，上层 Agent 代码、模型 prompt、工具 schema 全部无需改动。这一机制把“工具接入”从开发时行为变成了运行时行为，极大降低了扩展成本。

更精妙的是版本协商机制。MCP Server 在握手阶段声明自己支持的协议版本，Client 按版本自动适配，避免“工具上线了，但两边格式对不上”的尴尬。配合 MCP 的资源（Resources）与提示（Prompts）能力，一个 Server 不仅能动态提供工具，还能动态暴露上下文资源，形成完整的可发现能力面。这也是 MCP 在复杂 Agent 场景中不可或缺的原因。

菜单改版要花印刷费，服务台改版只需要后厨说一声。动态发现的本质是“解耦”——工具提供方和消费方不再被同一个发布周期捆绑，这正是大型 Agent 系统最渴望的灵活性。

生态兼容性

一个城市的餐厅各有各的菜单，外地游客看不懂；但连锁集团的服务台是统一的：不管进哪家门店，报会员号、点标准套餐、开电子发票，流程完全一样。MCP 想做的就是这种“跨店标准”。当你的 Agent 需要对接数据库、GitHub、浏览器、支付系统等十几个外部服务时，统一的协议远胜于为每个服务手写一套私有对接代码。

Function Calling 由各家模型厂商分别实现：OpenAI 的 function calling、Anthropic 的 tool use、国内通义和文心的 tool calling，接口细节各不相同。这意味着如果直接依赖各家 FC，每接入一个新模型，工具层就要重新适配一遍。MCP 则站在厂商中立的位置：Client 和 Server 都遵循同一协议，一套写好的 MCP Server 可以同时服务多种模型的 Agent——模型厂商可以不同，工具接入层却可以完全复用。

生态上，MCP 已然成为事实标准：OpenAI、Anthropic、Google 等主流厂商以不同形式兼容支持，社区涌现出大量开箱即用的 Server，覆盖数据库、文件系统、开发工具、浏览器自动化等领域。集成成本从“逐个适配私有 API”降至“一行配置连接”。对技术决策者来说，生态兼容性直接决定了团队未来在集成上要烧多少资源。

菜单各自为政还是统一服务台？生态兼容性差的方案，团队越用越累；生态好的方案，行业越用越厚。MCP 的开放性让它不仅在当下省事，更让未来的接入变得可预期。

安全模型

在老张的小餐厅，顾客喊一声“上菜”，后厨就动手做——没有登记、没有审批、没有留痕。这在创业期没问题，但连锁集团不能这么干：供应商要验资质、厨师凭工号上岗、特殊菜品要经理授权。安全模型的核心差异，就在于是“信任所有调用”还是“管控每一次调用”。

Function Calling 的安全依赖上层业务代码自行把关：模型输出了工具调用意图，后端收到后自己判断“这个参数合法吗？这个操作该不该执行？”。协议层不提供任何约束——FC 的职责止于“听懂你点了什么菜”，至于后厨要不要真做这道菜，完全是业务方的事。工具少时这很简单，工具一旦涉及支付、删除、对外发送消息，风险就全压在业务代码的自觉性上。

MCP 把安全做进了协议层：Server 声明工具权限与作用域范围，Client 可以对敏感操作要求用户显式审批（human-in-the-loop），调用全过程生成审计日志，谁在什么时候调了什么工具一目了然。这意味着 MCP 天然适合企业级场景——敏感操作必须经过确认，每次调用留痕可追溯。安全不再是散落在业务代码里的 if-else，而是协议保证的标准化能力。

小餐厅靠信任，大集团靠制度。工具调用能力越强，越需要协议的“门禁”来守门——MCP 把安全从“业务代码的质量问题”提升为“协议层面的标准能力”，这对企业落地 Agent 几乎是刚需。

组合实践

聪明的食客不会冲进后厨自己炒菜——他们看菜单做决定，剩下的交给服务台调度。AI 工具调用的最佳实践同样是分层：让模型做它最擅长的决策，让协议做它最擅长的事情。现实中不少团队把 FC 和 MCP 当二选一的竞品，其实它们天生是一对搭档。

组合的分工逻辑非常清晰：Function Calling 负责“决策层”。模型根据用户自然语言，输出结构化的调用意图——“我要调用哪个工具、传什么参数”。这一环利用了 LLM 强大的意图理解与参数抽取能力，是 FC 的绝对主场。MCP 则负责“执行层”：拿到模型输出的工具名和参数后，通过 MCP Client 动态发现工具所在 Server、完成认证与路由、执行调用、返回结果。

实践中一个典型 Agent 的调用链路是：用户输入 → 模型通过 FC 输出结构化意图（工具名 + 参数 JSON）→ MCP Client 根据工具名路由到对应 Server → Server 执行真实函数 → 结果回传模型生成最终回复。这样设计的好处是：既能享受 MCP 的动态接入、统一安全和生态复用，又不放弃 FC 让模型精准决策的能力。决策与执行完全解耦，任何一层升级都不影响另一层。

点菜的是顾客，炒菜的是后厨，服务台负责连接——各司其职，才是一家大餐厅的高效运作。记住这个分工，你就能在架构评审会上从容回答“到底该用 FC 还是 MCP”：不是二选一，而是分两层。

选型决策矩阵

摆摊的小吃车需要豪华服务台吗？不需要，一张菜单足够了。可要开连锁酒店餐厅，没有统一服务台，早晚乱成一锅粥。选型的本质，是对自身业务规模与复杂度的诚实评估。老张的生意经很简单：多大盘子，配多大的系统。

决策矩阵可以用三把尺子来量。第一把尺子是规模：工具数量少于 5 个、模型单一、团队就两三人——直接用 Function Calling，简单直接，别引入额外基础设施；工具数量几十上百、多个模型并发调用——上 MCP，把工具接入标准化，否则团队会淹没在适配代码里。第二把尺子是复杂度：工具需要频繁动态更新、按需暴露给不同 Agent——MCP 的动态发现是刚需；工具长期固定不变——FC 的轻量反而是优势。第三把尺子是生态：目标系统已有现成的 MCP Server（数据库、GitHub、浏览器等常见中间件）——接 MCP 事半功倍；所有工具都得从零自研——FC 上手更快。

一个稳健的落地节奏是：由 FC 入局，按需上 MCP。MVP 阶段用 FC 快速验证产品和业务逻辑；当工具多到维护成本失控、或者需要接入外部生态时，再引入 MCP 作为统一执行层，把 FC 保留为决策层。这样既不错过 MCP 的生态红利，也避免在验证期过度建设。

先想清楚自己是小吃车还是连锁餐厅，再决定用菜单还是服务台。选型本质上是对业务边界的回答：现在复杂吗？未来会多复杂？答案不同，最优解不同。

AI 应用场景

Python 演示

"""MCP vs Function Calling 简化模拟演示"""import jsonfrom typing import Callable  def get_weather(city: str) -> str:    return f"{city} 今日晴 22°C"  def calc_price(amount: float, discount: float = 1.0) -> str:    return f"实付 {amount * discount:.2f} 元"  class FunctionCalling:    """固定菜单：工具预先静态注册，模型从中选择"""     def __init__(self):        self.tools = {}     def register(self, name: str, fn: Callable, desc: str) -> None:        self.tools[name] = {"fn": fn, "desc": desc}     def decide(self, intent: str) -> str:        for name in self.tools:            if name.replace("_", "") in intent.replace(" ", ""):                return name        return "get_weather"  class MCPServer:    """服务台：动态发现工具，统一路由执行"""     def __init__(self):        self.servers = {}     def add_server(self, name: str, tools: dict) -> None:        self.servers[name] = tools     def list_tools(self) -> list:        result = []        for server, tools in self.servers.items():            for tname in tools:                result.append({"server": server, "name": tname})        return result     def call(self, name: str, args: dict) -> str:        for tools in self.servers.values():            if name in tools:                return tools[name](**args)        raise KeyError(f"工具 {name} 未发现")  class Agent:    """组合模式：FC 做决策，MCP 做执行"""     def __init__(self, fc: FunctionCalling, mcp: MCPServer):        self.fc = fc        self.mcp = mcp     def run(self, query: str) -> str:        tool = self.fc.decide(query)        args = {"city": "北京"} if "天气" in query else {"amount": 99}        return self.mcp.call(tool, args)  if __name__ == "__main__":    fc = FunctionCalling()    fc.register("get_weather", get_weather, "查询天气")    fc.register("calc_price", calc_price, "计算价格")     mcp = MCPServer()    mcp.add_server("weather_svc", {"get_weather": get_weather})    mcp.add_server("billing_svc", {"calc_price": calc_price})    print("MCP 动态发现工具:", mcp.list_tools())     agent = Agent(fc, mcp)    print(agent.run("今天北京天气"))    print(agent.run("买 3 个苹果 99 元打 8 折"))

1. fc.register("get_weather", get_weather, "查询天气")静态注册一个工具到函数调用表，相当于把菜品印上菜单。
2. def decide(self, intent: str) -> strFC 层的决策函数，基于意图匹配选择工具，模拟模型输出结构化选择。
3. mcp.add_server("weather_svc", {...})向 MCP 服务台添加一个服务端，相当于连锁集团接入一个新供应商档口。
4. def list_tools(self) -> listMCP 动态发现的关键操作，运行时返回所有 Server 当前暴露的工具清单。
5. def call(self, name: str, args: dict) -> strMCP 层的路由执行，根据工具名称找到对应 Server 并执行真实函数。
6. tool = self.fc.decide(query)组合模式的第一步：FC 做决策，选出“调哪个工具”。
7. return self.mcp.call(tool, args)组合模式的第二步：MCP 做执行，完成真实调用并返回结果。

常见误区

面试题