什么是 Function Calling(函数调用)?大模型是如何通过它来调用外部工具的,整个流程分哪几步?
Agent
答案要点 Function Calling 让大模型能"使用外部工具":查数据、调 API、执行动作 模型本身不执行任何代码,它只输出"我想调哪个函数、参数是什么"的结构化 JSON 三步流程:声明工具 schema → 模型出参 → 程序执行后把结果回灌给模型 解决了纯文本模型"只会说不会做"、拿不到实时/私有数据的问题 是 Agent(智能体)的地基能力 核心概念 Function Calling 是一种让大模型以结构化 JSON 的形式"表达调用意图"、由外部程序真正执行函数、再把结果交还给模型继续生成的机制。要先破除一个常见误解:模型自己并不能执行代码,它只是根据工具描述,决定"该调用哪个函数、传什么参数",真正跑代码的是你的程序。 三步流程 声明工具(schema):开发者在请求里用 JSON Schema(一种描述数据结构的规范)写清每个函数的名字、功能、参数类型,比如 getweather(city: string)。 模型出参:模型判断当前问题需要用工具时,不再回复自然语言,而是输出结构化调用请求,如 {"name": "getweather", "arguments": {"city": "北京"}}。 执行回灌:你的代码解析这段 JSON、真正去调天气 API,再把返回结果作为一条新消息塞回对话,模型基于真实数据生成最终回答。 为什么需要它 | 纯对话模型 | 加上 Function Calling | |---|---| | 知识截止到训练日期 | 能查实时数据 | | 只能输出文本 | 能触发真实动作(下单、发邮件) | | 容易编造数字 | 数字来自真实接口 | 入门之后,可以继续深入:多工具并行调用、模型选错工具时怎么兜底,以及在此之上循环起来的 Agent 与工具接入标准 MCP。
口语版讲法(约2分钟)
- 一句话定义:模型出调用意图,程序真执行
- 澄清误区:模型从不亲自跑代码
- 三步流程:声明 schema、模型出参、执行回灌
- 比喻:老板下指令,助理去办事
- 埋钩子:循环起来就是 Agent,标准化就是 MCP
如果面试官问我 Function Calling 是什么,我会先给一句话定义:它是让大模型能够"调用外部工具"的机制——模型输出一个结构化的调用请求,由外部程序真正执行,再把结果喂回给模型继续回答。 这里有个特别容易讲错的点,我一定会主动澄清:模型自己不执行任何代码,它只负责"下命令"。整个流程分三步。第一步是声明工具,我们在请求里用 JSON Schema 把每个函数描述清楚,比如有个 getweather 函数,参数是城市名,功能是查天气。第二步是模型出参,当用户问"北京今天天气怎么样",模型发现训练数据里没有实时天气,就不再直接回答,而是输出一段 JSON,说我要调用 getweather,参数 city 等于北京。第三步是执行回灌,我们的代码解析这段 JSON,真正去调天气接口,拿到"25 度、晴"之后,把结果作为一条消息塞回对话,模型再基于真实数据生成最终回答。 打个比方,这就像老板和助理的配合:老板是模型,说"帮我查下明天去上海的高铁票";助理是你的程序,去 12306 查完把结果递回来,老板再决定怎么答复客户。老板从头到尾没碰过 12306,但事情办成了。 它的价值在于补齐了大模型的两个短板:一是知识有截止日期、拿不到实时和私有数据;二是只会说不会做。有了 Function Calling,模型就能查库存、发邮件、下订单。再往深一层说,如果把"调工具、看结果、再决定下一步"循环起来,就是 Agent 的雏形;而工具接入的标准化,就是最近很火的 MCP 协议——这两块我也可以展开聊。
关键一句:模型不执行代码,只输出结构化的调用意图,真正执行函数并回灌结果的是外部程序。
面试官可能的追问
- 【概念辨析】有人说 Function Calling 就是让大模型帮你跑代码,这个说法对吗?模型在整个调用链路里到底负责哪一环、不负责哪一环?
- 【场景切入】假设你要做一个查快递的客服机器人,用户问"我的包裹到哪了",模型本身不知道物流信息,你会怎么用 Function Calling 把物流接口接进来?说说完整流程。