小刘檀木的大模型日记 · Day18 · AI Gateway、AI Nacos-帮普通人把AI学进简历系列Day18|AI Gateway、AI Nacos大模型应用从 Demo 到生产中间差一个治理层前言一次“换模型改代码”的小事故上周四晚上 10 点半一个朋友给我发消息说他们的 AI 客服准备第二天灰度。结果临上线前老板突然来了一句“把模型从 A 换成 B成本便宜一点效果也试试。”这事听起来很小改个base_url换个model再改一把api_key。二本小透明当年刚做工程时也觉得这不就是三行配置的事。然后事故就来了。测试环境改了生产环境没改生产环境改了灰度策略没改灰度策略改了日志里又分不清到底是哪一路模型在回答。这就是大模型应用从 Demo 走向生产时最容易被忽略的一层模型调用也需要治理。今天这篇我们聊两个越来越重要的词AI Gateway和AI Nacos。先记一个粗暴版本AI Gateway 管入口Nacos 管控制面。一个负责请求怎么进来、怎么转发一个负责配置怎么变、服务怎么发现、工具怎么注册。PART 01AI Gateway 管入口——把模型调用从业务代码里拆出来很多人听到 Gateway第一反应是“网关不就是反向代理吗”放在传统 Web 系统里这句话不算错。但到了 AI 应用里Gateway 的价值会明显变大。因为大模型调用背后多了几层麻烦模型供应商多OpenAI、Claude、通义、DeepSeek、本地 LLaMA调用成本高一个用户狂点刷新钱真的会烧返回时间长流式输出、超时、重试都要处理内容有风险Prompt 注入、敏感词、越权工具调用观测很关键你得知道哪个模型贵、慢、错得多所以 AI Gateway 不只是转发请求更像模型调用的统一入口。它至少能帮你做几件事统一鉴权业务方只拿内部 token不直接接触模型厂商 key模型路由简单问题走便宜模型复杂问题走强模型限流熔断防止某个用户或某个应用把额度打爆观测统计记录 token、延迟、错误率和成本安全治理对输入输出做内容检查对工具调用做权限控制这样业务代码就不用写一堆if model ...。它只需要面对一个统一入口。比如用 OpenAI 兼容协议业务代码可以长这样from openai import OpenAI client OpenAI( api_keyinternal-app-token, base_urlhttps://ai-gateway.example.com/v1, ) resp client.chat.completions.create( modelcustomer-service-fast, messages[ {role: system, content: 你是企业客服助手回答必须基于知识库。}, {role: user, content: 我的发票怎么重新开}, ], ) print(resp.choices[0].message.content)注意这里的modelcustomer-service-fast它不一定是真实模型名而是内部逻辑名。真正转到gpt-4.1-mini、qwen-plus、deepseek-chat还是本地 LLaMA由 Gateway 的路由策略决定。这就像你去饭店点“今日套餐”不用关心后厨今天是哪口锅炒的。对业务代码来说稳定最重要。PART 02Nacos 管控制面——配置、服务、MCP 工具都要能动态发现那 Nacos 在这里干嘛如果说 AI Gateway 是流量入口那 Nacos 更像控制面。传统微服务里Nacos 常做两件事服务发现和配置管理。服务发现解决“谁还活着、地址在哪”配置管理解决“参数怎么改、改完谁生效”。到了 AI 应用对象变了。以前你注册的是订单服务、用户服务。现在你还可能注册模型服务llama-local-8b、qwen-plus、embedding-serviceMCP Server文件系统工具、数据库查询工具、工单工具Prompt 模板客服 prompt、审核 prompt、总结 promptAgent 配置可用工具、模型策略、超时参数这就是 AI Nacos 值得关注的地方它不只是管传统微服务也开始往AI Registry / MCP Registry / Agent 管理这类方向延伸。分工可以这样理解Gateway每一次请求怎么进、怎么鉴权、转给谁、怎么限流Nacos有哪些模型/工具可用、配置是什么、变更怎么推送一个管“跑在路上的车”一个管“路网和信号灯”。比如模型路由策略不应该散落在每个应用仓库里。它更适合放进配置中心routes: customer-service-fast: primary: qwen-plus fallback: deepseek-chat max_input_tokens: 8000 timeout_ms: 15000 rules: - when: intent refund and vip true model: gpt-4.1-mini - when: input_tokens 1000 model: qwen-turbo这段配置表达的是业务仍然调用customer-service-fast但背后可以按意图、用户等级、输入长度去路由。更关键的是你可以改配置而不是重新发版。这对生产系统太重要了。上线后你会经常遇到这种情况某个模型今天延迟飙高先切 fallback某类问题答得差临时调高强模型比例某个 MCP 工具出问题先下线工具某个 prompt 效果不好灰度新版 prompt如果每次都要改代码、打包、发版团队很快就会被变更拖垮。PART 03把它们放进一个真实 AI 应用我们拿企业知识库助手举个例子。这个系统看起来只是“用户问一句AI 答一句”但生产链路通常很长用户问题进来Gateway 做鉴权、限流和日志应用做 query 改写和 RAG 检索Gateway 根据策略选择模型模型必要时调用 MCP 工具输出再经过安全检查记录 token、成本、延迟和命中率这里面最怕什么最怕所有东西都写死在代码里模型名、key、工具地址、prompt、阈值。Demo 的时候爽生产的时候每一个“写死”都会变成坑。我更建议普通团队按三个阶段推进第一步先治理配置。把模型名、base_url、超时、fallback、灰度比例从代码里拿出来放进 Nacos 这类配置中心。第二步再治理模型入口。让业务统一调用 AI Gateway不要让每个业务系统自己保存一堆厂商 key也不要让每个业务自己实现限流、重试和日志。第三步最后治理工具和 Agent。当 MCP Server、内部工具、Agent 配置越来越多时再把工具注册、发现、权限和灰度纳入统一治理。这样做有个好处你不是为了追概念而上架构而是随着复杂度一点点长出治理能力。真实工程里架构不是画出来的是被事故逼出来的。但我们最好别等事故把人逼到凌晨三点。结尾别让模型调用继续裸奔今天这篇你只要带走一张图就够了AI Gateway数据面入口负责鉴权、路由、限流、观测、安全Nacos / AI Nacos控制面中心负责配置、注册发现、MCP/Agent 资产管理业务应用只关心业务逻辑不应该到处散落模型 key 和路由规则大模型应用走到生产最怕的不是模型不够聪明而是调用链路不受控。模型可以换供应商可以换Prompt 可以换工具也可以换。但前提是这些变化不能每次都变成一次发版事故。大模型应用从 Demo 走向生产第一步不是换更大的模型而是把失控的调用变成可治理的系统。互动时间如果让你们公司现在接一个 AI Gateway你最想先治理哪件事模型 key、成本、限流、日志还是 MCP 工具下一篇预告我们继续聊推理参数temperature、top_p、max_tokens 这些按钮到底怎么调才不玄学。— END —小刘檀木 · 帮普通人把 AI 学进简历