你的Agent如何处理工具调用失败(如API超时、返回空)？有设计重试、降级或用户澄清机制吗
1️⃣ 考察意图
这道题考察的是Agent工程中的鲁棒性设计，属于系统设计+工程取舍的综合类型。面试官真正想看的是：你能否区分“理论上的优雅方案”和“生产环境中的真实坑”。刁钻点在于：工具调用失败不是单一问题，而是临时性失败（超时/限流）、永久性失败（API下线/参数错误）、语义性失败（返回空但逻辑正确） 的混合体。答好了能展示你对分布式系统容错（Circuit Breaker、指数退避）、LLM行为控制（prompt约束、few-shot示例）以及用户体验（用户澄清 vs 静默降级）的深度理解。
2️⃣ 标准答
我会从重试、降级、用户澄清三个层面展开，并补充一个常被忽略的监控与自愈层。
重试机制：区分失败类型，避免盲目重试
- 临时性失败（如HTTP 503、超时>5s）：采用指数退避，初始间隔1s，每次翻倍，最多3次。使用
tenacity库或自定义RetryHandler，并加入jitter（±0.5s随机抖动）防止惊群效应。 - 永久性失败（如HTTP 400、参数错误）：不重试，直接降级。通过工具返回的
error_code或status字段判断，例如"error_type": "invalid_request"。 - 幂等性检查：重试前必须确认工具是幂等的（如GET请求、idempotency-key）。非幂等操作（如扣款）重试会引发重复扣款，此时应直接降级+用户澄清。
- 实际坑：某次电商Agent调用支付API超时，重试3次后成功，但用户收到4次扣款通知。解法：在重试请求中携带
idempotency_key（如user_id+timestamp+order_id），服务端去重。
降级策略：从“硬失败”到“软失败”
- 备用工具链：主工具失败时，尝试备用工具。例如天气API超时，降级到本地缓存（
cache.get("weather")）或简化回复（“无法获取实时天气，建议查看窗外”）。 - 语义降级：工具返回空（如搜索无结果），不直接报错，而是用LLM推理生成替代方案。例如用户问“附近火锅店”，搜索API返回空，Agent可回复“未找到火锅店，是否改为川菜馆？”——这需要prompt中注入
tool_return_empty的few-shot示例。 - Circuit Breaker模式：监控工具失败率，若连续5次失败（滑动窗口1分钟），熔断该工具10分钟，期间所有请求走降级路径。实现用
pybreaker库，状态机：Closed → Open → Half-Open。 - 实际坑：降级后LLM可能“幻觉”出虚假数据。例如搜索失败，LLM直接编造“海底捞评分4.5”。解法：降级回复必须显式声明不确定性，prompt中写“当工具返回空时，你必须说‘抱歉，我无法获取该信息’，禁止编造”。
用户澄清：何时问、怎么问
- 触发条件：工具返回空且无备用方案；工具返回模糊结果（如多个候选人）；工具返回错误但用户可提供额外信息（如“请提供订单号”）。
- 澄清策略：使用结构化输出，让LLM生成
clarify_request对象，包含question（向用户提问）、options（可选选项）。例如：
{"action": "clarify", "question": "您想查询哪个订单？", "options": ["订单A", "订单B"]}**
- 避免过度澄清：若工具失败是临时性的，先重试再澄清；若用户已提供足够信息，不要重复问。通过上下文窗口判断：如果用户消息中已包含
order_id，工具仍返回空，则直接降级而非澄清。 - 实际坑：用户问“帮我查快递”，Agent反问“哪个快递公司？”，用户回答“顺丰”，Agent又问“快递单号？”，用户崩溃。解法：一次澄清收集所有缺失参数，prompt中写“当需要澄清时，一次性列出所有缺失字段，不要分多次问”。
监控与自愈：生产环境的最后防线
- 日志记录：每个工具调用记录
tool_name、duration_ms、status、error_type、retry_count。用structlog或json格式，方便ELK分析。 - 告警阈值：工具失败率>5%（1小时窗口）触发P0告警；重试次数>3次触发P1告警。
- 自动恢复：熔断后，Half-Open状态允许1个请求通过，若成功则关闭熔断器。这需要健康检查端点（如
/health）快速验证工具可用性。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从重试、降级、用户澄清三个层面回答。重试层面，区分临时性失败（指数退避+幂等性检查）和永久性失败（不重试直接降级）；降级层面，设计备用工具链和语义降级，并用Circuit Breaker防止雪崩；用户澄清层面，用结构化输出一次性收集缺失参数，避免多轮追问。总结一句：鲁棒性不是加try-catch，而是对失败类型做精细化分类，并让LLM在不确定性下保持诚实。”
4️⃣ 高频追问 & 应对
追问 1**：如果工具返回空，但用户坚持认为有数据，你怎么处理？
这是“语义性失败”的典型场景。首先，检查工具返回的
status字段：如果是"success"但data为空，说明查询本身无结果，此时Agent应回复“未找到匹配数据，建议修改查询条件”。如果用户仍坚持，则触发用户澄清：让用户提供更多信息（如“请提供订单号或时间范围”），并记录该case用于后续优化（如调整搜索参数）。注意：禁止LLM编造数据来安抚用户，prompt中必须硬约束“当工具返回空时，只能回复基于事实的结论”。
追问 2：重试时如何避免对下游API造成压力？
核心是指数退避+随机jitter。例如初始间隔1s，每次翻倍（1s→2s→4s），并加入±0.5s的随机抖动。同时，设置最大重试次数（通常3次）和全局并发限制（如每个工具最多10个并发重试）。更激进的做法是使用令牌桶：每个工具分配一个令牌桶（速率1 req/s），重试请求消耗令牌，令牌耗尽则直接降级。此外，Circuit Breaker的熔断机制也能在API压力过大时自动切断重试。
追问 3：降级后用户满意度下降，如何评估降级策略的好坏？
用A/B测试或离线评估。离线评估：收集历史失败case，让LLM生成降级回复，人工评分（1-5分），目标平均分≥3.5。线上评估：监控任务完成率（降级后用户是否完成目标）和用户反馈（如“不满意”按钮点击率）。如果降级后完成率<50%，说明降级策略太弱，需要优化备用工具或增加用户澄清。一个具体指标：降级场景下，用户澄清后的任务完成率应≥70%。
5️⃣ 避坑 · 常见错误答法
- ❌ “所有工具调用失败都重试3次，然后报错。” → ✅ “必须区分失败类型：临时性失败（超时/限流）才重试，永久性失败（参数错误/API下线）直接降级，否则重试会浪费资源并放大错误。”
- ❌ “工具返回空时，让LLM自己编一个合理答案。” → ✅ “工具返回空时，LLM必须显式声明‘无法获取信息’，禁止编造。可以引导用户提供更多信息，但绝不能幻觉数据。”
- ❌ “降级就是返回一个固定错误消息。” → ✅ “降级应提供有意义的替代方案，如备用工具、语义推理或用户澄清。固定错误消息会让用户困惑，降低信任度。”
6️⃣ 简历呼应
- 如果你有RAG项目：从“检索失败”切入，类比工具调用失败。例如“我的RAG系统在检索为空时，会触发LLM推理生成替代查询，类似工具调用的语义降级。我实现了重试+降级后，检索召回率从70%提升到85%。”
- 如果你只做过传统NLP：用“微服务容错”类比。例如“我在传统NLP系统中处理过API超时，使用指数退避重试和Circuit Breaker。Agent的工具调用本质是微服务调用，容错模式可复用。”
- 如果你是校招无项目：聚焦论文复现。例如“我复现了ToolLLM论文中的错误处理机制，用few-shot示例让LLM在工具失败时生成澄清问题。虽然没上线，但我理解了重试、降级、用户澄清的trade-off。”
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs
- Circuit Breaker Pattern (Martin Fowler, 2014)
- tenacity: Python retry library (官方文档)
- “A Survey on Tool Learning with LLMs” (2024, arXiv:2405.17935)
- “When Not to Trust LLMs: Uncertainty Estimation in Tool-Augmented Models” (2024, ACL)