HTTP 200 不等于结果可用：LLM 应用的错误处理，比你想的多一层

你接口测通了，返回 200，就以为万事大吉。

可 LLM 应用里，200 只代表一件事：模型成功吐出了一段文本。这段文本对不对、能不能用、安不安全，HTTP 协议一个字都不管。

这就是 LLM 应用最容易被忽略的坑：技术成功 ≠ 业务可用。传统靠错误码吃饭的错误处理框架，在 LLM 这里只覆盖了一半战场——剩下那一半，叫"语义失败"。

一、故障全景：10 类错误，一半"没报错但不可用"

把 LLM 应用会出的问题拆开看，共 10 类：

技术失败（6 类，有状态码，程序能判断）：无效输入、网络/连接、超时、限流(429)、服务宕机、鉴权失败。

语义失败（4 类，不报错但不可用）：上下文超限、格式错乱、幻觉编造、工具部分完成。

注意后半句——幻觉、格式错、上下文超限，这些在传统错误码体系里根本不存在。一个客服机器人"自信地"编出一条不存在的退款政策，HTTP 全程都是 200，业务却已经赔了。

最危险的失败，从来不是"报错"，而是 HTTP 200 下返回"看似合理、实则错误"的内容。

二、先分类，再动手：3 类失败对应 3 种动作

处理任何错误的第一步是分类，分类直接决定你该"重试 / 上报 / 校验"：

关键判断：技术失败通常能重试；语义失败重试一万次也还是错的，必须校验、修复或转人工。治理重点要从"会不会报错"转向"结果对不对"。

三、七件套：覆盖全链路的弹性模式

输入校验 + 超时：调用前挡掉空值/格式/越权，省下推理成本；交互式设 20s 超时，离线任务放宽到数分钟。

上下文窗口 + 结构化输出：发前数 token，超限就删旧消息/摘要/拆分；优先拿 JSON 而非纯文本，按 schema 校验后再进下游。

幂等性 + 状态追踪：扣款成功但确认前断网，盲目重试 = 重复扣费。写操作（支付、发消息、建单）必须幂等。

指数退避 + Jitter：限次重试，1/2/4 秒逐级翻倍，每次叠加随机抖动，避免上千请求同时重试引发二次风暴；只对瞬时故障重试。

回退与优雅降级：主模型 → 小模型 → 缓存/预设 → 人工；降级不违背原始需求（法律合同别用缓存顶）。

断路器：失败率超阈即熔断，请求直接走回退，把"调用失败"和"雪崩扩散"隔开，保护健康下游。

限流 / 队列 / 并发：削峰、保护配额，交互请求优先。

四、三条底线（上线前问自己）

降级不违背原始需求：能用小模型/缓存的地方才降级，实时数据、强合规场景不行。

主备必须物理隔离：主备走同一厂商同一通路，outage 会一起挂。

写操作必须幂等：凡涉及支付、发消息、建单，重复执行就是事故。

一句话收尾

LLM 应用的可靠性 = 传统弹性模式 + 针对"概率性输出"新增的语义校验层。你没法让模型变确定，但你可以把"结果对不对"变成系统能判断、能兜底的事。

配套 7 条上线前检查清单与七件套详解，见 PPT《LLM 应用开发指南：错误处理与故障应对》。

企业 AI 落地坊 · 只聊能落地的企业 AI 与工程实践