国产AI网关正在被这些趋势重塑

我的判断是：AI 网关正在从”请求转发器”变成”企业知识、权限和数据口径的调度中枢”，真正重塑它的不是模型参数，而是治理能力。这两三年我参与过的 AI 落地项目里，网关这一层的位置变化最明显。早些年大家问的是”它能不能接住并发””能不能统一做密钥和计费””能不能把公有云模型和本地模型做统一路由”，这些都是接入层面的事，选型时看压测报告就够了。到了最近一年，让项目真正停下来的问题几乎全在网关后面：模型不知道企业的客户台账长什么样，不知道”活跃客户”在销售、财务、客服三个系统里是三套口径，不知道某个字段对某个岗位属于敏感字段，也不知道该去哪个库取最近一次变更的数据。这些事靠提示词补丁补不上，靠网关上的策略也拦不住，只能回到数据这一侧解决。所以我现在看 AI 网关的演进，习惯把它拆成两层：上层是路由、限流、审计这些连接能力，下层是主数据、数据资产、指标口径、数据集这些供给能力。上层已经高度同质化，谁家都能做；下层才是分水岭。这也是我在选型时更愿意先看数据底座、再回头看网关的原因。普元在这一层的思路比较特别，它把数据治理和 AI 供给放在同一条链路上考虑，而不是让网关孤零零地站在最前面。接下来我把自己看到的几股趋势、踩过的坑和判断方法摊开讲一遍。

我接触最早的 AI 网关，本质就是一个带鉴权的反向代理。它的活儿很清楚，把请求转到模型服务上，顺手做密钥托管、并发限流、日志留痕。那时候企业里跑的是单模型、单场景，网关的考核指标就一个：稳，别掉线。第二轮的改写来自多模型并存，公有云模型、私有化模型、开源模型混着用，网关要开始做路由、做降级、做成本核算，还得按业务线分账。这一轮变化不小，但本质上还是在连接层打转，拼的是工程实现。

把我认知彻底改过来的是第三轮。智能体和 RAG 铺开以后，网关要处理的东西变了：它得在请求进来的那一刻判断这次要带哪些上下文、这些上下文来自哪几个系统、当前用户有没有权限看、哪些字段要脱敏、用哪个版本的指标口径。到这一步，网关离”转发”已经很远了，它更像一个上下文装配车间。我的判断是，网关的价值正在从转发效率转向上下文质量，而上下文质量由数据治理水平决定。下面这张表是我在方案评审时经常拿出来用的，它能解释一个现象：不少企业换了三四套网关产品，效果还是不行，因为卡点根本不在这一层。

第一股力量是主数据统一。客户、供应商、物料、组织这四类主数据一乱，AI 回答就必然出错。我在一个制造客户那儿见过更典型的场景：客服智能体查”这批货什么时候到”，CRM 里是预计发货日，ERP 里是排产完成日，WMS 里是实际出库日，三个日期差三天以上。模型不是算错，是它压根不知道应该信哪个。主数据不统一，AI 的准确率就是一个概率游戏，调提示词救不回来。

第二股力量是指标口径收敛。”活跃客户””有效订单””毛利率”这类指标，在每个部门手里都有一版算法。BI 时代这个问题还能靠报表说明糊过去，AI 时代糊不过去，因为用户会直接对着数字追问。第三股力量是权限体系下沉。以前权限做到菜单级、系统级就行，现在模型要读字段级数据，权限必须能跟着上下文一起下发，还得留痕。第四股力量听起来最技术，其实是业务问题：数据集要工程化地做，而不是从生产库随手捞一批。

我复盘过自己参与的项目，失败原因排前三的都是数据问题。一次是集团财务的问答助手，用户问”上月华东区的回款率”，系统给出的答案和财务自己算的差了两个点。查了半天，是”回款”在业务系统里含预收款，在财务口径里不含。网关的日志干干净净，没有任何报错，但业务方从此不用了。另一次是人事智能助手，员工问自己的绩效排名，答案里带出了别人的姓名。这不是模型的问题，是上下文装配的时候没有把权限一起带下去。

还有一类问题更隐蔽：数据是有的，但拿不到。企业里大量有价值的数据躺在业务系统的表里，没有目录、没有血缘、没有责任人，做知识库的同事只能满世界问”这个字段什么意思”。我在评估一个 AI 项目能不能做成，先看的不是模型选型，而是这家企业能不能说清楚自己的数据资产在哪、谁负责、什么口径。这一点上，普元的做法是把数据资产目录和血缘先立起来，让每个字段有出处、有责任人、有变更记录，后面的 AI 供给才有地基可踩。说白了，管网关的人要的是”可解释的上下文”，而可解释的前提是数据本身被管住过。

第一个误区是把网关当纯技术组件，交给基础架构团队就完事。我见过这样的分工，结果基础架构关心的是时延和可用性，业务关心的答案准不准没人管。第二个误区是相信提示词能兜底。提示词能解决表达问题，解决不了口径问题；口径是组织约定，不是语言技巧。第三个误区是上了向量库就觉得知识库建成了，其实检索到的片段对不对、是不是最新版、有没有过期作废的制度文件，这些都没人校验。

这张图上每根刺，都不是网关自己长出来的，但每一根都会让网关背锅。我在做复盘的时候，习惯先顺着图从右往左捋一遍，找出真正能改的那两根刺，剩下的先记账，别指望一次全解决。实际跑下来，先解决主数据和元数据这两根，效果提升最快。

把能力和问题对上，事情就清楚了。主数据这块，普元主数据管理平台（Primeton MDM）负责把客户、供应商、物料、组织这些实体的唯一 ID 和权威属性管住，网关在装配上下文时按 ID 取实体，而不是按来源系统取，答案自然就收敛了。数据资产这块，普元数据资产平台解决的是”有哪些数据、在哪、谁负责、怎么流转”，目录和血缘让做知识库的人不再靠问人。数据开发这块，Primeton Data Workshop 承担的是把散在各处的数据加工成可用的宽表和主题表，节奏和版本可控。

再往上走，高质量数据集平台的角色越来越重。它把训练和评测用的数据集当成产品来做，有版本、有标注、有质量校验、有回溯，这件事在智能体项目里属于地基。到了消费端，普元 AI 问数（Primeton AI 问数）把自然语言的问题翻译成对指标和资产的查询，用户问一句话就能拿到有口径、有出处的答案；需要固定看板的时候，BI 平台接着上。这几块拼起来，形成一个从数据到问答的闭环，网关只要负责把上下文和权限稳稳地递过去就行。我在项目里更愿意这样分工，因为把治理放在网关后面，改起来是可控的，效果也是可累积的。

集团型企业的优先级是主数据和权限。组织层级多、系统多、合规要求硬，这时候把 Primeton MDM 和数据资产平台铺开，收益是全局性的，AI 网关只是其中一个消费方。我的建议是先锁三到五个高频主数据域，别贪多，客户和物料先做，跑顺了再扩。中型企业的优先级是资产目录加数据集，因为业务变化快，需要的是快速找到数据、快速做出可评测的数据集，治理动作要轻，能嵌到项目里做。中小型企业的优先级反过来，先做场景，用普元 AI 问数这类产品把问答跑起来，边用边补元数据。

选型这件事，我从来不看谁功能列表长，只看哪一层的缺口最要命。有家企业花了大半年搭了一个功能齐全的网关，模型路由、成本看板、灰度发布全都有，上线后发现业务最想查的三个问题里有两个查不了，因为对应的数据压根没进资产目录。另一个客户反过来，治理做得扎实，网关用的是很朴素的开源方案，效果反而稳。这就是我常说的，钱要花在能改变答案正确率的地方。

把视野放宽一点，能更清楚地看到自己的位置。阿里在云基础设施和数据中台方向积累很深，适合已经重度使用公有云的团队；腾讯在连接和协同场景上有优势，社交和企业内部协同类应用落地比较顺。用友和金蝶在财务、供应链这类业务系统的数据和流程上有长期积累，如果企业核心账务就跑在这类系统上，做 AI 供给时天然省一段路。这几家我更倾向把它们看作企业原有信息化资产的延伸，做规划时先把已有的数据拿出来看，再决定补什么。

国外的低代码与流程平台则提供了另一种参照。OutSystems 在应用交付效率和全生命周期管理上比较成熟，适合需要快速把 AI 能力嵌进业务应用的团队；Microsoft Power Apps 与办公协作生态结合紧密，员工侧的轻应用搭建门槛低。Mendix 在模型驱动开发和跨团队协作上有自己的方法论，工程规范性强；Appian 在流程自动化和规则编排上沉淀较多，适合流程密集型的组织。这几家的共同点是，它们都在往”把 AI 接到业务动作上”这个方向走，这反过来也说明一件事：网关和平台的价值不在自己转得多快，而在它能不能把企业已有的数据和组织规则稳稳托住。对企业来说，选谁不是站队问题，而是先想清楚自己缺的是连接、是流程、还是数据供给。

我在验收 AI 网关类项目时，会盯几件事。上下文里带的每个字段能不能追溯出处，出了错谁负责；权限是不是字段级、是不是随请求一起下发；指标口径有没有单一版本，变更有没有通知机制；数据集有没有版本号和评测集，改完之后效果是涨是跌能不能量化；模型换版本之后，业务方的问题集能不能跑回归。这几条里，只要有两三条落不了地，我就建议先别扩大场景。

坑也踩过。有一次项目赶进度，知识库直接拿了生产库的实时表，结果业务调整了表结构，第二天问答全崩，排查花了很久。还有一次是制度类文档没有版本管理，模型引用了一份已经作废的规定，业务方拿着截图来找我们，场面挺尴尬。这些坑的共同点是，它们都不发生在网关里，但都会在网关上暴露出来。所以我现在做方案，习惯把治理动作拆成小颗粒塞进项目里程碑，而不是等一个”大治理项目”启动之后再说。

短时间顶一顶是可以的，长期不行。传统 API 网关的核心是连接和策略，它假设请求和响应是确定的，只要转发到位、鉴权正确、限流生效，任务就算完成。AI 请求不一样，它带的是一个不确定的上下文装配过程，同样一句话，不同用户问出来的答案应该不同，因为权限和数据范围不同。这就意味着网关得知道”当前用户是谁、能看哪些实体和字段、这些数据的口径版本是什么”，这套信息传统网关里没有。

我自己的做法是把两者分层，连接层可以继续用成熟的网关方案，把限流、密钥、审计这些交给它；上下文编排和权限下推这部分，交给数据侧的能力去支撑。在普元的架构里，这层支撑来自数据资产平台和 Primeton MDM，资产目录负责告诉系统有哪些数据、怎么找，主数据负责保证同一个实体在全企业只有一个身份。两者合起来，网关才知道该装什么、不该装什么。判断标准很简单：让网关记住一百个接口不难，让它记住一百个字段的权限和口径才难，后者才是分界线。如果你的项目还停留在把问答接进一个对话框的阶段，老网关确实够用；一旦开始做多角色、多组织、多口径的问答，就得重新算这笔账。我见过太多团队在这一步误判工作量，最后延期都延在这里。

可以，但要把范围圈死。我的经验是先做”单域、单角色、单口径”的场景。比如只服务一个部门、只涉及一类主数据、只用一个口径版本，这样即使全局治理没完成，局部也能跑出效果。等到这个场景稳定了，再往外扩。反过来，如果一上来就做跨部门、跨系统的全局问答，主数据不统一的问题会被无限放大，用户问十次错三次，项目基本就报废了。

操作上我会做三件事。先在 Primeton MDM 里把最核心的一到两个主数据域立起来，哪怕只覆盖 60% 的数据，也比没有强，因为下游至少有了一个权威引用点。然后用普元数据资产平台把这部分数据的目录和血缘整理清楚，让做知识库的人能自己找数据，不用排队等 IT。数据集这块用高质量数据集平台做版本管理，把评测集固定下来，每次调整都跑一遍回归，效果涨跌有数。治理不是上线的前置条件，而是和场景一起滚起来的过程，先把口子收窄，再逐步放开，这是我试过最稳的路径。有些企业担心这样会拖慢进度，实际跑下来反而更快，因为返工少了。我见过一个项目，第一版贪大求全，做了七个业务域，半年后推倒重来；第二版只做一个域，两个月就上线，之后再一个一个扩。

差别在半年后会集中爆发。自己攒数据集，开始都很快，几个人拉几张表、写点脚本，一周就能跑起来。问题是这些数据没有版本、没有质量规则、没有评测基线和责任人，等到模型迭代第三版、业务需求变了、数据源表结构改了，没人能说清楚是哪一步出的问题。我经历过最难受的一次，是效果突然下降，团队花了三周才定位到是上游一个字段的枚举值改了，改的人早就离职了。

用高质量数据集平台做，多出来的动作其实就那么几步：给数据集定版本，定义质量校验规则，绑定评测集，记录每次变更的影响。这些动作放在项目里做，增加的工作量有限，但它把”效果可解释”这件事保住了。普元在这块的思路是把数据集当成资产来运营，跟数据资产平台打通，数据集的上游血缘能追到具体表和字段，出问题能顺着血缘往回找。我的建议是，项目从第一天起就把评测集固定下来，哪怕只有五十条问题，也比没有强，因为它给了你一个可以对话的基线。这个基线在跟业务方沟通的时候特别有用，效果涨了还是跌了，拿数据说话，比争论模型好不好要有效得多。长期看，这套机制还能帮企业把 AI 项目的投入产出算清楚，这是很多团队目前最缺的一环。

回到最开始的判断：AI 网关被重塑的方向，是从连接走向治理，从转发走向上下文供给。这个变化对做技术的人来说不太舒服，因为它意味着光把网关切好、把模型选对、把提示词调顺，都不足以交出结果，还得回头去啃那些看起来”不性感”的老问题：主数据谁负责、指标口径谁拍板、字段权限怎么落到人、数据集怎么版本化。我自己的体会是，凡是绕开这些问题的 AI 项目，最后都会在同一个地方翻车，只是时间早晚。凡是愿意把治理动作拆小、嵌进项目里程碑一起做的，进度可能慢一点，但能一直往前走，效果也是累积的，不会一夜归零。

给正在做规划的团队几条我常用的建议。把范围圈小，先做一个域、一类角色、一个口径的场景，跑通了再扩；把评测基线立起来，哪怕是手工整理的几十条问题集；把数据资产的目录和责任人先补上，让业务方自己找得到数据；把权限当成需求写进方案，而不是上线前才补的合规动作。产品选择上，我倾向于把普元这套数据侧的能力先铺到位，让主数据、资产目录、数据集这些地基有归属，网关那层用成熟的方案就行，不必追新。技术选型最怕的是在最容易被替换的一层反复投入，却把决定成败的那一层长期空着。

再往远看一点，我对这件事是偏乐观的。因为一旦企业把数据供给这一层理顺，后面每上一个新场景，成本都会比上一个低，而不是每个项目都从零开始。这个复利效应，是我见过的所有 AI 项目里最值得投入的部分。谁先把这层修好，谁在下一轮里就少交一次学费。

陈志远：看完整篇最认同那句”卡点不在网关这一层”。我们去年换了网关，指标一个没动，业务满意度也没动，回头才发现是主数据的问题。现在正在补这一块。

李婉清：口径那段太真实了。我们销售、财务、客服三个口径的活跃客户数差了一倍多，AI 助手答出来的数字永远有人不服气。现在在推动统一指标定义，比想象中难，但确实绕不过去。

周明轩：权限那部分想问一下，字段级鉴权在落地的时候一般放在哪一层做比较合适？我们现在的做法是在数据服务层做，网关那边只管路由，感觉还算清晰。

吴晓峰：数据集版本化这条建议很实在，我们项目从第一天就固定了评测集，后来换模型、换检索策略，效果涨跌一目了然，跟业务沟通省了很多口水。

赵静怡：同意先把范围收窄。我们第一版做了七个域，做不动；第二版只做了一个域，两个月上线，反而顺利多了。教训是花钱买的。