完整题目
在智能Agent调用外部工具（如API）时，可能遇到超时、错误响应、空结果等异常情况。请设计一套完整的容错机制，说明重试策略（如指数退避、最大重试次数）、功能降级方案（如默认返回、局部功能替代），并分析在何种情况下应引入用户澄清流程以提升系统鲁棒性和用户体验。
本文目录
一、异常分层与捕获机制
工具调用异常按来源分三层处理：
| 层级 | 典型异常 | 处理策略 |
|---|---|---|
| 网络层 | 超时、连接断开、DNS失败 | 重试 + 熔断 |
| 应用层 | 4xx/5xx、限流、格式错误 | 降级 + 告警 |
| 业务层 | 空结果、语义不匹配 | 用户澄清或兜底 |
核心原则：每层只处理本层能决策的，向上层暴露必要上下文。
二、重试策略设计
指数退避 + 抖动：
delay = min(base * (2 ** attempt) + random_jitter(), max_delay)
attempt < max_retries # 通常3-5次- 参数示例：base=1s, max_delay=30s, max_retries=3；需按总deadline、依赖延迟与限流协议调整，并预留降级时间。
- 抖动避免惊群效应
- 按语义决定重试：部分瞬时5xx、网络超时，以及4xx中的408/429可在预算内重试；429按Retry-After等服务约定等待。参数错误、授权拒绝和确定性不支持不应原样反复重试，不能按4xx/5xx一刀切。
- 写操作超时不代表未发生：使用同一业务动作的稳定幂等键；缺少幂等保障且结果未知时先查外部状态/对账或人工核对，不能盲目再执行。
熔断器（Circuit Breaker）：连续失败达阈值后快速失败，防止拖垮下游。
三、多级降级方案
按优先级递进：
- 缓存回退：仅在该用户/租户有权访问且业务允许陈旧数据时，返回带过期标记的成功结果；不能用缓存证明当前写操作状态。
- 默认值/静态规则：如地图API失败时返回"建议直接搜索目的地"
- 功能裁剪：关闭该工具，用LLM内部知识替代（需提示用户"以下信息可能非实时"）
- 流程终止：核心工具失败时优雅退出，而非 hallucinate
四、用户澄清触发条件
必须引入人工确认的场景：
- 工具返回低置信度结果（如多个POI相似度接近）
- 降级后信息质量显著下降（实时性/准确性受损）
- 用户query本身意图模糊（"附近好吃的"需确认范围/偏好）
交互设计：澄清请求应携带上下文（"地图服务暂不可用，您指的是A商场还是B餐厅？"），避免重复提问。
五、工程落地要点
- 可观测性：每个工具调用埋点（latency、status、retry_count）
- 配置化：重试参数、降级开关支持动态调整
- 兜底Prompt：明确告知LLM当前处于降级状态，约束其生成行为
学习建议
建议掌握常见网络异常处理方法，理解重试与降级的设计权衡，结合实际场景练习容错流程设计。
参考资料
换一种问法，检查是否真正理解
场景切入
假设你做个天气助手，调第三方API查温度时超时了，或者返回个空结果，你打算怎么处理？用户还在等回复呢。
层层追问
Agent调外部工具出错了，你会怎么兜底？……如果重试了还失败，直接告诉用户“查不到”还是想办法？……那什么情况下你得反过来问用户才能保证体验？
直球架构
设计一套Agent调用外部API的容错机制，包括重试策略比如指数退避、降级方案比如默认返回，以及触发用户澄清的条件，你怎么设计？
练习口述回答 · 约4分钟
- 一句话定位：本质是系统鲁棒性设计
- 重试策略与边界：可重试vs不可重试，指数退避+熔断
- 多级降级：缓存、默认值、功能裁剪、终止
- 用户澄清触发条件：低置信度、降级质量下降、意图模糊
- 落地风险与工程要点：可观测性、配置化、兜底Prompt
这道题其实是在问，当[[Agent]]依赖的外部工具不可靠时，我们怎么保证整个系统还能稳定运行，同时不让用户体验崩掉。我会从重试、降级、用户澄清三个层面来设计，但真正落地时，每个方案都有它适用的边界，不是一股脑全上。
先说重试。我一般会把异常分成网络层和应用层两类。网络超时也可能发生在写操作已经成功之后，先看幂等键和外部状态。部分瞬时5xx、408或429可按预算/服务约定重试，429尊重Retry-After；参数错误、权限拒绝等应修正或重新授权，不能把所有4xx一律当不可重试。重试策略我用指数退避加抖动，可先用base1秒、最大30秒、最多3次作为示例配置，再受总deadline、依赖延迟和Retry-After约束，不是通用最优值。抖动很重要，不然一堆请求同时重试，下游直接雪崩。这里有个坑：重试不是万能的，连续失败次数多了，我会引入熔断器，比如10秒内失败超过5次，直接快速失败，保护下游。
再一个就是降级。降级不是一刀切，我会按优先级递进。第一级是缓存回退，但要确保用户/租户授权、业务允许陈旧数据，并标“可能过期”；不能据此确认退款等当前写操作状态。第二级是默认值或静态规则，比如地图API挂了，我就返回“建议直接搜索目的地”，而不是让LLM瞎编。第三级是功能裁剪，关掉这个工具，用LLM内部知识替代，但得提示用户“以下信息可能非实时”。最后一级是流程终止，核心工具挂了就优雅退出，绝不[[Hallucination]]。举个例子，在客服退款场景里，如果订单查询API超时，我会先试缓存，不行就返回“系统繁忙，请稍后再试”，而不是让模型编一个退款状态。
这里有个前提：降级方案必须在设计阶段就定义好，不能运行时再想。上线后我会特别关注降级频次，如果某个工具频繁触发降级，说明它本身有问题，得修。
然后说用户澄清。不是所有异常都要问用户，那样体验太差。我只有在三种情况下才会触发澄清：一是工具返回低置信度结果，比如搜“附近好吃的”返回多个相似POI，我会问“您指的是A餐厅还是B餐厅？”。二是降级后信息质量明显下降，比如实时天气API挂了，我用历史数据替代，得问用户“当前数据可能不是最新的，您能接受吗？”。三是用户query本身意图模糊，比如“查一下订单”，我会问“您想查订单号还是退款状态？”澄清请求要带上下文，别让用户重复说。
另外，实际落地时，重试和降级不是孤立的，它们需要跟业务场景联动。比如在金融风控场景里，降级策略可能完全不同，因为对实时性和准确性要求极高，降级方案得重新设计。这个边界划分很有意思，值得深入探讨。
最后收一下。我会把容错机制看成系统的“安全带”，平时不显眼，但关键时刻能救命。工程上我会埋好所有调用点的延迟和状态，把重试参数和降级开关做成配置化，方便动态调整。同时给LLM写一个兜底Prompt，明确告诉它当前处于降级状态，约束它别乱编。说白了，。