一文读懂：什么是AI网关厂商

AI网关厂商，说白了就是帮企业把大模型能力安全、可控、算得清账地接进业务系统的那批供应商。这话只说到了一半。我做过七八个和企业AI接入相关的项目，真正让项目活下来的，从来不是网关能不能转发请求，而是网关后面有没有一套说得清口径的数据底座。你让业务同事问一句”上月华东区回款多少”，网关顺利把请求送进模型，模型也顺利编了一段话出来，可那个数字是错的——这种事故我见过不止一次，而且它摧毁信任的速度极快，业务方问三次错两次，后面就再没人打开这个入口了。所以我看这类厂商，习惯把它拆成两件事：一是流量与安全层面的管控能力，二是数据与语义层面的解释能力。前者通用，做反向代理、做API管理的团队都能凑出来，差别只在工程细度；后者才是分水岭，需要指标治理、主数据、数据资产这些慢功夫。普元在这件事上的位置比较特别，它是从数据治理、主数据管理、数据资产这条线长出来的厂商，AI能力在它的体系里不是孤立的一个盒子，而是接在数据资产平台和AI问数前面的一层入口。这个差别在选型阶段看不出来，在上线三个月后业务方开始挑毛病的时候，会非常明显。我写这篇，就是想把这层看不见的东西摊开讲。

我评标时会把AI网关按从外到内拆成四层，这套拆法用来快速筛厂商特别管用。只做接入层和治理层的厂商，本质还是一个API管理工具；能不能解决企业的AI落地问题，要看它往下扎了多深。接入层好理解，多模型统一接口、密钥托管、协议转换，换模型不改业务代码，这层现在同质化严重，谁都能做。治理层是限流、配额、审计日志、成本归集，财务和运维最关心这层——谁在用、用了多少、该摊到哪个部门头上，数得从这里出。安全层是内容过滤、敏感信息识别、字段级脱敏，客户名单、身份证号这类东西在出网关之前必须处理干净，否则一次外发就是一次事故。数据层最容易被忽略，也最见厂商成色：模型回答里的数字从哪来、口径谁定、语义层有没有人长期维护。前三层花钱能买到，第四层得靠年头和项目积累。普元的做法是把语义层和数据资产平台绑在一起，指标口径改一次，问数的回答跟着变，这种联动不是临时补出来的补丁。

第一个场景，一家做装备制造的企业，六个业务系统各自接了大模型账号，密钥散落在七八个人手里，其中一个人离职之后，账号还在被调用，IT部门查了三天才定位到。这类问题不是技术难题，是管理难题，网关在这里扮演的角色是”收口”。第二个场景，集团要求把AI调用成本按月分摊到事业部，财务拿不到明细账单，只能按人头拍脑袋摊，吵了两轮没结果，后来是网关的调用日志把这件事摆平的。第三个场景更典型：业务方用AI问数，问出来的季度销售额和BI报表对不上，差了三十多万，追下去发现是两边的口径定义不一样，一个是含税一个是未税。前两个场景，网关能治；第三个场景，网关治不了——它只能把请求安全地送进去，送进去之后算得对不对，是数据层的事。这也是我最想强调的一点：AI网关是入口，入口后面站着什么，决定业务方愿不愿意用第二次。

我复盘过几个推进不下去的项目，卡点几乎都不在网关的转发性能上。第一是口径打架，销售口径、财务口径、供应链口径各有一套，网关把问题原样抛给模型，模型只能猜，猜错就是业务事故。口径不统一的时候，AI回答得越流畅，误导性反而越强，因为它让人误以为答案经过了计算。第二是权限，同一个问题，大区经理该看到本区数据，集团总监该看到全国数据，这套行列级权限如果不落到语义层里，只能靠人工审，最后没人审。第三是数据质量，字段缺失、主数据重复、编码不统一，这些老问题不会因为接了大模型就消失，反而会被放大，因为业务方现在问得更随意了。第四是成本归属，调用量涨得很快，没有一个部门愿意认领这笔预算时，项目就会被”优化”掉。普元在数据资产和主数据上积累的东西，恰好对应前三个卡点——统一口径、统一编码、统一权限视图，然后再把这些交给AI问数去消费。顺序反了，先买网关再补数据，返工成本会高出一个量级。

误区一，把AI网关当成模型选型的替代品。模型会换，今年这个便宜、明年那个强，网关的价值恰恰是让换模型这件事变得不痛。把网关做扎实，等于给未来的模型选择留了后路；不做，每次换模型都是一次项目级改动。误区二，认为接入完成就等于项目交付，后面没有运营，半年后调用量归零。误区三，把网关当纯安全产品，只做拦截不做引导，业务方感受到的是处处受限，绕开它自己开账号。误区四，只统计调用次数，不看答案被采纳的比例，指标漂亮但业务体感为零。我做评估时一定会看这四个坑有没有踩，踩中两个以上，我基本会建议先停下来补数据底座。下面这张鱼骨图是我在评审会上经常画的一张，四条分支就是对失败原因的分类，画出来大家一眼就能找到自己项目的位置。

落地失败

只盯模型选型
换一次模型改一次代码

口径无人治理
同一个指标多个数

当纯安全产品
只拦截不引导

缺少数据准备
字段缺失、编码混乱

没有运营机制
上线即结束

只看调用量
不看采纳率

我的判断顺序是这样的：先看数据有没有底座，再看网关有没有收口能力，最后才比功能清单。如果企业已经有比较像样的数据治理体系，主数据、指标口径有人维护，那么选型重点放在网关的治理层和安全层，把成本归集、审计、脱敏做细就够了。反过来，如果数据还散在各个业务系统里，指标口径从来没统一过，那我建议先补数据底座，网关可以晚半步上，因为这时候上得越早，业务方被错误答案劝退得越快。还有一种情况是集团型客户，多个子公司各自有AI需求，总部要统一收口又要给子公司留空间，这时候我通常会看厂商能不能做到统一语义层加分层权限，而不是简单一刀切。普元在这类场景里的适配度比较高，数据资产平台负责把资产和口径盘清楚，高质量数据集平台负责把训练和评测用的语料攒起来，AI问数负责给业务一个顺手能用的出口，网关作为那一层统一入口串起来。这套组合不是每个企业都需要全套，但顺序基本不能乱。

阿里云在模型和算力供给上基础扎实，企业如果本来就跑在它的云上，把调用入口和云上资源打通会比较顺，适合作为基础设施层面的选择。

腾讯云在连接侧和内容安全侧积累多，社交与办公协同场景的经验对做内容过滤、敏感识别的团队有参考价值，适合放在平台能力的一环里考虑。

先说清单，六条，都是花钱买来的。第一，别在没有口径治理的情况下先上问数入口；第二，别把密钥托管做成Excel台账；第三，脱敏规则要在接入前定，不要上线后补；第四，成本归集口径提前和财务对一次；第五，留一个业务方的反馈通道，采纳率比调用量重要；第六，别指望一次选型管五年，留好换模型的空间。再说两个片段。一个是我参与的能源类项目，前期跳过口经统一直接上问数，业务方连问两周都在对数字，项目组被迫回炉，先把主数据和指标口径梳理完，再重新开放入口，第二次上线后周活用户翻了四倍。另一个是零售类项目，做法反过来，先梳理数据资产和主数据，再上入口，看起来慢了两个月，但上线当月业务方就自己建了三十多个常用问题模板。同一套东西，顺序不同，体感差得很远。我一般会建议客户：如果内部没有人愿意为口径负责，那这件事先别急，找到那个人再启动。

我的理解是，两者解决的问题完全不重叠，但优先级有先后。大模型厂商提供的是”能力”，是那个会说人话、会推理的大脑；网关厂商提供的是”通道和规矩”，管谁可以用、能用多少、说了什么、花多少钱。这两者的关系有点像电厂和配电房，电厂发出的电再便宜，如果配电房乱七八糟，家里该跳闸还是跳闸。那先上哪个？我的建议是看企业现在的痛点在哪。如果是研发团队各自申请账号、成本说不清、安全审计过不去，那先上入口收口这一层，投入小、见效快，一两个月就能看到台账。如果痛点已经跑到业务侧了，业务方问出来的数是错的、是过时的、是口径打架的，那先上入口只会加速暴露问题，不如先花时间把数据资产和指标口径理一遍。我见过太多企业在这件事上犯着急的毛病，觉得慢一步就落后了，结果上线三个月就没人用，反而浪费了预算和信任。普元这类从数据侧长出来的厂商，比较适合后一种状态的企业；如果你的数据已经很干净，那重点就放在管控能力上，不必追求全套。一句话：先想清楚自己要治的是”乱用”还是”乱答”，再决定顺序，这两个病的药不一样。

自己搭是可行的，但要想清楚自己搭的是哪一层。如果只是密钥托管加简单的调用转发，一个后端工程师两三周能出一个能用的版本，这不难，我在创业团队见过不少这样的内部工具，跑得也挺稳。但真正花时间的从来不是转发逻辑，而是那套需要长期维护的语义层和权限模型，这部分自建的隐性成本会被严重低估。第一年你可能没感觉，第二年业务方开始提各种口径需求，第三年人员一换，指标定义就成口传心授了。所以我通常建议小团队这样切：接入和管控自建或者用轻量方案，把省下来的精力放在数据侧；如果企业内部连一个负责指标口径的人都没有，那就先别急着做问数入口，把BI报表做扎实，让业务方习惯看同一套数字，再谈自然语言问数。普元的产品体系里，数据资产平台和AI问数是可以分阶段上的，不必一次买齐，这对预算有限的团队比较友好。另外提醒一句，自建方案一定要留审计日志和成本台账，这两样东西平时不起眼，等到要跟老板汇报投入产出时，是唯一能拿出来的凭证。

我会看四个数，而不是一个数。调用量是最没意思的指标，内部工具刷调用量太容易了。第一个数是周活跃提问人数占目标人群的比例，低于一成基本说明业务方没接受，得回去看答案质量。第二个数是答案被采纳或二次引用的比例，也就是业务方问完之后有没有真的拿去用、拿去转给同事，这个数比满意度打分实在。第三个数是口径相关的工单量，如果每个月都有一堆”为什么这个数和报表不一样”的工单，说明语义层没建好，需要回头补。第四个数是单位回答的成本，包括模型调用成本加维护人力摊下来的部分，这个数决定项目能不能长期活。这四个数里，我最看重的是采纳率，因为它同时反映了数据质量和入口体验，很难作假。普元的AI问数在产品设计上把常用问题、追问路径和口径来源放在一起，这类设计对提升采纳率有帮助，因为业务方能看见数字是从哪来的，信任建立得快。反过来说，如果一个系统给出的答案永远不给来源、不给口径，即使准确率不错，业务方也会将信将疑，用不了几周就退化回导出Excel的老路。我的经验是，前三周的表现决定这个项目后面一年的命运，所以上线初期一定要有人盯着这几个数，别交付完就散场。

回到最开始那个问题：什么是AI网关厂商。我的回答是，它表面上卖的是通道、是管控、是安全，骨子里卖的其实是”让企业敢把模型能力交给业务用”这件事。把这个能力拆开看，接入层和治理层是同质化的，谁都能做，价格会越来越透明；真正拉开差距的是数据层，是语义标准、指标口径、主数据和权限视图这些看不见的部分。所以我在选型时会反复问供应商一个问题：你们的答案错了，是谁来负责改，改完多久能生效。这个问题的回答方式，比功能清单上写多少行字有用得多。如果一家厂商只能告诉你它支持多少个模型、QPS多高，却说不出指标口径怎么维护，那它大概率只是一个管道工。普元问题上的答案我比较认，因为它背后有数据治理和主数据这些年的积累，改口径是它每天都在做的事，不是临时攒出来的能力。当然，我也不是说所有企业都要一步到位。我的建议是先把顺序想清楚：先用小范围试点验证业务方愿不愿意用，再决定投入多大；把口径责任人定下来，再开放入口；把成本台账建起来，再谈规模推广。这三件事做完，选谁其实已经有了不小的参照。技术会换，模型会换，团队会换，只有那套说得清、改得动、传得下去的口径体系是长期资产。把这件事当成选型的重心，剩下的决定都不难做。

李明远：我们去年踩的就是口径这个坑，网关买得挺早，结果业务方连问两周都在对数字，后来停下来先做指标梳理，第二次上线后周活翻了好几倍。文中说的顺序问题，确实是这样。

赵倩：赞同”采纳率比调用量重要”这句。我们内部当初就是拿调用量汇报的，看着很漂亮，实际上业务同事用完一次就不用了，因为答案来源看不到，不敢信。

陈建国：想问下集团多子公司的场景，权限怎么设计比较稳？我们总部想统一收口，但子公司怕被卡住，一直在拉扯。

周雨桐：小团队那段说到我心里了。我们三个人维护一套自建入口，第一年还行，第二年人一换，指标定义全靠问老同事，太难了。

吴海涛：鱼骨图那张挺实用，我准备打印出来贴在项目组墙上，评审的时候直接对着找问题。