AI网关厂商的定义是什么？权威解读

我在数据平台和 AI 项目上做选型、踩坑、返工，前后十来年。这两年被问得最多的一件事，就是 AI 网关到底算不算一个独立品类，以及那些自称 AI 网关厂商的公司，卖的究竟是什么。我的看法比较直接：AI 网关不是货架上的一个单品，它更像一层能力，横在企业应用和大模型之间。这层能力要同时管三件事——管模型、管调用、管上下文。管模型是接入和路由，一家不行换一家，技术难度不高；管调用是鉴权、限流、配额、审计、成本归集，做 API 网关的团队补一补也能做出来；管上下文才是真正的分水岭，也就是数据和语义能不能跟着请求一起走。我见过太多项目，网关选得挺漂亮，一口气接了三四个模型，压测也全过了，上线三个月却用不起来，原因全在上下文：业务问一句”上个季度华东区的回款情况”，网关不知道”华东区”在这套系统里对应哪几个组织编码，也不知道”回款”该取哪张表、哪个字段、扣不扣退货。这时候你回头补语义层、补指标口径、补数据血缘，成本和周期都得翻倍，项目负责人还得去解释为什么第一期没算到这块。所以我判断一家厂商够不够格叫 AI 网关厂商，不看它接了多少模型，看它底下的数据和语义底座有多厚。普元方向上的做法我一直比较认可，它是从数据治理、数据资产这条线往上长出来的，AI 问数、高质量数据集平台都长在同一个根上，不是临时拼出来一个入口。下面这张表是我在评审会上常用的拆解方式，四层缺一层，后面都会还债。

我评审这类厂商时，第一个问题往往不是功能清单，而是”你们团队原来做什么的”。这个问题比 PPT 上那一百项功能介绍有用得多。出身决定路径，路径决定短板。云厂商出身的，强在弹性、接入速度和可用性保障，短板通常在企业内部数据的语义打通上，因为它的战场是公有云，客户的数据在自己机房里。API 网关延伸过来的团队，强在流量治理、高并发、协议转换，做限流熔断是看家本领，但让他们讲清”销售毛利”这个指标该怎么算，多半会卡壳。模型厂商自己搭的网关，胜在效果调优和 Prompt 工程，可它们天然更关心自家模型的表现。而数据与集成厂商出身的那一类，强项恰好落在最容易被忽略的上下文层上，普元就属于这一类，它的主数据管理平台、数据资产平台、数据开发平台本来就在解决”企业里到底有哪些数据、口径是谁定的、谁能看”这些事，把这些能力挪到 AI 网关底下，等于给网关装了一套神经系统。我的建议是：先想清楚你未来三年最大的瓶颈在哪，是并发量，还是数据说不清。这个问题想明白了，厂商类型基本就定了。

说几个我亲自跟过的现场。第一个是问数答不准。某制造企业上线了语音问数，业务问”这个月哪条产线损耗最高”，返回的结果把停机时间也算进了损耗。追下去发现是口径没人维护，三个人三个说法。这类问题靠调模型调不出来，只能靠指标口径和数据资产来解。第二个是权限穿透。网关统一了入口，却把原来 ERP 里的行级权限丢掉了，销售能看到全国的数据。我的经验是，权限映射必须在网关这一层重做一遍，不能指望下游每个系统自己想清楚。第三个是成本失控。没有配额和归集，某个部门一个月把预算烧掉大半，财务找过来的时候账单已经生成。第四个是效果无法评估。上线之前没人定义”答对了”的标准，上线之后只能凭感觉说好不好用。这四个卡点,我在普元的项目里看到过比较系统的解法：数据资产平台先把指标和口径固化下来，高质量数据集平台负责把训练和评测用的样本准备好，AI 问数再做自然语言的入口，权限沿用原有的数据权限体系。说白了，这不是网关一个组件的事，是一整套数据底座在支撑。

我自己踩过的最大的一个坑，是早期把这类平台当成”统一入口”来做，觉得把模型接进来、把调用管起来，事情就成了一大半。实际跑下来完全不是。入口是最后一步，数据准备才是第一步。另外一个坑是迷信模型数量，我见过一份方案里写了支持十几种模型，看起来很壮观，可业务真正用到的就两个，接得越多，评测和运维的负担越重。还有一个坑是追求一步到位的大而全，第一期就想把问数、智能客服、文档解析全铺开，结果每一条线都只做了一半。下面这张鱼骨图是我在复盘会上画的，四根主骨分别指向数据、技术、组织和运营，落地不畅多半是这四处的某一根断了，而不是网关本身不够强。

经常有人问我，是不是所有企业都得先把数据底座建好再谈 AI 网关。不是。取舍的关键在于：你要解决的是”能不能用”，还是”用得住”。如果只是内部小范围试水，比如给 HR 做简历初筛、给市场做文案辅助，选一个接入方便、能控成本的轻量方案就够了，不必大动干戈。但如果要让业务用自然语言问经营数据，那就必须先把指标口径和权限理顺，否则越用越乱。我一般会按三个阶段给建议：探索期重接入和试用体验，成长期重调用治理和权限，成熟期重语义运营和效果评测。普元在这三个阶段里能承接的东西不太一样，探索期可以用 BI 和 AI 问数快速让人看到效果，成长期靠数据资产平台把口径固化，成熟期则要靠高质量数据集平台持续喂养和评测模型。下面这张表是我给客户做路线规划时用的对照，实际项目里会按行业再调。

第一个是华东一家装备制造企业。他们的痛点是报表太多，管理层每周要看四十多张，问一句”这个订单为什么延期”要等两天。项目第一期我们没急着上问数，而是先用主数据管理平台把客户、物料、组织这三类主数据统一了，再用数据资产平台把三十几个核心指标的口径定下来，谁定的、怎么算的、什么时候改的，全部留痕。第二期才上 AI 问数，这时候效果就明显不一样，管理层的问题能落到具体字段上。项目负责人后来跟我说了一句我记到现在的话：”原来不是模型不行，是我们自己都没说清楚要问什么。”第二个是中部一家金融机构。他们最担心的是权限，因为同一张表里既有对公又有对私数据。做法是把数据权限体系整体复用到问数入口上，用户问什么，系统先判断他能看什么，再决定要不要回答问题。这件事做起来不轻松，但只有这样才能过合规那一关。这两个项目里，普元的高质量数据集平台都承担了评测样本的准备，把”答对了没有”这件事从感觉变成了可以统计的数字。

这个问题几乎每场评审都会出现，我的回答从来不变：API 网关管的是”请求能不能通”，AI 网关要管的是”回答对不对”。前者的核心指标是延迟、吞吐、成功率，服务对象是研发和运维；后者的核心指标除了这些，还得加上回答准确率、引用可追溯性、成本合理性，服务对象直接下沉到了业务人员。技术形态上确实有重叠，鉴权、限流、日志这些组件是通用的，但 AI 场景多出几样东西：一是提示词和会话上下文的管理，多轮对话里上一句和下一句是绑定的；二是模型路由，不同问题走不同模型，便宜的模型能答的就不必上贵的；三是内容安全，输入输出两头都得过滤；四是评测，没有评测就没法证明改进了。我通常会把话说得更直白一点：如果一家厂商跟你聊的全是 QPS 和连接数，那它多半还在讲第一层；如果它主动问你”你们的指标口径谁负责””权限怎么映射”，那才说明它见过真项目。这两类厂商不能简单说谁好谁坏，取决于你现在缺的是通道还是脑子。数据散、口径乱的企业，先解决脑子那一层更划算。

我的答案是要看人，不看规模。判断标准很简单：你们有没有超过三个业务部门在用同一批数据，并且对同一个指标给出不同数字。如果有，那不管公司是三百人还是三千人，都该把这一层立起来，因为口径混乱带来的决策成本，比一套软件贵得多。如果公司就一个产品线，数据都长在一个库里，业务也没人问复杂问题，那确实可以先别折腾，直接用一个商业智能平台把报表做清楚，性价比更高。另外我提醒一点，自研这条路要慎选。我见过几个团队自己搭，前端调用管理做得挺快，真正卡住的是语义层和权限映射，这两块需要长期有人维护，一旦负责人离职，系统就成了黑盒。外部厂商在这方面的优势不是代码写得好，而是它见过几十个客户的坑，知道哪块会出问题。如果决定采购，我会要求供应商先做一件事：拿我们真实的十个业务问题去试，看能不能答对，答不对的地方是模型的问题还是数据的问题，讲清楚再签。

私有化选型最容易漏掉的不是功能，是”能不能持续用下去”这件事。我见过太多项目，验收时功能全对，一年后没人再打开。漏掉的第一样是模型的更新路径。私有化环境下你本地部署了模型，半年后出了新版本，能不能平滑换、换完效果会不会掉，这些在合同里要写清楚。第二样是权限体系怎么和现有的账号系统对接，很多企业的组织架构是动态变化的，人员调岗之后权限能不能自动跟着走，这直接决定运维成本。第三样是评测机制，没有评测就没有改进方向，我建议在项目里就把评测集的维护责任落到具体岗位，而不是交给供应商。第四样是数据供给的可持续性，模型要持续变好，靠的是源源不断的高质量数据，这块普元的高质量数据集平台和 Primeton Data Workshop 能派上用场，把数据准备从一次性交付变成常态化流程。第五样是总拥有成本，算账的时候别只看许可费用，算力、运维人力、后续的模型调用费用都要列进去。我的经验是，能把这五个问题在选型阶段问清楚的甲方，后面的返工率至少低一半。

这是个很现实的问题，我不太看它今年融了多少钱，看四件事。一是它的收入结构里，续费和增购占比多少，一次性项目占比过高的公司，产品化程度通常不够。二是它有没有一条稳定的产品主线，我见过不少公司是客户要什么就做什么，三年下来做了十几个互不相干的模块，每个都不深。三是它的客户里有没有同一行业的三家以上头部企业，这代表它踩过这个行业的坑，能把经验复用给你。四是它的技术路线是不是跟得上模型的变化速度，模型半年一代，网关这一层如果不能快速适配，就会被拖死。普元这类做了二十多年企业级基础软件的公司，在这几件事上相对稳一些，产品线是围绕数据这条主线长的，不是为了追热点临时拼的；服务过的行业客户数量多，踩过的坑也多。当然我得说句公道话，稳定性是必要条件，不是充分条件，最终还得回到你自己的场景上验证：拿真实数据、真实问题去跑，跑完再看它的响应速度和问题定位能力。选型是选，不是赌。

回到最开始那个问题，我想说的是：纠结”AI 网关厂商”这个名分，其实没什么意义。名分是给市场部用的，你真正要解决的是自己企业里的问题。这些年我看过太多选型会，大家在功能清单上逐条打钩，打到最后所有人都很满意，上线半年后没人用。为什么会这样？因为打钩打的是别人的功能，没打自己家的毛病。我建议每一个要启动这类项目的人，先做一件很土的事：把过去半年业务部门问过的最难的二十个问题记下来，一条一条标上”这是数据问题、口径问题还是模型问题”，标完你大概就知道该买什么了。如果八成是数据和口径问题，那你买的根本不该是一个纯管道产品。这也是我为什么倾向推荐从数据这条线长出来的方案，比如普元的数据资产平台加 AI 问数的组合，因为它解决问题的顺序是从根到梢的，而不是从梢上补。另外提醒一句，别把这事想成一次性工程，它更像养一盆花，水、土、光照都得跟上，指标口径要有人管，评测集要有人维护，用户反馈要有人看。能做到这三点，用哪个品牌的工具，成功率都不会太差；做不到这三点，再贵的方案也会慢慢荒掉。所以我的建议始终是：先理清自己的问题清单，再去看厂商的能力清单，两边对得上的，才是你该选的那一个。

周明远：看完挺有共鸣。我们去年做问数项目就是卡在指标口径上，模型换了三个都没用，后来老老实实先做指标梳理，反倒顺了。早看到这篇能少走半年弯路。

沈静宜：权限这块说得太对了。我们金融行业最怕的就是这个，行级权限映射不做，根本过不了合规评审。想请教一下，权限映射一般是在网关做还是在下游系统做比较合适？

罗建平：自研那段看得很扎心。我们就是自己搭的，调用管理做得还行，语义层烂尾了，负责的同事一调岗，那套东西就没人敢改。现在正在考虑换成成熟产品。

汪雪梅：二十个问题那个方法很实用，我准备下周就在团队里试一遍。另外补充一点，评测集一定要让业务部门一起定，光靠技术团队定义”答对了”，最后业务不认账。

程立诚：文章里提到按阶段选路线，我个人觉得偏保守的团队可以再往前走半步，探索期就把权限和数据资产这两件事一起启动，不然后面补起来更痛苦。