Appearance
72. 什么是 AI Agent 中的 Function Call？
难度 P0 必背 · 岗位 应用 · 频率 ★★★ · 预计阅读 10 min
本题阅读地图
- 💡 简要回答
- 📝 详细解析
- 🎯 面试总结
👔 面试官：说说 Function Call 是什么，原理是怎样的？
🙋 我：Function Call 就是让大模型直接调用 API 嘛，模型自己去访问网络、查数据库，然后把结果返回给用户。
👔 面试官：模型「自己」去访问网络？模型有直接执行代码的能力吗？它能联网吗？
🙋 我：呃……那是模型输出一段调用指令，后端代码去执行？
👔 面试官：对了一半。你说的那是 Function Calling 出现之前的土办法，靠解析自然语言。Function Calling 的核心是模型输出结构化 JSON，「模型只负责决策、代码负责执行」这个最基本的分工你还没说清楚。
这道题的核心就一句话：模型是大脑，代码是手脚，两者职责严格分离。
TL;DR 速记
- 是什么：Function Call 是模型输出结构化工具调用请求，由代码真正执行函数。
- 核心分工：模型只决策调用哪个工具、传什么参数；宿主程序负责鉴权、校验、执行和回传结果。
- 怎么答：流程是“工具 schema 给模型 → 模型返回
tool_calls→ 代码执行 → 工具结果回填 → 模型生成最终答案”。
图解
💡 简要回答
Function Call（函数调用）是 AI Agent 架构中的核心机制：开发者用 JSON Schema 把工具描述好传给模型，模型判断需要调工具时不输出自然语言，而是直接输出一段结构化的 tool_calls JSON，告诉你「我要调哪个函数、参数是什么」，你的代码拿到这段 JSON 去真正执行，把结果塞回对话，模型再生成最终答案。
整个流程本质上是两轮对话：第一轮模型说「我需要调这个工具」，你去执行，第二轮模型拿到结果给出最终答案。
📝 详细解析
Function Call 解决了什么问题
在没有 Function Calling 之前，想让模型帮你调工具，完全靠解析自然语言。模型输出「我需要查一下北京的天气」，你再写 if/else 判断它「说」的是要查天气，然后手动去调 API。这个做法极其脆弱——模型换个说法，你的 if/else 就失配了，根本没办法标准化。
Function Calling 的出现把这件事固定下来：模型不再「说」要调工具，而是直接输出一段结构化 JSON，开发者按格式解析就行，准确率大幅提升，也有了统一标准。这套机制由 OpenAI 在 2023 年推出，现在 Claude、Gemini、DeepSeek、Qwen 等主流模型都支持。
三个角色：把 Function Call 理解成一场任务委托
理解 Function Call 的关键是搞清楚谁做什么：
- 开发者是 HR：负责给每个工具写「职位说明书」，就是 JSON Schema，告诉模型「我们有哪些工具、每个工具能做什么、需要哪些参数」。
- 模型是经理：读完说明书之后决定「这个任务需要调哪个工具、参数填什么」，然后把指令下达出来。
- 你写的代码是员工：真正去跑函数、访问网络、查数据库，把结果汇报回来。
关键点：模型全程只是在「下指令」，它不亲自执行任何代码，也没有直接访问网络的权限。
工具定义：schema 怎么写
工具 schema 是一份结构化的「工具说明书」，用 JSON 格式写：
python
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市的实时天气，包含气温、天气状况、风向风速，仅支持中国大陆城市",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如「北京」「上海」，不要带省份前缀"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "温度单位，默认用摄氏度"
}
},
"required": ["city"]
}
}
}
]其中最关键的字段是 description。模型在决定「要不要调这个工具、参数怎么填」时，能依赖的唯一依据就是这段描述。写得含糊，模型就会「瞎猜」。「获取天气」和「查询指定城市的实时天气，包含气温、天气状况、风向风速，仅支持中国大陆城市」，对模型判断准确率的影响差距很明显。
完整调用流程：两轮对话 + 中间执行
python
import openai, json
client = openai.OpenAI()
messages = [{"role": "user", "content": "北京今天天气怎么样？"}]
# 第一轮：把工具定义和问题一起传给模型
response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=tools,
tool_choice="auto" # auto 让模型自己判断要不要调
)
msg = response.choices[0].message
if msg.finish_reason == "tool_calls": # 模型要调工具，还没给最终答案
tool_call = msg.tool_calls[0]
func_args = json.loads(tool_call.function.arguments) # {"city": "北京"}
# 中间执行：你的代码真正去跑函数
result = "北京今天晴，15°C，东北风 3 级"
# 第二轮：把工具结果塞回对话，再问一次模型
messages.append(msg)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": result
})
final = client.chat.completions.create(model="gpt-4o", messages=messages, tools=tools)
print(final.choices[0].message.content)
# 输出：北京今天天气晴朗，气温 15°C，东北风 3 级，适合外出。finish_reason == "tool_calls" 是关键信号，模型用它告诉你「我需要工具，还没准备好给答案」。
并行工具调用
当用户一口气问「帮我查北京、上海、广州三个城市的天气」，模型可以在一次响应里同时输出多个 tool_calls，三个城市的查询请求一起发出来，你的代码并行执行，大幅提升效率。
常见踩坑与反例
踩坑 1：以为模型真的执行函数
错误描述：「模型自己去联网、查库、调用 API。」
正确做法：模型只输出结构化调用意图。真正执行的是后端代码，代码还要做鉴权、参数校验、超时和错误处理。
踩坑 2：还在解析自然语言
错误描述：让模型输出“我想查天气”，再用正则或 if/else 猜它想调什么。
正确做法：用 schema 定义工具，让模型返回 tool_calls JSON；业务代码按结构化字段执行。
踩坑 3：schema 描述太含糊
错误描述：工具只写 name=get_info，描述是“获取信息”。
正确做法：描述清楚工具用途、适用边界、参数格式和限制条件；必要字段放进 required。
踩坑 4：忽略多工具和并行调用
错误描述：默认一次响应只会有一个工具调用，只处理 tool_calls[0]。
正确做法：按 tool_call_id 遍历所有调用，可并行执行独立工具，并把每个结果分别回填给模型。
面试官可能继续追问
追问 1：
tool_choice=auto是什么意思？ 答题要点：让模型自行判断是否调用工具；也可以强制指定某个工具或禁止工具，用于受控流程。追问 2：工具参数不合法怎么办？ 答题要点：代码层必须校验 JSON、必填字段、枚举、权限和业务规则；不合法时返回错误，让模型修正或转人工。
追问 3：工具调用失败怎么处理？ 答题要点：区分可重试错误、用户输入错误和系统错误；记录 trace，必要时重试、降级或明确告知失败原因。
追问 4：Function Calling 和 MCP 的关系是什么？ 答题要点：Function Calling 是模型输出调用请求的机制，MCP 是工具能力对外暴露和接入的协议，常组合使用。
🎯 面试总结
答这道题必须点出两件事：①职责分离——模型只决策（输出 JSON），代码才执行（真正调用），这是最容易答错的地方；②两轮对话结构——第一轮拿到 tool_calls 信号，中间执行工具，第二轮把结果塞回去让模型生成最终答案。能画出这个流程图，面试官基本就满意了。