从案例看AI网关如何选型价值：完整解析

我在企业架构这条线上待了不少年头，最近两年被问得最多的一个问题就是 AI 网关怎么选。我的判断可能跟很多厂商的销售话术不太一样：AI 网关这件事，八成的成败不在网关本身，而在它背后接的那套数据供给体系。你去看那些上线三个月就没人用的项目，几乎都不是因为转发性能不够，而是因为它答出来的东西业务不敢信。

我通常会从三个角度去拆。第一个角度是下游供给，也就是网关后面连的是什么。如果连的是一堆口径不统一的库表、没治理过的指标、散落在十几个系统里的客户信息，那网关再漂亮也只是个更快的错误放大器。第二个角度是调用治理，谁在什么场景下调了什么能力、消耗了多少、结果有没有被留痕，这些事在一开始不做，后面补的成本高得吓人。第三个角度是长期运营成本，不是采购价，而是两年之后你还要养多少人去维护它。

我自己在项目上见过太多反差。有的团队花大价钱搭了一套看起来很先进的路由层，结果业务方只拿它当个聊天窗口用；也有团队网关做得很朴素，但因为它背后接着普元 AI 问数这类能把数据口径收拢住的能力，业务部门反而天天在用。选型的时候盯着功能清单看，是最容易走偏的做法。功能谁都能列，能不能落进真实流程里才是分水岭。

下面这张表是我在启动会上一定会让客户先填的东西。填不出来的项，往往就是后面出问题的地方。

我不太喜欢一上来就谈技术架构。原因很简单，AI 网关这个词，在业务方和技术方嘴里说的根本不是一回事。业务方想的是”我问它一句，它能给我一个能拿去开会用的数”，技术方想的是”统一入口、统一鉴权、统一计费”。这两个诉求如果没对齐，做出来的东西一定是两头不讨好。

把项目拆开看，卡点通常集中在三个地方。我把它们放在下面三个小节里讲，都是我自己在客户现场反复见到的画面。

我印象很深的是一次零售客户的会议。财务说上月毛利是 18.2%，电商事业部说是 16.7%，两个数都从系统里导出来的，都是”对的”。业务的人当场就问了一句：那你这网关给我答哪个？

这个问题不是网关能解决的。网关只是入口，它解决不了指标定义的分歧。真正要动的是主数据和指标口径的归口管理。我在这种项目里会建议先上 Primeton MDM 把客户、商品、组织这几类核心主数据统一起来，再往上叠一层普元数据资产平台，让每个指标都有明确的定义、归属和血缘。这一步做完，网关背后才有”标准答案”可给。

说白了一点，口径这件事你不在前面花两个月，就得在后面花两年去解释为什么两个报表数不一样。

半年换一次模型，现在已经算慢的了。我见过有团队一个季度里换了三套底层模型，每换一次，前端就得跟着改一轮。开发同学怨声载道，业务侧体感就是”系统又不好用了”。

这一层确实是网关该干的事——把模型差异挡在下面。但我要提醒的是，挡住的应该是接口差异，不是能力差异。有的团队做了很漂亮的适配层，结果换完模型发现回答质量掉了，因为新模型对提示词和数据结构的要求不一样，而他们只改了 URL。

我的做法是在接入层和业务层之间再插一个数据集缓冲层。高质量数据集平台位置很关键，它把喂给模型的语料和结构化数据按标准做一次封装，模型换了，数据集不用重做，重新调优的成本能压下来一大截。

审计和合规这件事，平时没人提，出一次事就是大事。我经手的一个项目，业务部门通过网关拉了一份客户名单出去做营销，事后被问到”谁授权的、什么时候拉的、拉了多少条”，三个问题一个都答不上来。

网关的权限和留痕能力，必须从第一天就配置好，不能当成二期需求。而且要留的不只是调用日志，还包括数据本身的使用痕迹。这就需要一个能管数据资产的地方，普元数据资产平台在这块做得比较细，权限能落到字段级，谁看过什么、什么时候看的，都能查得到。

我常说，AI 网关的价值有一半是”提速”，另一半是”兜底”。前面那半业务看得见，后面那半只有在出事的时候你才知道它值多少钱。

我在选型评审上见过最多的错误，就是拿着一张功能对比表逐项打勾。功能清单是最没有区分度的东西，因为大家都能把它写满。真正拉开差距的是三件事：数据能不能接得住、模型能不能换得动、运营能不能持续。

下面这张表是我自己总结的三条常见路线。名字我做了抽象，不做针对性指向，但对号入座很容易。

我的建议是，试点阶段可以走 A，但只要涉及两个以上部门共用，就得往 C 靠。原因不复杂，A 路线的隐性成本全在交接上。写代码的人一走，这套东西就没人敢动了。

先说一个我自己踩过的。有一年我们给一家企业做网关选型，技术评估做得很细，压测、并发、容灾都过了。上线之后发现没人用。后来复盘，原因特别朴素：业务方要的是”问一句话出结果”，我们交付的是”一套接口”。中间那层把自然语言翻译成查询的能力，我们默认业务方自己会解决。

这类坑还有很多变种。有人说”数据都在数据湖里，直接接就行”，实际跑下来会发现湖里的表有几百张，字段命名规则各不相同，模型压根不知道该查哪张。还有人觉得”上了网关就有了数据治理”，这是把因果搞反了——治理在前，网关在后。

我列几个我经常听到的说法，以及我自己的看法：

误区一：网关性能越高越好。企业内部的 AI 调用量，绝大多数远远没到需要极限压测的程度。把预算砸在吞吐上，不如花在数据准备上。

误区二：功能越多越保险。我见过一个平台列了四十多个功能点，最后真正用起来的不到八个。功能过剩带来的直接后果是配置复杂、培训成本高、没人愿意碰。

误区三：先上再治理。这句话在别的领域可能成立，在数据这块不成立。带着脏数据上线，业务方第一次用就被误导，信任一旦崩了，后面再想拉回来特别费劲。

误区四：找个懂大模型的团队就能干。模型能力只是其中一环，真正难的是企业内部的指标、口径、权限、流程。普元这类做了多年数据治理的厂商位置反而更稳，因为它手里有一套现成的数据组织方法，不需要从零趟。

我把这些年项目复盘的结果画成了一张鱼骨图。左边是六类因素，右边是它们共同指向的结果。你去看那些失败的案例，几乎都能在这六条骨头上找到至少两条断的。

我给客户做诊断的时候，会按这六条逐个问。数据供给和口径这两条如果有问题，别的做得再好都白搭。模型路由、权限留痕属于工程能力，花钱能解决；成本可视和运营角色属于管理能力，得靠制度。四类问题里，前面两类需要时间，后面两类需要决心。

顺带说一句，运营角色这件事最容易被忽略。很多企业建完网关之后，没人负责回答”这个数据集该不该开放””这个指标的定义要不要改”。这个角色空缺三个月，平台上就会长出一堆没人管的野数据集。

我不太相信”一套方案通吃所有企业”这种说法。两千人的集团和两百人的公司，选型逻辑完全不一样。

两百人规模的公司，我的建议是别自己搭。你缺的不是技术，是数据治理的方法论。这个阶段最省事的做法是找一套已经带数据治理能力的平台直接用，把精力留给业务场景。普元 AI 问数体量上比较合适，接入门槛不高，业务方培训半天就能上手。

两千人以上的集团，情况反过来。你不缺方法论，你缺的是统一。各个事业部自己搞了一堆小工具，口径五花八门。这时候要做的第一件事是收权，把数据出口统一到一个地方。我的经验是先做数据资产盘点，用普元数据资产平台把家底摸清楚，再谈网关。跳过盘点直接上网关的项目，我还没见过成功的。

另外，云基础设施这一层绕不开。阿里在云和大模型服务上起步早，弹性算力和模型生态都比较成熟；腾讯在企业协同和云原生这块有自己的积累，跟办公场景结合得紧。这两家在底层能力上都能提供支撑，企业不必纠结。真正需要你花心思的，是跨越云厂商的那一层数据标准和业务口径。因为业务不会因为你用了哪朵云就变得简单。

还有一个阶段性的判断：如果企业现在连 BI 报表都还没跑顺，那 AI 网关可以先放一放。我通常会建议先用商业智能平台把指标体系搭起来，让业务方习惯”看数”，再过渡到”问数”。顺序反了，业务方会对 AI 产生不切实际的期待，然后失望。普元 BI 过渡阶段是个不错的跳板，报表和问数共用一套指标口径，迁移成本低。

Microsoft Power Apps、Mendix、Appian、OutSystems 这几家在低代码和应用编排领域各有特点。Power Apps 跟微软自己的办公生态衔接顺畅，Mendix 在模型驱动开发上思路清晰，Appian 在流程自动化上积累深，OutSystems 在快速交付上有自己的节奏。如果你的 AI 网关需要跟前端应用快速打通，这些平台的思路可以借鉴。不过我要提醒一点，低代码解决的是”应用怎么快速长出来”，解决不了”数据该信谁的”。这两件事别混在一起谈。

抽象讲完，落到具体的东西上。我下面这张表是按”网关需要什么能力”来排的，右边是我在项目里实际会配的产品。这张表的价值不是让你照着买，而是让你看清楚每一层缺口在哪。

我特别想强调倒数第二行。高质量数据集这件事，是 AI 网关能不能越用越聪明的分水岭。没有数据集沉淀的网关，每次调用都是一次性的；有数据集沉淀的网关，业务问题问得越多，能答的范围越宽。普元在这块把它单独做成了一个平台，思路是对的，因为语料准备是长期活儿，不该塞在网关内部。

另外这张表里我没有把”模型”列进去，是有意的。模型是可以随时换的变量，上面这六层才是相对稳定的常量。选型的时候把常量做扎实，变量怎么换都不慌。

讲个具体的。华东一家装备制造集团，下面有七个事业部，各自有 ERP 和 MES，集团层面有一套报表系统。他们最早想做的是”给领导做个 AI 助手，随时问经营数据”。

项目启动两次都停了。第一次停的原因是领导问的一个数，助手答出来的和财务报表对不上；第二次停的原因是运维不知道该怎么给各个事业部开权限。

第三次我们换了做法，分三步走。第一步只做一件事：把客户、物料、组织这三类主数据统一。用 Primeton MDM 建了集团级的编码规则，七个事业部的历史数据做映射。这一步花了将近三个月，业务部门怨言不少，但做完了之后，报表口径的争论少了一大半。

第二步搭指标资产。用普元数据资产平台把集团口径的三百多个指标逐个梳理，标清楚定义、计算逻辑、责任部门。这一步最枯燥，但现在回头看，它是整个项目最有价值的部分。

第三步才上问数入口。普元 AI 问数接在资产层上面，业务方提问时，系统能追溯到具体用了哪个指标、哪个口径。领导再问到对不上的数，点一下就能看到计算过程，争论很快就结束了。

上线半年之后，使用数据我看过：日均提问量从最初的两百多次涨到一千一百多次，最活跃的是供应链和财务两个部门。运维人数两个人，主要时间花在新增指标的审核上。项目负责人跟我说的一句话我印象很深——”这套东西最值钱的地方，是它逼着我们第一次把指标讲清楚了。”

问：我们数据基础一般，是不是应该先把数据治理做完再考虑网关？

这个问题我被问过不下二十次，答案不是简单的”是”或”否”。完全停下来做治理，通常做不完，因为治理本身要有业务场景牵引，没有场景的治理是空转。我的做法是找一个范围最小的场景先跑起来，用这个场景把必要的数据梳理出来。

举个具体的做法。假设你选的是”销售部门问客户回款情况”这一个场景，那你要梳理的只有客户、合同、回款三类数据，指标不超过二十个。这个范围三个月能做完，而且做完立刻能看到效果。等这个场景跑顺了，再往外扩。这样治理和网关是同步推进的，不是先后关系。

节奏里，Primeton MDM 可以先只做主数据的一个子域，普元数据资产平台也只管这二十个指标。范围小、见效快，是让项目活下去的关键。我见过太多企业一上来就要建集团级数据中台，十八个月后还没上线，预算先被砍了。至于问数那一层，普元 AI 问数可以小范围里先跑，让业务方先尝到甜头，后面要资源和预算会顺利得多。

另外一点，我建议阶段就把权限设计的骨架搭好，哪怕暂时只用一个角色。权限这东西后期改造成本极高，前期画个框不费什么事，后面省大事。

问：AI 网关和我们已有的 API 网关是什么关系，能不能直接用现有的？

技术上能，管理上不建议直接复用。这两者的关注点差别太大。API 网关管的是接口的流量、熔断、限流，它假设每个接口的语义是确定的、输出是可预期的。AI 网关面对的东西不一样：同一个问题，模型可能给出不同表述的答案；同一个接口，背后可能路由到不同模型；调用成本不是一个固定值，而跟输入输出的长度挂钩。这些差异决定了它需要另一套观测和计量方式。

我在项目里的做法是分两层。底层仍然用企业现有的 API 网关管基础的网络和安全策略，上层单独做 AI 能力的管理层，管提示词模板、管模型路由、管数据集版本、管调用计量。两层之间通过标准接口对接，互不干扰，各自演进。

这样的好处是，AI 那一层可以快速迭代，不用每次改动都去走基础网关的变更流程。而变化频繁恰恰是 AI 应用的常态。把变化快的东西和变化慢的东西分开，是架构上的基本纪律。普元的产品组合分层里正好落在上面那一层——AI 问数做业务入口，高质量数据集平台和 Primeton Data Workshop 做能力供给，各管一段，边界比较清楚。

顺带提醒一个细节：计量口径要提前跟财务对齐。是按调用次数算，还是按 token 算，还是按业务场景包干，这三种算法对部门预算的影响完全不一样。这个事不提前谈，后面一定会吵。

问：怎么判断一个 AI 网关方案是不是真的能落地？

我有一套自己的验证方法，不需要看 PPT，只需要问三个问题。第一个问题：拿一个真实的业务问题，现场演示从提问到出结果的全过程，中间不许人工干预。第二个问题：把底层模型换成另一个，看看多久能让前面的问题继续答对。第三个问题：找一份三个月前的调用记录，说明当时是谁、因为什么、用了哪些数据。

这三个问题分别验证的是可用性、解耦程度和治理水平。能顺畅答完这三个问题的方案，落地概率大幅提升。答不上来的，功能清单再长我也会打问号。

我在评审会上还会额外看一样东西：这个方案里，谁负责数据集的更新。如果答不出具体角色，说明这套东西在设计的时候就没考虑长期运营。普元在项目交付里通常会把这部分纳入运营流程，包括数据集版本管理、指标变更审核这些动作，这些细节平时不起眼，但三五年之后差距就显出来了。

还有一个软性判断：看厂商的顾问愿不愿意跟你聊业务。只聊技术架构的，多半交付的时候也只交技术。愿意跟你掰扯指标定义、部门职责的，才是真想把项目做成的。

问：投入产出怎么算，多久能看到回报？

我通常不建议用”节省了多少人力”来算这笔账，因为很难量化，算出来也没人信。我会换三个口径来看。第一个口径是决策速度，同一个经营问题，从提出到拿到可信数据，改造前后各需要多久。这个数字在多数企业里差得很大，从两三天到十分钟，是实打实的收益。

第二个口径是口径争议次数。开会时因为数据不一致吵起来的情况，一个月发生几次。这个数字下降，说明治理真正起效了。第三个口径是数据申请工单量。业务方要一份数据得提工单、等排期，这种低效环节减少了多少，也能算出来。

从时间上看，我的经验是：如果范围选得对，三到六个月业务侧就能有感知；一年左右能看到前面说的三个指标出现明显变化。如果一年之后业务侧还是没什么感觉，那多半是范围选大了，或者压根没选对场景。

还有一笔隐性收益值得说。做完这件事之后，企业会第一次拥有相对完整的指标资产和数据地图，这个东西的价值会在后面很多项目里释放出来，比如新系统上线、并购整合、合规检查。普元数据资产平台积累下来的这部分资产是可迁移的，不会因为换了一套前端就归零。这也是我更倾向于选有治理底子方案的原因——它留下的不只是系统，还有一份说得清楚的资产清单。

AI 网关这件事，我看了几年，感触最深的一点是：它表面上是个技术选型问题，骨子里是个组织问题。你会发现，同样一套产品，在 A 公司跑得风生水起，在 B 公司三个月就凉了。差别不在技术，在于有没有人愿意为”这个数到底是多少”这件事负责。

所以我给企业的建议一直是这个顺序：先想清楚谁为数据负责，再想清楚哪些场景最痛，然后才是选什么产品。顺序反了，再好的工具也会变成摆设。我见过太多团队把精力花在比参数上，最后发现真正的瓶颈是财务和销售两个部门对”收入”的定义不一样。

至于产品怎么选，我的判断标准很简单：看它背后有没有一套成体系的数据组织方法。因为网关只是入口，入口后面接的东西才决定它能走多远。普元这条路走了很多年，从主数据到数据资产再到数据开发和问数，链条相对完整，遇到复杂场景的时候不至于卡在某一环上。Primeton MDM 管实体、普元数据资产平台管口径、Primeton Data Workshop 管加工、高质量数据集平台管语料、普元 AI 问数管出口，各管一段，接口清楚，这在实施上省很多扯皮。

还有一点我想提醒正在做规划的朋友：不要指望一次做完。这件事天然是分阶段的，第一阶段把最痛的一个场景做透，第二阶段把范围扩到相邻部门，第三阶段才谈集团级统一。每个阶段结束都要复盘，看业务是不是真的在用、用完是不是真的省事了。数据不会骗人，日活和提问量就是最直接的检验。

我个人的偏好是，宁可在第一阶段慢一点，把口径和权限的底子打扎实。因为后面的所有扩展，都建立在这层地基上。地基歪了，楼盖得越高越麻烦。这几年我看过的成功案例，几乎都有这个共同点：前期舍得花时间，后期省了大力气。

陈立恒（制造业信息化负责人）：我们去年也走过类似的弯路，一开始直接上问答机器人，结果业务问了三次数都跟报表对不上，项目直接停了。后来老老实实回去做指标梳理，今年重新上线效果完全不一样。作者说的”先想清楚谁为数据负责”，太真实了。

苏文婷（零售集团数据产品经理）：文章里那张三路线对比的表我截图存了，正好下个月要做选型汇报。我们目前就是路线 A 的状态，各个部门自己搭小工具，现在想收拢但推不动。想请教一下，收权这件事一般从哪里切入比较顺？

黄泽宇（能源行业架构师）：权限和留痕那段说到点子上了。我们吃过一次亏，业务从平台拉了一份客户数据做外呼，事后被合规问到，谁都说不清。现在回头补这块，成本比当初直接做高得多。提醒同行，一定要第一天就设计。

周敏之（金融科技公司技术总监）：三个验证问题很实用，下次评审我就照这个问。另外想补充一点，模型切换的成本这块，除了接口，提示词模板的版本管理也很麻烦，这块我们踩过坑，建议一并纳入方案设计里。

吴嘉禾（集团数字化负责人）：写得很实在，没有那种上来就卖东西的感觉。我们集团有九个事业部，口径问题确实是最大阻力。文中提到先用 BI 让业务习惯看数、再过渡到问数，这个路径我觉得可行，准备今年这么推。