

大家好，我是晚安code。

MCP 都出来了，Function Calling 是不是该退休了"——这俩根本不是一回事，怎么就开始互相替代了？后来我发现这个误解在社区里还挺普遍，但凡聊到 MCP，就有人把 Function Calling 当"即将被淘汰的旧技术"。这篇就把这件事一次讲清楚：**Function Calling 是什么、有哪些使用细节、以及它和 MCP 到底是什么关系**。文末有结论，不想看过程可以直接跳到最后。

![](https://developer.qcloudimg.com/http-save/yehe-11608098/1fe12c9417704840dadac22e53fa340e.webp)

## 一、Function Calling 是什么

**Function Calling（函数调用）**：大模型 API 内置的一种能力，允许你用 JSON Schema 描述函数，模型在对话中自主决定「要不要调、调哪个、传什么参数」，返回结构化参数让你去执行。你可以把它理解成模型的一种「点单能力」——它负责说清楚要什么，并不负责把菜做出来。

Function Calling 是大模型连接真实世界的第一块基石，它没有过时，反而所有花哨的 Agent 架构都建立在它之上。（以 2026 年 8 月的 OpenAI / Anthropic API 为准）

我刚接触这个能力时有个典型误解：我以为把工具描述给模型，模型就会"顺手把函数执行了"。其实不会。模型只负责输出 `tool_calls`，也就是"函数名 + 参数"，真正执行的是你写在代码里的函数。这个边界如果不理解，后面排查 bug 会非常难受。



![模型只管点单，做菜永远是你的代码](https://developer.qcloudimg.com/http-save/yehe-12591818/3ab8cde1772ef31e3589fccf843056e8.png)

## 二、Function Calling 的调用机制

Function Calling 从 2023 年 6 月由 OpenAI 引入（`gpt-3.5-turbo-0613` 首发），到现在核心机制几乎没变：一次调用是「模型表达意图、你的代码执行」的往返。所谓"函数调用"，严格说不是模型调用了函数，而是模型**表达了一次调用意图**。

一次完整调用走 4 步：

1）**描述工具**：用 JSON Schema 把函数的样子告诉模型，名字、参数、要填哪些。
2）**模型表态**：模型判断要不要调、调哪个，返回 `tool_calls`（函数名 + 参数 JSON）。
3）**你执行**：你解析参数，调用真实函数，拿到结果。
4）**回填收尾**：把执行结果以 `role: "tool"` 追加进对话，再请求一次，模型基于结果给出最终回答。

```python
from openai import OpenAI

client = OpenAI()  # 需配置 OPENAI_API_KEY

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询指定城市的天气",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"]
        }
    }
}]
```

```python
resp = client.chat.completions.create(
    model="gpt-4o-mini",        # 以 2026 年中 API 为准
    messages=[{"role": "user", "content": "北京今天冷吗？"}],
    tools=tools,
)

tc = resp.choices[0].message.tool_calls[0]  # 模型只"表达意图"，不会真去执行
print(tc.function.name)         # get_weather
print(tc.function.arguments)    # {"city": "北京"}
```

注意第 3 步输出的是一个 JSON 字符串，你的代码必须自己 `json.loads` 后真正去查天气。整个流程画成时序图就是下面这张：

![Function Calling 一次调用时序图：模型表达意图，应用执行并回填结果](https://developer.qcloudimg.com/http-save/yehe-12591818/8b98074fed01b79ea0b6ae6e45866d97.png)

## 三、Function Calling 的使用细节

会用 Function Calling 很简单，用好才难——`tool_choice`、并行调用、`strict` 这三个细节，决定它到底是玩具还是生产级能力。

### 1）tool_choice：控制模型什么时候必须调

**tool_choice 参数**：控制模型「是否调用工具、调用哪个」的开关，可选 `auto`（默认，模型自己定）、`required`（强制至少调一次）、指定某个函数。它是 Function Calling 的遥控器。

```python
client.chat.completions.create(..., tool_choice="auto")       # auto：模型自己定（默认）
client.chat.completions.create(..., tool_choice="required")   # required：强制至少调一次
client.chat.completions.create(                               # 指定函数：只允许 get_weather
    ...,
    tool_choice={"type": "function",
                 "function": {"name": "get_weather"}},
)
```



### 2）并行函数调用：一次响应多个 tool_calls

2023 年 11 月起，模型可以在一次响应里返回**多个** `tool_calls`，比如用户同时问北京和上海的天气。执行时每个调用都要单独跑，结果必须用各自的 `tool_call_id` 回填，对不上号模型就串了。

```python
tool_calls = resp.choices[0].message.tool_calls

for tc in tool_calls:
    result = run_your_function(tc)   # 各自执行，可并行
    msgs.append({                    # 把执行结果回填
        "role": "tool",
        "tool_call_id": tc.id,       # 必须对应原调用 id
        "content": str(result),
    })

resp2 = client.chat.completions.create(model=..., messages=msgs)
```



![一次响应多个 tool_calls，结果要按 id 回填](https://developer.qcloudimg.com/http-save/yehe-12591818/495d52d1ebdf34e5d94d005985e3644d.png)

### 3）strict 模式：让参数输出严格符合 schema

**结构化输出（Structured Outputs）**：OpenAI 提供的一种约束，开启后模型返回的函数参数被保证严格匹配你给的 JSON Schema，不再"大致对、偶尔错"。（以 `gpt-4o-2024-08-06` 及之后模型为准）

```python
tools = [{
    "type": "function",
    "function": {
        "name": "add_order",
        "strict": True,   # 结构化输出：参数严格符合 schema
        "parameters": {
            "type": "object",
            "properties": {
                "item": {"type": "string"},
                "count": {"type": "integer"},
            },
            "required": ["item", "count"],
            "additionalProperties": False,
        },
    },
}]
```

> **可能有人会问：strict 开了是不是就万事大吉？**
>
> 不是。strict 只保证「参数长什么样」，不保证「业务对不对」——模型可能给 `count: 0` 这种合法但奇怪的值。另外 strict 只支持 JSON Schema 子集，比如不支持 `anyOf` 之类的复杂写法，schema 写过头反而报错。

### 4）几个躲不过的坑

- **参数校验别偷懒**：模型输出再准也是文本，`json.loads` 前先做健壮性处理，格式坏了要有兜底。
- **流式模式下 tool_calls 是增量**：流式返回时 `tool_calls` 是分段 `delta` 拼出来的，很多初学的人直接读 `message.tool_calls` 拿到空数组，一脸懵。要自己累加 `delta.function.arguments`。
- **上下文别无限膨胀**：每回填一轮结果，token 就涨一截，循环调用要设终止条件，别让模型自问自答到超时。

![](https://developer.qcloudimg.com/http-save/yehe-12591818/90a5096f35fb8fe98c3f009a81a067aa.webp)

## 四、MCP 是什么（只讲一句，不展开）

MCP 不是又一种函数调用，而是一份关于「怎么把工具接到 AI 应用」的标准化协议——它解决的是连接问题，跟模型怎么决策没有直接关系。

**MCP（Model Context Protocol）**：Anthropic 于 2024 年 11 月开源的一个协议，规定 AI 应用（宿主）如何发现并调用外部工具，底层用 JSON-RPC。你可以把它理解成「AI 工具的 USB-C 接口」——以前每种工具都要跟每个应用单独接线，现在插同一个口就行。

```python
from mcp.server import MCPServer

mcp = MCPServer("demo")

@mcp.tool()              # 声明这是一个工具
def add(a: int, b: int) -> int:
    """Add two numbers."""  # 描述必须写，模型靠它理解
    return a + b

if __name__ == "__main__":
    mcp.run(transport="stdio")
```



![MCP 解决的是"每个工具接每个应用"的接线难题](https://developer.qcloudimg.com/http-save/yehe-12591818/648df29a66f2681f861889f182bd8db9.png)

## 五、MCP 和 Function Calling 的真实关系

MCP 不会取代 Function Calling——它俩一个是「决策机制」，一个是「连接协议」，根本不在同一层，不存在谁吃掉谁。更准确的说法是：**MCP 反而依赖 Function Calling**，因为它暴露出来的工具，最后还是要被宿主转成各家模型的 function calling 格式，走同一条「模型表达意图 → 代码执行 → 结果回填」的回路。

我当初把 MCP 服务器接进自己的工具链时才发现这个真相：宿主（比如 CherryStudio、Claude Code 这类客户端）会先通过 MCP 协议拿到服务器的工具列表，再把它转成当前模型认识的 function calling schema 喂进去，模型返回 `tool_calls` 后，宿主再通过 MCP 协议把这个调用转发给服务器执行。MCP 只是把「工具的发现和连接」标准化了，模型侧那一整套决策机制还是 function calling 在干活。

![](https://developer.qcloudimg.com/http-save/yehe-12591818/86f545eecd439fa56ddd7092c9723888.webp)

```python
mcp_tools = mcp_client.list_tools()        # ① MCP 协议取工具列表
fc_schema = to_function_calling(mcp_tools) # ② 转成 function calling 格式
resp = chat.completions.create(            # ③ 走同一条决策回路
    ..., tools=fc_schema,
)
```

两者的分工，一张分层图说清楚：

![Function Calling 与 MCP 分层关系图：决策层与协议层分工协作](https://developer.qcloudimg.com/http-save/yehe-12591818/624b168dcb77f1fa0e8ed5b88a87065f.png)

| 对比维度 | Function Calling | MCP |
|---------|-----------------|-----|
| 本质 | 模型决策机制 | 工具连接协议 |
| 解决的问题 | 模型怎么表达「要调工具」 | 应用怎么发现、调用外部工具 |
| 所在层级 | 模型与应用之间 | 应用与工具之间 |
| 是否依赖对方 | 不依赖 MCP | 依赖，工具最终要走 function calling |
| 典型场景 | 单应用、模型自带工具 | 多客户端共享一批工具、防厂商锁定 |

> **可能有人会问：那我项目里到底用 Function Calling 还是 MCP？**
>
> 大部分单应用的场景，直接 Function Calling 就够了，少一层网络跳转、配置也简单。只有当同一批工具要被多个客户端（Claude、Cursor、自己的 App）共享，或者想避开各家模型 schema 格式不一致的麻烦时，才值得上 MCP。

OK 说破这个真相之后，那句"MCP 取代 Function Calling"基本可以洗洗睡了。以我目前的实践来看：**Function Calling 是地基，MCP 是在地基上盖的标准化管线**，MCP 越普及，反而说明 Function Calling 这套决策机制越稳固。单机应用你大可以只用 Function Calling；等工具要跨多个客户端复用了，再加 MCP 那一层，两者是叠加，不是二选一。

---

我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你在项目里用 Function Calling 遇到过哪些坑？或者你更看好直接函数调用，还是会上 MCP？


MCP 都出来了，Function Calling 是不是该退休了"——这俩根本不是一回事，怎么就开始互相替代了？后来我发现这个误解在社区里还挺普遍，但凡聊到 MCP，就有人把 Function Calling 当"即将被淘汰的旧技术"。这篇就把这件事一次讲清楚：Function Calling 是什么、有哪些使用细节、以及它和 MCP 到底是什么关系。文末有结论，不想看过程可以直接跳到最后。

Function Calling 会被 MCP 取代吗？理清两者关系与使用细节

Function Calling 会被 MCP 取代吗？不会。本文讲透它的调用机制与使用细节，说清两者分层关系：一个是机制，一个是协议。

人工智能

编程语言

FunctionCalling与MCP并非替代关系，而是分层协作：FunctionCalling是模型决策机制，负责输出结构化调用意图；MCP是工具连接协议，标准化工具发现与调用。MCP依赖FunctionCalling执行决策，两者叠加使用。单应用直接调用即可，多客户端共享工具才需引入MCP。

代码解释

服务器

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Function Calling 会被 MCP 取代吗？理清两者关系与使用细节-腾讯云开发者社区-腾讯云

Function Calling 会被 MCP 取代吗？理清两者关系与使用细节

Function Calling 会被 MCP 取代吗？理清两者关系与使用细节

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐