Appearance
工具调用：那双手
到这里，我们已经有了会思考的大脑（LLM），也补上了知识（RAG）。但这时候的它，依然只是个"会说"的存在：你想让对方把订单状态发给你，它只能说"订单是待发货"；要真的去改个状态、发封邮件、调个接口，它干不了。
一个只会说话、不会干活的"员工"，是帮不上什么大忙的。这一篇就讲它怎么长出"手和脚"——也就是工具调用（工具参与决策，在技术圈常叫 Function Calling，函数调用）。
先破一个普遍误会
很多人以为"工具"是模型自己会的。其实模型根本不会使用工具。真相要往外退一步，才看得清楚。
工具，本质上是人写好的一段段函数——"查天气"是一个函数，"给用户发邮件"是一个函数，"读某个文件"是一个函数。这些函数是程序员一枚枚造出来的零件，摆在那里备用。
模型真正做的，只有一件事：判断该用哪个零件，以及怎么用。 它不会去真的调用，它只是"表达意图"。
怎么表达？不是靠说话的"我想要天气"，而是靠一套约定好的格式。当模型觉得"这事必须动工具才能办"，它会说出类似这样的话：
要调用：查询天气
参数：城市 = 北京——仅此而已。它给出的不是"执行"，而是一个"请求"。真正把"查询天气"这个函数呼起来、把结果拿回来的，是中间那个框架。然后把结果再递回给模型，由它组织成一句人话告诉你。
一次完整的"工单流转"
把整个过程摊开，很像走一张工单：
- 模型开单：用户问"北京天气怎么样"，模型判断该用工具，便按格式写下"我想调用《查询天气》，参数北京"。
- 系统接单：框架收到这张"单"，检查格式对不对、参数健不健全。
- 系统执行：真的去把"查询天气（北京）"这个函数运行起来。
- 系统回执：把返回结果（"北京，晴，25℃"）交还回给模型。
- 模型答复：模型拿到结果，组织成通顺的回答："北京今天晴，气温25度。"
注意这中间的微妙处：模型从头到尾没有真刀真枪碰过系统内部。它只是负责"决定 + 填参数"，真正的执行、尤其是那些有后果的执行，都被中间这道闸看管着。
这带来一个极重要的好处：安全。 一个模型说"我要删除全部数据"，系统在接单那一步就可以拒绝，不会真把它删了。人的控制，恰恰是在这层"工单审核"上放进去的。
为什么需要工具
你可能会想，塞进 RAG 的资料不也能提供信息吗？两者不冲突，分工不同：
- RAG 喂的是"静态知识" —— 手册里写着的、相对不变的事实。
- 工具接通的是"动态世界" —— 实时是几点、今天天气、库存还剩多少、某接口现在返回什么。
而且工具的用处远不止"查"。它让模型第一次拥有了改天换地的能力：发个消息、下一张订单、提交个表单、跑一段程序。没有工具，模型永远是信息的"解说员"；有了工具，它才能是事情的"参与人"。
常见的工具，其实也就几大类：
- 取数据：查天气、查股价、查订单、读数据库、抓网页；
- 写数据：记一条、提交表单、改一条记录；
- 对外动作：发邮件、发消息、发通知、订个日程；
- 算与编：跑一段代码、调用某个 AI 能力、操作文件。
一个智能体"能干多少活"，很大程度就取决于你给它备了多少趁手的工具、以及这些工具说明得清不清楚。
工具的"说明书"很重要
这里有个往往被低估的细节：每个工具都得配一份说明书——它叫什么名字、是干什么的、每个参数填啥。因为模型没有"肉眼看到你写的函数"，它只能依据这份说明书来判断"现在该不该用它、参数怎么填"。
所以：
- 描述越清楚，模型就越知道什么时候该用它、参数填得越准；
- 一个工具只干一件事，别做"万能函数"，模型容易犯迷糊；
- 报错要能传回来，工具失败了，把原因讲给模型听，它会换个思路再试，而不是傻在原地。
工具和技能，别混为一个词
这一篇讲的"工具"，是单个零件——查天气、发邮件，一件是一件事。
下一篇要讲的"技能"，是一套工序——把好几件工具按顺序拼起来的完整流程。它俩一个是手，一个是用手的方法。
一个比方：工具是工具箱里的一把螺丝刀，技能是"怎么拆装一台设备"的完整教程。 教程里要用好几把工具，但教程本身是一个整体。
这一篇的要点，用一句话收束：
模型本身并不会用工具。它只是判断"该用哪个、怎么填参数"，把"请求"交给中间的框架去真正执行。工具让只会说的模型能"动手"，让信息变成动作；而中间那道"工单审核"的闸，正好是安放安全与控制的地方。
有了手，接下来该解决另一个实际问题——它转头就忘：「记忆机制：如何留存」。