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