LLM 请求生命周期是一个状态机 —— 像对待状态机一样对待它

大多数团队将 LLM 请求处理视为一个线性函数：调用 API，检查异常，可能重试一次，然后返回结果。但在实践中，情况完全不是这样。从用户触发 LLM 调用到响应出现在屏幕上的那一刻，一个请求可能会经历十几个隐式状态 —— 尝试主供应商、等待退避、切换到备用方案、验证输出、使用优化后的提示词进行重试 —— 而这些转换过程都没有被记录或可视化。

其结果是，调试变成了在分散于各个服务的日志中进行事后追溯，对于 “这个请求实际上做了什么？” 这一问题，没有一个权威的答案。将 LLM 请求生命周期视为一个显式的有限状态机，是一种架构上的演进，它让你无需进行考古式的工作就能回答这个问题。

为什么隐式状态是生产环境中的隐患

考虑一个典型的生产环境中的 LLM 调用封装。它可能包含：

• 一个带有指数退避（exponential backoff）的重试循环，用于处理瞬时错误
• 当主模型返回 503 或达到速率限制时，回退到备用模型
• 一个验证步骤，检查输出是否符合预期的模式（schema）
• 当验证失败时，重写请求并重新提示的路径

其中每一个都是一种状态。它们之间的每一次转换都是一个事件。但大多数实现将所有这些逻辑编码为单个函数内部嵌套的 if-else 逻辑，并使用捕捉到部分转换却遗漏其他的临时日志记录。

实际的后果体现在三种反复出现的失败模式中：

静默回退（Silent fallbacks）。 主模型失败，系统路由到备用模型，用户得到了响应 —— 但响应的质量略微下降，或者延迟、成本比平时更高。由于没有人显式记录回退转换，这种模式在仪表盘中是不可见的，直到下游有人发现异常。

伪装的重试风暴（Retry storms in disguise）。 当供应商经历性能下降而非硬性错误时，重试可能在第三或第四次尝试时成功，表现为 “慢请求” 而非 “失败”。从外部看系统运行良好。但累积的重试成本在增加，而 P90 延迟在数周内默默爬升。

被误归类为成功的验证失败（Validation failures misclassified as successes）。 API 返回 HTTP 200，但响应未能通过模式验证。封装器重新提示一次，获得了有效的响应并将其返回。调用方看到的是成功。而该请求需要两次 LLM 调用而非一次、耗时两倍、成本也是两倍的事实，却未被记录。

这三种失败的根源相同：中间状态是不可见的。

映射实际状态

一个实用的模型为任何 LLM 请求定义了八种状态：

1. PENDING —— 请求已排队但尚未发出
2. DISPATCHED —— 请求已发送至特定的供应商/模型
3. AWAITING_RESPONSE —— 等待流式输出开始或响应到达
4. VALIDATING —— 响应已到达；正在检查输出
5. RETRYING —— 上一次尝试失败；退避定时器正在运行
6. FALLING_BACK —— 主路径被视为不可用；正在路由到备用方案
7. CIRCUIT_OPEN —— 熔断器已触发；请求直接失败而不尝试联系供应商
8. TERMINAL —— 请求达到最终结果（SUCCESS、VALIDATION_FAILURE、EXHAUSTED 或 DEGRADED）

这些状态之间的转换是事件，而不是日志消息。每次转换都有原因（触发因素）、目标状态（去向）和成本（增加的延迟、消耗的 Token、供应商的变更）。

使这个状态机显式而非隐式的关键在于，将每一次进入和退出状态记录为结构化事件，而不是散落在重试循环中的 log.info 副作用。

区分三类不同的故障

隐式实现变得复杂的另一个原因是，工程师将实际上需要不同处理方式的三种故障类型混为一谈：

瞬时基础设施故障（Transient infrastructure failures） 是短暂且可自我修复的：429 速率限制、短暂的 503 错误、网络超时、负载下的 TLS 握手超时。正确的应对措施是等待并重试同一个供应商。等待时间应从 1 到 2 秒开始，每次尝试翻倍，并包含随机抖动以避免惊群效应。在升级处理之前，合理的上限是 3 到 5 次重试。

加载中…