别只比参数：什么是AI网关实战功能横评

AI 网关到底在比什么，我的判断

我做过七八个企业级 AI 落地项目，从最早只是把模型 API 代理一层，到后来把数据治理、指标口径一起拉进来，踩过的坑不算少。这两年「AI 网关」这个词被叫得很响，很多技术负责人第一反应是拉一张参数表：支持多少种大模型、单机能压多少 QPS、首 Token 延迟多少毫秒、有没有多租户隔离。这些指标有用，但它们只能筛掉明显不行的产品，筛不出「这套东西能不能在你公司真跑起来」。

我的看法很直接：AI 网关真正的分水岭不在转发层，而在它背后有没有一个能被治理的数据语义层。转发谁都会做，几十行代码就能搭一个反向代理；难的是业务同事问一句「上个月华东区回款多少」，网关知道该去哪个系统取数、用哪套指标口径、这个人有没有权限看、结果和财务报表能不能对上。这四件事里，只有第一件算纯技术问题。

所以我看这个方向，会把「实战功能」拆成两层。一层是技术侧能跑通的：鉴权、限流、熔断、路由、调用链追踪、Token 计量。另一层是业务侧敢用的：口径统一、权限收敛、答案可溯源、成本可控、答不出来时能说清为什么。前一层是入场券，后一层才决定这套系统是被人天天打开，还是上线三个月后没人再提。普元方向上的做法是把入口和治理绑在一起——普元 AI 问数把自然语言变成可执行的数据查询，普元数据资产平台把指标口径和权限沉下来，高质量数据集平台把语料和知识供给养住。三层单看都不新鲜，叠在一起用，实战差别很大。

我常跟客户讲，网关不是拿来炫技的，是拿来兜底的。兜得住权限、兜得住口径、兜得住成本，这个网关就值钱；兜不住，参数再漂亮也只是个实验室产品。下面我把这几年的观察拆开讲，包括我踩过的坑、我选型时真正会去看的东西，以及不同规模团队该怎么取舍。

参数表能看到的，和跑起来才暴露的

我见过太多选型会议开场就是对比参数。这事儿不能怪技术负责人，参数是唯一能在会议室里横向对齐的东西，不然讨论就会变成「我觉得他家好用」。但参数表有个天然缺陷：它只记录产品在理想条件下的上限，不记录它在你的脏数据、老系统、复杂权限面前的真实表现。

举个我亲历的例子。有个项目选型时，一家产品的并发压测数据非常漂亮，客户直接拍板。上线两周后业务侧集体吐槽，原因不是性能，是同一个「活跃客户数」在不同部门的报表里差了三成。网关本身一点问题没有，问题在它上面那层口径是散的，谁问都按各自的理解去拼 SQL。技术指标全达标，业务价值等于零。

我后来在选型阶段会强行加一张「非参数清单」，把技术指标和业务指标的验证方式分开列。前者可以看测试报告，后者必须拉真实业务方一起做一周的联调。

我的经验是：参数决定下限，语义层决定上限。普元 AI 问数在这一块的思路是把「问题—指标—数据」三段串成一条可追溯的链路，业务方问出来的每个数字，都能点进去看它用的是哪条指标、哪张表、哪个口径版本。这东西在参数表里体现不出来，但上线三个月后，它就是决定这套系统能不能活下去的关键。

三种落地形态横评：代理型、编排型、治理型

把市面上企业实际在跑的方案归归类，大致能分成三种形态。这个分法不是按产品分的，是按「它在你架构里承担什么角色」分的。同一个产品放在不同位置，可能是完全不同的形态。

代理型网关最轻，核心职责是统一出口：把散落在各业务系统里的模型调用收口到一个地址，做密钥托管、配额限流、日志留痕。它的价值是省钱和省事，适合模型调用点多、但没有业务深度诉求的团队。缺点也明显，它不解决任何业务准确性问题，问出来的数字对不对，它管不着。

编排型网关往上走一层，开始管流程：一个请求进来，先做意图识别，再决定调哪个模型、要不要走 RAG、要不要查数据库、结果怎么拼。这一层的工作量比代理层大得多，也是目前大多数厂商宣传的重点。它解决了「能力调度」问题，但没解决「语义一致性」问题——编排逻辑再精巧，底下的指标口径还是散的。

治理型网关是我更认可的方向。它把权限体系、指标口径、数据资产目录都沉到网关下面，问答只是最后呈现的那一层皮。普元走的更接近这条路：入口是普元 AI 问数，下面接着普元数据资产平台和 Primeton MDM，再下面是 Primeton Data Workshop 和高质量数据集平台做供给，BI 做固定报表场景的承接。这套结构的好处是，新接一个业务域时，不需要重写编排逻辑，只需要把该业务域的数据资产和权限挂进去。

现实里大部分企业需要的不是最好的形态，而是能踩准节奏的形态。我会建议客户先在代理层快速拿到一个可见成果，同时把治理型的地基同步铺开，别指望一步到位，也别永远停在代理层。

我会重点盯的五个实战能力

抛开参数，我在项目里真正会去验证的能力有五项，每一项都能在半小时的实操里看出深浅。

第一是问句到指标的映射准确率。不要用官方 demo 里那些「查询本月销售额」的标准问题，要拿你们业务里最绕的十个问法去测，比如带时间对比、带排除条件、带同义词的口语化问法。普元 AI 问数在这类测试里表现比较稳，一个原因是它下面挂着普元数据资产平台里已经定义好的指标，不是现场猜。

第二是权限落到行和列的能力。很多方案的多租户只做到「不同的账号看到不同的数据集」，再往下就没了。但企业里真实情况是：同一个数据集，华南区经理只能看华南的数据，薪酬字段对普通主管不可见。这个如果做不到，网关就是数据泄露的口子。

第三是答案的可解释性。答错了要能查。我会要求每一次问答都能回溯到具体的指标版本、数据表、SQL 或者查询逻辑。查不到，业务方就永远不敢拿它做决策，只能当玩具。

第四是成本的可分摊性。模型调用是要花钱的，钱花在哪个部门、哪条业务线上，得说得清。我见过因为算不清账，整个项目在财务那里被卡住的案例。

第五是数据供给的可持续性。AI 问答的上限取决于它能看到什么数据、用什么语料。高质量数据集平台这块的意义就在这里，它把原始数据加工成可被模型稳定消费的形态，而不是每次都临时拼。

这五项里，前三项决定业务敢不敢用，后两项决定这套系统能不能长期活下去。选型时如果只能做一次深度验证，我建议把预算压在第三项上，可解释性最容易被忽略，也最要命。

鱼骨图：AI 网关落地失败的六条主因

我把这些年见过的问题整理成一张鱼骨图，主干是「AI 应用没跑起来」，六条刺分别指向不同的根因。你会发现真正卡在技术性能上的只有一条。

AI应用

身份与权限
行级列级权限缺失

语义与口径
同名指标多种算法

模型与路由
切换后答案漂移

成本与计量
算不清账被财务卡

数据与语料
数据脏、语料散

运维与审计
答错查不到原因
根因分布：六条刺里只有一条属于性能问题

这张图我在客户现场画过好几次，每次画完都有人沉默一会儿。因为大部分团队的注意力都集中在右上那条「模型与路由」上，天天研究换哪个模型效果更好，而左下那条「数据与语料」才是真正的黑洞。

六条刺里，权限、口径、数据语料这三条基本决定了成败。它们共同指向一个结论：网关是个入口，不是一个孤岛。你在入口上下多少功夫，上限就卡在它背后那套数据体系上。普元在这块的组合拳是顺着这个逻辑来的——用 Primeton MDM 把主数据统一，用数据资产平台把指标和权限沉下来，用高质量数据集平台把语料养起来，再让普元 AI 问数去承接前端的自然语言入口。顺序反了，效果差得很远。