一句话先摆这：Agent调外部工具/API,默认状态下一超时就整条对话崩，用户看到的是一堆红色报错。这篇就讲怎么让它"调失败也别死"。

我做的是一个查物流的智能体，要调第三方快递接口。问题是那个接口高峰期经常三五秒不响应，偶尔直接502。一开始没做任何兜底，结果用户问"我快递到哪了",接口一抖，Agent整个流程中断，啥也回不出来。

避坑清单，按踩的顺序列：

坑一：不设超时，干等到死。 默认很多工具节点不主动断，接口不响应它就一直挂着，用户那边转圈十几秒。先把单次调用超时压到合理值，我设的3秒，超了立刻进重试逻辑。

坑二：无脑重试，雪上加霜。 接口本来就忙，你立刻连发三次，等于帮它DDoS。重试要带退避——第一次失败等1秒，第二次等2秒，最多两到三次。别死磕，磕不出来就该降级了。

坑三：没有降级话术，重试完直接抛错。 这是最伤体验的。重试还失败，不能把技术报错甩给用户。我配了一句兜底回复："物流系统当前繁忙，您的快递单号是X,可以稍后在XX页面直接查询。"——把单号回给他，给个替代路径，比一句"系统错误"强一百倍。

坑四：分不清"该重试"和"不该重试"的错。 超时、502这种是临时的，值得重试。但参数错误、单号不存在这种，重试一万次也没用，应该直接进降级。我按错误类型分了流，省了无效重试。

讲个真实数字：加了退避重试加降级之后，那个物流接口的"用户可见失败率"从大概12%降到2%以下。剩下那2%也不是白屏了，是给了兜底话术和自助链接。

这套重试-降级逻辑我是在一个零代码搭智能体的平台上配的，工具调用节点能直接设超时、设重试次数、连降级分支，可视化拉条件线就行，不用自己在代码里写try-except嵌套。不过有个取舍得提：平台的重试策略是通用的，遇到那种"要根据返回body里的业务码决定重不重试"的细活，还是得自己在节点里加判断，它不会替你读懂每个第三方接口的脾气。

记住一点：Agent的稳定性，七分在它怎么处理"调用失败",三分在调用本身。把失败路径设计好，比追求成功率更重要。

（顺一句，大模型那层我用的是讯飞MaaS,现成API直接接，不操心算力。）