完整题目
在智能Agent调用外部工具（如API）时，可能遇到超时、错误响应、空结果等异常情况。请设计一套完整的容错机制，说明重试策略（如指数退避、最大重试次数）、功能降级方案（如默认返回、局部功能替代），并分析在何种情况下应引入用户澄清流程以提升系统鲁棒性和用户体验。
本文目录
一、异常分层与捕获机制
工具调用异常按来源分三层处理：
| 层级 | 典型异常 | 处理策略 |
|---|---|---|
| 网络层 | 超时、连接断开、DNS失败 | 重试 + 熔断 |
| 应用层 | 4xx/5xx、限流、格式错误 |
页面加载中…
面试题 · Agent
搜索「延迟」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在智能Agent调用外部工具（如API）时，可能遇到超时、错误响应、空结果等异常情况。请设计一套完整的容错机制，说明重试策略（如指数退避、最大重试次数）、功能降级方案（如默认返回、局部功能替代），并分析在何种情况下应引入用户澄清流程以提升系统鲁棒性和用户体验。
工具调用异常按来源分三层处理：
| 层级 | 典型异常 | 处理策略 |
|---|---|---|
| 网络层 | 超时、连接断开、DNS失败 | 重试 + 熔断 |
| 应用层 | 4xx/5xx、限流、格式错误 |
按学习路线查看教程、项目和面试题。
| 降级 + 告警 |
| 业务层 | 空结果、语义不匹配 | 用户澄清或兜底 |
核心原则：每层只处理本层能决策的，向上层暴露必要上下文。
指数退避 + 抖动：
delay = min(base * (2 ** attempt) + random_jitter(), max_delay)
attempt < max_retries # 通常3-5次熔断器（Circuit Breaker）：连续失败达阈值后快速失败，防止拖垮下游。
按优先级递进：
必须引入人工确认的场景：
交互设计：澄清请求应携带上下文（"地图服务暂不可用，您指的是A商场还是B餐厅？"），避免重复提问。
建议掌握常见网络异常处理方法，理解重试与降级的设计权衡，结合实际场景练习容错流程设计。
场景切入
假设你做个天气助手，调第三方API查温度时超时了，或者返回个空结果，你打算怎么处理？用户还在等回复呢。
层层追问
Agent调外部工具出错了，你会怎么兜底？……如果重试了还失败，直接告诉用户“查不到”还是想办法？……那什么情况下你得反过来问用户才能保证体验？
直球架构
设计一套Agent调用外部API的容错机制，包括重试策略比如指数退避、降级方案比如默认返回，以及触发用户澄清的条件，你怎么设计？
这道题其实是在问，当[[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，明确告诉它当前处于降级状态，约束它别乱编。说白了，容错不是事后补洞，而是设计时就留好的退路。