大家好，我是晚安code。
MCP 都出来了，Function Calling 是不是该退休了"——这俩根本不是一回事，怎么就开始互相替代了？后来我发现这个误解在社区里还挺普遍，但凡聊到 MCP，就有人把 Function Calling 当"即将被淘汰的旧技术"。这篇就把这件事一次讲清楚：Function Calling 是什么、有哪些使用细节、以及它和 MCP 到底是什么关系。文末有结论，不想看过程可以直接跳到最后。
一、Function Calling 是什么
Function Calling（函数调用）：大模型 API 内置的一种能力，允许你用 JSON Schema 描述函数，模型在对话中自主决定「要不要调、调哪个、传什么参数」，返回结构化参数让你去执行。你可以把它理解成模型的一种「点单能力」——它负责说清楚要什么，并不负责把菜做出来。
Function Calling 是大模型连接真实世界的第一块基石，它没有过时，反而所有花哨的 Agent 架构都建立在它之上。（以 2026 年 8 月的 OpenAI / Anthropic API 为准）
我刚接触这个能力时有个典型误解：我以为把工具描述给模型，模型就会"顺手把函数执行了"。其实不会。模型只负责输出 tool_calls，也就是"函数名 + 参数"，真正执行的是你写在代码里的函数。这个边界如果不理解，后面排查 bug 会非常难受。
二、Function Calling 的调用机制
Function Calling 从 2023 年 6 月由 OpenAI 引入（gpt-3.5-turbo-0613 首发），到现在核心机制几乎没变：一次调用是「模型表达意图、你的代码执行」的往返。所谓"函数调用"，严格说不是模型调用了函数，而是模型表达了一次调用意图。
一次完整调用走 4 步：
1）描述工具：用 JSON Schema 把函数的样子告诉模型，名字、参数、要填哪些。
2）模型表态：模型判断要不要调、调哪个，返回 tool_calls（函数名 + 参数 JSON）。
3）你执行：你解析参数，调用真实函数，拿到结果。
4）回填收尾：把执行结果以 role: "tool" 追加进对话，再请求一次，模型基于结果给出最终回答。
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"]
}
}
}]
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 的使用细节
会用 Function Calling 很简单，用好才难——tool_choice、并行调用、strict 这三个细节，决定它到底是玩具还是生产级能力。
1）tool_choice：控制模型什么时候必须调
tool_choice 参数：控制模型「是否调用工具、调用哪个」的开关，可选 auto（默认，模型自己定）、required（强制至少调一次）、指定某个函数。它是 Function Calling 的遥控器。
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 回填，对不上号模型就串了。
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)
3）strict 模式：让参数输出严格符合 schema
结构化输出（Structured Outputs）：OpenAI 提供的一种约束，开启后模型返回的函数参数被保证严格匹配你给的 JSON Schema，不再"大致对、偶尔错"。（以 gpt-4o-2024-08-06 及之后模型为准）
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 就涨一截，循环调用要设终止条件，别让模型自问自答到超时。
四、MCP 是什么（只讲一句，不展开）
MCP 不是又一种函数调用，而是一份关于「怎么把工具接到 AI 应用」的标准化协议——它解决的是连接问题，跟模型怎么决策没有直接关系。
MCP（Model Context Protocol）：Anthropic 于 2024 年 11 月开源的一个协议，规定 AI 应用（宿主）如何发现并调用外部工具，底层用 JSON-RPC。你可以把它理解成「AI 工具的 USB-C 接口」——以前每种工具都要跟每个应用单独接线，现在插同一个口就行。
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 和 Function Calling 的真实关系
MCP 不会取代 Function Calling——它俩一个是「决策机制」，一个是「连接协议」，根本不在同一层，不存在谁吃掉谁。更准确的说法是：MCP 反而依赖 Function Calling，因为它暴露出来的工具，最后还是要被宿主转成各家模型的 function calling 格式，走同一条「模型表达意图 → 代码执行 → 结果回填」的回路。
我当初把 MCP 服务器接进自己的工具链时才发现这个真相：宿主（比如 CherryStudio、Claude Code 这类客户端）会先通过 MCP 协议拿到服务器的工具列表，再把它转成当前模型认识的 function calling schema 喂进去，模型返回 tool_calls 后，宿主再通过 MCP 协议把这个调用转发给服务器执行。MCP 只是把「工具的发现和连接」标准化了，模型侧那一整套决策机制还是 function calling 在干活。
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 |
|---|---|---|
| 本质 | 模型决策机制 | 工具连接协议 |
| 解决的问题 | 模型怎么表达「要调工具」 | 应用怎么发现、调用外部工具 |
| 所在层级 | 模型与应用之间 | 应用与工具之间 |
| 是否依赖对方 | 不依赖 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？
