Function Calling
大语言模型如何按给定工具定义生成结构化调用请求，并由外部系统真正执行工具。
#tech / ai
#resource / function-calling
#type / concept
#status / growing
[!info] related notes
Function Calling
Function Calling 的本质不是“模型真的去执行函数”，而是：
- 你把可用工具的名称、参数结构告诉模型
- 模型判断当前问题是否需要调用工具
- 如果需要，它生成一段结构化的调用请求
- 真正执行工具的是你的后端或宿主程序
- 工具结果再回给模型，模型继续组织最终回答
一句话定义
Function Calling 是让模型按给定的工具描述，输出结构化参数请求，再由外部系统代它执行工具的一种机制。
为什么需要它
模型本身擅长语言理解，但不一定擅长：
- 精确计算
- 查询实时数据
- 调用业务系统
- 执行数据库、搜索、发消息之类的动作
这时就需要把“理解用户意图”和“真正执行动作”拆开。
最简流程
- 用户提问，同时系统把可用工具定义发给模型
- 模型判断要不要调用工具
- 如果要调用，模型返回工具名和参数
- 你的程序执行工具
- 工具结果返回给模型
- 模型基于结果生成最终回答
一个最小例子
比如你提供一个天气工具：
{
"name": "get_weather",
"description": "根据城市获取天气",
"parameters": {
"type": "object",
"properties": {
"city": { "type": "string" }
},
"required": ["city"]
}
}用户问：
杭州今天什么天气？模型可能返回：
{
"tool_name": "get_weather",
"arguments": {
"city": "杭州"
}
}然后你的服务端去真的调用天气接口。
面试里最容易被追问的点
它和普通 prompt 有什么区别
普通 prompt 只是让模型输出文字；Function Calling 让模型输出“结构化工具调用意图”。
模型会自己执行函数吗
不会。模型只负责“决定调用什么”和“参数是什么”，真正执行的是宿主系统。
它适合做什么
- 查天气
- 查数据库
- 调业务接口
- 执行搜索
- 调用内部工具链
和 MCP 的区别
- Function Calling 更像“单次工具调用机制”
- MCP 更像“让模型客户端以统一协议接入很多工具和资源的标准”
可以粗暴理解成：
- Function Calling 解决“这次该怎么调工具”
- MCP 解决“工具怎么以标准方式被接进来”
参数校验与兜底机制
模型返回的参数不能直接信任。工程上需要两层校验：
- 模型侧：通过 JSON Schema 约束参数类型、必填项、枚举值
- 运行时侧：用 Zod / Ajv 做结构校验，校验失败进入 repair-and-retry 流程
高风险操作（退款、删除、支付）还需要幂等设计、业务校验、二次确认和审计日志。
详见 Function Calling 参数校验与重试机制。
面试里的最短答法
Function Calling 不是模型自己执行函数，而是模型根据给定的工具定义，输出结构化调用请求，再由外部系统真正执行工具并把结果回传。它适合把模型的语言理解能力和外部系统的真实执行能力接起来。