Agent API容错：重试降级与澄清

回答与解析

一、异常分层与捕获机制

工具调用异常按来源分三层处理：

核心原则：每层只处理本层能决策的，向上层暴露必要上下文。

二、重试策略设计

指数退避 + 抖动：

delay = min(base * (2 ** attempt) + random_jitter(), max_delay)
attempt < max_retries  # 通常3-5次

• base=1s, max_delay=30s, max_retries=3
• 抖动避免惊群效应
• 区分可重试错误（5xx、超时）与不可重试（4xx、鉴权失败）

熔断器（Circuit Breaker）：连续失败达阈值后快速失败，防止拖垮下游。

三、多级降级方案

按优先级递进：

1. 缓存回退：返回上次成功结果（带过期标记）
2. 默认值/静态规则：如地图API失败时返回"建议直接搜索目的地"
3. 功能裁剪：关闭该工具，用LLM内部知识替代（需提示用户"以下信息可能非实时"）
4. 流程终止：核心工具失败时优雅退出，而非 hallucinate

四、用户澄清触发条件

必须引入人工确认的场景：

• 工具返回低置信度结果（如多个POI相似度接近）
• 降级后信息质量显著下降（实时性/准确性受损）
• 用户query本身意图模糊（"附近好吃的"需确认范围/偏好）

交互设计：澄清请求应携带上下文（"地图服务暂不可用，您指的是A商场还是B餐厅？"），避免重复提问。

五、工程落地要点

• 可观测性：每个工具调用埋点（latency、status、retry_count）
• 配置化：重试参数、降级开关支持动态调整
• 兜底Prompt：明确告知LLM当前处于降级状态，约束其生成行为

学习建议

建议掌握常见网络异常处理方法，理解重试与降级的设计权衡，结合实际场景练习容错流程设计。

口语版讲法(约4分钟)

• 一句话定位：本质是系统鲁棒性设计
• 重试策略与边界：可重试vs不可重试，指数退避+熔断
• 多级降级：缓存、默认值、功能裁剪、终止
• 用户澄清触发条件：低置信度、降级质量下降、意图模糊
• 落地风险与工程要点：可观测性、配置化、兜底Prompt

这道题其实是在问，当Agent依赖的外部工具不可靠时，我们怎么保证整个系统还能稳定运行，同时不让用户体验崩掉。我会从重试、降级、用户澄清三个层面来设计，但真正落地时，每个方案都有它适用的边界，不是一股脑全上。

先说重试。我一般会把异常分成网络层和应用层两类。网络层像超时、连接断开，这种可以重试，因为多半是临时抖动；应用层像4xx、鉴权失败，重试也没用，直接降级。重试策略我用指数退避加抖动，base设1秒，最大30秒，最多重试3次。抖动很重要，不然一堆请求同时重试，下游直接雪崩。这里有个坑：重试不是万能的，连续失败次数多了，我会引入熔断器，比如10秒内失败超过5次，直接快速失败，保护下游。

再一个就是降级。降级不是一刀切，我会按优先级递进。第一级是缓存回退，返回上次成功结果，但得打上“可能过期”的标记。第二级是默认值或静态规则，比如地图API挂了，我就返回“建议直接搜索目的地”，而不是让LLM瞎编。第三级是功能裁剪，关掉这个工具，用LLM内部知识替代，但得提示用户“以下信息可能非实时”。最后一级是流程终止，核心工具挂了就优雅退出，绝不Hallucination。举个例子，在客服退款场景里，如果订单查询API超时，我会先试缓存，不行就返回“系统繁忙，请稍后再试”，而不是让模型编一个退款状态。

这里有个前提：降级方案必须在设计阶段就定义好，不能运行时再想。上线后我会特别关注降级频次，如果某个工具频繁触发降级，说明它本身有问题，得修。

然后说用户澄清。不是所有异常都要问用户，那样体验太差。我只有在三种情况下才会触发澄清：一是工具返回低置信度结果，比如搜“附近好吃的”返回多个相似POI，我会问“您指的是A餐厅还是B餐厅？”。二是降级后信息质量明显下降，比如实时天气API挂了，我用历史数据替代，得问用户“当前数据可能不是最新的，您能接受吗？”。三是用户query本身意图模糊，比如“查一下订单”，我会问“您想查订单号还是退款状态？”澄清请求要带上下文，别让用户重复说。

另外，实际落地时，重试和降级不是孤立的，它们需要跟业务场景联动。比如在金融风控场景里，降级策略可能完全不同，因为对实时性和准确性要求极高，降级方案得重新设计。这个边界划分很有意思，值得深入探讨。

最后收一下。我会把容错机制看成系统的“安全带”，平时不显眼，但关键时刻能救命。工程上我会埋好所有调用点的延迟和状态，把重试参数和降级开关做成配置化，方便动态调整。同时给LLM写一个兜底Prompt，明确告诉它当前处于降级状态，约束它别乱编。说白了，容错不是事后补洞，而是设计时就留好的退路。

关键一句:容错机制与业务场景联动，不同场景降级策略差异大，比如金融风控和客服系统完全不同。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你做个天气助手，调第三方API查温度时超时了，或者返回个空结果，你打算怎么处理？用户还在等回复呢。

2. 问法 2 · 层层追问

   Agent调外部工具出错了，你会怎么兜底？……如果重试了还失败，直接告诉用户“查不到”还是想办法？……那什么情况下你得反过来问用户才能保证体验？

3. 问法 3 · 直球架构

   设计一套Agent调用外部API的容错机制，包括重试策略比如指数退避、降级方案比如默认返回，以及触发用户澄清的条件，你怎么设计？