本文将深入探讨Function Calling调用外部工具的基本原理，帮助大家理解大模型是如何通过自主解析内容、决策使用工具、结构化填槽等步骤，借助外部工具完成任务的。

如果把大模型比作一个“人类”，那TA只有大脑，眼睛和嘴巴，没有手脚，即它只会“思考”“看”和“说”，不会使用“工具”，比如我们问大模型“今天天气如何”。大模型本身无法回答这个问题，它必须借助“外力”调用相关“工具”来完成回答（下文有说人话的流程图举例）。

• “外力”：比如可以是“墨迹天气”等，因为“墨迹天气”是知道“天气”的。所以只要能调用“墨迹天气”，大模型就能间接回答用户的天气问题了。那么，如何“借助”呢？当然是我们今天要讲的主角–“Function Calling”了。（似乎还没有一个很合适的中文翻译，先大概理解为函数调用或者工具调用吧）
• Function Calling：自主“解析”内容并结构化【填槽】，自主“决策”使用工具并结构化【调用】。
• 自主解析内容：指只要看到Prompt里的内容，就能自动对内容按特定的格式进行解析；
• 自主决策使用工具：指根据解析后的结构化内容，自动调用工具（比如天气，地理位置，日期等），需要什么就自动调用什么。
• 结构化：一种Json格式而已。
• 填槽：指大模型根据与用户的历史对话内容，将信息结构化的解析出来。填槽的槽是个什么？是槽位，什么是槽位？可以理解为“参数”，比如用户询问今天北京天气时，那么填槽的参数就是：日期，城市；这两参数就是槽位。

槽位举例：

例1：

• 出发地：
• 目的地：

例2：

• 城市：
• 日期：

例3：

• 报销事由：
• 报销金额：
• 发生时间：

例4：

• 目的地城市：
• 酒店单价上限：
• 酒店单价下限：
• 区域偏好：

大模型调用工具的基本原理（即即大模型借助Function Calling具备了调用外部工具的基本原理）看不懂没关系下方有流程图解释。

B端产品经理的能力模型与学习提升

B端产品经理面临的第一大挑战，是如何正确的分析诊断业务问题。 这也是最难的部分，产品设计知识对这部分工作基本没有帮助，如果想做好业务分析诊断，必须具备扎实 ...

查看详情 >

1、System Prompt（系统提示词）中写明了都有哪些工具可以使用，使用时要给出参数，要写成什么格式；即系统提示词可理解为写给大模型看的，是系统对大模型下达的命令，既然是命令，大模型就得服从。命令中告诉大模型有哪些工具可以使用，大模型在执行任务时，如果遇到自己解决不了的问题时（比如天气问题）就看可以随时调用工具，但必须按工具要求的格式才能调用。

• 如果是DeepSeek或豆包等我们日常使用的这种应用系统，其System Prompt是已经被官方封装好的，用户不可见。即默认已经将相关的工具调用写到System Prompt里了。比如早期DeepSeek没有封装天气调用工具时，我们问它天气问题，它是回答不上来的。
• 如果是coze等制作Agent的平台，我们在搭建一个Agent时，就可以自己在System Prompt里按实际业务流程，自己去手写调用什么工具以及怎么调用。

2、意图识别：大模型根据和用户的对话信息进行自主识别用户要求做什么任务；

3、大模型自主决策回答用户当前的问题是否需要使用工具，以及决策使用哪个工具（比如天气工具）；

4、决策使用哪个工具后，然后确定调取工具设定的信息传递结构（提示词写了调用工具的格式以及调用什么工具需要传递什么参数，大模型按命令执行即可比如天气工具需“城市”和“日期”参数）；

5、调取与用户的所有的历史上下文的内容解析，并填槽(目的是寻找“城市”“日期”这两个参数)；

6、缺少参数就向用户发起追问，直到全部填槽完毕（直到“城市”和“日期”两个参数全部确定）；

7、按照槽的格式，大模型调用工具，生成模型回复；

以上，就是Function Calling的基本原理，看不懂没关系，我们接下来作解释：

我们看看System Prompt里该写些什么，大模型就能乖乖的借助Function Calling来调用工具了呢？

说明：下面描述中，如果是“//”后的文字，仅表示对这句话的旁白解释，并不是Prompt里的内容；

System Prompt举例：

人设与回复逻辑：

如果用户问到天气问题，你在完成用户要求时，可以使用工具； //这句Prompt可理解为：我们可以把Prompt看成是系统对大模型下达的任务命令，大模型会听话的按命令完成任务。因为大模型有语义识别能力即它像一个“人类”一样能理解语言，所以这句Prompt就是在命令大模型–如果用户在问天气情况时，你就自己去使用工具，怎么使用工具呢，见下面的Prompt。这里的“你”即“大模型”，“工具”指如果是让研发同学去开发一个Agent的话，那么调用什么天气工具由业务自己去决定（比如可能是“墨迹天气”或其他什么天气的MCP，不了解MCP没关系，就先当它是一个API或者插件去理解就行），或者如果是coze里搭Agent时，我们可以在搭建过程中自行选择调用什么“天气”工具。

##工具1    //这是Prompt提供的一个工具。上一句Prompt已经命令大模型，如果要使用工具的话可以自行使用，那么大模型作为一个执行命令的“人”，它会非常信任给它下达命令的“Prompt”，那它就会去调用工具，所以你“Prompt”作为大模型的主人你不能坑人家大模型，于是，“Prompt”就把工具放在这里，意思是说大模型你如果要用这个工具的话你就自己拿去用吧，工具就是下面这段内容。

根据“城市和日期”查询天气，你在使用时必须提供城市和日期两个参数，提供参数的方式要满足如下结构：    // “如下结构“即指前面提到的Json格式，也就是所谓的“结构化”；这段Json可理解为是调用天气工具的开关，开关里有“城市”和“日期”两个零件，缺一不可（你大模型自己根据自己和用户的历史对话去判断是否能识别出用户询问的天气的城市和日期，如果不能，就向用户发起追问）

{

“name”：“get_weather”，

“arguments”：{

“city”：要查询的城市

“date”：要查询的日期

}

}

##工具2:  //这是Prompt给大模型的另一个工具，大模型请自取

根据用户的描述比如“今天”“昨天”“明天”“下周一”，获取实际日期，使用时必须提供用户对于日期的描述这个参数，提供参数的方式要满足如下结构：

{

“name”：“get_date”，

“arguments”：{

“query”：用户对于日期的描述

}

}

以上，就是这段System Prompt的全部内容。

下面我们用一个例子来解释一下：

如果用户提问：“今天北京天气如何？”

大模型就开始自主解析：哦，用户在问天气，那我需要调用主人给我的天气工具“get_weather”，主人还告诉我说调用这个工具时必须要先把“城市”和“日期”参数确定下来，那我找找和用户的历史对话看看能不能获取到这两个参数，诶，用户说了“今天”，那我就可以调用主人给我提供的日期工具“get_date”了，这个工具只要一个参数（query：用户对于日期的描述）即可，那我就把“今天”填进去就行啦（填槽）。填好之后，大模型把这段“get_date”的Json返回给DeepSeek（如果在coze里就返回给coze，其他应用同理），DeepSeek作为一个封装好的应用，里面已经有一段代码或插件专门来接收和处理这段Json了，处理好之后会将“今天”的取值（比如2025年5月31日）返回给大模型，于是，大模型就拿到了“日期”这个参数。

嗯，再来看看“城市”这个参数，发现用户已经告诉我城市是“北京”了，既然“天气”和“城市”两个参数都确定了，那我就把它们填到天气工具“get_weather”里吧（填槽），填好之后，再把“get_weather”这段Json返回给Deepseek（和上面类似），Deepseek执行这段Json代码，把“天气信息”返回给大模型，大模型获得天气信息后组织语言（说人话），将“人话”输出给用户。

如果用户提问时没有说哪个城市，那大模型在自主解析到“get_weather”时发现需要“城市”和“日期”两个参数，现在“城市”无法确认，于是就会主动向用户发起追问：“哥，你要问哪个城市的天气呢？”当然，这只是举例，现在大部分应用已经将“位置”工具也封装好了，大模型在解释过程中会调用位置工具从而获得用户当前的位置所属的城市，也就不用向用户追问了。

小结：记住一句非常重要的话–在应用技术层，无论我们做了多么炫酷的设计，最终都只有一个目的，那就是为了找到相对更合适的一个提示词（Prompt）传递给大模型。因为，Prompt是我们【唯一】可以和大模型交互的方式。因为大模型要“干活”的话，我们必须告诉它要干什么活，怎么告诉呢，那就是提示词，也只能是提示词，只有提示词能直接和大模型“交流”。提示词不清晰，大模型就只能自由发挥，幻觉率也就自然更大。（仔细品味）