重试可能不安全：LLM 网关该如何处理部分流与副作用调用
Rama_Surasani_ · reddit · 2026-09-18
发帖人指出，LLM 请求失败后盲目重试并不总是安全：供应商停滞时，请求可能已流式输出、消耗 token、甚至完成了有副作用的工具调用。他提出生产环境需要分类处理策略：
- 无任何输出的传输失败：带抖动的有界重试
- 429 响应：遵守 Retry-After，只使用白名单内的降级模型
- 延迟超限：当剩余任务时限无法满足时直接取消
- 部分流：返回显式的不完整状态，绝不拼接两个模型的输出
- 已完成副作用调用：先用幂等键或外部状态核对，再决定是否重试
每次尝试应共享请求/trace ID，并记录供应商、模型、尝试次数、触发原因、已输出 token 数、工具调用状态、降级路由、总延迟与成本。作者还建议在 staging 中注入超时、429 和 503，验证副作用只发生一次、部分输出不被混合、恢复全程策略仍生效。
「编程与Agent」频道最新
- 把 X 推文自动化变成博客+Newsletter,打开率超过 SES — iannuttall · 2026-09-18
- MCP 生态失控式扩张，开发者调侃连 MCP 大会都开起来了 — lucasmeijer · 2026-09-18
- Showly 解决 AI 建站最后一公里:agent 产物一键预览发布成链接 — nikola_mr64990 · 2026-09-18
- jev():Postgres 扩展用自然语言搜全库,129 行仅花 $0.0009 — FrankFelixAI · 2026-09-18
- AI 驱动开发先解团队课题还是先做组织变革？Joe Justice 给出答案 — JoeJustice · 2026-09-18
- GPT-6 Astra 接入 Hyper3D Rodin MCP 直接产出可用 3D 资产 — AIwithGhotai · 2026-09-18