大模型(LLM)虽然拥有强大的理解和推理能力,但它也存在一些天然的局限。

例如:
换句话说,LLM 可以知道应该做什么,但不一定能够真正完成这件事。
因此,业界逐渐形成了 LLM + Tool(工具) 的模式:
两者结合后,AI 才具备了真正解决复杂任务的能力。
Tool Call(工具调用) 是指让大模型能够使用外部工具的一种机制。
当模型判断某个问题需要借助外部能力时,它会:
例如:
复制代码用户:今天上海天气怎么样?LLM:
发现需要实时天气数据
↓
调用 Weather Tool
↓
获取天气结果
↓
组织最终回答
整个过程,就是一次典型的 Tool Call。
答案是:Tool Schema。
可以把 Tool Schema 理解成:
例如我们有一个查询天气的函数:
复制代码function getWeather(city) {
return weatherApi(city)
}
对于程序员来说,我们知道:
复制代码函数名:getWeather
参数:city
作用:获取天气
但 LLM 并不能直接读取你的代码。
因此,我们需要通过 Tool Schema 来告诉模型:
复制代码{
"name": "get_weather",
"description": "获取指定城市的天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称"
}
},
"required": ["city"]
}
}
其中:
name:工具名称description:工具用途说明parameters:工具需要的参数当用户提问:
复制代码上海今天天气怎么样?
模型会阅读 Tool Schema,发现:
复制代码get_weather
↓
获取城市天气
↓
需要 city 参数
于是生成:
复制代码{
"name": "get_weather",
"arguments": {
"city": "上海"
}
}
需要注意的是,模型并不会执行函数。
Tool Schema 更像是一份接口文档。模型根据这份文档生成调用参数,而具体的接口请求和执行逻辑仍然由业务代码负责。
因此可以简单理解为:
前面我们已经知道:
那么当用户发起一个请求时,一次完整的 Tool Call 到底是如何完成的呢?
假设我们注册了一个天气工具:
复制代码{
name: "get_weather",
description: "获取城市天气",
parameters: {
city: "string"
}
}
当用户提问:
复制代码上海今天天气怎么样?
模型会根据 Tool Schema 判断:
复制代码需要查询实时天气
↓
找到 get_weather 工具
↓
提取参数 city=上海
↓
生成 Tool Call
生成的调用请求类似于:
复制代码{
"name": "get_weather",
"arguments": {
"city": "上海"
}
}
需要注意的是:
随后由业务程序执行工具,并将结果返回给模型:
复制代码用户提问
↓
LLM分析问题
↓
生成 Tool Call
↓
程序执行工具
↓
获得执行结果
↓
结果返回给LLM
↓
生成最终答案
例如工具返回:
复制代码{
"temperature": 31,
"weather": "晴"
}
模型便可以基于结果生成回答:
复制代码上海今天晴天,气温31℃,适合外出,但注意防晒。
因此,Tool Call 的本质是: