AI应用的静默失败：每个错误都必须留下记录

API超时、速率限制、空回复三类高频问题——失败路径的显式设计是AI应用走向生产的必要门槛

「静默失败」（Silent Failure）是软件工程中公认的反模式——程序遇到错误时不抛出异常、不记录日志，只是默默返回空值或假装成功。这个问题在AI应用中尤为普遍，且后果更难追踪，原因在于LLM的失败模式比传统API更为多样。

三类高频静默失败

一、API超时后未做任何处理

LLM API的响应时间因任务复杂度与模型负载而波动，从数秒到数分钟不等。若代码设定了过短的超时阈值，而任务实际需要更长时间，系统可能在未记录任何信息的情况下丢弃请求。用户界面显示加载状态后直接消失，既无错误提示，也无重试机制，开发者无从得知发生了什么。

二、速率限制（Rate Limit）后静默重试

所有LLM API均设有请求速率上限（RPM/TPM限制）。触及上限时，API返回HTTP 429错误。部分实现在后台无限重试，用户等待时间不断延长，最终看到的仅是通用的「请求失败」提示。若系统从未记录429事件，开发者无法判断速率上限是否需要提升，以及高峰时段费用是否因此翻倍。

三、空回复或格式不符

强制JSON输出时，LLM偶尔返回格式不符合预期的输出，例如在JSON外包裹说明文字，或完全返回空字符串。若代码直接呈现模型输出而不进行校验，用户看到空白界面，开发者面对的是一个完全无法定位的问题：是提示设计问题、模型问题，还是解析逻辑问题？

每次LLM调用应记录的最低字段

失败路径的显式设计

正确的设计原则是：每一个可能的失败分支，都必须有明确的处理逻辑——记录日志、通知用户、启动回退。「什么都不做」在AI应用中永远是错误的选择，因为LLM调用的费用计量以Token为单位，一次静默的超时重试可能在账单上留下痕迹，但在日志中毫无踪迹。

小结

AI应用的失败比传统API更难发现：模型可能返回格式正确但语义错误的输出，超时可能发生在多个层级，费用可能在静默重试中倍增。主动为每一个失败路径设计处理逻辑，使错误可见、可追踪、可告警，是AI应用从原型走向生产的必要门槛。