什么是 Function Calling？

Function Calling 是一种让大模型在需要时调用外部工具的机制。这里的外部工具可以是 API、数据库，也可以是开发者定义的自定义函数，用于帮助模型获取信息或执行操作。

在不同文档和实现中，这类外部能力可能被称为“工具”，也可能被称为“函数”。两种说法的核心指向接近：让大模型不只生成文本，还能在合适的任务中连接外部系统。

可以用一个简单类比理解：大模型像负责理解需求和选择方法的调度者，外部工具像可被调用的专业能力模块。模型判断用户要做什么，工具负责提供数据或完成动作。

要点： Function Calling 不是让模型凭空获得所有外部能力，而是让模型在应用程序提供的工具范围内，判断是否调用以及调用哪个工具。

为什么大模型需要 Function Calling？

大模型擅长理解语言、归纳信息和生成回答，但它自身不一定具备获取外部信息或直接执行业务操作的能力。Function Calling 的价值在于，把模型的语言理解能力与外部系统的实际能力连接起来。

扩展信息获取能力

当用户的问题需要外部数据支持时，模型可以通过工具调用 API 或数据库来获取信息。这样可以弥补模型仅依赖自身知识时可能遇到的信息边界。

支持业务动作执行

当任务不只是回答问题，而是需要触发某个操作时，Function Calling 可以通过自定义函数连接业务逻辑。例如，模型理解用户意图后，由外部函数执行相应操作。

让模型分工更清晰

在 Function Calling 架构中，模型主要负责理解用户查询、判断是否需要工具，以及选择合适的工具；外部系统则负责提供数据或完成动作。这种分工有助于把自然语言交互和相对确定的业务能力结合起来。

工具调用流程如何运转？

Function Calling 的高层流程通常由应用程序、模型和外部工具共同完成。应用程序先把可用函数及其使用说明提供给大模型，模型再根据用户查询判断是否需要使用函数。

阶段	主要参与方	核心任务
定义工具	开发者	定义可用工具，并说明每个函数的用途和使用方式
提供工具说明	应用程序	将函数列表及说明提供给大模型
判断是否调用	大模型	根据用户查询选择使用函数或不使用函数
连接外部能力	外部工具	通过 API、数据库或自定义函数获取信息或执行操作

开发者定义可用工具

工具通常由开发者定义。开发者需要明确工具能做什么、适合在什么情况下使用，以及它与业务系统或外部数据源之间的关系。

如果工具定义过于模糊，模型就更难判断何时应该调用该工具；如果工具能力范围过宽，调用边界也容易变得不清晰。

应用程序提供函数及说明

在工具调用流程中，应用程序会向大模型提供一组函数及其使用说明。模型并不是自动知道所有外部系统，而是基于这些已提供的工具描述进行判断。

因此，函数说明是模型理解工具能力的重要依据。它需要帮助模型区分：哪些问题适合调用工具，哪些问题可以直接回答。

模型判断是否需要调用函数

大模型会根据用户查询选择使用或不使用函数。也就是说，Function Calling 并不意味着每次用户提问都会触发外部工具。

例如，当用户只是询问概念解释时，模型可能不需要调用函数；当用户需要外部数据或执行操作时，模型才更可能选择工具。

特定流程中可以强制调用函数

在一些明确的业务流程中，函数调用也可以被设置为强制使用一个或多个函数。这样做适合那些必须经过外部工具确认、查询或执行的任务。

要点： 是否强制调用函数取决于业务设计。普通问答可以让模型自行判断；强约束流程则可以要求模型必须使用指定工具。

工具、函数与 API 有什么关系？

在 Function Calling 语境中，工具、函数和 API 经常一起出现，但它们并不是完全相同的概念。

概念	在 Function Calling 中的含义	典型作用
工具	更宽泛的外部能力抽象	包装 API、数据库访问或自定义函数
函数	模型可选择调用的能力单元	描述一个可被调用的具体能力
API	常见的外部能力来源之一	提供系统接口、数据查询或业务操作入口

工具是更宽泛的抽象

工具可以理解为对外部能力的封装。它既可以连接 API，也可以访问数据库，还可以对应开发者写好的自定义函数。

因此，在设计 Function Calling 时，不必把工具狭义地理解为某一种接口形式。关键在于：这个工具是否能被模型识别、选择，并在需要时连接到外部能力。

函数是可调用的能力单元

函数通常是开发者定义的能力单元。模型看到的是函数的名称、用途和使用说明，然后根据用户查询判断是否使用它。

在一些文档和实现中，“工具”和“函数”会被近似使用。为了便于理解，可以把函数看作工具的一种具体呈现方式。

API 是常见外部能力来源

API 是 Function Calling 常见的连接对象之一。模型本身负责理解用户意图，Function Calling 则把这种意图与 API 背后的外部能力连接起来。

不过，Function Calling 并不只等于 API 调用。它也可以连接数据库访问或自定义函数，具体取决于开发者提供了哪些工具。

Function Calling 的典型应用场景

Function Calling 适合那些需要连接外部系统的任务。只要用户需求涉及外部信息获取或业务动作执行，就可以考虑通过工具调用来补足模型能力。

用户需求	解决方式	效果
查询外部信息	调用 API 获取相关结果	让回答基于外部系统提供的信息
访问结构化数据	通过工具连接数据库查询	将自然语言问题转化为外部数据获取任务
执行业务动作	调用开发者定义的自定义函数	由外部系统完成具体操作
在多个能力中选择合适动作	向模型提供多个函数及说明	让模型根据用户查询判断是否调用以及调用哪个工具

信息查询场景

当用户提出的问题需要外部数据时，Function Calling 可以让模型通过工具获取信息。相比只依赖模型自身回答，这种方式更适合需要连接外部数据源的任务。

数据库访问场景

数据库可以作为外部工具的一类来源。开发者可以把数据库查询能力封装为工具，使模型在合适的用户请求下触发查询。

业务动作执行场景

当用户希望系统完成某个动作时，开发者可以把相关业务逻辑封装为自定义函数。模型负责理解用户意图，外部函数负责执行具体操作。

设计 Function Calling 能力时应关注什么？

Function Calling 的效果很大程度上取决于工具定义是否清晰、函数说明是否准确，以及工具范围是否符合业务边界。

工具职责要清晰

每个工具都应有明确职责。开发者需要说明工具用于解决哪类问题，而不是让一个工具承担过多不相关能力。

清晰的职责有助于模型判断何时调用工具，也有助于应用程序维护工具边界。

函数说明要便于模型判断

应用程序会把函数及其使用说明提供给大模型。函数说明应描述工具用途，帮助模型区分哪些用户查询需要调用工具，哪些不需要。

如果说明缺少使用条件，模型可能无法准确判断调用时机；如果说明过于宽泛，工具选择也可能变得不稳定。

必须使用工具的任务可设置强制调用

对于某些必须经过外部系统处理的任务，可以考虑设置强制使用一个或多个函数。这样可以减少模型在关键流程中跳过工具的可能性。

不过，是否强制调用应与业务流程一致。不是所有问题都需要工具，普通解释型问题通常可以由模型直接回答。

工具范围要贴合外部系统能力

工具通常由开发者定义，因此工具能力应与实际可用的 API、数据库或自定义函数保持一致。模型只能在应用程序提供的工具范围内进行选择。

检查清单： 设计工具前，可以先确认四件事：工具要解决什么问题、会连接哪些外部系统、函数说明是否足够清晰、是否存在必须强制调用的业务流程。

Function Calling 的适用边界和常见误区

Function Calling 能扩展大模型连接外部能力的方式，但它并不等于模型自动拥有外部系统的全部能力。理解边界，比单纯增加工具数量更重要。

误区一：有了 Function Calling，模型就能调用任何系统

Function Calling 的前提是应用程序向模型提供可用函数及说明。没有被定义和提供的工具，模型不能凭空完成外部信息获取或操作执行。

误区二：工具越多越好

工具数量增加并不必然带来更好的调用效果。模型需要根据用户查询判断是否使用函数，因此工具说明、职责边界和调用条件都很重要。

误区三：每次对话都应该调用函数

大模型可以选择使用函数，也可以选择不使用函数。对于不需要外部信息或业务操作的问题，直接回答可能更合适。

误区四：Function Calling 等同于完整业务自动化

Function Calling 只是连接模型与外部工具的一种机制。真正的业务流程还需要开发者定义工具、接入外部系统，并设计清晰的使用说明和调用边界。

小结

Function Calling 的核心，是让大模型在需要时调用由开发者定义的外部工具。工具可以连接 API、数据库或自定义函数，用于获取信息或执行操作。

理解 Function Calling 时，可以抓住三个关键点：第一，工具能力需要由应用程序提供给模型；第二，模型会根据用户查询判断是否调用函数，也可以在特定流程中被要求强制调用；第三，工具定义和函数说明决定了模型能否正确连接外部能力。