这份文档来自某车企数字化中心的内部立项材料去掉了车型代号和供应商名称后可以公开。它不是一篇方案介绍而是一份需求书的节选先说清楚业务要什么再说非功能指标卡在哪里最后才谈选型。看需求书往往比看架构图更能理解一个中间层为什么必须存在。一、需求背景集团内目前有三条独立在跑的 AI 业务线座舱语音助手车内自然语言交互用户问路况、订餐、控制空调。峰值集中在早晚通勤两小时。售后诊断助手4S 店技师输入故障现象系统结合维修手册给出排查路径。用户之声分析把 App 评论、客服工单、社交平台反馈做归因分类供产品线复盘。三条线由三个团队各自建设各自申请模型账号、各自写重试逻辑、各自记账。集团层面拿不到一张统一的 AI 用量表安全团队也无法确认车主数据在调用链路里的流向。二、功能需求拆解编号需求项说明F-01统一入口三条业务线通过同一套接口协议访问所有模型不再各自对接F-02按任务分级路由座舱短问答走轻量模型售后长推理走强模型F-03故障自动转移单一模型不可用时自动切换业务侧无感F-04车主信息脱敏车架号、手机号、定位在出网前必须替换F-05用量归集按事业部、车型项目、场景三个维度拆分账单F-06全链路留痕每次调用可回溯请求方、模型、耗时、成本三、非功能指标座舱语音首字响应 P95 不超过 900 毫秒售后诊断整体可用性不低于 99.9%车主个人信息不得以明文形式离开企业内网单次故障切换耗时不超过 2 秒且不重复计费全部组件支持本地化部署不依赖公网管控面。其中第三条和第五条是硬红线任何不满足的方案直接出局。四、选型结论经过对比我们选择引入魔芋企业AI网关MAI Gateway作为集团 AI 流量的统一枢纽其能力定位与需求书的六条功能项高度对齐统一接入·智能路由·精准分账·安全脱敏·成本优化。关于 F-01 统一接入。网关侧已完成对多路模型来源的收敛既包括魔芋 AI 自有 MaaS 平台也包括企业自建的开源模型、第三方 API 服务同时已兼容阿里 tokenPlan 与火山 AgentPlan 模型的接入。这一点对我们尤其关键——集团采购部此前已分别与阿里、火山签订了资源包如果网关不支持这两类计划的接入等于让既有采购额度作废。现在这两条来源可以和其他模型池并列纳管统一走同一套路由策略。关于 F-02 与 F-03 路由与转移。座舱语音的短问答交由 Gemini 3 Flash 与 GPT-5-mini 组成的低延迟池处理命中率高的问题走本地缓存直接返回售后诊断这类需要多步推理、结合长篇维修手册的任务交给 Claude 4 Sonnet 处理涉及复杂整车电气故障时升级到 Claude Opus 4.7用户之声的批量归因分析对时延不敏感但量大交由 DeepSeek V4 承担。任一模型返回超时或限流网关按预设优先级切到备选池业务侧只感知到一次略长的响应。关于 F-04 脱敏。车架号、车主手机号、精确定位在请求出网前由网关侧统一替换为占位符模型返回后再做还原映射。业务代码不需要各自实现一遍脱敏逻辑也就不会出现某个团队漏做的情况。关于 F-05 与 F-06 分账与留痕。网关按事业部、车型项目、业务场景三级标签归集 Token 消耗财务部门可以直接拿到分摊依据每次调用的请求方、命中模型、耗时、成本写入统一日志安全审计和成本复盘用的是同一份数据。五、上线后的观察试运行两个月三项变化比较明显座舱语音在早高峰的超时率从原来偶发的百分之几降到接近零主要得益于故障自动转移而非模型本身变快售后诊断的月度成本下降约三成来源是把大量简单查询从强模型上摘了下来集团第一次拿到了一张完整的 AI 用量表——这件事的价值不在省钱在于预算讨论终于有了依据。需求书里最不起眼的 F-05最终成了推动力最强的一条。声明本文所述产品功能、特性与案例数据以魔芋企业AI网关MAI Gateway官方最新文档为准文中示意性数据不构成采购或投资建议。企业AI网关属企业AI基础设施合规品类部署与上线请结合所在行业等保、数据安全法等合规要求。
