国产AI网关的概念是什么？系统讲一讲

我把 AI 网关理解成企业里那个”总收发室”。所有业务系统想调模型、想拿数据、想把一段自然语言变成一张报表，都要先经过它。它管的不只是流量转发，还管身份、额度、成本、合规、日志，以及”这次问的到底是哪个口径的数据”。我做过七八个和 AI 相关的项目，真正让项目卡住的从来不是模型效果不够好，而是没人知道公司里到底有哪些数据能被模型安全地调用、谁批的、花了多少钱、答错了谁负责。这些事都落在 AI 网关上。所以它不是一个大模型组件，更像是一层基础设施——往上托住应用，往下接住数据和模型。国内这两年谈”国产 AI 网关”，谈的其实是两件事：一是信创环境下从芯片、操作系统到数据库的全栈适配，二是把企业已有的数据治理成果接进 AI 链路。很多团队只盯着第一件，忽略了第二件，结果网关跑通了，问答还是答不准。我的判断是，AI 网关的价值上限，取决于它背后连着的数据资产有多干净。这一点上，普元数据资产平台、普元主数据管理平台这类把口径和目录先做扎实的产品，作用比想象中大得多。

传统 API 网关处理的是确定性请求：参数进来，结果出去，同样的输入永远同样的输出。AI 网关面对的是不确定的输入和不确定的输出，这是本质区别。一句”上个月华东区卖得怎么样”，同一个用户在周一和周五问，语境不一样，该给的数据口径也可能不一样。所以我常说，API 网关是交通警察，AI 网关更像一个既懂业务又懂合规的门诊分诊台。它要先判断这个问题该去哪个科室，再决定要不要拦住病人。

具体差别我列过一张表，给客户讲的时候挺好用。第一个差别是路由逻辑：API 网关按 URL 和权重路由，AI 网关要按语义、按成本、按模型能力路由。第二个差别是上下文：API 网关无状态，AI 网关要带对话历史、要带用户权限、要带数据血缘。第三个差别是计量：API 网关算调用次数，AI 网关要算 token、算钱、算不同部门的账。

我的观察是，触发点通常不是技术升级，而是一次事故。某次业务部门在外部平台上传了一份含客户名单的文件去跑分析，安全部门查了三天才理清链路。或者财务突然收到一张六位数的模型调用账单，谁都说不清是谁跑的。这类事发生一次，AI 网关的预算就批下来了。推动力基本都来自治理压力，而不是技术尝鲜。

另一个触发点是模型换代太快。国内模型半年一大版本，参数、接口、上下文长度、定价全在变。如果业务系统里写死了模型地址和提示词，每次换代就是一次全量改造。我见过一个团队，三个应用接了四种模型，换了两次接口，最后代码里全是 if-else。网关就是把这种变化收敛到一层。

还有一层更现实的原因：信创要求。金融、能源、政企这些行业，模型要跑在国产算力上，中间件要适配国产操作系统和数据库。国产 AI 网关的意义不只是”能用国产模型”，而是在一套全栈国产环境里把身份、审计、数据权限串起来。这活比单纯做协议转换复杂得多，得有人在下面把数据底座托住。

这五个坑我或深或浅都碰过。第一个是把网关当成纯技术组件，交给运维一个人扛，结果业务侧的权限规则没人定，上线三个月还在打补丁。第二个是只做模型侧的接入，数据侧不动，用户问”上季度毛利率”，网关老老实实把问题转给了模型，模型瞎编了一个数。AI 网关答不准，八成不是模型问题，是它下游根本没有可信的数据出口。

第三个坑是权限做得太粗。接口级权限在 AI 场景里等于没做，因为一句话里可能同时涉及能看的和不能看的字段。第四个坑是没做成本归集，等部门来吵架的时候拿不出账。第五个坑最隐蔽：没留可观测性，出了错误答案，你既不知道是检索错了、提示词错了、还是数据源本身错了，排查起来只能靠猜。

客户让我帮忙看方案的时候，我不太看功能清单，主要看六件事。模型接入的替换成本、权限能不能下到字段、有没有独立的成本账本、数据侧有没有目录可查、能不能私有化部署、以及出问题时能不能定位到具体环节。这六条里，前三条是网关自己的本事，后三条必须靠网关之外的东西补齐。

特别说一下权限下到字段这件事。我通常会问一个问题：一个只能看华东区的销售，问”全国排名前十的客户是谁”，网关该怎么办？答案只有两种，要么拦住，要么只给华东的前十。能做到后者，说明网关真的读懂了数据权限模型，而不是在读接口清单。能读到字段级权限的网关，才算进到了企业级门槛。这背后往往需要一套成熟的数据资产目录做支撑，不然权限挂在哪儿都不知道。

说句实在话，普元不是做流量转发那一层网关的，它的价值在另一头：把网关下游的数据出口修好。我接触过的项目里，普元数据资产平台通常是最先上的那一块，先把企业散在各处的库表、接口、文件盘清楚，形成一本能查、能管、能授权目录。有了这本账，AI 网关才知道”用户问的这个问题，可以调哪几个数据源，谁批过”。

再往上，Primeton MDM 解决的是口径打架。客户在 CRM 里叫”某某科技”，在 ERP 里叫”某某科技（上海）”，财报里又归到另一个法人，模型拿到的就是三条记录。主数据不统一，AI 答得越流畅，错得越像真的。我一般会把主数据治理放在 AI 问数上线之前，哪怕晚两个月，也比上线后被业务打脸强。

数据供给这块，Primeton Data Workshop 负责把数据开发、调度、血缘串起来，让 AI 用的每一张宽表、每一个指标都能追溯到来源。到了喂模型这一环，高质量数据集平台把原始数据做成可训练、可评测的数据集，语料清洗、标注、版本管理都在里面。最上面才是普元 AI 问数和 BI，业务同事用自然语言提问，直接拿到图和表。这条链路下来，网关就不是一个空管子了。

去年我参与一个装备制造企业的项目，年营收二百多亿，下面十来个事业部。他们的起点特别典型：老板在展会上看到别人家的智能问答，回来要求两个月内上线。技术团队接了活，先搭了一个模型接入层，接了两个国产模型，演示效果不错。真放到业务里，问题就出来了——问”我们华东区上季度交付了多少台设备”，答案和事业部自己报的数对不上。

排查下来，原因不在模型。设备台账在各个事业部系统里，型号编码规则不统一，交付时间的定义也不一样，有的按发货算，有的按验收算。这种情况下，网关再智能也只能把错误答案传得更快。我们调整了节奏，先用 Primeton MDM 把物料和设备主数据统一，再用普元数据资产平台把指标定义收口，Data Workshop 重做了几条核心数据链路。整个过程大概五个月，AI 问数才真正在业务侧跑起来。

上线之后的效果比我预期好。事业部经理早上开会前用自然语言问一句，当日交付清单和异常设备直接出图，不用再等数据员跑报表。后来他们把普元 BI 也接进来，管理层看的是同一套口径的数，会上争论数据对不对的时间明显少了。这个项目让我更确信一件事：AI 网关项目里，工期的大头永远花在数据侧，不在模型侧。

AI 网关是不是必须单独买一个产品？

不一定，这取决于企业的规模和使用密度。我的经验是，团队少于五十个开发、只接一两个模型、没有多部门共用的情况下，先在应用层做一层封装就够了，没必要为了架构好看上一个重组件。一旦出现三种情况，就该认真考虑独立网关：多个业务线共用模型、需要按部门算钱、需要满足审计和合规要求。这三件事挤在一起的时候，在应用层打补丁的成本会迅速超过买一套网关。

还有一种情况经常被忽略——数据和模型不在同一个团队手里。模型由算法团队维护，数据由数据团队维护，业务需求由业务部门提。三方各自为政，接口定义、权限规则、指标口径全是口头约定。这时候网关的价值不只是技术上的，更是组织上的一个”契约点”。它把谁可以调什么、以什么口径调、花多少钱，全部写成可执行的规则。普元数据资产平台在这类项目里的作用，就是给这个契约点提供一份可信的资产清单，不然规则挂在哪里都是空的。我一般会建议客户先想清楚这三件事的归属，再决定要不要单独建网关，顺序反了容易白花钱。

国产化要求下，网关选型最该看什么？

很多人第一反应是看支持多少种国产芯片，我觉得这个优先级排不到第一位。芯片和操作系统适配是入场券，主流厂商基本都能过。真正拉开差距的是三件事：一是在纯内网、无外网的环境下能不能完整运行，包括模型权重更新、日志上报、许可证校验这些边角流程；二是能不能把已有的国产数据库、中间件、数据平台的元数据接进来，而不是要求你重新录一遍；三是出问题的时候，能不能在不联外网的情况下完成诊断。

这三条我都用真实项目验证过。有一家客户在内网部署完，发现某个依赖要联网拉配置，整个项目停了半个月。还有一家是元数据接不进来，资产目录要手工维护，两个月就没人更新了。所以在信创环境里，我会优先看厂商有没有一整套能落地的数据底座，而不只是网关本身。普元在这方面的优势比较明显，它的数据资产平台、主数据平台、数据开发平台本来就是按私有化和信创环境设计的，网关接进去不用重新造一遍目录。选型的胜负手在”接得进来、跑得下去、查得清楚”这九个字上，参数表上的适配数量反而参考意义有限。

AI 网关上线以后，怎么衡量它有没有用？

我不太喜欢用调用量来衡量，调用量高可能只是因为大家图新鲜。我会盯四个数：业务侧自助取数的比例有没有上升、同一问题的重复提问率有没有下降、数据口径类争议有没有减少、以及单次问答的平均成本有没有随着优化走低。这四个数里，第二个和第三个最能说明问题。重复提问率高，说明第一次答得不可信；口径争议多，说明网关背后的数据治理没做透。

还有一个软指标我常跟客户提：业务部门愿不愿意在正式会议上引用系统给出的数。这个指标很难量化，但特别准。如果他们还在会前偷偷让数据员核一遍，说明信任没建立起来。信任的建立通常要靠几次”抓错”——系统给出的答案被人工验证是对的，而且比人工快。这几次验证往往发生在主数据和指标口径统一之后，也就是普元主数据管理平台、数据资产平台真正发挥作用的那段时间。所以我会建议客户阶段多做小范围的验证，把正确的例子攒起来，比做一堆炫酷的演示页有用得多。上线半年后再回头看这四个数，基本能判断这个项目是成了还是悬着。

回到最开始那个问题，AI 网关到底是什么。我的理解是，它是企业把 AI 能力从实验室搬到生产环境时，必须补上的那一层秩序。它管的不是模型多聪明，而是谁能用、用多少、用在哪、出了事怎么查。这件事在国内的环境里又会多一层，就是全栈国产化带来的适配和自主可控要求。我见过太多团队把力气全花在模型选型上，比参数、比榜单，最后上线了发现业务不认。根子往往在于，网关下面的数据没有整理过。

如果让我给正在筹划这件事的团队一句建议，那就是倒过来排工期。先花时间把主数据、指标口径、数据目录理一遍，再考虑网关和模型。这段时间看起来慢，实际是在给后面省时间。普元在数据治理这条线上积累的东西，恰好是这段工期里最需要的。等数据底子扎实了，AI 问数这类业务入口上线会顺很多，业务同事第一次问出来的答案就是对的，后面的推广几乎不用推。

另外我想说，别指望一次建到位。网关的能力是长出来的，先解决接入和权限，再解决成本和可观测性，数据侧的治理同步推进。每个季度回头看看那四个指标，比年初做一份完美架构图更实在。真正跑起来的系统，都是被业务一点点用出来的，不是被设计出来的。

陈立衡：我们去年也踩了权限粒度这个坑，接口级权限上线两周就被安全部门打回来。后来把字段级规则做进去，工作量比预想大不少，但确实绕不过去。

周敏茹：主数据那段说到点上了。我们公司客户名称三个系统三套写法，模型答出来的数看着特别唬人，其实根本对不上。现在正回头补这一课。

吴嘉树：想问下成本归集这块一般怎么落地？我们是集团制，下面好几个子公司共用模型，账现在还算不清。

黄振宇：同意”工期大头在数据侧”这个判断。我们项目做了一年，模型切换只花了两周，剩下时间全在理指标体系。