Function Calling 是什么？模型是怎么学会调工具的？

先这样答

Function Calling 解决的是「模型只会说话、不会动手」的问题。完整链路四步：第一步，应用把可用工具的清单写进提示词——每个工具一段描述和参数 Schema（名字、类型、哪些必填）。第二步，模型收到用户请求后，判断该用哪个工具，输出结构化的调用意图：工具名加一组符合 Schema 的 JSON 参数。注意这一步模型并没有执行任何东西，它只是生成了一段结构化文本。第三步，你的应用代码解析这段输出，实际执行——调内部 API、查数据库、发请求。第四步，把执行结果拼回对话，模型基于结果继续生成回答，或者发起下一次调用。

「模型怎么学会的」：底模在训练阶段就见过大量「对话情境 → 输出结构化调用」的样本，这是模型厂商在训练和后训练阶段专门做的能力，不是推理时的技巧。所以同一个模型对不同框架的适配差异不大，真正的差异在工具描述写得好不好。

工程上最重要的认知是：模型只负责「决定调什么、参数填什么」，执行的权力和责任都在应用侧。参数校验、权限检查、失败重试，全是你的代码的事。把这一层做扎实，Function Calling 才从演示变成生产。

面试官会怎么追问

• 模型怎么知道该调哪个工具？ 靠工具描述和参数说明与当前任务的匹配度，所以描述写作是准确率的第一影响因素；工具一多还会叠加检索问题，需要先做工具筛选。
• 模型填的参数不可靠怎么办？ 应用侧强制做 Schema 校验（类型、必填、枚举值），不合格就带着错误信息让模型重填，不要直接执行。
• 和普通的结构化输出有什么区别？ 结构化输出只是格式约束，Function Calling 是一套完整协议：工具定义、意图识别、多轮调用循环、结果回填，厂商 SDK 对这套流程做了封装。

回答的坑

• 说成「模型调用了 API」。模型从不执行，执行永远在应用侧，这个边界说不清会显得概念混乱。
• 不提 Schema 校验。生产环境直接信任模型输出的参数是事故来源。