标准答案
- 超时应设置分层 deadline，并把取消信号传到下游；可重试的请求使用有限次数、指数退避和抖动。已经产生副作用的工具调用不能按普通生成请求盲目重试。
- 限流要识别供应商、租户、用户和模型四种配额，读取 Retry-After 或错误元数据，排队或降级，而不是多个实例同时快速重试。
- 上下文过长应在调用前估算并按优先级裁剪历史、检索片段和工具结果；内容拒答则应保留安全边界，向用户解释可提供的安全替代帮助，不能通过改写成更隐蔽的请求绕过策略。
题目解析
超时不是单一数字。浏览器、API 网关、应用服务、队列消费者、供应商连接和模型推理都可能有 deadline。外层超时小于内层时会留下下游继续执行的问题，因此要设计取消传播和孤儿任务清理。
重试只适合瞬时、无副作用、可证明幂等的失败。429、部分 5xx 和连接重置可能可重试；参数错误、认证失败、上下文超长和明确拒答通常不应重试。
上下文超长要保留可观测信息，例如裁剪前后 Token、被删除的消息类别和最终模型。否则用户只看到“模型失败”，开发者无法知道是历史增长还是检索爆炸。
拒答不是服务异常。产品可以提供缩小范围、去除敏感信息、使用合规知识库或转人工的路径，但不能把安全拒答统一显示成网络错误。
常见误区
- 所有错误都重试三次。这样会放大限流、重复副作用和成本问题。
- 把上下文超长归因于模型不稳定。应先统计输入各组成部分的 Token 占用。
- 为了提高成功率而不断改写拒答请求。安全边界应保持不变，正确做法是提供合规替代任务。