考察点
这是腾讯等大厂 Agent 岗一面的必考题，也是最基础的工具调用题。面试官想确认你分得清「模型侧」和「应用侧」的职责边界：很多人误以为模型自己会去执行函数。追问通常往「tool_calls 是直接执行的吗」「多个工具同时触发怎么办」「和 Prompt + 正则解析有什么区别」走。
参考答案
一句话定义
Function Calling 是模型按预定义的 JSON Schema 输出结构化调用意图的能力。注意关键词是「输出意图」——模型从不执行任何函数，它只是生成一段符合 schema 的 JSON（函数名 + 参数），由调用方代码解析后真正执行，再把结果喂回模型生成最终答复。
完整调用流程
一次完整的工具调用至少是两次模型请求：
- 应用侧把工具列表（name、description、parameters 的 JSON Schema）随用户消息一起发给模型，通常还有
tool_choice参数控制是否强制调用。 - 模型判断需要工具，返回
tool_calls字段，内容类似{"name": "get_weather", "arguments": {"city": "北京"}}。这一轮模型的「回答」就是这个 JSON。 - 应用代码解析 JSON，做参数校验，调用真实函数或 HTTP 接口，拿到结果。
- 把结果以
role: "tool"的消息（带上对应的tool_call_id）追加到对话历史，再次请求模型。 - 模型基于工具返回生成面向用户的自然语言答复。
支持并行调用的模型一次可以返回多个 tool_calls，应用侧可以并发执行后一次性回填。这里有个工程细节：回填时 tool 消息和 tool_call_id 必须一一对应，少一个多数 API 会直接报错。
底层怎么实现的
模型侧靠两样东西。一是训练：在 SFT 阶段混入大量「对话 + 工具 schema + 正确调用 JSON」的样本，让模型学会在合适时机输出调用格式；后续 RLHF 再强化「该调才调、参数要填对」的偏好。二是解码约束：很多推理服务用 constrained decoding（基于 JSON Schema 或语法的受限采样）保证输出一定是合法 JSON，不会出现括号不闭合这种低级错误。
和 Prompt + 正则解析的区别
没有 FC 之前，大家在 Prompt 里写「如果要调工具请输出 ACTION: xxx」，再用正则或 json.loads 去抠。这条路有三个硬伤：输出格式不稳定，模型经常多说话导致解析失败；该调不调、不该调乱调，行为不可控；多工具多参数场景下 Prompt 会膨胀得没法维护。FC 把这件事变成了模型原生能力加 API 层的一等公民字段，可靠性高一个量级。
可能的追问
- tool_choice 设成 required 但用户问题不需要工具会怎样？ 模型被强制必须调一个工具，通常会瞎填参数调一个最「像」的，产生幻觉调用。所以 required 只适合明确的单意图场景，比如表单抽取。
- 模型幻觉出不存在的工具名怎么办？ 应用层做白名单校验，不在工具列表里的一律拒绝执行，把「工具不存在」作为错误结果回传给模型让它自我纠正。
- 为什么说 FC 是 Agent 的基石？ Agent 的「行动」本质就是工具调用，ReAct 循环里每一步 Act 都是一次 FC。没有稳定的 FC，Agent 的规划再好也落不了地。