01

60 秒回答模板

Agent 工具调用超时后，不能简单报错或无限等待。我会先给每类工具设置超时预算：交互链路里的工具要短超时，后台任务可以异步更长；超时后先判断工具是否可重试、是否幂等、是否有副作用。可重试的读工具可以有限重试加退避，不可盲目重试写工具。降级方案包括使用缓存或上一次结果、返回部分结果、换备用工具、让模型说明当前无法获取实时信息、把任务转异步并通知用户。系统层还要有熔断、隔离、队列和并发限制，避免一个慢工具拖垮整个 Agent。最后要记录 trace、超时类型、降级路径和用户反馈，用于优化工具稳定性和超时阈值。

考点 同步链路总预算
难度 真实面经题
回答目标 设计超时降级和可靠性
02

深入解析

01

超时预算要按链路拆分

Agent 的总响应时间要拆成模型思考、工具调用、结果处理和最终生成几段。不同工具不能使用同一个超时值。用户正在等待的同步工具要更短，离线分析或长任务可以转异步。没有预算拆分，就无法判断是工具慢、模型慢还是调度慢。

02

先判断是否可重试

超时后不能默认重试。只读、幂等、短耗时的工具可以有限重试，并使用指数退避或切换副本；有副作用的工具必须先确认是否已执行成功，避免重复写入、重复通知或重复扣费。重试次数也要受总超时预算约束。

03

降级不等于随便编答案

如果工具拿不到实时数据，Agent 应明确告诉用户哪些信息无法确认，并基于已有上下文给出可用但受限的回答。可选降级包括缓存结果、历史结果、部分字段、备用工具、规则答案、人工接管或引导用户稍后查看。模型不能因为工具失败就编造工具结果。

04

支持部分结果和异步继续

多工具任务中，一个工具超时不一定要终止全链路。如果其他工具已有结果，可以先返回部分结论并标注缺失信息；对长耗时任务，可以创建后台任务，完成后通过通知、消息或会话续接返回结果。这样比让用户一直等更合理。

05

系统保护要防止级联故障

慢工具会占用连接、线程和模型上下文，可能拖垮整个 Agent 服务。工程上要做熔断、限流、并发隔离、队列长度限制和降级开关。对经常超时的工具，调度器可以临时降低权重或不再选择。

06

可观测性决定后续优化

需要记录每次工具调用的开始时间、超时时间、重试次数、错误类型、降级分支和最终用户结果。只有这样才能区分是外部依赖慢、参数导致慢、队列排队慢，还是 timeout 设置不合理。

03

易错点

  • 把超时处理等同于重试，没有判断幂等性和副作用。
  • 工具失败后让模型继续编结果，破坏事实可信度。
  • 所有工具使用同一个 timeout，无法适配交互和后台任务差异。
  • 只考虑单次调用，没有考虑多工具链路中的部分结果和关键依赖。
  • 没有熔断和隔离，慢工具可能拖垮整个服务。
  • 不记录 trace 和降级原因，后续无法定位是工具问题还是预算问题。
04

面试官追问

超时时间应该怎么设置？

从用户可接受时延和链路总预算倒推，再结合工具历史 P95/P99 延迟设置。核心同步工具短预算，后台任务长预算，并保留取消能力。

什么时候可以重试？

读操作、幂等操作、网络瞬断或临时 5xx 可以有限重试；写操作和不可逆副作用必须先确认执行状态，不能盲目重试。

工具失败时模型应该怎么回答？

模型应基于已知信息回答，并明确说明实时工具结果不可用。不能把猜测包装成工具返回事实。

多工具任务里一个工具超时怎么办？

看这个工具是否是关键依赖。非关键工具可以跳过或返回部分结果；关键工具可以降级、转异步或让用户选择继续等待。

如何避免降级路径被滥用？

要给降级设置触发条件、日志和告警，定期统计降级率。如果长期走降级，说明工具稳定性或容量需要修复。