Agent 调用外部工具失败时，如何区分短暂网络抖动、工具服务不可用和业务错误，并设计超时、重试、熔断与降级策略？｜滴滴 AI 应用开发面经解析

60 秒回答模板

我会先把工具调用失败分成三类，而不是统一重试。短暂网络抖动通常表现为连接超时、偶发 5xx、DNS/TLS 抖动或单次请求延迟异常，适合短超时、指数退避、少量重试和 jitter；工具服务不可用通常是持续 5xx、超时率升高、限流或依赖故障，需要熔断、限流、排队保护、降级到缓存或备用工具；业务错误通常是参数不合法、权限不足、资源不存在、余额不足、状态冲突等，重试没有意义，应该把错误转换成可解释反馈，必要时让 Agent 重新规划参数或请求用户补充信息。策略上我会按工具重要性和副作用设计。读操作可以更积极重试，写操作必须有幂等 key、去重和补偿，避免 Agent 重复下单、重复发券或重复修改状态。每个工具要有 connect timeout、read timeout、总 deadline 和上游预算传递，防止一个慢工具拖垮整轮 Agent。熔断要基于错误率、超时率、P95/P99、并发和限流码，半开探测恢复；降级要提前定义 fallback，例如返回缓存结果、只做检索不执行动作、切换备用 provider、让模型承认当前工具不可用并给出人工处理路径。最后用 traceId 串起用户请求、模型规划、工具入参、返回码、重试次数和最终回复，才能定位是模型计划问题、参数问题还是外部依赖问题。

考点 失败先分类：网络抖动可重试，服务不可用要保护，业务错误要改参或反馈

难度 真实面经题

回答目标 让候选人展示 Agent 工具调用的生产级可靠性思维：按错误语义分类，用有边界的容错保护依赖和用户体验，并通过观测数据持续改进。

深入解析

错误分类

先区分网络抖动、服务不可用和业务错误。网络抖动是偶发、短时、可能重试成功；服务不可用是持续性或容量性问题；业务错误代表请求语义不成立，继续重试只会放大流量和噪声。

超时预算

工具调用要设置连接超时、读取超时和总 deadline，并把整轮 Agent 的剩余时间向下传递。没有超时预算时，一个慢工具会让多步规划全部堆住，也会让用户看到长时间无响应。

重试边界

重试只适合可恢复、可幂等的失败。读请求可以指数退避并加 jitter，写请求必须使用幂等 key、请求去重和状态校验。对 4xx 业务错误、权限错误、参数错误不应盲重试。

熔断降级

当某工具持续超时、错误率升高或触发限流时，应熔断并进入半开探测，避免 Agent 集群持续打爆依赖。降级方案包括缓存、备用工具、只读模式、人工转接和明确拒答。

Agent 反馈

错误不能只作为异常栈丢给模型。需要把可恢复状态、用户可行动信息和工具不可用原因转成结构化 observation，让 Agent 决定改参、换工具、询问用户还是停止执行。

观测闭环

埋点要覆盖工具名称、错误类型、状态码、耗时、重试次数、熔断状态、降级路径和最终答案质量。只有能按工具和错误类型聚合，才能发现慢依赖、坏参数和模型规划缺陷。

易错点

把所有失败都归为网络问题，默认重试。
忽略写操作副作用，没有幂等和去重。
只设置单次超时，不控制整轮 Agent deadline。
没有熔断和限流，依赖故障时让 Agent 集群持续放大流量。
错误信息直接丢给模型或用户，缺少结构化错误码和可行动反馈。
只看成功率，不看 P99、重试次数、降级率和最终答案质量。

面试官追问

如果工具返回 429，应该重试吗？

要看限流语义。可以读取 Retry-After 或限流窗口做延迟重试，但必须限制并发和总预算；如果是长期配额不足，应熔断或降级，而不是所有 Agent 同时退避后再一起冲击依赖。

写工具调用为什么必须强调幂等？

因为 Agent 可能因超时不知道写操作是否已经生效，如果直接重试会造成重复副作用。幂等 key、业务状态机和去重表可以保证同一意图最多生效一次。

工具失败后要不要让模型自己解释？

可以让模型组织语言，但底层必须提供结构化错误码和可展示原因。不能让模型凭异常栈猜测，否则容易把权限、限流或服务故障编成错误建议。

如何防止重试风暴？

用全链路 deadline、指数退避、jitter、最大重试次数、客户端限流、熔断和队列长度保护。关键是把重试当作有预算的容错，而不是默认无限补偿。