有没有做过工具调用失败后的feedback策略设计
1️⃣ 考察意图
面试官想看你是否真正落地过 Agent 系统，而非只懂理论。考察类型是工程取舍 + 系统设计。刁钻点在于：工具调用失败是 Agent 中最常见的“长尾问题”，但很多候选人只会说“重试三次”这种空话。答好了能展示你对 Agent 鲁棒性、状态管理、以及用户体感的硬实力——尤其是能否在失败时做出有信息量的反馈，而非简单报错。
2️⃣ 标准答
工具调用失败后的 feedback 策略，核心是分类处理 + 状态机驱动。我把它拆成三层：检测层、决策层、反馈层。
检测层：识别失败类型
- 超时：设置全局 timeout（如 10s），超时后直接标记为
timeout。 - 工具返回错误：解析 HTTP 状态码或工具自定义错误码（如
400参数错误、500服务不可用）。 - 无效结果：工具返回了空值或格式不对（如 JSON 解析失败），需用 schema 校验（如 Pydantic）。
- 逻辑错误：工具执行成功但结果不符合预期（如天气 API 返回了昨天的数据），这最难检测，需结合上下文判断。
决策层：基于失败类型选择策略
- 重试（Retry）：对超时或临时性错误（如 503），用指数退避重试，最多 3 次。坑：不要对 400 类错误重试，会浪费 token 且激怒用户。
- 参数修正（Parameter Adjustment）：若工具返回“参数缺失”或“格式错误”，让 LLM 重新生成参数。例如，用户说“查北京天气”，但工具要求城市 ID，LLM 第一次没转成 ID，失败后反馈“需要城市 ID”，LLM 再查一次。trade-off：这增加一次 LLM 调用，但比直接报错更优雅。
- 降级（Fallback）：主工具失败后，切到备用工具。例如，天气 API 挂了，用缓存数据或通用知识回答（如“北京今天大概 20°C”）。实际落地的坑：缓存数据要有时间戳，避免给用户过时信息。
- 告知用户（User Notification）：所有策略都失败后，用自然语言解释原因，而非抛技术错误。例如：“抱歉，天气服务暂时不可用，我查到了昨天的数据，仅供参考。”
反馈层：实现细节
- 状态机：在 Agent 循环中维护一个
tool_call_state，记录每次调用的状态（pending→success/failed）。失败后，状态机自动跳转到对应策略分支。 - 日志与监控：记录失败模式（如哪个工具、什么错误、重试次数），用于离线分析。例如，发现某个 API 在 15:00-16:00 频繁超时，可以动态调整 timeout 或提前降级。
- 用户体感：反馈要有信息量。不要说“工具调用失败”，而是说“我尝试了两次都没能获取到实时数据，已改用缓存数据，数据来自 1 小时前”。这展示 Agent 的“思考过程”，提升信任感。
优化：基于历史失败模式动态调整
- 用强化学习思路：记录每个工具的成功率，当某个工具连续失败 5 次后，自动降低其优先级，优先用备用工具。
- 或者用规则引擎：根据错误码映射到固定策略（如
503→ 重试 3 次 + 降级；400→ 参数修正）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从检测、决策、反馈三个层面回答。检测层，我区分超时、错误码、无效结果等类型；决策层，根据类型选择重试、参数修正、降级或告知用户，并注意对 400 类错误不重试；反馈层，用状态机管理流程，并给用户有信息量的解释。总结一句：好的 feedback 策略不是简单重试，而是让 Agent 在失败时依然能给出合理响应。”
4️⃣ 高频追问 & 应对
追问 1：如果工具调用成功但返回了错误数据（如 API 返回了晴天但实际下雨），你怎么检测？
这是最难的问题。我会用一致性校验：如果 Agent 有多个工具（如天气 API + 地图 API），交叉验证结果。例如，天气说晴天，但地图显示有雨伞图标，则标记为冲突。另一种方法是置信度阈值：让 LLM 对结果打分（如 0-10），低于 5 分则触发重查。实际落地中，这需要大量标注数据，所以更实用的做法是用户确认：直接问用户“我查到的是晴天，您那边实际天气如何？”。
追问 2：重试时怎么避免无限循环和 token 浪费？
设置最大重试次数（如 3 次）和全局 token 预算（如 4096 tokens）。每次重试前检查剩余 token，如果不够一次完整调用，直接降级。另外，用指数退避（1s, 2s, 4s）避免雪崩。还有一个技巧：重试时复用之前的上下文，而不是让 LLM 重新生成，减少 token 消耗。
追问 3：降级策略中，怎么保证缓存数据不过时？
缓存数据要带时间戳和有效期（TTL）。例如，天气数据 TTL 设为 1 小时，股票数据 TTL 设为 5 分钟。反馈时，明确告诉用户数据时效性：“这是 30 分钟前的数据”。如果 TTL 过期，则不能降级，必须告知用户失败。trade-off：TTL 太短会频繁触发失败反馈，太长会误导用户，需根据业务场景调整。
5️⃣ 避坑 · 常见错误答法
- ❌ “工具调用失败就重试三次，不行就报错。” → ✅ 重试要区分错误类型（如 400 不重试），报错要给出有信息量的解释，而非技术错误码。
- ❌ “用 try-catch 捕获所有异常，然后返回‘系统错误’。” → ✅ 异常要分类处理，并给用户具体原因（如“天气服务暂时不可用”），同时记录日志用于后续优化。
- ❌ “降级策略就是返回空数据。” → ✅ 降级要提供替代方案（如缓存数据或通用知识），并明确告知用户数据来源和时效性。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索失败后的反馈”切入，类比工具调用失败。例如，检索不到文档时，是重写 query 还是降级到通用知识，策略类似。
- 如果你只做过传统 NLP：用“对话系统中的错误处理”类比。例如，意图识别失败时，是澄清还是回退到默认回答，核心思路一致。
- 如果你是校招无项目：聚焦论文复现，如 ReAct 或 Toolformer 中的失败处理机制。可以提“我复现了 ReAct 论文，并模拟了 API 失败场景，用状态机实现了重试和降级”。
- 《ReAct: Synergizing Reasoning and Acting in Language Models》—— Agent 循环的经典论文，含失败处理思路
- 《Toolformer: Language Models Can Teach Themselves to Use Tools》—— 工具调用的自监督学习，含失败样本处理
- 《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》—— 推理链中的错误恢复
- LangChain 官方文档：Agent 错误处理与重试机制（含代码示例）
- 《Building LLM Applications: A Guide to Robust Tool Calling》—— 博客，讲实际落地的坑与解法