一、强模型暂停访问，提醒企业别把 AI 当成稳定外包员工
很多企业第一次接触 AI Agent 时，会下意识把它理解成一个“更聪明的员工”：接入资料，给它权限，让它处理客服、文档、代码、运营、报表甚至审批建议。
这种想法在演示阶段很容易成立。模型响应正常，任务边界简单，数据量有限，大家看到的是效率提升。
但一旦进入生产环境，问题会变复杂。模型服务可能限流，某个能力可能临时不可用，安全策略可能把请求打回到较弱模型，供应商也可能调整价格、地区、权限或产品策略。企业如果把整条流程都绑定在一个模型上，就会发现 AI 不是“稳定员工”，而是一个外部依赖。
外部依赖本身不是问题。企业每天都在依赖云服务、短信服务、支付接口、地图接口、ERP、CRM、微信公众号和小程序平台。问题在于，这些传统系统通常会做超时、重试、备用通道和人工兜底，而很多 AI 项目没有。
二、企业 AI 项目最容易漏掉的是“不可用时怎么办”
很多 AI 项目方案里会写模型选择、知识库、提示词、工作流和效果评估，却很少认真写一章：当模型不可用时怎么办。
比如 AI 客服，如果强模型不可用，是直接停止回复，还是切换到低阶模型，还是只返回固定 FAQ，还是提示人工客服接管？
比如合同审查，如果模型输出被安全策略拦截，是换模型继续分析，还是只做风险点摘要，还是把任务转给人工法务？
比如 AI 编程助手，如果长任务执行到一半失败，是保留中间结果，还是从头开始，还是拆成更小任务交给不同模型？
比如企业知识库，如果多模态检索或复杂推理暂时不可用，是退回关键词搜索，还是只展示来源文档，还是让员工手动筛选？
这些问题听起来不如“新模型跑分”有吸引力，但它们决定 AI 能不能放进真实业务。
三、降级不是备用一个便宜模型这么简单
很多人理解的降级，是“主模型挂了就换一个便宜模型”。这只是最粗的一层。
真正可用的降级方案，至少要分四层。
第一层是能力降级。强模型可以做长文档推理、复杂代码迁移、多轮业务判断；普通模型可能只能做摘要、分类、改写和信息提取。业务流程要清楚哪些任务能降级，哪些任务不能降级。
第二层是动作降级。模型正常时可以给出操作建议；风险较高时只能生成草稿；再降一级时只展示候选资料，不再生成结论。尤其是涉及付款、合同、客户承诺、权限变更和生产系统操作的场景，不能因为换了模型还继续自动执行。
第三层是渠道降级。AI 客服不能用时，可以转人工；内部助手不能用时，可以回到知识库搜索；代码助手不能完成修改时，可以只生成分析报告；自动化流程失败时，要能回到人工审批和原系统操作。
第四层是数据降级。有些模型或平台不适合接触敏感数据。切换备用模型时，企业必须确认数据能不能发过去、是否需要脱敏、是否只能在私有环境运行。
所以降级不是技术人员临时改一个模型名，而是业务流程本身要支持“不同能力、不同权限、不同风险等级”的运行方式。
四、备选方案应该在项目开始时设计，而不是出事后补
企业做 AI 项目时，应该在第一版方案里就写清楚备选路径。
先定义任务等级。哪些任务只是辅助员工，比如摘要、分类、检索、草稿生成；哪些任务会影响客户、合同、财务、生产环境和权限；哪些任务一旦出错会造成明显损失。任务等级不同，允许使用的模型、权限和自动化程度就不同。
再定义模型路由。不是所有任务都要用最强模型。简单问题可以用低成本模型，复杂判断再升级到强模型；强模型不可用时，只允许回退到低风险动作，而不是让备用模型继续做高风险决策。
再定义人工接管。AI 失败时不能只报错。系统应该告诉员工失败原因、已完成哪些步骤、哪些资料已经检索、当前建议是什么、接下来需要人工确认什么。
最后定义日志和复盘。每次降级、失败、人工接管和模型切换都应该留下记录。否则企业很难判断问题出在模型、数据、提示词、权限还是业务流程。
五、中小企业第一版 AI 落地，不要做成单点依赖
对中小企业来说，最现实的策略不是一上来做一个无所不能的 AI Agent，而是做一个边界清楚、可以失败、可以人工接管的小闭环。
比如先做售后知识库助手。AI 负责检索资料、生成回复草稿、标注来源和提示风险，最终由客服发送。这样即使强模型暂时不可用，也可以退回关键词搜索和人工回复，不会影响整个客户服务链路。
再比如先做研发辅助。AI 负责阅读代码、提出方案、补充测试和整理文档，但不直接合并代码、不直接发布生产环境。模型不可用时，开发团队仍然可以基于已有分析继续推进。
再比如先做内部流程问答。AI 只负责解释制度、指向资料、提醒审批路径，不自动替员工发起付款、改价或对外承诺。这样即使回答能力降级，风险也被限制在可控范围内。
企业真正要追求的不是“AI 永远不出错”，而是“AI 出问题时，业务还能继续，风险不会扩散”。
六、华茂思简判断
新闻来源
- Anthropic: Claude Fable 5 and Claude Mythos 5
