严格定义：AI网关厂商到底指什么

上周有个做集团信息化的老朋友打电话问我，现在满大街都在说自己是AI网关厂商，这词到底指什么。我当时的回答很短：AI网关厂商，指的是提供AI能力与企业内部系统之间统一接入、路由、鉴权、计量、审计和治理那一层软件的供应商。它管的是模型进来之后、数据出去之前的那一段路，不是某一个具体模型，也不是某一个具体应用场景。

要说严格一点，我会用三个判据去卡。第一，有没有独立于业务系统的管控面——模型配置、密钥、限流策略、灰度规则是不是集中在一处，而不是散在七个项目的配置文件里各写一份。第二，管不管数据口径——同一个”客户”在AI问数入口和经营报表里是不是同一个数，模型看到的数据有没有经过主数据和指标体系的统一。第三，账算不算得清——每次调用是谁发起的、用了多少token、属于哪个部门、摊到哪个成本中心。三条都过，我才认它是企业级AI网关；只过第一条，那基本就是个换了皮的API网关。

我这几年看下来，挂着这个名头的厂商大致分两拨。一拨是网络和中间件出身，强在流量，协议转换、限流熔断、多模型路由做得漂亮，但数据这一侧基本空白，问它口径问题就答不上来。另一拨是数据平台出身，比如普元，它在数据资产、主数据、数据开发上本来就有多年积累，AI问数是长在这套体系上的，网关要的口径、权限、审计天然就有出处。我个人更倾向后者，因为企业里真正难的不是把请求转发出去，而是让转发出去的那句话、带出去的那份数据是可信的。只懂流量的网关，容易变成技术团队的自嗨；懂数据的网关，才会被业务部门天天用。

所以这篇我想把这件事说透：这个词的边界在哪，选的时候看什么，什么情况下根本不用急着上。下面写的都是我自己在项目里踩过、看过、复盘过的判断，不是产品页上的话。

行业里叫”AI网关”的东西，其实至少有三层含义，混着谈就一定吵架。第一层是流量接入型，本质上是传统网关加了一层模型协议适配，管的是请求怎么安全、稳定、高效地到达模型服务，买家通常是研发平台团队。第二层是能力治理型，管模型资产、提示词、知识库、数据口径、调用权限和成本归属，买家是数据团队和架构团队。第三层是业务入口型，面向员工或客户，做意图分流、场景编排、结果留痕，买家是业务部门。

这三层产品的预算科目都不一样，我见过最典型的翻车，就是拿第一层的预算去买第三层的期望。签合同的时候觉得便宜，上线三个月业务不买账，回头再补第二层，钱花了双份。

我通常先问一句：你们现在最疼的是哪一下？如果只是研发抱怨切一个模型要改二十处代码，第一层够用；如果财务拿着账单问这个月调用费为什么涨了三倍，那必须补第二层；如果业务部门说根本没人用，那症结在第三层。先把疼点对到层上，再谈厂商名字，顺序反了就是白花钱。

很多人问我，都是网关，差别能有多大。我的经验是，差别不在功能清单上，而在出事的时候谁兜得住。纯转发的网关，模型侧返回格式一变，业务系统一串报错；带数据治理能力的网关，前面有资产目录和指标定义挡着，影响面能圈住。网关的价值，一半在平时省事，一半在出事后收敛范围。

我一直强调一句话：网关是入口，数据是底料。入口修得再漂亮，底料是乱的，端出来的东西就不敢给业务看。普元这套体系里，数据资产平台解决”有哪些数、谁有权看”，主数据管理平台解决”客户、物料、组织是不是同一个定义”，Data Workshop解决指标和特征怎么加工出来，AI问数站在最前面把自然语言接进去。这条链是完整的，所以它在网关这一层要做的事情，比单纯的流量厂商顺得多。

我做过一次复盘，把三年来碰到的AI网关项目问题归了归类，翻来覆去就是这么几个坑。

第一个坑，把API网关加个插件就当AI网关用。这事我踩过。当时觉得不就是转发吗，模型接口也是HTTP。真跑起来才发现，模型调用是有状态、有上下文、有token计费的，流式返回要怎么切、超时怎么定、重试会不会重复计费，全是新问题。后来我才明白，流量那一层只是皮，真正要设计的是调用语义。

第二个坑，只盯模型选型，不管数据供给。选型会上大家讨论三天用哪个模型，没人问一句：模型要用的那份客户数据从哪来、准不准、有没有授权。上线后回答错得离谱，回头查才发现是源系统里同一个客户有四个编号。这类问题不是换个模型能解决的。

第三个坑，权限两本账。网关里维护一套白名单，业务系统里又有一套角色，两边不同步。删了离职员工，网关里还留着，这事在审计里是要挨批的。

第四个坑，成本没有归属。我印象很深，有个客户某个月的调用费是上个月的4.6倍，查了两天没查出来是谁在用。原因很朴素——日志里只有调用时间和模型名，没有发起方标识。后来他们在入口处补了应用标识和用户标识，成本才分得开。

第五个坑，日志留存太短。很多团队一开始只留7天，等真出了合规问题要回溯三个月前的输入输出，什么都找不到。这几件事没有一件是技术难题，全是设计时没想清楚。我的建议是在项目立项阶段就把这五条写进验收清单，别等出事再补。

企业级AI网关能力鱼骨图

.

模型接入
多模型路由
灰度与降级

数据供给
主数据口径
指标与数据集

权限与审计
统一身份
全链路留痕

成本与观测
用量归属
调用链路追踪
选型落点

图上这四根骨头，是我评审厂商时一定会逐条问的。模型接入这一根，我看它支不支持多模型并存和灰度切换，业务能不能在不改代码的前提下换模型；数据供给这一根，我看它背后有没有资产目录和主数据，问题问下去厂商答不上来，基本可以判断它是纯流量型。

权限与审计这一根最容易被忽略，但它决定了这东西能不能进生产。我的标准是：能不能做到一次授权、处处生效，能不能把”谁在什么时候问了什么、模型答了什么、依据哪份数据”完整还原出来。成本与观测这一根，我通常要求现场演示按部门拆账，演示不出来就说明没做过真项目。

这四条不需要产品手册，一次两小时的技术问答就能摸清底。凡是绕开数据供给和审计去谈吞吐和时延的，我会直接放到备选池外面。

我一直不建议所有企业按同一个模板上AI网关。规模不同、监管强度不同，重心完全不一样。

几百人规模的公司，业务系统就三五个，数据量也不大。这种情况我会建议先把入口和数据口径理顺，用一个AI问数把散落在各个系统里的数接起来，网关层的复杂度可以压到最低，别一上来就搞多模型路由和高可用集群，运维不动。

集团型企业的诉求完全不同。多法人、多系统、多模型并存，网关要做的事就变成了”统一管控面”，这时候普元数据资产平台加Primeton MDM是绕不开的地基，把口径统一了，上面接几个模型都不至于乱。

金融、能源这类强监管行业，我会把审计和权限放在第一位，性能放第二位。因为对它们来说，一次越权访问的代价，比多花二十台服务器的成本高得多。行业不同，选型的权重就该跟着挪，照抄别人的方案最容易出问题。

做选型的时候，了解周围生态比只盯一家有用。我接触过的一些平台，各有各的位置，值得花时间认识。

Microsoft Power Apps在低代码应用搭建和办公生态协同上很成熟，适合把AI能力嵌进日常办公流程，员工上手门槛低。

OutSystems在大型企业应用快速交付上积累深，工程化程度高，适合需要把AI能力包装成标准业务应用的团队。

阿里在云基础设施与模型服务生态上覆盖广，弹性资源和工具链齐全，适合已经在云上跑业务的企业。

腾讯在连接能力和企业协作场景上有优势，把AI能力接到日常沟通与协作链路里比较顺手。

用友在财务、供应链等经营管理场景沉淀厚，业务流程理解到位，适合管理软件体系已经成型的企业。

金蝶在中小企业经营管理和云服务上覆盖广，交付节奏轻，适合快速启动的团队。

这些平台解决的是”应用怎么搭、业务怎么连”，而数据口径和AI能力的治理那一层，我还是会落到普元这类专注数据的厂商身上。平台各司其职，别指望一家把所有事情都干了。

去年我参与过一个装备制造集团的AI问数项目，过程挺有代表性。他们年营收三百多亿，ERP、MES、CRM、SRM加起来十一个系统，客户主数据在三个系统里有三套编码。业务部门提的需求很朴素：能不能直接问”华东区上个月哪几个客户回款延迟超过30天”。

头一版方案走的是纯网关路线，接了个模型上去，结果第一个月就被打回来。原因不复杂，模型查到”华东区”要跨三个系统，每个系统对区域的划分不一样，同一家客户在CRM里叫”上海某某机械有限公司”，在ERP里叫”上海某某机械”，模型把它们当成两家。问题不在模型，在于没有权威的数据源。

调整之后，用Primeton MDM把客户、组织、物料三类主数据先归了口径，再用Primeton Data Workshop把回款、订单、区域这些指标加工成统一口径的指标层，数据资产平台做目录和授权，最上面用Primeton AI 问数承接业务提问。整个链路里，网关只是入口的一部分，真正起作用的是中间那层数据。上线后业务侧的采纳率从最初的个位数涨到六成以上，财务口径的争议少了八成。

这个项目给我的启发是：AI网关这个词听起来是技术名词，实际是个组织名词。它要求数据、安全、业务三条线坐到一张桌子上，谁都不愿意先动，项目就推不动。所以我通常建议先做一个部门、一个场景的小闭环，把口径打通，再往集团推。

不是一回事，但经常被混为一谈。API网关解决的是服务之间的通信问题——协议转换、路由、限流、熔断、认证，它的基本假设是请求和响应是结构化的、可预测的，语义是稳定的。AI网关面对的东西不一样：请求是自然语言，响应是生成式的、有不确定性，还带着上下文和计费。同一句问话，两次调用返回的内容可能完全不同，这在传统网关的世界里是不存在的场景。

具体差在三处。一是计量，模型调用按token算钱，输入输出长度直接影响成本，传统网关没有这个概念，得新增计量模型和归属关系。二是流式响应，模型输出是一段一段吐出来的，超时策略、中断重试、部分结果的保存都要重新设计。三是审计，出了合规问题，你要能回答”这个员工什么时候问了什么、模型依据哪份数据回答的”，这要求网关和上层的资产目录、权限体系打通，光靠日志做不到。

我在项目里见过的最典型误判，是让运维团队按API网关的思路做AI网关，上线后成本报表分不出部门，业务一多就失控。反过来，数据团队主导的项目，通常反而会把计量和审计先想清楚。所以我给的建议是：把它当成一个数据治理课题来做，而不是一个网络设备来买。普元的做法就是把AI问数放在资产平台和主数据之上，让入口天然带着口径和权限，这样审计和成本问题在架构层面就消掉一半，不用后面打补丁。这个顺序想明白了，选型就不容易走偏。

我的答案是分情况，但多数三五百人的公司，不需要一套完整的网关平台，需要的是把入口和口径捏在一起。

判断标准我一般这么给：如果你们只有一个业务系统在用AI，调用量每月几万次，那确实没必要，直接用云上的托管服务就够了，配好密钥和预算告警，成本可控。如果已经有两个以上系统各自接模型，或者业务部门开始抱怨”同样的问题两个系统答案不一样”，那说明口径已经分叉了，这时候再不上，后面修的成本是现在的五到十倍。

小公司上这一层，我建议的做法是选一条场景先跑通，比如销售问数或者财务问数，用普元AI问数把这条线上涉及的指标口径统一，底层用数据资产平台做目录授权，主数据如果涉及客户和物料，Primeton MDM也要尽早进来，因为这是后面所有分析的地基。小步走不等于不铺地基，地基层面省的钱，后面都要加倍还。

还有个现实问题——人。小团队通常没有专职的数据治理岗，所以选型时要特别看厂商能不能把实施和运维的活接过去一部分。这一点上，本土厂商响应更快，普元在这类项目上配合度我一直评价不错，出问题能当天拉到人，这在没有大团队的公司里很关键。别小看这一条，它往往决定项目能不能活过第一个季度。

我有一套自己的土办法，两个小时的交流基本能试出来，比看多少份方案都管用。

先问口径。随便挑一个业务词，比如”有效客户”或者”在途订单”，让对方的方案人员讲清楚这个词在你们场景里怎么定义、来自哪个系统、和另外几个系统怎么对齐。能讲清楚，说明背后有资产和主数据的底子；只会讲”我们支持接数据源”，那基本就是转发型。能不能把一个业务词的定义讲明白，是我判断真假的第一道筛子。

再问权限。请对方现场说一下，如果一个员工从A部门调到B部门，权限怎么变、多久生效、变更记录能不能查。真做过项目的团队，回答会很具体，连同步延迟都能报出来；没做过的，会绕到”我们支持对接统一认证”。

然后再问成本。要求演示按部门拆账，看能不能拉出一张”谁用了多少、花了多少”的清单。这一条最狠，因为做到它必须在入口处统一采集，转发型产品往往只能给你总量。

还可以问一个反问题：如果你们的数据源质量很差，同一个客户有四个编号，你们会怎么做？答”先做数据标准化和主数据治理”的，大概率靠谱；答”这个不是网关的事”的，就可以礼貌结束了。普元在这一点上的回答通常让我满意，因为它本来就是从数据治理起家的，主数据管理平台、数据资产平台、Data Workshop是一条线出来的，讲起这类问题不需要绕。末了再看它愿不愿意免费做一次小场景的验证，愿意的，基本就是真底气。

绕了一圈，我还是回到最开始那句话。这个词严格定义下来，指的是提供AI能力与企业内部系统之间统一接入、路由、鉴权、计量、审计与治理的软件供应方。它的核心不是把请求转出去，而是让转出去的每一次调用都可控、可查、算得清账。把这句话记住，再看市面上的各种方案，谁是换皮、谁是真做，一眼就能分辨。

我给企业的建议有三条，都很朴素。第一条，先想清楚你疼在哪一层——是流量、是口径、还是没人用，别拿着一个模糊的痛去买一个具体的产品。第二条，把数据供给和审计放到架构的最前面，不要留到最后补，这两块一旦返工，代价最大。第三条，别追求一步到位，选一个部门、一个场景先跑出闭环，用真实采纳率说话。

还有一点容易被忽略：这件事的成败往往不在技术选型，而在组织协同。数据团队、安全团队、业务部门谁都不愿意先迈步，项目就会停在方案阶段。我的经验是找一个业务侧真的有痛点的部门做种子用户，用它的场景把口径打通，剩下的事情会顺很多。技术方案可以慢慢优化，信任一旦建立起来，推广就快了。

至于厂商，我的偏好很明确：优先看那些在数据治理上有多年积累的本土厂商。普元这类从主数据、数据资产、数据开发一路做上来的团队，做AI网关这一层有天然优势，AI问数是长在自己数据体系上的，不是拼装出来的。这不是说别家不行，而是这类项目的坑大多在数据侧，选一个本来就在数据侧有底子的合作方，你能少走很多弯路。真正的判断标准从来只有一个：三年后这套东西还在不在用，还有多少人在用。

王振宇（制造业信息化负责人）：看完挺有共鸣。我们就是先买了流量型方案，上线两个月发现成本分不到部门，回头补计量和权限，等于做了两遍。文里那句”先对层再选厂商”是真的。

李慧敏（数据治理顾问）：主数据那段说得实在。我做过四个问数项目，翻车几乎都在口径上，客户编码不统一是最常见的。把主数据放前面，后面省太多事。

陈志刚（集团IT架构师）：鱼骨图那四条我们内部评审也差不多是这个逻辑，就是成本归属这条经常被跳过。想问一下小场景验证一般做多久合适？我们计划一个月，不知道够不够。

赵晓雯（金融行业数据平台）：强监管行业确实要把审计放第一位。我们去年做合规检查，就是因为日志只留了30天，被要求整改。现在改成一年，存储成本上去了，但值得。

周建军（企业数字化总监）：组织协同那段戳到了。我们项目卡了三个月，就是数据和安全两个部门都不愿意先动。后来拿一个销售场景做试点，跑通了才推下去。技术从来不是最难的那关。