Tool Calling 工具调用实战：手写循环调用链

上一节，咱们说第三章要解决一个问题：怎样让模型连接并使用真实的业务能力。

而想要解决这个问题，最简单的方式就是使用 Tool Calling

跟大家举个例子，假设用户问：

查询订单 A1024 是否满足退款条件，并告诉我是否需要人工审核。

大家可以想一下，如果按照咱们之前实现的 RAG ，那么模型会怎么处理呢？

模型的处理方式肯定是：

查询知识库是否有这条信息，如果有就进行融合检索。

然后把检索到的信息和用户的问题一起发给大模型。

但是，大家想想，这样的话，检索的信息是不是就是完全固定的了。

因为大模型并 不能知道 A1024 订单具体是什么商品，也不知道这个商品具体是多少钱。

所以，这一小节咱们就要利用 Tool Calling 完成两个事情：

• 根据订单号查询到具体的订单信息
• 根据订单信息判断是否满足退款条件

Tool Calling 到底是什么

Tool Calling 大家可以理解为：应用把可以使用的工具（Tool 函数）的调用方式交给模型，模型根据用户任务决定是否调用对应的工具（Tool 函数）。

但是这里 注意：

真正的 工具（Tool 函数） 调用并不是模型调用的，模型只会返回工具名和参数，最后的调用是应用本身完成的。

应用完成 工具（Tool 函数）调用之后，再把响应的结果给模型。

最终让模型生成回答。

这里给大家生成了一个流程图，大家可以作为参考：

这样的一套流程，有的人会叫做 Function Calling，有的会叫做 Tool Calling。

但是本质上都是一个意思。

明白了什么是 Tool Calling 之后，接下来咱们来看下 Tool Calling 的执行原理。

想要理解 Tool Calling 的执行原理，咱们必须得先明确一件事，那就是：模型和咱们写的 Agent 程序，是绝对的两个独立的东西。

假设，咱们有一个 Tool 函数（工具） 叫做 getOrder ，那么这样的一个函数是 Agent 应用的函数（Node 或者 Python 的一个函数（方法））

而模型（GPT、Claude、GLM） 都是在对应大模型厂商的服务器上的。

模型一定是不知道 getOrder 这样的函数，也不能直接调用函数。

所以，Tool Calling 并不是把函数交给模型运行，而是在模型和应用之间 约定了一套调用流程 （请先记住这个词，后面的小节会详细讲）。

还是回到前面的订单问题：

查询订单 A1024 是否满足退款条件，并告诉我是否需要人工审核。

这句话最终会经过下面几个步骤。

第一步：把用户问题和工具说明交给模型

假设现在有两个工具函数：

工具函数一：get_order
作用：根据订单号查询订单信息
需要的参数：orderId

工具函数二：check_refund_eligibility
作用：判断订单是否满足退款条件
需要的参数：订单状态、商品类型、签收天数和退款金额

那么 Agent 应用就会先调用大模型，同时告诉模型：当前有两个工具可以使用。

第二步：模型提出工具调用请求

模型看到用户要查询订单 A1024，就会发现自己缺少这笔订单的真实数据。

所以，它会先返回一个工具调用请求，类似于下面这样：

我要调用：get_order
调用参数：orderId = A1024

注意，这一步没有查询订单。

模型只是完成了两个判断：应该使用哪个工具函数，以及调用工具函数需要提供什么参数。

至于这个工具是不是真的存在，参数格式对不对，模型都不会管。

第三步：应用执行真正的工具

应用收到模型提出的调用请求以后，会根据工具的名字找到真正的 getOrder 函数。

然后根据模型给的请求参数，调用该函数，得到对应的返回值。

假设订单系统返回：

订单号：A1024
商品：咖啡机
商品类型：普通商品
订单状态：已签收
签收天数：3 天
退款金额：3000 元

那么，到这里，模型的 第一次调用 已经结束了。

但是，咱们一定得知道，到目前整个任务并没有完成。

咱们还得把 get_order 返回的信息交给模型才可以。