一、什么是Function Call
我们可以提前定义并清晰描述好函数。当用户与大模型进行对话时，如果用户的意图与函数的描述相匹配，大模型便会智能地生成一个包含参数的JSON对象作为输出，用于调用一个或多个函数。需要特别说明的是：大模型本身并不会主动执行函数，它只负责生成带参数的JSON对象。我们可在合适的时机，利用这个对象在代码中真正完成函数的调用。
二、Function Call的核心作用
大模型的训练数据存在时间限制，它无法联网，也不能获取最新发生的事件。因此，当用户询问模型不了解的数据信息时，可以通过后台的函数调用获取后台返回的结果，再交由大模型进行回复。这一机制有效弥补了模型知识更新的滞后性，提升了回答的实时性与准确性。
三、Function Call的执行流程
具体流程可通过以下示例来理解：
用户向大语言模型提问：斯德哥尔摩今天在下雨吗？
大模型检测到用户的意图，并与后台API库中提供的某个功能函数服务相匹配，于是通知后台：你可以调用这个功能函数（比如我们称之为“天气函数”）进行查询，同时将该函数所需的参数以JSON格式发送给后台。
后台执行天气函数，将函数返回的结果再提交给大模型。
大模型根据用户的提问以及函数返回的结果，生成最终回复。
四、大模型如何判定何时使用函数？
来看这个函数示例：
该函数的名称为 get_current_weather。除了名字字段外，下方还有一个描述字段：“给定一个地点，获取当前的天气情况”。这一描述至关重要——大模型在与用户对话时，正是通过这段描述来匹配用户的意图，从而选择对应的函数。如果函数的描述不够清晰，大模型就无法准确识别用户意图。因此逻辑十分明确：大模型借助函数的描述来判断是否匹配用户的需求。
该函数最底部还有一个 function_call 字段。当其值为 auto 时，遵循上述调用逻辑。此外，还有两个可选值：
insert-function-name：当判断用户意图符合函数描述时，无论大模型本身能否回答，都强制调用该函数（此处需要填入具体的函数名称）。none：在任何情况下都不调用该函数。
五、如何确定调用函数需要哪些信息
再看这段代码示例。其中包含一个 parameters 字段，其下又有一个 properties 字段，里面列出了函数所需的参数信息。本例中只有一个参数，名为 location（地点）。该参数下还有两个子字段，其中一个为 description，用于说明 location 参数的具体含义。
这样一来就很清楚了：大模型通过函数中参数的描述来判断调用该函数需要提供哪些信息。因此，当它告知后台应该使用哪个函数时，也会将用户提供的信息转化为函数所需的参数值，并以JSON格式返回给后台。后台拿到这些参数后，直接调用函数即可获得结果。
此外，还有一个 required 字段，它告诉大模型哪些参数是必填项。如果用户提供的信息，再加上大模型自身掌握的数据，仍然无法填满所有必填字段——那么大模型就不会调用这个函数。
六、连续Function Call的典型场景
假设用户提问：“斯德哥尔摩比巴黎的天气更晴朗吗？”
你会发现，只查询一次函数无法得到最终答案。那该如何处理呢？实际上需要建立一个与大语言模型对话的循环：先调用天气函数查询斯德哥尔摩的天气，将结果告知大模型；再调用天气函数查询巴黎的天气，再将结果告知大模型。最终大模型结合这些信息，给出完整的回答。
那么问题来了：遇到这种需要多次调用函数的情况，我们如何知道何时不再需要继续调用？
OpenAI官方文档中明确指出：GPT的每次回复都会附带一个 finish_reason 字段。当该字段的值为 stop 时，就意味着最终结果已经生成完毕。
进一步延伸：如果可以多次调用函数，便能完成更多复杂的任务。例如：“帮我把今天北京的天气编成一首七言绝句诗，同时把这首诗转成text格式，保存到本地我的文档里。”这是连续Function Call的另一种应用场景——在同一个任务下调用不同的函数。只要函数功能是现成的，与多次重复调用同一个函数的逻辑并无本质区别。顺着这个思路向下探索，可以衍生出许多丰富的应用场景。
七、Function Call的更多实际应用
如果要求大模型“列举出欧洲最大的三个城市主要使用什么语言，同时让大模型以JSON格式输出”，通常我们会怎么处理？当然可以直接通过Prompt让大模型生成结果，但有时它会输出这样的内容：
这显然不符合预期。换个思路：如果我们能定义一个符合预期输出格式的函数，借助Function Call的能力，最终输出我们想要的结果，是不是更理想？函数可以这样定义：
最终生成的结果如下：
这个示例很好地达成了预期目标，也给我们带来了更多启发。对于更多类型的任务，利用Function Call的能力来实现，确实充满想象空间。