问智能体被宣传得无所不能实际部署后连“查个订单状态”都经常翻车。问题出在哪答问题出在把智能体想得太强把工具调用想得太简单。翻车的重灾区不是“理解意图”是“异常处理”。一、一个典型的翻车现场用户说“查一下订单X123的发货状态”。智能体回答“已发货单号SF1234567890”。但实际上订单X123根本不存在。智能体编造了一个看起来合理的回答。问题不在“理解意图”——智能体确实理解了。问题在“工具调用失败后的处理”——当系统返回“订单不存在”时智能体没有如实反馈而是自作主张编造了答案。二、工具调用稳定的三个关键细节细节一工具描述要“业务友好”不要“技术直译”模型选工具靠的是描述文本。描述写得太技术化模型不知道该用哪个写得太笼统模型可能选错。错误的描述正确的描述根据订单号查询订单详细信息包括状态、收货地址、物流单号。适用于客服查单、售后核实等场景。如果订单号不存在返回明确的订单不存在错误信息不要编造数据。细节二异常情况不给模型“自由发挥”的机会大部分智能体项目的问题假设外部API永远正常。但API会超时、会报错、会返回空数据。建议给每类异常预设兜底规则异常类型兜底规则API超时15秒返回“系统繁忙请稍后再试”API返回错误码把错误码原文反馈给用户查询结果为空直接说“未找到相关记录”不要让模型在异常情况下自己发挥。它的“创造力”在异常时会变成灾难——编造数据、美化错误。细节三参数校验在应用层做别依赖模型自检模型输出的JSON可能格式不对、字段缺失。必须在应用层做强制校验三、稳定工具调用的架构分层大模型负责理解意图、提取参数、生成最终回答应用层负责校验参数、执行工具调用、处理异常、走兜底规则把“安全网”放在应用层而不是依赖模型自我纠错。大模型做它擅长的理解和生成应用层做它擅长的校验和执行。FAQQ智能体的工具调用和普通API调用有什么区别AAPI调用是“程序→系统”的确定性交互。工具调用是“用户→大模型→系统”的非确定性交互——中间多了语义转换环节。这个环节的容错设计是工程核心。Q开源模型做工具调用够用吗AQwen2系列、DeepSeek系列都支持。和GPT-4的差距在复杂工具选择和异常处理上。工具控制在5个以内、异常逻辑写在应用层开源模型的生产可用性可以接受。Q工具调用的日志需要记录什么A用户原始输入、模型选择的工具和参数、API返回结果含耗时、用户是否满意。有这套日志才能持续优化。一句话总结智能体翻车的重灾区不在“理解”在“异常处理”。工具描述写清楚使用场景应用层做好校验和兜底比换更好的模型更能提升稳定性。