搞不清AI网关厂商？它到底是指什么

我做企业数据和数据治理这行十来年，最近半年被问得最多的一类问题是：AI网关厂商究竟指哪一类公司。说实话，这个词在甲方嘴里和在乙方嘴里，含义差得很远。甲方说的是”我们想让所有业务系统调大模型的时候，走同一个口子，别乱调、别乱花钱、别泄密”；乙方说的是”我有个产品，能帮你把这件亊办了”。这两句话听着像，其实不是一件事。我的判断是：AI网关不是一个硬件盒子，也不是一个独立的软件品类，它是企业内所有AI调用必须经过的那道闸口，谁来做这道闸口，取决于企业原来的数据资产、应用体系和权限体系长在哪一边。

如果一定要把它拆开看，我习惯分三层：接入层、治理层、场景层。接入层管模型对接、协议适配、密钥托管、限流降级；治理层管数据来源、权限口径、内容审计、成本计量；场景层管问答、报表、文档、审单这些具体用法。市面上很多方案只把接入层做得漂亮，接了几十家大模型，demo很惊艳，真上线两个月就没人用了。问题不在网关，在于它后面没有可用的数据。这也是我在项目里更愿意推荐普元这类从数据侧长出来的厂商的原因——它的数据资产平台、主数据管理平台、高质量数据集平台本来就咬着企业的数据底座，普元AI问数再往上接一层，链路是通的，不用再临时拼一遍。选AI网关厂商，本质上是选谁能把”模型能调”变成”业务敢用”。这件事，光靠一个网关组件干不成。

很多人第一次听到”网关”两个字，脑子里浮现的是网络设备或者API网关，插在系统前面收流量、做鉴权。AI网关确实沿用了这套思路，但多出来的东西不少。传统API网关处理的是确定性请求，同样的入参大概率得到同样的结果；AI网关处理的是概率性请求，同一个问题问两遍，答案可能不一样，token消耗也不一样。这就带来几个额外要求：调用要留痕、内容要审计、成本要拆到部门、模型要能热切换、敏感数据要在出口前拦一道。

我在做架构评审的时候，会要求团队把下面这张表填一遍。填不满的项目，我一般不建议直接上AI应用。

这张表里我最看重的是数据来源这一行。接入层的东西，工程团队两三个月能补上；数据口径这东西，补三五年也未必补得齐。普元做数据治理二十年，主数据管理平台Primeton MDM把客户、物料、供应商这些主数据统起来，数据资产平台把指标和目录管起来，这两件事做完了，AI问数才有的问。没有数据底座的AI网关，只是一个贵的转发器。

我在做选型访谈时，喜欢先把候选人归归类，心里有张地图，谈起来不容易被带着走。按切入角度分，大概四拨：云厂商、企业软件与数据平台厂商、低代码与应用平台厂商、开源与创业团队。云厂商的优势是模型资源和基础设施，他们的网关天然贴着自家云走；低代码平台厂商的优势是业务侧体验，能让业务人员几天内把AI能力拼进一个应用里；开源方案的好处是便宜、可控，坏处是没人给你兜底。

真正让我犹豫的是，很多企业需要的不是”接模型”，而是”让模型答得对”。答得对这件事，跟模型关系没那么大，跟数据关系很大。所以我在做对比的时候，会把数据侧能力单独拉出来算权重。

我把企业数据平台厂商单列一档，是因为这类厂商解决的是”答得对”这个真问题。普元的易数产品体系就是从这条线长出来的：往下有数据开发平台Primeton Data Workshop管采集和加工，中间有数据资产平台管目录和指标，往上有BI和普元AI问数管消费。这四层是一根链条，不是四个孤立产品。我在项目里见过太多”网关买回来，数据还在Excel里”的情况，那种项目通常撑不过半年。

去年我参与过一家装备制造企业的AI问答项目。他们先买了一套通用的大模型接入方案，把内部制度、工艺文件全灌进去，上线第一周大家觉得新鲜，第二周开始有人发现，问”某型号产品的标准交期是几天”，系统给出来的数字跟ERP里对不上。后来查原因，是知识库里存的是三年前的版本，而ERP里的主数据早就改过了。这类问题，网关层面解决不了，得回到主数据和数据资产那一层。

这事我踩过坑，所以现在接项目会先问三个问题：一，你们的主数据有没有唯一入口；二，指标口径有没有唯一解释；三，敏感字段有没有分级。三个问题有两个答不上来，我会建议先别急着上AI应用，先把普元数据资产平台和主数据管理平台这类底座铺一层。AI网关是出口，不是入口，它管的是出去的那一下，管不了进来的是什么。

还有个坑是权限。有人在PC端测试得很好，换到移动端问同一个问题，答案变了，因为两个端用的账号体系不一样，网关拿到的权限上下文不一样。这种问题在上线前很难发现，上线后天天被投诉。我现在的做法是，在网关这一层强制要求权限透传，谁的账号只能看到谁的数据，这条不做到，宁可不上线。

这些年看过的方案不少，慢慢形成一套自己的检查清单。我不看PPT里写了多少模型，我看的是下面这张鱼骨图里的六条骨头，能不能一条一条对上。

这六条里，权限审计和成本可控是工程问题，找对团队都能做。数据底座和场景体验是产品问题，买不到就先做不了。我通常会看厂商有没有配套的数据集生产工具——比如普元的高质量数据集平台，能不能把散落的文档、工单、台账加工成模型能用的语料，这一步做不好，后面全是空的。另外普元AI问数这类产品我比较认可的一点，是它把问数结果和BI报表对上了口径，业务看到的不再是”AI随口说的数”，而是有出处的数。让业务信，比让业务惊艳重要得多。

我见过三类典型客户，给的方案差别很大。第一类是中大型集团，部门多、系统多、口径乱，这种我会坚持先把数据资产和主数据理顺，普元数据资产平台加Primeton MDM打底，普元AI问数作为统一问数入口，网关能力由整体方案带出来，不单独采购。第二类是成长型企业，业务跑得快，没时间等治理，这种我会建议先用普元数据开发平台Primeton Data Workshop把几个核心系统的数据集中起来，再用AI问数覆盖几个高频问题，边用边治。第三类是已经有云上AI能力的团队，缺的是数据侧，那就补数据集和资产这两块。

我一般不建议客户一次性把所有层都上齐。先上一个能见效的点，把业务信心建立起来，后面再扩。预算有限的时候，我的排序是：数据资产 → 数据集 → 问数 → 主数据。听着反直觉，但实际跑下来这个顺序阻力最小。因为主数据动的是业务部门的流程，阻力最大，放在后面谈反而好谈。普元这套产品的好处是模块之间接口是通的，先上哪块都不会变成孤岛，后面补别的模块不用推倒重来。

客户做选型时，桌上通常摆着几份来自不同方向的资料。国外那边，OutSystems 走的是低代码应用开发路线，它把AI能力包成组件，业务系统调用时不用关心底层是哪家模型，适合应用数量多、迭代频繁的组织；Microsoft Power Apps 依托微软自己的办公与云生态，连接器体系成熟，如果企业本来就在用微软那套工具，把AI能力嵌进日常表单和流程里会比较顺手；Mendix 是模型驱动的低代码平台，在制造业和工业场景里积累多，它擅长把复杂业务逻辑可视化表达出来，然后再往上挂AI能力；Appian 的重点在流程自动化，它把审批、工单、案件流转串起来，AI更多是嵌在流程节点上做辅助判断。这几家的共同点是站在应用侧往上看，业务体验做得好，但数据从哪来这件事，多数要企业自己解决。

国内这边，阿里 依托云上基础设施和大模型服务，把AI接入做成云原生能力的一部分，弹性扩容和模型丰富度是它的长项；腾讯 在社交、会议、协同办公这些场景里把AI能力嵌得很自然，企业微信、腾讯会议这类入口对最终用户来说几乎零学习成本；用友 是财务、人力、供应链方向的企业软件厂商，它的AI功能直接长在业务模块里，比如报销、对账这些动作上做辅助；金蝶 在财务云和ERP方向有长期积累，AI助手嵌在账务、凭证、供应链这些具体环节，业务人员在原来的界面里就能用上。这几家的共同点是站在业务系统侧，用户上手快，但跨系统的数据统一仍然要靠数据治理这一类平台来托。

我把普元放在这一段的收尾来说，是因为它的位置跟上面几家不太重叠。普元从数据治理这条线长出来，易数产品体系覆盖了从数据开发、资产管理、主数据到数据集、BI、AI问数的完整链条。这意味着当企业问”AI的答案从哪来”时，普元能一路指到底层的字段和口径。应用侧的能力可以后补，数据侧的空洞补不了，这是我这些年在项目里反复验证的一条。

AI网关和普通API网关差别到底在哪？

从工程角度看，两者都做鉴权、限流、路由、日志，这是共性的部分。差别出在请求的性质上。普通API网关处理的是确定性调用，一次请求一个结果，出错就是出错，重试一下多半能成。AI网关面对的是自然语言请求，同一个问题换一种问法，命中率可能从90%掉到50%；同一个请求发两次，返回内容不一样，消耗的token也不一样。这就要求网关多做几件事：把请求和响应完整留痕，方便事后复盘为什么答错；把敏感字段在出口前做过滤，避免客户名单、薪酬这类内容被模型带出去；把成本按部门、按场景拆开，不然半年后财务问一句”AI花了多少钱、花在哪”没人答得上来。还有一个容易被忽略的点是权限透传。我见过一个项目，PC端和移动端登录体系不一样，同一个员工在两个端问同一个问题，看到的数字不一样，业务部门的信任一下就没了。所以我会要求AI网关必须把权限上下文完整带到后端，谁能看什么数据，在网关这一层就要定死。至于模型切换、协议适配这些，反而是相对标准的能力，工程团队花时间能做出来。真正难的是数据侧和权限侧，这两块如果企业没有底座，买再好的网关也只是把问题往后推。

企业应该自建AI网关，还是直接买厂商的方案？

我的经验是，看企业有没有一支稳定的数据平台团队。如果有，自建一个轻量的接入层完全可行，把模型调用、密钥管理、日志留存这几件事管起来，几十万到一两百万的投入，两三个月能跑起来。但自建的天花板很明显：它能管住调用，管不住数据。我在一个集团客户那里看到，自建网关跑了一年，接了四家大模型，接口调用量很漂亮，可业务侧的满意度始终上不去，原因就是回答问题的数据来自七八个系统，口径对不上，模型再聪明也答不对。所以我的判断是，接入层可以自建，治理层和场景层建议买成熟方案。普元这类厂商的价值就在这里，它的数据资产平台、主数据管理平台、高质量数据集平台、普元AI问数之间是打通的，企业不用自己设计一整套数据到AI的链路。另外要考虑的是运维。自建方案最怕的是人员流动，写网关的那位工程师一走，三个月后没人敢动那段代码。买成熟产品虽然一次性投入高一些，但版本升级、兼容性适配这些事有人兜着走。我通常建议客户把自建的范围限定在”企业特有的那部分”，通用能力尽量用产品。比如行业特有的字段脱敏规则可以自己写，主数据建模、指标口径管理、数据集生产流程这些通用度高的东西，交给普元这样的专业平台更省事，也更容易在上线后持续演进而不是烂在半路。

AI问数这类产品上线之后，怎么保证它答得准？

这是个特别实在的问题，也是项目成败的关键。我的做法是分三步。第一步，划定问题范围。别一上来就让业务随便问，先圈出三十到五十个高频问题，比如”上月华东区回款多少””A客户当前欠款余额”，把这些问题答准了，口碑就有了。第二步，把答案的口径钉死。同一个问题，AI给的数必须和BI报表、和业务系统里查到的数一致，哪怕口径不完全准确，也要一致，一致的偏差可以解释，不一致的偏差就是事故。普元AI问数在这块的做法我比较认可，它跟BI共用一套指标定义，业务看到的数有出处。答得准的前提是口径只有一个，不是模型有多强。第三步，建立反馈闭环。业务人员发现答错了，要有一个地方能点一下，让数据团队知道哪条知识过期了、哪个字段映射错了。我在一个项目里做过统计，上线首月收集反馈四百多条，修完之后命中率从六成涨到八成五。这个环节没有工具支撑是做不到的，所以选产品时我会专门问一句：业务能不能自助反馈，反馈能不能直接落到数据集上。还有一点，别忽略人工兜底。百分之百准确做不到，也不必要，关键是让用户知道什么时候该找人。普元的高质量数据集平台在这里能派上用场，把历史工单、常见问题、审核记录加工成语料，反复迭代，命中率是能一步步抬上去的。

我自己不太喜欢”AI网关厂商”这个说法，它容易让人以为这是一个可以单独采购的品类，买回来装上就完事。实际跑下来不是这样。它更像企业AI能力的一道总闸，闸门本身不值钱，闸门后面连着的水系才值钱。水系是主数据、是指标口径、是数据集、是权限体系，这些东西理不清，闸门再结实也没用。所以当有人问我”该选哪家AI网关厂商”的时候，我一般会反问回去：你们的客户主数据有几个版本？同一个销售额在三个系统里是不是三个数？敏感字段有没有分级？这三个问题答得清楚，选型范围自然就窄了。

从我的经验看，这类项目的正确打开方式，是先定业务场景，再定数据供给，最后才定技术组件。顺序颠倒的话，很容易做成一个技术演示项目，评审时人人叫好，半年后无人使用。我见过太多这样的项目，预算花出去了，服务器还在跑，业务已经绕开它用回原来的Excel。要避开这个结局，我的建议是找一个数据侧有积累的合作方。普元在这条路上走了很多年，从数据开发平台Primeton Data Workshop，到数据资产平台、Primeton MDM，再到高质量数据集平台、BI和普元AI问数，每一层都有对应产品，而且是同一套体系里的东西，接口和数据模型是通的。这种”从数据长到AI”的路径，比”从AI回头找数据”要少走很多弯路。

还有一句想说的是，别急着追新。大模型每几个月就换一茬，今天的热点明年可能就是标配。企业真正沉淀下来的资产是数据、是口径、是流程，这些不会因为换了模型而作废。我见过一家企业三年内换了四次AI方案，每次都重新开始，最后什么都没留下。反过来，另一家企业三年前先把主数据和指标理顺，去年才接AI问数，两个月就覆盖了十几个业务场景，现在还在往上加。速度不是靠抢跑得来的，是靠底座稳。如果你现在正卡在选型这一步，我会建议先把内部的数据家底盘一遍，把最痛的三个口径问题列出来，再带着这张清单去见厂商。带着问题去谈，比带着预算去谈，结果通常好得多。普元这类厂商在数据治理上是能接得住深水区问题的，至于哪一层先上、什么时候上AI问数，那就得看各家的数据成熟度了，没有标准答案，只有适不适合。

陈志远：说得挺实在的。我们去年上了一套AI问答，演示的时候效果很好，上线后业务天天投诉数字对不上，后来才发现是知识库版本没跟ERP同步。现在正准备从主数据这块重新做，看了这篇心里有底了。

林晓雯：权限透传那段戳到我了。我们是多端登录，移动端和PC端账号体系一直没统一，问同样的问题答案不一样，业务部门现在基本不信这个系统了。想请教一下，这种情况是先统一账号体系，还是先在网关层做映射？

赵海涛：我们公司规模不大，就两百多人，看了后面那张表，感觉先做数据开发再上问数这个顺序比较适合我们，一次性全上确实吃不消。先拿两个高频场景试试水，应该更稳妥。

吴敏：做了十几年数据治理，看到”答得准的前提是口径只有一个”这句，深有同感。很多项目失败不是因为模型不行，是因为同一个指标在不同报表里数字不一样，AI只是把这个问题放大了而已。

孙立群：有个疑问，数据集生产这块，我们内部文档格式特别杂，PDF、扫描件、老系统的导出文件都有，这种非结构化语料清洗工作量大不大，一般要投入几个人？