一句话回答
查天气这件小事,已经包含完整的工具链路。AI 负责理解和判断,先理解用户目标,再选择工具和参数;程序执行工具拿到真实数据;结果回到 AI 后,AI 再判断要不要带伞并回答用户。
01 用户只说了一句话
intent split
明天上海天气怎么样?需要带伞吗?
明天上海天气怎么样?
需要查询实时天气数据。
需要带伞吗?
需要根据天气结果进行判断。
第一步不是立刻回答,而是先理解用户到底想完成什么。
02 AI 自己并不知道明天的天气
real-time data
模型知识
来自训练阶段,适合解释概念和常识,但不等于明天的实时天气。
实时天气
下不下雨、多少度、风多大都会变化,需要外部工具查询。
事实会变化时,可靠做法是先查,再答。
04 AI 准备调用天气工具
parameters
get_weather
location上海
date明天
“明天”如果需要标准日期,还要转换成具体年月日。
05 注意:AI 只是“提出调用”
orchestration
AI 决定要查天气程序收到调用请求天气工具真正查询
AI 负责判断,程序负责调度,工具负责干活。
06 天气工具真正开始工作
tool result
城市上海
天气小雨
温度22~27℃
降雨概率70%
风力3级
07 工具结果重新交给 AI
context update
用户问题
明天上海天气怎么样?需要带伞吗?
工具结果
小雨 / 22~27℃ / 降雨概率 70%
08 AI 根据结果进行判断
reason on result
降雨概率 70%+天气为小雨=建议带伞
天气工具负责提供数据,是否带伞这个建议由 AI 根据数据完成。
09 把整个链路串起来
full chain
用户提问
AI 理解任务
判断需要实时数据
选择 get_weather
准备参数
程序执行工具
工具返回结果
AI 继续判断
返回用户
10 如果用户没有说城市怎么办?
missing parameter
用户只问明天天气
AI 检查参数
发现缺少城市
询问用户
用户提供上海
调用天气工具
信息不足时,不要硬着头皮调用工具,更不要替用户猜城市。
11 如果天气工具失败怎么办?
retry
第一次查询
请求超时
等待
第二次查询
成功返回
临时错误可以有限重试,连续失败就明确告诉用户暂时无法获取。
12 如果用户的问题变复杂呢?
parallel calls
用户问题
查询上海天气
查询杭州天气
汇总结果
AI 比较
给出出行建议
两个城市的天气互不依赖,可以并发查询。
13 如果还要帮用户创建日程呢?
serial task
查询天气
判断是否下雨
如果适合
查询下午 3 点是否有空
创建日程
必须先知道天气,才能决定要不要继续查日历和创建日程。
14 一个简单问题,已经包含 Agent 的核心结构
concept map
理解用户问题Prompt / 上下文
判断需要实时数据Agent 判断
选择天气工具Tool Calling
理解工具用途工具说明
填写上海、明天参数
调用天气服务工具执行
工具失败再次尝试Retry
同时查两个城市并发
查完天气再建日程串行
连接外部工具MCP 等接入方式
15 从“回答问题”到“完成任务”
agent workflow
用户目标
AI 理解
判断需要什么
选择工具
准备参数
程序执行
获得真实结果
AI 继续判断
必要时继续调用工具
完成任务
AI
理解问题、判断缺什么、选择工具、读懂结果并组织回答。
程序
接收工具调用请求,调度工具,处理权限、重试和返回结果。
工具
真正查询天气、搜索资料或执行外部系统动作。
本节练习
画出一条天气工具链
把“明天上海天气怎么样,需要带伞吗”拆成理解任务、选择工具、填写参数、执行查询、返回结果、判断带伞和最终回答,并补上缺城市与工具失败两个分支。
目标用户真正想知道什么?
数据需要什么实时信息?
工具应该选哪个工具?
参数城市和日期是否完整?
失败超时、缺参怎么处理?
回答如何把数据变成建议?
本节小结
- 简单的天气查询,也包含完整的 Agent 工具链。
- AI 通常只是提出工具调用,真正执行的是外部程序和工具。
- 工具返回数据以后,还要交回 AI 做判断和表达。
- 缺参数、工具失败、多城市并发、先查天气再建日程,都是同一条链路的不同变体。