这是某中型游戏工作室内部 AI 中台的版本演进记录按里程碑整理。它记录的不是功能列表而是一个团队怎么从能跑就行一步步走到必须有个网关。v0.1 —— 一个策划的下班后实验背景文案策划想让 NPC 对话不那么模板化自己申请了个模型 API写了段脚本批量生成候选台词导进配置表里。当时的实现一个 Python 脚本密钥写在源码里跑完就删。遗留问题没人知道这件事也没人管。v0.3 —— 三个方向同时开花背景效果不错消息传开了。三个方向同时启动NPC 动态对话——玩家自由输入NPC 实时回应本地化——把中文文本批量译成英、日、韩、西、葡五个语种玩家客服——处理充值、卡关、封号申诉类咨询。当时的实现三个方向各写各的调用层。NPC 组用的是低延迟模型本地化组按批量任务接了另一路客服组图省事直接复用了策划那个脚本改的。暴露的问题密钥有四份其中一份还留在某个已离职外包的仓库分支里本地化跑到一半遇到限流脚本没写退避整批任务失败重跑白烧一笔客服侧偶尔返回过长的回复前端排版直接错乱没有统一的输出约束。v0.5 —— 第一次尝试自建中间层背景主程决定收口自己写了一个转发服务把四个调用点接进去。实现的功能统一密钥管理、简单的失败重试、按调用方打日志。跑了两个月后的发现重试逻辑写得太简单模型返回 429 时无脑重试反而加剧了限流日志只记了调用方和耗时没记 Token 数月底账单来了还是分不清哪条业务花的新加一路模型来源要改代码、走发版流程运营想做个活动 A/B 测试等不起玩家在 NPC 对话里输入过手机号和身份证号有人试图刷客服这些内容原样送出去了安全同学看到日志时脸都白了。结论自建这条路走得通但要把它做到能用需要的工作量远超预期而这些工作量和游戏本身的竞争力毫无关系。v1.0 —— 引入统一网关做法把自建转发服务替换为魔芋企业AI网关MAI Gateway定位是统一接入·智能路由·精准分账·安全脱敏·成本优化。接入侧的变化。网关这一层纳管的模型来源比自建时宽得多魔芋 AI 自有平台、工作室自建的开源模型本地化领域我们微调过一版专用模型、各类第三方 API同时已兼容阿里 tokenPlan 与火山 AgentPlan 模型的接入。后面这一条解决了一个很现实的问题——发行方为我们采购了阿里和火山两边的资源计划此前只能靠单独的旁路调用现在能和其他模型池并列纳入同一套路由策略额度不再浪费。路由侧的变化。按场景做了分级NPC 实时对话对首字延迟极敏感走 Gemini 3 Flash 与 GPT-5-mini 组成的低延迟池同一玩家的高频重复问题命中缓存直接返回本地化批量任务不赶时间但量大交给 DeepSeek V4 在夜间跑成本压得很低涉及世界观设定、剧情分支一致性校验这类需要长上下文的活交给 Claude 4 Sonnet极少数需要整体剧本结构推演的任务才动用 Claude Opus 4.7。安全侧的变化。玩家输入在出网前统一做敏感信息识别与替换手机号、身份证号、支付订单号在网关侧被拦下并替换为占位符。这件事放在网关做而不是让三个业务组各写一遍是我们从 v0.5 那次事故里学到的。成本侧的变化。网关按项目、业务线、场景三级标签归集用量。第一次出账时我们发现本地化只占调用次数的一成多却吃掉了近四成 Token——因为整段文本反复重译。定位到之后加了增量翻译这一块支出直接砍掉一大半。v1.2 —— 现在的状态新增一路模型来源不再需要发版运营侧做对话风格 A/B 测试可以在网关配置里灰度分流。上一次某家模型服务商区域性抖动时NPC 对话在玩家侧只表现为一次略慢的回复没有报错——故障转移是在网关里完成的游戏侧一行代码都没改。回头看这条路从 v0.1 到 v1.0真正花时间的不是接模型而是接完之后的那些事密钥、限流、脱敏、记账、灰度、故障转移。这些事和游戏好不好玩没有关系但不做AI 就只能停留在某个策划下班后的实验。统一网关的意义是把这些和业务无关的工程负担从每个团队身上拿走放到一层里集中解决。声明本文所述产品功能、特性与案例数据以魔芋企业AI网关MAI Gateway官方最新文档为准文中示意性数据不构成采购或投资建议。企业AI网关属企业AI基础设施合规品类部署与上线请结合所在行业等保、数据安全法等合规要求。
