企业刚开始使用大模型时，它通常只是一个辅助工具。模型暂时无法访问，员工还可以回到原来的工作方式。
但随着大模型逐渐进入客服、知识查询、文档审核、销售支持和内部流程，一旦服务中断，影响就不再只是"少了一个聊天窗口"，而可能是整个任务无法继续。
大模型应用也会遇到各种异常：模型接口超时、调用额度不足、网络中断、知识库检索失败、业务系统无法连接，或者返回结果不符合预期格式。即使模型服务本身正常，任何一个依赖环节出现问题，最终功能都可能不可用。
因此，企业在设计大模型应用时，不能只考虑"正常情况下能做什么"，还要回答一个更现实的问题：当它不能工作时，业务怎么办？
首先需要区分，大模型在流程中扮演的是辅助角色，还是关键角色。
如果它只是帮助员工润色邮件，短时间不可用的影响有限，可以提示用户稍后重试。但如果它负责识别客户请求、生成订单信息或分配工单，故障可能直接阻塞业务。
不同场景需要不同的恢复目标。企业不必为所有功能建设同样复杂的备用方案，而应优先保护那些影响客户、收入、交付和合规的流程。
第二步，是列出可能的失败方式。
不少系统只判断模型接口有没有返回成功状态，却没有检查答案是否真正可用。接口可能正常返回空内容，也可能缺少必填字段、引用了无效资料，或者在工具调用过程中停在中间状态。
因此，系统需要区分模型超时、内容生成失败、格式验证失败、知识检索失败、工具调用失败和权限不足等情况。不同问题的处理方式并不相同，不能全部依靠重复调用解决。
对于短暂的网络波动，可以进行有限次数的自动重试。但重试必须设置间隔和上限。如果外部服务持续异常，大量请求不断重试，反而会增加系统压力和费用。
涉及创建订单、发送消息和修改数据的操作，还要特别防止重复执行。第一次请求可能已经成功，只是结果没有及时返回。如果系统直接重试，就可能创建两张订单或向客户发送两次通知。
这类操作应当使用唯一任务编号，并在执行前检查是否已经完成。大模型可以决定调用什么工具，但最终系统必须保证同一项业务动作不会因为重试而重复发生。
备用模型是常见的降级方式，但不能简单替换。
不同模型对提示词、结构化输出和工具调用的处理可能不同。主模型失败后，如果直接切换到另一个未经测试的模型，系统虽然恢复响应，结果质量却可能无法满足要求。
企业应提前验证备用模型能够处理哪些任务，并为它设置清楚的使用范围。复杂分析可以暂停，简单分类和信息提取则继续运行。降级的目标不是保持全部能力，而是保住最重要的业务功能。
缓存也可以用于部分场景。
产品说明、常见制度和公开问答如果变化不频繁，可以保存经过确认的历史结果。当模型暂时不可用时，系统优先展示已有答案，并明确标注内容的更新时间。
但订单状态、库存数量和审批进度等实时信息不适合直接使用旧缓存。错误的实时数据可能比没有答案造成更大影响。缓存必须根据内容类型设置有效期，不能把"曾经正确"当成"现在仍然正确"。
另一种降级方式，是从智能处理退回到规则和模板。
例如，大模型无法生成完整客户回复时，可以提供经过审核的基础模板；自动工单分类失败时，可以进入人工待处理队列；合同分析不可用时，系统仍然允许员工查看原文和基础信息。
这种设计看起来没有大模型那么智能，却能保证业务继续运转。真正可靠的系统，不应该因为一个增强能力失效，就让所有基础功能一起消失。
人工兜底也需要提前设计。
很多项目在方案中写着"异常时转人工"，却没有明确转给谁、通过什么渠道、携带哪些信息。如果故障发生后，员工还要重新收集资料并重复描述问题，人工兜底就会变得低效。
转人工时应保留用户问题、已经获得的资料、模型执行到哪一步、失败原因和已完成的操作。这样人工人员可以接着处理，而不是从头开始。
用户界面的提示同样重要。
系统不能长时间显示"正在思考"，让用户不知道是否应该等待。出现异常时，应清楚说明当前哪些功能不可用、是否已经保存任务、用户可以稍后重试还是需要转人工。
对于模型生成但未经过完整验证的结果，也应明确标识，不能让用户误认为任务已经成功完成。
监控需要覆盖整条链路，而不只是模型接口。
企业应关注响应时间、超时率、格式验证失败率、知识检索结果、工具调用成功率和转人工数量。接口返回成功但业务任务没有完成，同样属于故障。
当备用模型被启用、错误率持续升高或人工队列快速增长时，系统应及时通知负责人。否则，降级方案可能悄悄运行很长时间，业务质量已经下降，团队却没有察觉。
降级方案还需要定期演练。可以主动关闭某个测试环境中的模型连接，检查备用模型能否启用、任务是否进入人工队列、重复操作是否被阻止，以及恢复后未完成任务如何继续。
没有经过演练的备用方案，只是一种设想。
大模型正在成为企业流程中的重要组成部分，但它不应该成为业务唯一能够通过的道路。能力越强、使用越深，越需要为异常准备清楚的退路。
一个成熟的大模型应用，不仅要在模型可用时提高效率，也要在模型不可用时保持业务连续。真正的可靠性，不是永远不发生故障，而是故障发生后，系统仍然知道下一步该怎么做。