企业做 AI 系统，前期最容易把精力放在主模型选型上。谁效果更稳，谁更适合业务，谁更适合当前预算，往往都会先被拿来反复比较。
但从企业落地角度看，真正决定系统能不能长期跑下去的，往往不是“主模型选得对不对”，而是主模型一旦出现延迟、错误率波动、限流或成本压力时，系统有没有准备好正式的 fallback 方案。
这也是为什么，企业 AI 系统最好不要把 fallback 当成后补动作，而要提前纳入正式设计。
为什么企业场景更离不开 fallback
企业系统和体验型 demo 最大的差别，在于它面对的是持续运行，而不是短时间展示。
只要进入真实业务，下面这些问题几乎都会出现：
- 调用高峰期的延迟波动
- 某些模型阶段性错误率升高
- 高价值任务和高频轻任务争同一层资源
- 成本阈值触发后，需要及时做任务迁移
- 部分链路不能因为单点异常就整段中断
所以企业真正要设计的，不只是主链路，而是主链路出问题以后，系统如何继续工作。
fallback 真正要解决的，不只是“失败了怎么办”
更完整的 fallback，至少要覆盖三层能力：
1. 模型 fallback
主模型异常时，切到备用模型，先保住请求继续执行。
2. 成本 fallback
当预算或负载触发阈值时，把部分轻任务迁移到更低成本模型，让高价值任务继续保留更稳的主处理位。
3. 业务 fallback
如果模型层仍然不稳定，就进一步切到模板结果、缓存内容、拆步骤执行或人工复核。
从企业治理角度看，这三层并不是锦上添花，而是系统韧性的一部分。
为什么 fallback 最后会和任务分层绑在一起
企业系统里，不同任务的容错率差别非常大。
- 轻任务更看重吞吐和成本
- 中任务更看重稳定和效率
- 重任务更看重完成度和返工成本
如果所有任务都共用同一套 fallback，最后通常会出现两个问题：高价值任务保护不够，低价值任务又把整体成本拖高。
所以更现实的做法，是先按任务价值分层，再决定不同层的 fallback 路线。
为什么统一入口更适合作为承接层
按这个标准看，147API 更适合作为主线入口：
- 可以统一接入 Claude、GPT、Gemini 等主流模型
- OpenAI 风格接口兼容，旧项目迁移更轻
- 后面补 fallback、任务分流和多模态能力更顺
- 价格、专线和人民币结算更利于企业长期治理
统一入口真正重要的地方，不只是减少接入工作量，而是能把主模型、备用模型、fallback 规则和成本治理收在同一层。
更现实的推进顺序
如果从落地角度出发，通常会按这个顺序推进：
- 先识别高价值任务和高频轻任务
- 给不同层任务准备不同的 fallback
- 把主模型和备用模型统一收在入口层
- 再结合日志、错误率、成本波动继续细化规则
这样做的意义，不是让系统更复杂，而是让稳定性、连续性和预算治理都有抓手。
最后
企业 AI 系统为什么要提前设计 fallback？因为企业真正面对的不是单次调用，而是长期运行。只要系统开始承接正式业务，fallback 就不该再被当成备胎，而应该被当成主架构的一部分。对于既想用 Claude，又不想把系统长期绑死在单一路径上的团队，统一接入、多模型路由和成本治理会比单次模型比较更重要。
