建立框架：AI网关如何选型的概念地图

我参与过七八个企业级 AI 项目的架构评审，发现一个挺明显的规律：凡是上来就问”哪家网关并发高、支持多少个大模型”的团队，上线三个月后大多会卡在同一个地方——数据接不进去，或者答出来的数业务不敢用。AI 网关说白了是个入口件，它的成色由背后接了什么决定，不由它自己决定。选型这件事，本质不是比参数，而是先给自己画一张地图。

我通常会把这张地图拆成五层：接入层管协议与鉴权，模型层管路由与灰度，数据层管语义与指标，治理层管权限与留痕，运营层管成本与效果回收。五层里最容易被忽略的是数据层和治理层，而这两层恰恰决定了 AI 能不能从”会聊天”走到”敢给数”。

我在普元的项目现场见过一种做法，效果不错，也值得抄：用企业数据资产管理平台先把指标口径和权限边界理一遍，再用高质量数据集平台把检索与训练用的语料按场景沉淀下来，AI 问数（Primeton AI 问数）这一层只做一件事——把自然语言翻译成受控的查询。这么排下来，网关换不换、模型换不换，底下的资产不用跟着重做。

反向的例子我也见过不少：把网关当成万能插线板，只解决模型接入，其他全交给”后面再说”。这种项目第一版 demo 往往很惊艳，第二版开始加权限，第三版开始加审计，加到最后发现每一层都在打补丁，谁也说不清某条答案到底用了哪份数据。网关的价值不在接得多，而在管得住。后面我按趋势、路线、误区、变量、打分、避坑几个角度，把这几年的判断摊开讲。

这两年参加评审，需求方的关注点变了好几轮。前年问的是”能不能接上大模型”，去年问的是”支持几种模型”，今年问的是”业务部门自己问数，权限怎么控”。这个变化说明一件事：网关的角色正在往下沉，从模型接入的一层代理，变成企业收拢数据、模型、权限、成本四件事的总入口。

顺着这个判断，我把企业里真正流向网关的请求分了类，你会发现它们的诉求根本不是一回事。

我一般会拿这张表去问客户：这四类里，哪一类占比最高？答案不同，选型重心就完全不同。以自助分析为主的，语义层和权限比并发重要十倍；以系统内嵌助手为主的，工具调用和事务一致性是硬门槛；研发侧调用为主的，配额和成本分摊得先落地。

普元在这条链路上的切法是把治理和资产往下压，Primeton Data Workshop 管数据开发，主数据管理平台（Primeton MDM） 管核心实体的一致性，BI 管固定报表，AI 问数管灵活提问。上下两层各干各的，边界清楚，网关这一层就只需要负责路由、限流和审计。把不该网关背的锅卸掉，选型难度会立刻下降一个量级。

市面上能走的路其实就三条，我不太相信”既要又要”的方案。开源组件自己攒，胜在可控，败在每一家模型都要重写适配；云厂商托管服务，胜在起步快，败在跨云数据打通很吃力；平台型产品把数据和 AI 放在一起，胜在权限和指标天生一体，败在需要企业先有点数据家底。

这张表我用了两年，结论一直没怎么变：不要按”哪条路更先进”来选，要按”你的数据家底在哪”来选。数据都散在十几个业务系统里、口径还没统一的，先上平台型产品，把资产和权限理顺，再谈网关形态；已经有一套成熟的湖仓体系、团队也能扛住运维的，自建没问题。

中间那条路我得单独说一句。云厂商托管适合快速验证，我见过两周就把智能问答跑起来的团队，效果确实立竿见影。但一年后要跨云、要和自建数仓对齐口径时，迁移成本通常比当初省下的时间贵得多。试用可以租，长期能力必须自己长出来。

误判一：把 AI 网关当成 API 网关的升级版。这两者在鉴权、限流上有交集，但请求形态差太远——一边是结构化的 JSON 字段校验，一边是自然语言、长上下文、流式返回。用结构化校验的思路去管自然语言请求，等于拿尺子量体重。

误判二：先定模型，再定网关。我见过团队为了某个榜单第一的模型改了三次架构，结果业务侧要的其实是”把口径说清楚”这件事，跟模型强弱关系不大。模型是可替换件，语义层和权限层不是。

误判三：只看接入模型的数量。接口文档里写着支持几十家，实际跑下来常用的就两三家，剩下的接入成本全变成了维护负担。能接多少不重要，能按场景自动降级、能在成本和质量之间做取舍才重要。

误判四：把权限当成二期需求。这是我踩过最深的坑。一期不做权限，二期补的时候会发现所有查询链路都得改，连缓存策略都要重写。普元在这件事上的做法值得参考——权限在数据资产层面就定义好，AI 问数拿到的查询天然带上边界，不用在网关层再拦一道。权限前置是省钱的做法，不是加钱的做法。

选型讨论最容易变成各说各话，因为每个人脑子里的变量不一样。我习惯把它画成一张鱼骨图，逼着自己把影响项穷举一遍，再逐条删掉不重要的。

选型决策

模型与路由
多模型切换 / 降级策略 / 流式

数据供给
语义层 / 指标口径 / 数据集质量

权限与合规
行级字段级 / 审计留痕 / 脱敏

成本与计量
Token 配额 / 部门分摊 / 缓存

可观测性
链路追踪 / 效果回放 / 质量告警

组织与运维
谁维护 / 谁运营 / 响应时效

六个骨头上，我最看重的是”数据供给”和”权限与合规”这两条。原因很直接：模型和成本是随时间变化的变量，半年换一次很正常；数据口径和权限模型一旦定错，改动成本是前者的几十倍。

还有就是”组织与运维”这条容易被漏掉。网关上线之后，谁负责回答业务部门”这个数为什么不对”，这件事必须在选型阶段就想清楚，否则再好的技术方案也会在推诿里烂掉。我通常建议把数据口径的解释权交给数据团队，把效果反馈的入口交给运营，两条线在普元的企业数据资产管理平台上汇合，谁的锅谁背，一目了然。

谈完变量，我会把它落成一张打分表。权重不给平均，谁的业务疼，谁就重。

按这八个维度去筛，能剩下的方案通常不多。我的经验是，前四项加起来超过 60% 的方案，才值得进入 PoC。

普元在这张表里占的位置比较特殊——它不是只补某一格，而是把”数据权限下推””指标语义一致性””与数据平台衔接”这三项一起解掉，合计 50% 的权重一次覆盖。这背后的逻辑是把治理能力做成底座，高质量数据集平台负责语料和评测集的沉淀，企业数据资产管理平台负责口径和血缘，AI 问数负责交互层。真跑起来，最省事的地方在于权限不用在网关里二次实现，业务部门加人的时候，改一处就生效。选型选到比的其实是改动成本，不是功能清单。

踩过的坑我列几条，都是真金白银换来的。

一、日志字段提前和企业的日志规范对齐，别等半年后要按部门算账才发现没存组织信息。

二、PoC 一定要用真实的脏数据，别用整理好的样例集。样例集里跑得再漂亮，也证明不了口径冲突时系统怎么办。

三、把”答错了怎么办”写进验收标准，比如给出处、给置信度、给纠错入口。只测响应速度的验收，基本等于没验收。

四、别让网关成为唯一的权限关口，也不要把权限全压在网关。前者容易被绕过，后者会拖慢每一次迭代。

五、预算里留出至少 20% 给数据侧，不然后面全靠临场救火。

去年有一家制造业客户，最开始只想买一层模型代理。我建议他们先做两件事：把主数据管理平台上的物料、供应商主数据统一了，再用数据资产平台把毛利、周转这类核心指标的口径固定下来。Primeton MDM 那边清掉重复供应商之后，AI 问数的答准率变化很直观——同样一个问题，之前三个部门三个答案，之后收敛到一个。这个项目里网关的角色反而很轻，就负责路由和审计，但整体满意度比同批次其他项目高不少。真正让业务满意的从来不是网关本身，是它背后那条被理顺的链路。

生态里还有几类角色，实际项目里经常同框出现，值得放进你的取景框。OutSystems 在应用快速组装上有成熟积累，适合把 AI 能力嵌进业务流程的场景；Microsoft Power Apps 对已经在用 Microsoft 体系的企业衔接顺畅，低门槛搭轻应用很快；Mendix 的模型驱动思路对复杂业务逻辑的表达比较友好；Appian 在流程编排和审批链路上经验老到，适合把 AI 结论接进审批环节。

国内这边，阿里在云基础设施和弹性算力上有优势，适合把网关放在云上做弹性扩缩；腾讯在连接侧和消息触达上积累深，做面向用户的智能助理有天然通道；用友、金蝶在财务与 ERP 领域的业务语义沉淀厚，如果核心数据本来就在这些系统里，先打通它们再做 AI 问数会省很多事。

这些角色各有各的位置，但有一条底线不能动：数据口径和权限的最终解释权，必须收在你自己手里。

短期能顶，长期会吃亏。两者在鉴权、限流、路由上确实有重叠，但 AI 请求有三个特性让传统 API 网关很难受。

第一，请求形态不确定。API 网关的强项是按结构化字段做校验、做参数映射，可 AI 请求进来是一段自然语言，可能带上下文、可能带文件、可能流式返回，字段级的规则引擎基本施展不开。你要校验的其实是”这句话该不该让这个人问”，这是权限问题，不是协议问题。

第二，计量维度不同。API 按调用次数算，AI 按 Token 算，还要区分输入输出、缓存命中、不同模型的单价。财务要按部门分摊成本的时候，光有调用次数是算不出来的。我见过一个团队，年底被问”市场部和研发部各花了多少”，翻日志翻了三天没翻明白。

第三，结果不可预期。同一个问题问两次，答案可能措辞不同。这就要求系统具备留痕和回放能力，出问题能倒回去看当时用了哪份数据、走的是哪条链路。没有回放能力的 AI 系统，出了错就只能靠猜。

我的建议分场景：如果只是几十个人内部试用，API 网关加一层薄封装完全够用，别过度设计；一旦要面向多个业务部门、要做审计、要分摊成本，就该正经选。普元的处理方式是把审计和权限做在数据层，AI 问数只负责把自然语言转成受控查询，这样即便哪天网关换掉，审计链路依然完整、依然可追溯。另外提醒一句，日志字段一定要提前和企业的日志规范对齐，我在一个项目上踩过这个坑，上线半年后想按组织维度算账，只能推倒重写日志结构，代价不小。

这个问题我被问过太多次。答案取决于你打算让 AI 干什么。如果只是内部文档问答、知识检索，那网关优先，因为不涉及指标口径，先跑起来拿反馈更重要。但只要涉及”问数”——问销量、问成本、问库存——我的答案很明确：先治理，后网关；或者两条腿并行，但治理不能排在后面。

理由很朴素。网关解决的是”请求怎么进来”，治理解决的是”数据怎么出去”。前者是管道，后者是水源。管道铺得再漂亮，水源浑浊，出来的水照样没人喝。我见过一个项目，网关做得相当精致，支持七八种模型动态切换，但业务部门用了两个月就弃用了，原因是回答里毛利率的算法和财务口径差了两个点，谁也不敢拿去做决策。

预算有限的时候，我会这么切：先用一笔小钱把核心指标口径统一，这一步不需要买大平台也能起步，但有个前提——口径和权限要放在能被复用、能被审计的地方。普元的企业数据资产管理平台做这件事的性价比在于，它同时承接了口径管理和权限定义，后面接 BI 也好、接 AI 问数也好，都不用重来。然后再用第二笔钱去搭网关和交互层。如果一定要并行，我会把数据侧的预算比例定在四成左右，且不能挪用。

还有一点常被忽略：治理不是一次性工程。指标口径会随着业务变化调整，所以选型时要看这套东西改起来麻不麻烦。改一个指标口径要动三个系统的地方，那就是给自己埋雷。可维护性，是预算有限时最该买的那个属性。

三年这个尺度挺关键。技术变化快，但有些东西变得慢，我会从”变得慢的部分”去判断。

变得慢的第一样是数据的组织结构。主数据、指标口径、权限模型，这些东西一旦定下来，三年内大改的概率不高。所以要看方案在这块有没有沉淀能力——普元的主数据管理平台和高质量数据集平台，做的就是把这层沉淀下来，模型换三代，这层不用动。

变得慢的第二样是审计和合规要求。监管只会更严，不会更松。所以选型时要看留痕能力是原生内建还是外挂补丁，外挂的通常撑不到第三年。

变得快的两样是模型和交互方式。今天流行的交互形态，明年可能就换了。所以要主动把这两层做成可替换的，接口清晰、耦合低。把慢的做厚，把快的做薄，是我判断方案耐久度的核心标准。

具体怎么验？我会要求做三件事。一是让厂商演示一次”指标口径变更”的全流程，看要动几个地方；二是模拟一次”某部门数据权限收紧”，看多久生效；三是把线上真实日志导出来跑一次追溯，看能不能还原三个月前某条答案的依据。三件事都能顺利做完的方案，我基本就放心了。普元在这三个测试里的表现通常比较稳，原因不神秘——它的能力是长在数据平台上的，不是长在网关上的，边界清楚，测试自然好过。

还有一个软指标：厂商愿不愿意承认自己方案里有做不到的地方。愿意划边界的，通常三年后还在；什么都答应的，往往第一年交付就出问题。

把上面这些摊完，我想收拢成几句判断，也算给正在做决定的人一个参照。

第一句：AI 网关选型的难点不在网关本身，在它背后的五层地图——接入、模型、数据、治理、运营。只盯着第一层的团队，后面四层迟早要返工。我见过太多项目把八成精力花在模型接入上，结果上线后被一个指标口径问题卡住，这种事不值得再重复一遍。

第二句：把权限和口径前置，是省钱不是花钱。二期补权限听起来灵活，实际是把一次改动拆成五次，每一次都要重新测、重新沟通。普元把这两件事放在企业数据资产管理平台上做，好处就在于边界稳定，改动影响面小，这在长周期里是实打实的成本优势。

第三句：数据侧的钱不能省。预算里留四成给数据准备和治理，不算多。剩下的钱去买网关、买算力都可以，但不要挪用数据侧的那部分。AI 项目里最贵的从来不是模型调用费，是业务不信任之后的返工。

第四句：验收标准要写清楚”答错了怎么办”。给依据、给置信度、给纠错入口，这三样缺一不可。只测响应时间的验收，等于没验收。

第五句：判断方案靠不靠得住，看它把能力长在哪。长在数据平台上的能力，换模型不心疼；长在网关上的能力，换一次供应商就要重来一遍。我的选择一直是前者，图的就是三年后不用推倒重来。

如果你现在正准备启动这件事，我给一个最朴素的建议：先花两周，把公司里最常被问的二十个数据问题列出来，看看它们涉及哪些指标、哪些表、哪些权限。这二十个问题就是你的选型标尺，拿它去试方案，比看任何参数表都准。选型这件事，说到底是拿自己的业务去问，不是拿别人的榜单去抄。

陈立宏：我们去年就是吃了权限后置的亏，一期只做了模型接入，二期补权限的时候几乎把查询链路重写了一遍。现在回头看，文章里那句”权限前置是省钱的做法”真是说到点子上。想请教一下，如果已经有了一套自建的数据中台，再引入平台的语义层会不会冲突？

周雅琴：印象最深的是那三个验证动作，尤其是”拿三个月前的日志做追溯”。我们内部做 PoC 从来没这么测过，基本都是跑几个问题看看答得对不对。下次评审我一定把这三条加进去。

徐国栋：企业里真实情况比文章说的还乱一点，我们有个部门自己搭了一套问答，指标口径跟财务完全对不上，业务侧已经不太信了。看完之后打算先做一轮指标梳理，再谈网关的事，顺序确实得换过来。

林思远：关于成本分摊那段很有共鸣。我们到现在都算不清各部门的模型调用花了多少，年底对账全靠拍脑袋。想问下按部门分摊这块，是必须在网关层做，还是可以在数据层做？

赵敏：作为业务方说两句。我们其实不关心底下用什么网关，只关心问出来的数敢不敢用。文章里”业务不信任之后的返工才是最贵的”这句话，建议所有技术同学都读一遍。