传统后端服务里，错误通常有清晰信号：连接超时、HTTP 500、字段校验失败或数据库事务回滚。大模型应用增加了一类更麻烦的状态——调用在技术上完全成功，模型也输出了合法文本甚至合法 JSON，但内容不可用、事实错误、遗漏约束，或者生成了会让后续工具执行危险动作的参数。
因此，大模型应用的稳定性不能只看 API 可用率。一个接口可能达到 99.99% 的请求成功率，业务任务完成率却明显更低。要把原型变成可运营系统，团队必须同时建设两套防线：一套处理网络、容量和供应商故障，另一套处理语义、策略和工具执行故障。
先定义“成功”
最常见的设计错误，是把收到模型响应视为任务完成。更可靠的系统至少区分四层成功：传输成功，表示请求和响应完整到达；协议成功，表示状态码、流式传输和结构化格式符合要求；语义成功，表示内容满足业务规则；事务成功，表示工具产生的外部副作用与系统记录一致。
例如，一个报销智能体调用模型生成付款参数。HTTP 200 只说明模型服务响应了；JSON Schema 通过只说明字段类型正确；金额、收款人和审批链一致才属于语义成功；银行扣款成功且内部账单状态同步，才算事务成功。任何一层失败，都需要不同处理策略。
这套分层应落到可观测指标上。除了延迟、状态码和 token 消耗，还要记录结构化输出通过率、业务规则拦截率、工具调用成功率、人工接管率、重试后恢复率和端到端任务完成率。只有如此，团队才能发现“服务没有报错，但用户一直得不到正确结果”的灰色故障。
失败分类决定恢复动作
瞬时故障包括连接中断、部分 5xx、临时容量不足和限流。它们可以重试，但应使用指数退避和随机抖动，设置最大次数与总时间预算。所有实例在同一时刻固定间隔重试，会形成惊群效应，让正在恢复的上游再次被压垮。
永久故障包括凭据失效、无权限、请求格式错误和不受支持的模型参数。重试不会改变结果，只会增加延迟和费用。系统应快速失败、记录原因并通知责任人。对用户则需要给出可行动的信息，例如重新授权、修正输入或联系管理员。
语义故障包括格式合法但内容不满足要求、引用不存在、答案与可信数据冲突、遗漏必要步骤或触发安全策略。它们不能简单套用网络重试。相同提示重新调用同一模型可能得到不同答案，也可能反复犯同一类错误。恢复方式应根据风险选择：自动修复、二次校验、检索权威数据、换模型复核或转人工。
工具故障还要区分“确定失败”和“结果未知”。如果支付接口明确返回余额不足，可以安全结束；如果请求已发送、连接在响应前断开，支付可能已经完成。盲目重试会重复扣款。所有产生副作用的操作都应使用幂等键，让同一个逻辑动作的多次请求返回同一结果，而不是重复执行。
重试也有预算
大模型调用成本高、延迟长，重试策略必须有边界。可以为一次用户请求设置总预算，再为规划、检索、生成和工具调用分配子预算。某一步耗尽预算时，系统应选择降级或结束，不能让后续步骤无限等待。
重试条件也应足够具体。429 可以参考服务端的 Retry-After；部分 5xx 和网络超时可以有限重试；400、401、403 通常不应重试。语义校验失败若允许重试，应把校验错误反馈给模型，改变提示或上下文，而不是原样重复。
还要避免重试放大。客户端、API 网关、智能体框架和底层 SDK 如果各自重试三次，一次失败可能变成 81 次调用。团队应明确唯一的重试责任层，其余层关闭自动重试或只做一次安全重连，并把全链路尝试次数写入追踪信息。
降级链要保持能力边界
常见降级路径是主模型失败后切换备用模型，再使用缓存结果，最后转人工。它看起来简单，实际需要回答三个问题。
第一，备用模型是否具备同等能力。上下文长度、工具调用格式、结构化输出和安全策略可能不同，直接替换会造成隐性语义退化。系统应为每个模型维护能力画像，并按任务要求路由，而不是把所有模型视为同一接口。
第二，备用路径是否真的独立。如果主模型和备用模型共享云区域、网关、身份服务或向量数据库，供应商切换并不能解决公共依赖故障。韧性设计需要绘制依赖图，识别共同故障域。
第三，降级结果是否可以被业务接受。客服回复可以缩短，风险审核不能降低阈值；推荐系统可以返回热门内容，付款审批不能绕过规则。降级必须保持安全和合规边界，宁可停止高风险任务，也不能为了“可用”而输出未经验证的决定。
断路器、限流与隔舱
当上游持续故障时，继续发送请求会占满连接池和工作线程。断路器在失败率超过阈值后进入打开状态，让后续请求快速失败；等待恢复窗口后进入半开状态，只放少量探测请求；探测成功再恢复正常流量。它保护的不只是供应商，也保护本系统不被慢调用拖垮。
限流和并发控制解决容量问题。大模型服务常同时受每分钟请求数、token 数和并发数限制，应用应在入口估算成本，通过队列平滑突发流量。不同业务应分配独立配额，避免低优先级批处理耗尽交互请求资源。
隔舱模式进一步切断故障传播。摘要、客服、代码生成和关键审批可以使用独立队列、连接池和预算。某类长文本任务堆积时，不应拖垮所有智能体。多租户平台还要按客户隔离配额，防止单个租户的异常循环消耗共享资源。
缓存不是简单保存答案
缓存可以在模型不可用时提供降级结果，也能降低费用和延迟，但大模型请求很难用传统 URL 键直接命中。提示词中的时间、用户权限、知识库版本和模型参数都会影响结果。若缓存键忽略这些因素，系统可能把旧政策答案返回给新问题，或把一个用户有权看到的内容泄露给另一个用户。
因此，缓存条目需要携带生成时使用的模型版本、提示模板版本、数据快照、权限范围和有效期。涉及实时库存、价格、医疗或政策信息的答案应设置很短期限，甚至只缓存检索材料而不缓存最终结论。语义缓存虽然能把相似问题映射到同一结果，但阈值过宽会把关键差异抹平，必须按业务类型评估。
在故障降级时，界面还应明确告诉用户结果来自缓存以及生成时间。隐藏陈旧性会把可用性问题变成信任问题。对高风险业务，缓存只能作为参考资料，不能替代新的验证和审批。
可观测性要贯穿一次任务
一次智能体任务可能跨越多个模型调用、检索查询和工具执行。只看单个 API 日志，无法回答用户为什么失败。系统需要为整个任务分配统一追踪标识，把每一步的输入摘要、模型与提示版本、延迟、token、重试原因、校验结果和工具状态串联起来。
日志又不能无限记录原始提示与回答，其中可能包含个人信息、商业秘密和凭据。工程上应采用字段级脱敏、分级保留和访问审计：运行指标长期保存，敏感正文缩短保留期限，高风险调试数据必须经过授权。用于复盘的样本也应去标识化，并记录谁在什么目的下访问。
告警应围绕用户结果设计。供应商 5xx 上升当然需要报警，但结构校验失败率、人工接管率、平均任务步骤数和单任务费用突然变化，往往更早暴露模型或提示回归。尤其要监控智能体循环：如果模型在同一工具上不断尝试，系统应在达到步数或费用阈值时主动终止，而不是等账户配额耗尽。
上线前的一份最小检查表
一个可进入生产的大模型流程，至少应回答这些问题：每种错误由哪一层负责重试；写操作是否有幂等键；是否存在任务级超时和费用上限；主模型不可用时允许降级到哪里；输出由哪些确定性规则校验；高风险动作由谁确认；日志如何脱敏；模型、提示和知识库变化如何回滚；供应商完全中断时，用户能看到什么。
如果团队无法清楚回答其中任何一项，说明系统仍处在演示阶段。韧性工程的目标并不是消灭失败，而是让失败范围有限、状态可知、恢复有序，并且不会因为一次模糊响应造成不可逆后果。
语义正确性需要多层验证
结构化输出是第一层。通过 JSON Schema、枚举、范围和必填字段，可以拦截格式与类型问题，但无法证明事实正确。第二层是确定性业务规则，例如金额上限、库存非负、设备参数范围和审批权限。能用代码判断的约束，不应只写进提示词。
第三层是数据依据。需要事实回答时，系统应从可追溯来源检索，并验证答案中的实体、日期和数值是否能被证据支持。引用链接存在不等于引用有效，最好将关键声明拆分后逐项核对。
第四层是风险分级。低风险内容可以自动发布，高风险决策应要求人工确认。人工不是万能兜底：审查界面需要突出模型依据、规则告警和变更差异，避免审核者在大量流畅文本中机械点击通过。
基于另一个模型的“LLM-as-a-judge”可以提高筛查覆盖率，但不应成为唯一判据。评审模型也会受提示、位置偏差和共同知识盲点影响。更稳妥的组合是确定性规则、可信数据校验、抽样人工评估和离线基准测试。
智能体最需要事务意识
当模型只生成文本，错误通常停留在屏幕上；当它能发邮件、建工单、修改数据库和控制设备，错误会进入现实系统。智能体执行层应采用“计划—校验—授权—执行—确认”的状态机，并为每一步持久化状态。
写操作应先生成明确的动作预览，经过权限与策略检查后再执行。外部系统返回成功时记录结果标识；返回未知时先查询状态，再决定是否重试。多步骤任务可以借鉴 Saga 模式，为已完成步骤设计补偿动作，但要承认并非所有副作用都可逆——邮件发出后无法真正撤回，设备动作也可能造成物理后果。
因此，执行权限应遵循最小授权。只读检索与写入操作分离，高风险工具需要短期令牌、参数白名单和人工确认。模型不应直接持有长期凭据，也不应自行决定绕过确认步骤。
从故障演练走向工程成熟
韧性无法只靠架构图验证。团队应主动注入超时、429、半截流式响应、错误 JSON、工具响应丢失、检索空结果和模型幻觉，观察系统是否按预期重试、降级和告警。每次上线新模型、修改提示或更换工具接口，都要重复关键场景。
生产复盘也不能只统计供应商事故。一次模型给出错误答案却未被发现，同样应作为事故分析：哪一层验证缺失，为什么监控没有捕捉，是否需要新增规则或评测样本。随着这些样本沉淀，系统会逐步形成自己的故障知识库。
大模型应用的可靠性不来自“选择一个更聪明的模型”，而来自把不确定组件放进确定的工程护栏。重试、断路器和降级解决可用性，Schema 与业务规则解决可验证性，幂等与状态机解决副作用一致性，权限和人工确认控制风险。只有这些机制共同存在，API 的一次成功响应才有机会变成业务上的可靠完成。
参考资料