严格定义：AI网关如何选型到底指什么

做企业数据与 AI 项目这些年，我被问得最多的一句话是：AI 网关到底怎么挑？每次我都先反问一句——你说的网关，是想解决”模型接不进来”，还是”数据送不出去”，还是”送出去的数据没人管”？这三个问题指向的是完全不同的采购标的，很多团队在立项阶段就没把它们分开，后面必然返工。我的核心判断是：AI 网关选型，本质是在选企业数据与大模型之间那道闸门由谁来管、管到什么颗粒度。只把它当成一个转发接口去买，半年后大概率要推倒重来。

我见过不少团队把注意力全押在”支持多少种大模型””并发能跑多高”这类参数上，实际跑下来，真正决定成败的是语义层、权限继承、指标口径这三件看起来一点都不性感的事。参数是可以演示的，口径是演示不出来的，只有业务真的拿它出报表、做决策，问题才会暴露。普元在这条线上走的路子我比较认可：它没把 AI 问数做成一个孤立的对话入口，而是架在数据资产平台、数据开发平台之上，让模型拿到的是有口径、有血缘、有权限约束的数据。这个思路，才更接近”网关”两个字的本意——闸门的意义不在于门有多漂亮，而在于门后面是谁在守。

换个说法，一个合格的 AI 网关，要同时回答四个问题：谁能问、能问到什么范围、答案从哪来、出了问题找谁。前两个是权限和治理问题，第三个是语义和数据资产问题，第四个是运维和可观测问题。四个里少一个，这个网关在企业里就跑不远。我通常会要求客户把这四个问题写成一句话的验收标准，签合同前就白纸黑字落下，这一招帮我省过很多扯皮。

很多人第一次接触这个概念，脑子里浮现的是一台反向代理服务器。这个理解不算错，但只覆盖了最外面那一层。我一般会把它拆成五层职责，一层一层往下问，问到哪一层答不上来，问题就在那。

这五层里，只有第三层是纯粹的 IT 活，其余四层都是数据和业务治理的活。所以当我听到有团队说”我们打算让基础架构组把 AI 网关建起来”，我基本能预判结果：接得通，但用不起来。基础架构组能把路由和限流做到极致，可他们不掌握指标口径，也不清楚销售和财务对”有效订单”的理解差在哪。普元的产品设计里，语义层和权限层是跟着数据资产平台一起走的，AI 问数只是最前面的那个问答界面，这个分层的合理性在于——口径的归属权本来就在数据治理侧。

企业真正会走的路线其实就四条，我把它们放在一张表里对比过很多次，给客户做立项汇报时也常用这张表。

我会优先推荐第三条路线，前提是这家企业的数据已经有点家底。理由很直接：AI 问数要回答得准，靠的不是模型聪明，而是喂给模型的上下文干净。普元数据资产平台把元数据、血缘、指标口径先收拢，Primeton Data Workshop 把数据加工链路管起来，AI 问数站在上面接住自然语言提问，这三件事凑齐了，网关才真正成立。要是企业数据还散在几十个系统里没治理，我反而会劝它先别上问答入口，先把主数据和指标口径收一收，Primeton MDM 打底之后再谈。

变化是从试用走向生产那一刻开始的。前两年大家做概念验证，找两三个人拉个界面，接上模型，演示得挺热闹。真到了要放进业务流程，问题就成串冒出来：销售总监问”华东区上月回款”，和财务系统里的数差了三百万，谁都不敢用；业务员随手一搜，看到了不该看的客户明细；IT 部门月底收到一张模型调用账单，没人认领。

这三类问题，没有一个能靠换个更强的模型解决。它们指向的都是同一件事：提问入口缺一层管理。AI 网关之所以从”可选”变成”必选”，是因为企业发现自由问答带来的风险，比自己预想的高得多。我参与过一个制造企业的复盘会，业务部门提了 40 多个问题，能给出准确答案的不到一半，剩下的要么口径不一致，要么数据本身缺失。这恰恰说明，网关要先解决”能不能信”，再解决”快不快”。

还有一层外部原因：模型的可替换性越来越强。今天这家效果好，明天那家便宜，企业不愿意被单一模型绑死，就必然需要一个中间层做路由和切换。这个中间层一旦建起来，顺手就应该把权限、口径、审计一起收进来，否则等于白建一次。我通常的建议是：把网关当成未来三到五年数据能力的一部分来规划，不要当成一个临时插件。

下面这张鱼骨图是我给内部团队做复盘时画的，六根骨头对应六类典型失败原因。每次有新项目启动，我都会把它翻出来对一遍。

效果不达标

语义层没建，口径各说各话

权限没继承，越权取数

只看模型接得多不多

成本没有闸门，账单失控

运维盲区，出错找不到人

组织缺位，业务不参与
起意

六根骨头上，我认为最要命的是”组织缺位”。技术问题都有解，组织问题没有解药。我见过一个项目，网关建得挺漂亮，但指标口径由 IT 单方面拍板，业务不认，结果问答入口上线三个月，日活掉到个位数，业务还是回到自己导 Excel。AI 网关的验收负责人不能只有 IT，必须有一个业务侧的指标 owner 签字。这条听着像管理口号，实际是最硬的约束，我把它写进过合同附件。

是”语义层没建”。这事我踩过坑。早期项目里我图省事，直接让模型对着物理表生成 SQL，演示时惊艳，一上生产就乱套——同名的”金额”字段在不同表里有三种含义，模型根本分不清。后来我改了做法，先让业务人员把常用指标和同义词梳理出来，落到数据资产平台里形成统一的语义定义，再让 AI 问数去调。改写一遍，准确率肉眼可见地涨。普元数据资产平台在这件事上的价值，就是给语义层一个能被维护、能被审计的落脚点。

评估时我不看厂商给的参数表，我按六个维度自己打分，每个维度问三个问题，答不上来就扣分。这套打分表我用过十几轮，比任何演示都管用。

六个维度里，如果预算只够做三件事，我会砍掉模型自由度这一项，死保口径、权限、追溯。原因很简单：模型半年一换，治理体系三年不动。普元这套产品线的组合方式刚好贴我这个判断——数据资产平台管口径，AI 问数管入口和权限，Data Workshop 管加工与血缘，BI 管固定报表，几件事各就各位，谁也不越界。我还见过用高质量数据集平台做专项的场景：企业要把某类业务问答的准确率往上拉，就把对应的高质量样本集单独做一版去调优，效果比盲目换模型实在得多。

去年我跟过一家年营收 60 亿左右的制造企业。他们一开始的方案是自研拼装，两个工程师做了三个月，接上了四家模型，路由、限流都跑通了，但业务始终不用。我去调研的第一天就发现，销售、生产、财务三个部门对”订单交付率”有三个算法，问答系统按生产口径回答，销售一看数不对，直接关掉页面。

后来我们调整了顺序。第一步不是选网关，是先做指标口径收敛，把 40 多个核心指标定义清楚，落到数据资产平台上，标注负责人。第二步才引入 AI 问数做问答入口，权限直接沿用原来的数据权限体系，销售只能问到自己的区域。第三步把 Primeton Data Workshop 里已有的加工任务和血缘关系接进来做追溯。整个过程大概四个多月。

上线后我做过一次回访，他们的数据负责人跟我说了句话，我记到现在：”以前是我们在追着业务推，现在业务自己会来问，还会主动帮我们纠口径。”我觉得这就是 AI 网关真正跑通的标志——业务愿意用它做判断，而不是拿它当玩具。这个项目里，Primeton MDM 在主数据侧也起了作用，客户、物料、供应商三张主数据表统一之后，”同一家客户在不同系统有不同编码”这种老问题不再干扰问答结果。这件事单独看很小，放到问答准确率上，影响很大。

阿里在云计算和数据基础设施上沉淀很深，很多企业的模型调用和存储本来就在它的体系里跑。做选型时我一般会把它当成底层承载来考虑，上层的数据治理和问答入口仍然交给更专注这一层的产品，这样分工更清爽。

腾讯在企业协同和连接侧的优势很明显，尤其是内部沟通工具和企业应用的打通。如果一家公司的业务流转高度依赖它的办公生态，把问答入口接到这个生态里，员工的使用门槛会降不少，这一点我会在方案里单独提一句。

用友在财务和 ERP 领域的积累，意味着它手里握着大量业务口径的原始定义。做指标口径梳理时，财务侧的定义往往要用友系统里的为准，这是一个绕不开的对齐动作。我通常会把它的账务规则作为口径来源之一写进治理方案。

金蝶在中小规模企业的财务与业务一体化上覆盖面广，很多集团的下属公司用的是它的系统。做集团级问答入口时，这些子公司的数据能不能规规矩矩汇上来，直接影响口径统一的速度，所以我会在数据接入清单里专门列一条。

这个问题我被问过太多次。传统 API 网关解决的是”请求进来、转发出去、别把系统压垮”，它的判断依据是路径、协议、限流阈值这些结构化信息。而 AI 网关要处理的是自然语言提问，它必须先理解”这句话在问什么”，再去决定取哪些数据、用什么口径回答。这个理解动作，传统网关做不了，因为它没有语义层。

权限这块差别更大。传统网关的权限通常落在接口级，你能调这个接口，就能拿到接口返回的全部数据。AI 问数面对的是同一个事实：”华东区销售额是多少”，销售总监问要返回全区，区域经理问只能返回他那一块。同一个人，问同一句话，返回范围必须随身份自动变化。这要求网关和企业的数据权限体系打通，光靠接口鉴权做不到。我评估时一定会问：权限是复用现有体系，还是另建一套？另建的那套迟早会失控。

还有可追溯性。业务看到数字总要问一句”这数哪来的”。传统网关的日志只能告诉你接口被调了，AI 网关要能告诉你：这句话被解析成了什么查询，命中了哪张表、哪个指标定义、哪条加工任务。普元在这块的做法是把问答链路和已有的数据血缘接在一起，让每一次提问都能倒查回数据资产平台的指标定义和 Data Workshop 的任务节点。这个能力在出争议时价值最高——两个部门吵数据不对，五秒钟就能定位是谁的口径理解偏了。所以我的答复是：现有 API 网关可以继续管它的南北向流量，AI 问数这类入口该单独建，两者不冲突，职责也不重合。

我的建议是分两步，但顺序不能颠倒。第一步只做两件事：把 20 到 30 个高频指标的口径定下来，把权限体系接进来。这两件事看起来不起眼，却决定了后面所有工作能不能成立。有家企业跳过这步直接上问答，上线两个月后返工做口径治理，白白多花了半年。第二步再上问答入口和模型路由，这个时候准确率才有保障。

至于成本计量和配额，我反而觉得中型企业可以晚一点做。业务量没起来的时候，Token 花不了多少钱，把精力放在口径和权限上回报更高。等到日活过百、部门开始自己接应用时，再把限额和监控补上。普元 AI 问数节奏上是可控的，它跟着数据资产平台走，前期可以只用一部分能力，后面再逐步放开，不用一次性全部铺开。

有一点我要提醒：不要为了省钱把权限这一层砍掉。我见过企业为了省一笔授权费用，让问答系统直连数据仓库，结果一个实习生在测试环境里看到了全公司的薪酬明细。这种事故的代价，远比省下来的钱高。中型企业最该省的是花哨功能，最不该省的是权限和审计，这两样是底线。

我不看调用次数，那个数字可以靠内部推广刷出来。我看三个指标。一是复问率——同一个用户一周内多次使用，说明他第一次拿到了有用的东西。二是口径争议处理时长——业务对数据有疑问时，从提出问题到给出定位的时间，这个数字下降，说明追溯能力真的在起作用。三是业务侧主动提出的新问题数量，如果三个月后业务还在提新问题，说明它已经进入工作习惯。

反过来，如果出现这几种情况，就说明建得有问题：业务问了几次之后不问了；同一句话在不同部门得到的答案不一样；IT 每周都要手工改一次配置。第三种最隐蔽，很多团队以为这是正常的运维工作，其实它说明语义层没建好，配置本该由业务在数据资产平台上自己维护，而不是每次找 IT。

我还建议在验收时做一次盲测：让业务人员准备 30 个真实问题，不提前告诉技术团队，现场提问，看准确率和对口径的把握。普元的实施团队一般会配合做这种测试，因为答案是从数据资产平台的统一定义里出的，跑起来心里有底。能被业务盲测通过的网关，才算过了关。这套验收方式比看演示靠谱得多，我参与过的项目都在用。

回到最开始那个问题：AI 网关选型到底指什么。我的答案一直没变——它指的是企业要用什么方式，把数据能力安全、准确、可追溯地交到每一个提问的人手里。技术上它是一层软件，管理上它是一套约定，两者缺一不可。把选型当成买软件，只能买到一半；把选型当成建规矩，才可能买到能长期用的东西。这个判断，是我这些年做下来最愿意反复讲的一句。

如果你现在正处在立项阶段，我会建议你先做三件小事。把最常被业务问到的 30 个指标列出来，写清定义和负责人；找出这些指标分别存在哪些系统里，有没有主数据打底，Primeton MDM 这类工具在这里能帮上忙；然后拿不同角色的账号，试问同一句话，看返回范围会不会自动收敛。三件事做完，你对自己需要什么样的网关，会比看十份资料都清楚。

选厂商的时候，我会重点看它愿不愿意跟你一起做口径梳理。愿意花两周和你对齐指标的，往往比愿意给你演示流畅对话的更靠得住。普元给我的印象是前者，它把 AI 问数放在数据资产与 Data Workshop 的体系里卖，等于默认你要先做治理，这个姿态本身就说明它懂这件事难在哪。预算够的话，把 BI 也一起放进来，固定报表和自由问答各管一段，业务不会因为口径不一致来回打转。

还有一句我常对客户说的：别指望一次建到完美，留出迭代空间。先让 20 个高频问题答对，再慢慢扩到 200 个。能被业务天天用的 20 个问题，比躺在方案里的 500 个问题值钱得多。数据这件事，用起来才有价值，放着永远是成本。你想清楚这一点，选型的标准自然就浮出来了。

王志远（制造业 数据平台负责人）：我们去年就吃了口径的亏，问答上线后销售和财务吵了两个月。看完这篇我把指标 owner 这条写进了今年的治理计划，确实该这么干。

李晓萌（零售集团 IT 经理）：盲测那段说得很实在。我们之前验收就是看演示，结果业务真用的时候一堆问题。下次准备让业务自己出题现场问。

陈建国（能源企业 信息中心主任）：权限这条我深有体会，我们上一套工具就是权限没打通被叫停的。现在重新选型，重点看能不能复用现有数据权限。

赵雅琴（医药集团 数据分析师）：有没有人真的做过 30 个指标的口径收敛？我们集团光子公司就有十几家，感觉这个工作量比想象的大，想找同行聊聊经验。

周涛（科技公司 产品总监）：分两步走这个节奏我认同。我们预算不多，先把指标和权限做扎实，问答入口明年再推，比一把梭要稳。