Function Calling 是什么- [intro-what-is-function-calling]
Function Calling 是什么?
模型出意图、程序真执行,三步讲清大模型怎么调工具
原题:什么是 Function Calling(函数调用)?大模型是如何通过它来调用外部工具的,整个流程分哪几步?
Agent
30 秒回答
- Function Calling 让大模型能"使用外部工具":查数据、调 API、执行动作
- 模型本身不执行任何代码,它只输出"我想调哪个函数、参数是什么"的结构化 JSON
- 三步流程:声明工具 schema → 模型出参 → 程序执行后把结果回灌给模型
- 解决了纯文本模型"只会说不会做"、拿不到实时/私有数据的问题
回答与解析
答案要点
Function Calling 让大模型能"使用外部工具":查数据、调 API、执行动作
模型本身不执行任何代码,它只输出"我想调哪个函数、参数是什么"的结构化 JSON
三步流程:声明工具 schema → 模型出参 → 程序执行后把结果回灌给模型
解决了纯文本模型"只会说不会做"、拿不到实时/私有数据的问题
是 Agent(智能体)的地基能力
核心概念
Function Calling 是一种让大模型以结构化 JSON 的形式"表达调用意图"、由外部程序真正执行函数、再把结果交还给模型继续生成的机制。要先破除一个常见误解:模型自己并不能执行代码,它只是根据工具描述,决定"该调用哪个函数、传什么参数",真正跑代码的是你的程序。
三步流程
声明工具(schema):开发者在请求里用 JSON Schema(一种描述数据结构的规范)写清每个函数的名字、功能、参数类型,比如
get_weather(city: string)。模型出参:模型判断当前问题需要用工具时,不再回复自然语言,而是输出结构化调用请求,如
{"name": "get_weather", "arguments": {"city": "北京"}}。执行回灌:你的代码解析这段 JSON、真正去调天气 API,再把返回结果作为一条新消息塞回对话,模型基于真实数据生成最终回答。
为什么需要它
| 纯对话模型 | 加上 Function Calling |
|---|---|
| 知识截止到训练日期 | 能查实时数据 |
| 只能输出文本 | 能触发真实动作(下单、发邮件) |
| 容易编造数字 | 数字来自真实接口 |
入门之后,可以继续深入:多工具并行调用、模型选错工具时怎么兜底,以及在此之上循环起来的 Agent 与工具接入标准 MCP。
口语版讲法(约2分钟)
- 一句话定位:Function Calling 解决模型只会说不会做的问题
- 核心机制:模型输出调用意图,程序执行
- 三步流程:声明 schema → 模型出参 → 执行回灌
- 落地风险:工具描述要清晰,权限和安全要兜底
这道题其实是在问大模型怎么突破纯文本的限制,去调用外部工具。Function Calling 的本质就是让模型输出结构化的调用意图,由程序真正执行,再把结果喂回模型。很多人以为模型自己能执行代码,其实不是,它只是根据工具描述决定调哪个函数、传什么参数,真正跑的是你的程序。
具体流程分三步。先说第一步,声明工具。开发者在请求里用 JSON Schema 写清楚每个函数的名字、功能、参数类型。比如我定义一个 get weather,参数是城市名,类型是 string,描述要写清楚。这一步有个坑,就是工具描述不能太模糊,否则模型容易选错工具。举个例子,客服系统里有个查订单的工具,还有个查退款状态的工具,如果描述都写“查询订单信息”,模型就可能混淆,所以描述要精确到“查询订单物流状态”和“查询退款审核进度”。
第二步,模型出参。模型判断当前问题需要调用工具时,不再输出自然语言,而是输出一个 JSON,比如 {"name": "get weather", "arguments": {"city": "北京"}}。这里要注意,模型可能输出错误的参数,比如传一个不存在的城市名,所以参数校验必不可少。
第三步,执行回灌。程序解析这个 JSON,真正调用天气 API,把返回结果作为新消息塞回对话。模型基于真实数据生成最终回答。这一步有个常见失败场景:如果接口超时或报错,直接把堆栈丢给模型,模型会胡编乱造。更好的做法是返回结构化的错误信息,比如“查询失败,请稍后重试”。
真正上线我会特别关注两点。一是工具描述的质量,描述越精确,模型选错概率越低。二是权限控制,模型只能决定调哪个工具,但能不能调、参数合不合法,必须由后端校验,不能信任模型自己判断。比如客服系统里,普通用户不能调“删除订单”这类高危工具。
所以我会把 Function Calling 看成模型和外部世界的受控接口。它解决了模型拿不到实时数据、只会说不会做的问题,但前提是工具定义清晰、权限和异常处理到位。
其实再往前走一步,多个工具要协作完成复杂任务时,单纯靠 Function Calling 一步步调用容易出错。我更倾向用状态机或 DAG 把依赖关系固化下来,比如“查库存、锁库存、创建订单”这种流程,不能让模型自由组合。
关键一句:多工具协作时,Function Calling 逐次调用容易出错,需要编排机制。
面试官还可能这样问
- 问法 1 · 概念辨析有人说 Function Calling 就是让大模型帮你跑代码,这个说法对吗?模型在整个调用链路里到底负责哪一环、不负责哪一环?
- 问法 2 · 场景切入假设你要做一个查快递的客服机器人,用户问"我的包裹到哪了",模型本身不知道物流信息,你会怎么用 Function Calling 把物流接口接进来?说说完整流程。