之前我们学习了Agent里的RAG和Memory,但还有一个很关键的部分一直没细讲,那就是Tool Use(工具调用)。
Tool Use
其实很多人第一次接触Agent时,会以为"会调用API"只是一个附加功能,但实际上,工具调用才是真正让Agent从聊天工具变为能做事的机器的关键。
LLM本质上只是一个语言推理系统,它虽然知道很多知识,但它没有"手"和"眼"。它不知道现在几点,也不知道今天广州下不下雨,更没法帮你操作数据库、执行代码或者控制设备。它只能"想",不能真正"行动"。
而工具本质上,就是把现实世界里的能力,包装成一种结构化接口(Schema),让模型知道:"这个东西能做什么、需要什么参数、会返回什么结果。" 以下是一个查询天气的例子:
{
"tool_name": "weather_api",
"description": "查询城市天气",
"parameters": {
"city": "string"
}
}
当Agent接收到"广州今天天气"这个任务时,它并不是直接回答,而是会进入一种循环:Thought(思考)→ Action(行动)→ Observation(观察),也就是昨天提到的ReAct框架。
一般的逻辑思考顺序是:
-
先思考需不需要工具
-
决定调用 weather_api
-
生成结构化JSON参数
-
系统真正去执行API
-
返回天气结果
-
模型再根据结果组织最终回答
这里可能会有个误区,以为"调用工具"是模型自己完成的,但实际上,模型只是负责生成调用指令,真正执行的是系统层。也就是说,模型负责"决定做什么",系统负责"真的去做",这个分层让系统层就可以加入很多容错机制。比如:
-
参数格式校验
-
超时限制
-
自动重试
-
fallback备用方案
-
默认参数补全
因为现实世界并不是稳定的,API可能挂掉,网络可能超时,返回的数据结构也可能变。如果没有这些系统层的保护,一个Agent在真实环境里会非常脆弱。这些机制是Agent的能够不偏离方向,能够完成任务的保证(至少会返回一个结果,会告诉用户到底做到了什么程度)。
另外,Agent其实是会"自我修复"的,比如模型第一次调用工具时,忘了传 city 参数,系统会返回:
参数错误:缺少 city 字段
然后这个错误信息会再次进入上下文,变成Observation。模型看到后,会重新分析问题,然后自动补全参数,再调用一次工具,过程中产生的错误并不是流程终点,而是Agent下一轮思考的输入。这种模式就是我们之前说的模型会根据输出进一步调整直到最后有一个答案。
在Agent中,Memory决定Agent记得什么;RAG决定Agent能查到什么;而Tool Use决定Agent真正能做到什么。因为只有工具,才能真正把模型的推理能力连接到现实世界,就跟猿人第一次学会使用工具才能称之为人类一样。