ByteByteGo最新指南指出，LLM应用与传统软件不同，需同时处理技术故障和语义故障（如幻觉、错误JSON），并通过重试、超时、熔断、幂等等技术增强弹性。
AI解读：LLM应用的输出是概率性的，同一个提示词每次可能给出不同答案，因此即使API调用成功，返回的内容也可能完全不可用——比如模型忽略了指令、返回了纯文本而非JSON、甚至幻觉出根本不存在的政策或产品。这就意味着传统软件只处理技术故障（如网络错误、超时），而LLM应用还必须处理语义故障，即技术上成功但逻辑错误的结果。ByteByteGo这篇指南的价值在于，它给出了一个清晰的分类框架：瞬时错误（如网络抖动、限流 429）可以重试，永久错误（如凭据无效 401/403）重试没用，语义错误则需要额外校验或人工介入。对开发者而言，真正的行动点在于：不要盲目重试，要用指数退避加抖动；对模型输出做schema校验；区分主备模型时确保它们不依赖同一家供应商；对会执行支付等操作的agent工具调用，务必实现幂等性，否则一次成功的支付可能因网络中断被重复扣款。指南没有提供具体的代码或性能数据，但它列出了工程上必须考虑的全部失败场景，相当于一张检查清单。普通用户不需要立刻做什么，但如果你是正在构建LLM应用的工程师，这篇文章值得逐条对照排查。
ByteByteGo发布了一份关于LLM应用错误处理与弹性设计的指南，核心论点是：LLM应用除了要处理网络中断、超时等技术故障，还必须处理模型幻觉、错误JSON等语义故障——这些故障即使API调用显示成功，结果仍可能不可用。指南从请求流程中的每个边界出发，给出了重试、超时、熔断、幂等等具体做法。
故障分类：瞬时、永久与语义错误
指南将LLM应用中的故障分为三大类：瞬时错误是暂时的，重试通常能解决，例如网络问题、限流（HTTP 429）和服务器故障（部分 5xx）；永久错误会持续存在，直到请求或系统发生变化，例如无效凭据（401/403）、不支持的文件类型、权限问题和格式错误的请求；语义错误指响应技术上正确但不符合应用需求，例如无效JSON、不支持的参数、幻觉等。
分类后处理方式不同：瞬时错误应短延迟重试或使用备用路径；永久错误应记录并通知相关方纠正；语义错误则需校验、修复或请求人工审查。指南也指出，并非所有错误都能干净归入一类，比如上下文长度超限对当前提示词是永久的，但缩短提示后即可解决。
- 瞬时错误示例：网络波动、DNS解析失败、限流（429）。
- 永久错误示例：API密钥失效（401/403）、提交了超大文件或非法日期。
- 语义错误示例：模型忽略指令部分、返回纯文本而非JSON、幻觉出不存在的信息、达到token上限导致响应不完整、拒绝无害请求、调用工具传错参数、违反业务规则。
重试、超时与熔断的正确使用
重试是最简单的弹性手段，但必须防止无限重试，否则会增加成本并加重服务负担。指南建议限制重试次数，采用指数退避（例如第一次等待 1 秒、第二次 2 秒、第三次 4 秒），并加入随机抖动，避免数千个失败请求同时重试造成流量尖峰。重试仅适用于超时、暂时性网络故障、429 和部分 5xx；对无效凭据、非法输入等每次都会得到相同结果的错误不应重试。
超时设定取决于用户体感：交互式聊天应用可能只等 20 秒，而离线文档分析任务可等几分钟；用户等待的屏幕任务应设更短期限，后台隔夜任务可放宽。熔断器适用于供应商持续不可用的场景，它有三种状态：关闭状态正常发送请求，打开状态立即拒绝或重定向请求，半开状态允许少量测试请求判断服务是否恢复；成功则关闭电路，失败则回到打开状态。这样可防止重复失败影响应用其余部分。
- 指数退避示例：1 秒 → 2 秒 → 4 秒，每两次失败后加倍。
- 抖动：在每次延迟中加入随机时间，避免同步重试造成流量洪峰。
- 熔断器三态：关闭（正常流量）、打开（拒绝请求）、半开（试探性放行少量请求）。
回退路径与降级策略的选择
指南描绘了典型的级联回退方案：优先使用主模型（通常质量更高），不可用时切换到较小的备用模型，再不可用则返回预定义响应或缓存信息，最后若无法安全处理，可转人工。但回退不能违背原始需求——小模型可能适合总结内部会议，却不适合解读复杂法律文件；缓存响应适合通用FAQ，但不适合查询当前账户余额。
需要特别注意的是避免单点故障：如果主模型和备用模型都访问同一家供应商，一次故障会让两者同时失效，真正的冗余需要两条路径之间有隔离。
- 回退链示例：主模型 → 备用小模型 → 缓存或预定义响应 → 人工接管。
- 限制：小模型不适用于高复杂度任务（如法律文件解读）。
- 冗余要求：主与备用路径不应依赖同一供应商。
业务规则、幂等性与上下文管理
LLM作为agent执行工具调用（如支付、发消息）时，存在一个特殊风险：动作可能成功，但周围工作流失败。例如支付成功但网络中断，应用没收到确认，若盲目重试会导致重复扣款。指南因此强调工具系统必须实现幂等性、状态追踪和恢复机制。
在处理用户输入前，应用应先做基础校验——空消息、非法文件格式、超大文档、无效日期都应提前拒绝，无需调用LLM判断。这能节省时间和处理成本，并给出更清晰的错误消息。对于上下文窗口限制，弹性设计应发送前预先计算token数，通过删除旧消息、总结早期内容、减少检索文档或拆分大任务来控制。
对于模型输出格式，指南建议在模型提供商支持时使用结构化输出功能，并在使用前按schema校验响应。幻觉类的语义失败无法靠异常捕获发现，需要额外的检查、可信数据源或人工介入。
- 幂等性示例：支付服务调用必须先记录状态，重试不改变已成功的事务。
- 上下文限制处理：发送前计数，裁剪历史，或拆分任务。
- LLM幻觉案例：客服机器人虚构退款政策、研究工具生成不存在的来源。
限流、并发控制与队列的作用
指南指出，LLM应用不能无限制地接受来自UI的请求。例如 1 万请求同时到达，如果全部立即转发给模型供应商，可能耗尽供应商配额、数据库连接、内存或预算。使用速率限制可控制单个用户或客户端的请求频率，并发控制可限制应用同时处理的请求数，队列则存储多余的请求，避免系统过载。指南还提到获取限流响应（429）并不意味着服务损坏，而是应用请求超过了供应商当前能处理的容量；此时可延迟请求、降低并发、入队或切换到有可用容量的另一个模型。
- 速率限制：控制用户提交请求的频率。
- 并发控制：限制应用同时处理的请求数。
- 队列：缓冲过量的请求，防止系统过载。
- 429 处理：延迟、降并发、入队或切换模型。