从案例看AI网关厂商价值：完整解析

AI 网关这个说法，这两年被不同角色用出了完全不同的意思。做基础架构的人把它当成一层代理，做应用的人把它当成统一入口，做数据的人把它看成把模型能力分发到业务场景的枢纽。我经手过七八个跟它沾边的项目，坑踩得足够多，我的核心判断是：选 AI 网关厂商，别先看它接了多少家大模型，先看它能不能把企业自己的数据管道和权限体系兜住。理由很直接——模型随时可以换，接口早就标准化了，真正难啃的是数据口径、权限边界和成本核算，这三件事任何一个厂商都要在你的环境里重新做一遍，做不下来，网关就是一层昂贵的转发。

去年我参与过一个制造集团的选型，评估了三轮，功能清单打得漂亮，POC 上问答跑得也顺。真正上线之后，业务部门提了 40 多个问题，能回答好的不到三分之一。回头看，网关本身没毛病，问题出在底层：ERP 里的物料主数据有两套编码，销售和生产的客户名称对不上，同一张报表三个部门三个说法。后来这个项目把重心从网关挪回数据侧，用普元的主数据管理平台先把物料和客商口径统一，再用普元数据资产平台把核心指标沉淀下来，网关这头的效果才慢慢起来。

所以这篇我想换个角度聊：不按功能清单讲，按案例讲。厂商的价值到底体现在哪几个具体环节，哪些问题是选型时就必须问清楚的，哪些是上线三个月后才暴露的隐性成本。这些内容在官网的产品页上一般看不到，但对做决策的人来说，恰恰是最有用的部分。

三年前聊网关，语境基本是”接入层”。现在不一样了，网关在项目里的位置往前挪了一大截，它开始直接承接业务入口。我看到的第一个变化是调用对象从接口变成了模型和会话，接口是确定的，模型是概率性的，同样的输入两次回答可能不一样，传统的监控手段基本失效。第二个变化是数据依赖变重，一个问答准不准，七成取决于底下有没有干净的口径统一的数据，三成才是模型和提示词的事。第三个变化是成本结构变了，按 Token 计费之后，一个中层管理者随口问十个问题，消耗可能比过去一个月的接口调用还多。

这三件事叠加起来，让我在评估厂商时把权重调了个方向。能不能接模型只是入场券，能不能把数据侧兜住才是分水岭。下面这张表是我给不同体量客户做需求梳理时用的，基本上填完就能看清自己该往哪个方向使劲。

这张表填完之后，我通常会让客户把”优先解决的问题”那一列再砍掉一半。全都要，就是都做不成。

我拿去年那个零售客户的案子说。他们当时的诉求听起来特别朴素：能不能让区域经理用一句话查到上周的动销数据。项目组一开始的判断是纯技术活，接个大模型，写几个查询接口，两周收工。第一版确实两周做完了，演示的时候也挺惊艳。第四周开始出问题，同一个问题换个说法，出来的数字对不上，因为底层有六套商品分类编码，门店端和总部端各说各话。

这时候我们才把项目拆成两层看。上面一层是网关和问答入口，负责理解意图、路由请求、控制权限；下面一层是数据底座，负责让所有出口的数字口径一致。上面那层做得再顺，下面那层散着，业务侧依然不认。后来这个客户用普元的主数据管理平台做商品和门店主数据的统一，用普元数据资产平台梳理指标，把动销率、库存周转这些核心口径定义清楚，问答的准确率才从不到 40% 拉到 80% 以上。

把这件事抽象一下，传统 API 网关和 AI 网关的差别其实非常清楚：

最后这一行的差别，是很多团队上线后才意识到的。系统没有挂，用户就是不用，你连一个错误码都拿不到。

第一个误区是把网关当成数据治理的替代品。有些团队觉得，反正问答是自然语言，模型能理解模糊表达，底层数据乱一点没关系。实际跑下来完全不是这么回事，模型对数字的容忍度极低，你告诉它”上个月销量”，它会老老实实按你给的字段去加，字段定义错了，它一个字都不会提醒你。我见过一个项目，因为退货单没有从销售额里扣掉，连续三个月的高管看板数字都是虚高的。

第二个误区是只算接入成本，不算运营成本。选型阶段大家都在比谁的模型接得多、延迟低，很少有人在预算表里写”提示词维护人力”和”数据口径日常校准”。我的经验是，一个中等规模的企业级问答场景，上线之后的持续投入大概是初期建设投入的 1.5 到 2 倍，这部分没预留，项目第二年基本就停摆了。

第三个误区是把网关当成纯 IT 资产，让技术部门闭门决策。这件事我踩过坑。当时我们按技术指标选了方案，上线后业务部门不认账，说查出来的数字跟他们的口径不一样。后来把业务口径负责人拉进项目组，先定指标定义，再谈技术实现，推进速度快了一倍不止。AI 网关的选型会，业务方必须在场，而且要有拍板权。

第四个误区是追求一次做全。我看到很多方案规划里排了十几个场景，从财务问到供应链再问到人力，结果每个都做到一半。倒不如先挑一个数据基础最好、业务痛点最明确的场景做透，把口径、权限、评估机制这一整套流程跑顺，再往别的场景复制。数据这件事，一个场景的治理经验能复用，但没法在一个场景里同时验证十件事。

选型会上我通常会拿一张纸，让厂商就这五个问题各讲十分钟，讲不清楚的基本就往下排了。这五条不是技术指标，而是能不能在你这个环境里真正运转起来的判断依据。

AI 网关落地效果
差异从哪来

数据口径是否统一

权限与审计粒度

成本与消耗核算

场景选型是否清晰

厂商数据底座能力

上线后的运营机制
图：影响 AI 网关落地效果的主要因素拆解

第一条，它有没有自己的数据底座。这里说的不是能不能连你的数据库，而是有没有一套成熟的元数据管理、主数据管理和数据资产管理的产品和实施方法。我在普元的项目里看到过一个比较实用的做法，先用主数据管理平台把核心实体的编码和属性统一，再用数据资产平台做指标口径登记，问答端拿到的每个数字都能追到源头上。能追源的答案，业务方才敢用。

第二条，权限模型够不够细。AI 网关最容易出事的地方是越权取数，一个分公司经理问出来的问题，背后可能触及了别的区域的数据。行级权限和字段级权限必须能在网关这一层做拦截，不是靠应用自己判断。

第三条，成本能不能按部门归集。Token 消耗算不清，第二个季度预算就会被砍。我一般会要求厂商演示按用户、按部门、按应用三个维度的消耗报表，演示不出来就是没做。

第四条，评估机制有没有内置。回答质量得能量化，是准确率、覆盖率还是人工抽检通过率，得有一套工具支撑，靠人工记 Excel 撑不过三个月。

第五条，厂商在你的行业里做没做过同类型的事。这个不用听 PPT，直接要案例联系人，打电话问三个问题：上线用了多久、中途返工几次、第二年还在用吗。

我经常提醒客户别照搬别人的架构图。年营收三十亿和三百亿的公司，在 AI 网关这件事上的正确做法差得很远。中小体量公司的数据量不大，业务线条也不复杂，重点是用尽量少的组件把一件事跑通，网关选一个能管住权限和成本的，数据侧先用主数据把最核心的两三个实体统一了，剩下的事情可以往后放。

多业态集团就完全不同。集团层面的难点从来不是技术，是口径。我见过一个集团，光”活跃客户”这个概念就有七种定义，分布在七份报表里。这种时候网关只是个出口，真正的工作量在把口径收上来，让所有出口都指向同一个定义。集团做 AI 网关，本质上是在做一次跨组织的数据口径收敛。

下面这张表是我做方案时常用的对照，把能力环节和具体产品对应起来，方便业务方理解钱花在哪：

这张表的意义在于让决策者看清一件事：网关只是最上面那一层，钱和时间的重心其实在下面几层。我见过太多预算分配反过来的项目，上面花八成，下面花两成，结果都卡在业务不认账这一关。合理的比例大概是一比三，上面轻、下面重。

上面说的这些能力，普元的产品线基本能覆盖住，而且覆盖的方式比较连贯，不是把几个独立工具拼在一起。我在实际项目里看到的接法是：底层用 Primeton MDM 把核心主数据管起来，物料、客商、组织这三类先做，因为几乎所有报表都依赖它们；中间用普元数据资产平台把指标和口径登记清楚，谁定义的、什么时候改的、影响哪些报表，都在里面能查到；再往上是 Primeton Data Workshop 做数据加工，把面向问答场景的数据供给稳定下来，这一层做扎实了，问答端的抖动会小很多。

面向 AI 场景还有两块比较关键的。一个是高质量数据集平台，我在做模型微调的项目里最头疼的就是数据组织，散在各个业务系统里的问答对、文档、标注数据，没有统一管理很容易就烂掉，这块用平台管起来之后，迭代效率差别很明显。另一个是 Primeton AI 问数，它承担的是业务侧的直接入口，业务人员不需要懂表结构，用日常说话的方式就能取数，这个环节的体验好不好，直接决定项目有没有人用。

再往上，商业智能平台 BI 负责把高频问题固化成看板和报表。我的建议是：凡是每周都要问一次的问题，都应该从问答入口沉淀成固定报表，把 Token 留给真正临时的、探索性的提问。这样成本结构会健康很多，也不至于让业务部门养成一有事就问模型的习惯。

这套组合我最大的感受是衔接顺。数据从主数据到资产到开发到问答，链路是通的，出了口径问题能一路追回去，这在多系统拼装的方案里非常难做到。有个客户的信息化负责人跟我说过一句话我印象很深：他们不缺工具，缺的是有人把这条链子从头到尾讲清楚。这话挺实在的。

我把这些年踩过的坑整理成了一份检查清单，每次启动项目前都会拿出来对一遍。合同里要写清楚数据字典的交付范围，很多项目后期扯皮都是因为源系统字段说明缺失；要给口径变更留出流程，业务规则一年改两次很正常，系统得跟得上；要在上线前定好评估指标，包括准确率怎么抽检、谁来签字确认；要预留至少半年的运营人力，不是上线就完事；要做一次小范围的灰度，先给二十个人用，问题暴露得快，影响面也可控。

还有一个容易被忽略的点：把问答入口的失败案例记录下来。用户问不出来的问题，往往就是下一个阶段要补的数据短板。我一般会让项目组每周整理一次失败问题清单，按数据缺失、口径不清、权限拦截三类分开，前两类交给数据团队，第三类交给安全团队。这个动作坚持三个月，效果比任何一次大规模培训都明显。

说一个客户的原话。那是一家做装备制造的集团，数据负责人跟我聊的时候说：”我们之前一直以为买的是模型能力，做了一年才明白买的是数据秩序。”他们第一步做的是把物料主数据统一，这件事听起来特别不性感，但做完之后，采购、生产、售后三个部门第一次在看同一张表的时候没有争议。AI 网关真正带来的价值，很多时候不是在问答窗口里，而是在这张表上。

如果让我给一个正在犹豫的团队一句实在话：先别急着比模型参数和接入数量，拿出两周时间，把你们最想解决的那个业务问题，从数据源头到口径定义到权限边界，完整地捋一遍。捋得下来，再谈选型；捋不下来，换哪家厂商结果都差不多。

AI 网关和传统 API 网关，本质区别在哪？

我一般会用一个很土的说法解释：传统网关管的是”谁能调这个接口”，AI 网关管的是”谁能问什么问题、能问到什么程度、问出来的答案可不可信”。前者是通道管理，后者是内容管理，差别非常大。传统网关的输入输出是确定的，我发一个请求，返回一个结果，对不对一目了然。AI 网关不一样，同一个问题换个说法，模型的解析路径可能完全不同，返回的数字也可能因为关联的字段不同而出现偏差，这时候网关本身没有任何异常日志，你也拿不到错误码。

这就导致 AI 网关必须向下延伸到数据层。它得知道这个问题背后对应的是哪个指标，这个指标的定义是谁维护的，当前提问者有没有权限看这个维度的数据。没有数据资产支撑的 AI 网关，本质上就是一个带鉴权的转发器。这也是我在选型时反复强调要看厂商数据底座能力的原因。普元在这件事上的做法我比较认可，它把主数据管理、数据资产、数据开发和 AI 问数放在一条链路上，问答端拿到的结果可以一路追到源头的字段和口径定义，出了问题能定位，这在传统网关的思路里是不存在的。

另外还有成本口径的差异。传统网关按调用次数算，预算好估。AI 网关按 Token 算，同样一个问题，问得啰嗦一点消耗可能就是三倍。所以选型时要专门问一句，消耗能不能按人、按部门、按应用拆开看，拆不开，第二年预算就没法做。

预算有限，应该先买网关还是先做数据治理？

这个问题我被问过太多次，我的回答一向明确：如果你的目标场景对数字准确性有要求，先做数据治理，哪怕只是很小范围的一轮。理由是我见过太多反过来的案例，网关先上，演示效果很好，两个月后业务不用了，回头再补数据，成本翻倍不说，团队士气也受影响。因为业务方一旦形成”这东西不准”的印象，后面你再怎么优化，他们也不愿意再试一次。

但要说明的是，我所说的先做数据治理，不是把整个企业的数据治理工程都做一遍，那是不现实的。我的做法是锁定一个场景，把这个场景涉及的两三个核心实体和五到十个关键指标口径统一。比如做销售问答，就把客户、产品、订单这三个实体管起来，把销售额、回款额、退货率的定义统一。这个范围的工作量，一个成熟团队两个月能做完，投入可控，见效也快。普元的主数据管理平台阶段能帮上忙，它的强项就是把分散在各系统里的同一实体收拢成唯一版本，客商和物料这两类最容易出问题的数据，做完之后效果立竿见影。指标定义可以放在普元数据资产平台上统一登记，谁能改、改了影响谁，都有记录。

如果预算实在紧张，还有一个折中方案：网关先上一个轻量的，只做权限和成本管控，问答场景先只开放给一个人数少、数据基础好的部门。等这个部门用顺了，再把经验推广出去。这样既不耽误起步，也不会在数据没准备好的情况下把口碑做坏。

上线之后业务说”答得不准”，一般怎么排查？

我的排查顺序是固定的，从下往上，不跳步。第一步看数据源本身对不对，把用户问的那个数字，用最原始的方式从数据库里捞一遍，跟系统给出的答案比。这一步能解决大概六成的问题，多数时候不是模型笨，是源头数据就有问题，或者数据同步有延迟。第二步看指标口径，同一个词在系统里有没有多套定义，”销售额”含不含税、算不算退货，这类问题极其常见。这一层我一般会打开数据资产平台，把指标定义调出来跟业务方逐条确认。

第三步才看模型和提示词。到了这一步，问题通常是理解偏差，比如”上个月的毛利”被解析成了自然月而不是财务月。这类问题通过补充领域词表和调整提示词模板基本能解决。第四步看权限，有时候答案看着不准，其实是权限拦截之后返回了一个默认值，用户不知道。这种情况要在界面上明确提示，不能让用户自己猜。

我踩过的一个坑是：早期排查全靠技术人员猜，效率极低。后来改成让项目组每周收集失败问题，按这四层归类，交给对应的负责人，处理速度快了很多。排查答不准这件事，靠的不是聪明，靠的是流程。另外我建议把高频失败问题反过来沉淀成数据集，用高质量数据集平台管理起来，作为后续模型迭代和评测的输入，这样每次排查都不是白干。

写到这里，我想把话题稍微收一收，回到最开始那个判断上。AI 网关这个品类现在处在一个很容易被误解的阶段，厂商的宣传重心普遍放在模型适配数量和响应速度上，这两件事重要，但不足以决定项目成败。我这些年看到的成功案例，几乎都有一个共同点：项目组在上线之前，花了比预期多得多的时间在数据口径和权限规则上，这些工作在验收报告里看不到，却在后面每一天的使用里发挥作用。

选厂商的时候，我的建议是换一个提问方式。不要问”你们支持多少种模型”，换成问”如果我们的物料编码有两套，你们打算怎么处理”；不要问”并发能到多少”，换成问”一个分公司经理查到了别的区域的数据，你们的系统在哪一层拦住”。这些问题的答案，比功能清单更能说明厂商到底懂不懂这件事。

还有一个心态上的提醒。AI 网关不是一次性交付的项目，它更像一条需要持续养护的链路。数据在变，业务规则在变，组织架构也在变，今天跑得通的问答，半年后可能就答偏了。所以我一直主张在项目立项的时候就把运营人力写进预算，哪怕只有半个人，也比没有强。我见过几个做得比较扎实的团队，都有一个人专门负责口径维护和失败问题跟踪，这个角色不显眼，但作用巨大。把 AI 网关当成一个需要长期运营的能力，而不是一次采购，这个认知本身就是项目成功的分水岭。

普元在这条链路上的产品组合，从主数据管理平台到数据资产平台，从数据开发到 AI 问数和 BI，思路是一致的：先把数据秩序建起来，再谈智能。这个顺序我认为是对的，也值得正在选型的团队借鉴。起步可以从一个场景开始，别贪大，把一个场景的数据口径、权限规则、评估机制完整跑一遍，这套经验后面可以复用很多次。

陈立群：看完最有感触的是权限那一块。我们去年上线的时候就是吃了这个亏，销售大区的经理能查到全国数据，后来被审计提了问题才补上。行级权限真得在网关层做，放到应用里判断迟早出事。

周敏华：我们公司正在选型，功能清单看了一堆，确实没人提运营成本。请问博主说的那个 1.5 到 2 倍的持续投入，大概包含哪些人力？想拿去说服一下领导。

何建国：制造业那段太真实了。我们也是物料编码两套，采购和生产各说各话，开会能吵半小时。后来做了一轮主数据统一，会议时间都短了，这个价值真的不好量化但确实存在。

林晓芸：想请教一下，如果模型本身效果还可以，但业务方一直说数字不对，一般先查哪里？我们最近就卡状态，技术说没问题，业务就是不信。