考察点
这道题出自腾讯大模型应用岗一面，是 Function Calling 系列的开门题。面试官想确认你不是只会调 API 传 tools 参数，而是真的理解链路上每一环：工具 schema 怎么进上下文、模型怎么决定调用、结果怎么回填。答得好不好，看你能否说出「模型从不执行函数」这个核心认知，以及两轮模型调用的完整时序。追问常往并行调用、参数幻觉、和 Prompt+正则方案的对比走。
参考答案
原理：受约束的结构化输出
先给结论：Function Calling 不是模型学会了执行代码，而是模型学会了按约定格式输出一段 JSON。这段 JSON 描述「我想调用哪个函数、传什么参数」，真正的执行发生在应用侧。
实现上分三层。第一层是 schema 注入：应用把可用工具的定义（函数名、description、参数的 JSON Schema）随请求一起传给模型，这些内容会以特定格式拼进上下文，成为 prompt 的一部分。description 写得清不清楚，直接决定模型的调用准确率——这是很多人忽略的，工具描述本质上是给模型看的 prompt。第二层是模型决策：模型在生成过程中判断当前问题是否需要工具，需要的话就中断普通文本生成，转而输出 tool_calls 结构。主流模型会用专门的 special token 或约束解码（constrained decoding）保证这段输出是合法 JSON。第三层是训练支撑：模型在 SFT 阶段用大量工具调用轨迹学过「什么时候该调、参数从上下文哪里取」，这不是推理时凭空发生的。
完整调用流程
以一次「查北京天气」为例，完整走一遍：
- 应用注册工具：
get_weather(city: string)的 JSON Schema，连同用户消息一起发给模型。 - 模型返回的消息里
finish_reason是tool_calls，tool_calls数组里有一项：id 为call_abc，函数名get_weather，arguments 是字符串'{"city":"北京"}'。 - 应用层拿到后，先
json.loads解析 arguments，再按 schema 做参数校验，通过后才执行本地函数，拿到结果「晴，25℃」。 - 把结果包装成一条
role=tool的消息（带上对应的tool_call_id），追加到 messages 末尾。 - 再次请求模型，模型基于工具结果生成最终自然语言回答：「北京今天晴，气温 25℃」。
关键点有两个：一，这是两轮模型调用，不是一轮；二，模型只看到工具返回的文本，它不知道函数内部是查了数据库还是调了第三方 API，更不知道执行是否耗时、是否有副作用——所以它输出的是「调用意图」，不是「调用行为」。
工程实践里的坑
面试时说清原理只是及格线，拉开差距的是实践经验：
- 参数必须校验。arguments 是 JSON 字符串，模型可能输出幻觉参数名、错误类型、甚至不存在的枚举值。我们的做法是解析后过一层 pydantic 校验，校验失败把错误信息回填给模型让它重试，而不是直接执行。
- 并行调用。
parallel_tool_calls开启后，模型一次可以返回多个 tool_call（比如「对比北京和上海天气」触发两次调用），应用侧可以并发执行，但回填时要保证每个 tool 消息的tool_call_id对得上。 - 工具结果要控制体量。一个返回几万字检索结果的工具会把上下文打爆，执行后要做截断或摘要再回填。
- 危险操作加闸。写库、发消息类工具，即使模型输出了调用请求，也要过权限检查或人工确认，执行网关这一层是安全兜底。
可能的追问
- 模型输出的 tool_calls 是直接执行的吗？ 答：不是，模型只生成结构化文本，解析、校验、执行全在应用侧。这既是架构事实，也是安全设计的根基——执行权必须收在工程侧。
- 模型幻觉出一个不存在的函数名怎么办？ 答：应用侧按注册的工具白名单校验，匹配不上就把错误作为 tool 消息回填让模型自我纠正；同时检查 system prompt 里是否有暗示不存在工具的描述。
- Function Calling 和 Prompt+正则解析有什么区别？ 答：正则方案靠模型自由发挥再靠代码兜底，格式稳定性、参数类型安全、多工具区分都没保障；FC 用 schema 约束输出，有训练支撑，工程上可校验、可解析、可统计，是生产级方案。