Tool Use：工具调用
参数里的知识并不总够用。有些任务需要查天气、查数据库、执行代码、调用搜索、发送请求。Tool Use 的关键不是“模型突然会用 API 了”，而是它学会了判断什么时候应该把问题交给外部工具，并把工具结果重新组织成可读答案。
先判断需不需要工具
再构造调用参数
最后用结果回答
换个任务，看模型什么时候会决定调用工具
你可以切换任务类型，再切换当前阶段。页面会分别展示用户问题、模型内部判断、工具调用参数、工具返回值，以及最终回答和“不调用工具时”的对比。
当前用户请求
这一步不是给人看的自然语言，而是给工具看的结构化参数。
真实值来自外部系统，模型接下来要基于这些结果继续生成。
如果不调用工具
调用工具后的回答
Tool Use 和 RAG 有什么不同
RAG 更像“查资料”
它主要从知识库里取证据片段，再让模型基于这些文本回答。核心是补充事实和上下文。
Tool Use 更像“执行动作”
它可以调用天气 API、数据库查询、计算器、日历、代码执行器，不只是拿文本片段，而是拿真实系统结果。
RAG 常回答“是什么”
比如制度、产品说明、知识问答、FAQ、手册问答，这些更偏向基于文档检索。
Tool Use 常回答“查一下 / 算一下 / 做一下”
比如查天气、算汇率、下订单、读库存、发送邮件、运行 SQL，这些更偏向工具执行与状态读取。
一个好用的工具调用系统还需要什么
清晰的工具 schema
工具名、参数、类型、必填项要定义清楚，否则模型很难稳定生成可执行调用。
参数校验
不能把模型生成的任何参数都直接执行，真实系统里通常会做类型校验、权限检查和风险限制。
结果回流格式
工具输出不能只是一坨原始数据，通常还要整理成模型易读、用户可审计的格式。
失败处理
工具超时、无数据、权限不足都很常见。系统要让模型知道“这次没成功”，而不是默默编造结果。
一句话总结： Tool Use 让模型不只会“说”，还能通过外部系统去“查、算、做”，这也是很多 Agent 能真正落地的前提能力。