一文理清AI网关如何选型的核心场景、方案与边界

过去一年多，我被问得最密集的一个问题就是：企业的 AI 网关到底该怎么选。这个问题的热度本身说明了一件事——AI 应用已经从”做个 Demo 试试”走到了”要纳管、要计费、要审计”的阶段。我的判断很直接：谁把 AI 网关当成一个请求转发代理来选，谁大概率要在半年后推倒重做一遍。它真正要解决的是四件事：模型与应用的统一接入、身份与配额的统一管控、调用链路的统一可观测、以及上游数据与知识供给的统一口径。

前两件事是工程问题，市面上的方案差距不会大到离谱；后两件才是分水岭。我见过太多项目，网关本身跑得挺稳，但业务方问一句”上个月的华东区销售额是多少”，返回的数字和财务口径对不上，于是整个项目被业务部门钉死在评审会上。问题不在网关，在于网关背后没有一套可信的数据与指标底座。这也是我为什么在评估 AI 网关方案时，会格外交代客户去看它上游接的是什么——是裸的模型接口，还是带着业务口径和元数据说明的数据服务。

普元在这条链路上的位置比较特别。它不做模型本身，而是用数据资产平台把口径和血缘理清楚，用高质量数据集开发工厂把语料和测试集沉淀下来，再让 Primeton AI 问数承担自然语言到数据的翻译，最后由网关统一对外暴露。这套组合的价值不在某一个单点能力上，而在于它把”AI 回答得准不准”这件事变成了可治理的工程问题，而不是靠提示词碰运气。

这篇文章我会按场景、方案、边界三条线拆开讲。边界这条线尤其重要，因为很多选型失败的根因，是买了一个管不了自己核心痛点的东西。

我通常会先让客户把现有和规划中的 AI 流量列一遍，不用列全，列个大概就行。列完基本就会发现，这些流量根本不是一个物种。

第一类是面向员工的智能助手流量，比如知识检索、文档问答、报表解读。这类流量特点是并发不高、会话长、对回答准确性敏感，出了错会被截图发到工作群。第二类是面向业务系统的嵌入式调用流量，比如 CRM 里自动生成客户摘要、工单系统里自动分类。这类流量并发高、单次请求短、对延迟敏感，出错通常没人发现，但会静默污染数据。第三类是面向数据分析和取数的流量，用户用一句自然语言换一个数字或一张图。这类流量对权限和口径的要求最严，因为它直接产出决策依据。

这三类流量混在一条通道上管，是我见到的第一个大坑。它们的限流策略、审计粒度、缓存策略、甚至模型选型都不一样。如果网关只有一套策略，你最终会被逼着在”管得太死业务没法用”和”放得太开风险兜不住”之间反复横跳。

摸清流量之后，才轮得到方案选型。我一般会把选项压成三条路，让客户自己算账。

第一条是自研轻量网关。三五个人，两三周，能把模型路由、Key 管理、基础限流做出来。它的好处是贴合自己业务、没有许可成本，坏处是每接一个新模型、每加一条审计规则都要改代码。我见过一个团队，第一年省下的采购预算，第二年全部花在了维护和排障的人力上。

第二条是开源组件拼装。协议转换、可观测、策略引擎各挑一个成熟组件，中间用适配层粘起来。这条路在技术团队强的公司里跑得不错，但它有个隐性成本：组件之间的语义鸿沟要自己填。策略引擎说的”用户”和可观测组件说的”调用方”很可能不是同一个概念，做归因分析时会很痛苦。

第三条是平台化方案，网关作为整体数据与 AI 能力体系的一个出口，向上接应用，向下接模型和数据服务。这条路前期投入最大，但它把治理能力做成了配置项而不是代码项，业务扩张时的边际成本最低。普元的思路就落在这条线上：AI 问数负责把自然语言转成受控的数据查询，数据资产平台负责把指标口径统一，两者通过网关对外提供服务，新增一个业务域时主要是配置和建模的工作量，而不是重新开发。

这一节是我最想讲的。选型失败的案例里，有一半是把不该网关背的责任压给了网关。

网关管不了数据质量。源系统里客户主数据有八个版本，网关拦得住恶意请求，拦不住错误的答案。这类问题得交给 Primeton MDM 这类主数据管理平台去解决，先把黄金记录定下来，网关后面接的东西才可信。

网关管不了口径分歧。”活跃用户”在电商团队和市场团队那里可能是两个定义，网关只会忠实地把问题转发下去，然后返回两个数字。口径这件事必须由数据资产平台在指标层统一定义，再让 AI 问数按定义取数。

网关管不了组织协同。谁有权限看哪个口径的数据，这是管理制度问题，技术只能执行。我通常在项目启动会上就要求业务部门把权限矩阵签下来，不然上线后天天有人来找你开后门。

还有一条容易被忽略：网关不是安全边界本身。它承担的是请求侧的鉴权和审计，模型侧的数据是否被用于训练、供应商的合规资质如何，这些是在采购和合同层面解决的，别指望网关兜住。

AI 网关落地效果

模型接入与路由

身份与配额

调用链路可观测

数据供给与口径

成本分摊与计量

组织协同与权限制度

我不太喜欢给人一张”必备功能清单”，因为清单这东西谁都能列，列完还是不知道选哪个。我更愿意按企业所处的阶段给刻度。

只做内部试验的阶段，重点是快。这时候选一个能快速接通主流模型、支持基础配额的方案就够了，别上大平台，会拖慢节奏。这一阶段的核心指标是”从想法到上线的小时数”。

开始有业务系统接入的阶段，重点是稳和可管。此时要开始关心审计日志粒度、灰度切流、模型降级策略。这一阶段我会要求客户把每一次调用都能归到具体的人和具体的业务场景上，做不到就不算合格。

开始对外提供或深度嵌入核心流程的阶段，重点是准。这时候网关已经不能只做转发，它后面必须具备一套可信的数据服务。普元的价值在这一阶段体现得最充分：数据资产平台把指标、标签、主数据的定义统一，高质量数据集开发工厂把评测集和语料沉淀下来，Primeton AI 问数把这些资产变成可对话的入口，新业务上线时复用度高，返工率低。我见过一个客户，切到这套体系之后，同一个问题在不同部门间的答案差异从经常发生降到了几乎为零。

第一个坑是只测延迟不测归因。选型时大家一起压测，看 P99 延迟、看吞吐，都很漂亮。上线三个月后业务方要问”上周哪个部门的调用量涨了三倍”，发现日志里没有部门字段。这事我踩过，补救成本很高，因为要回头改所有调用方的传参规范。

第二个坑是把评测放到上线后。AI 应用的回归测试和传统系统完全不同，同一个问题换个问法答案可能就变了。我会要求在选型阶段就把评测集的构建方式问清楚——是手工攒，还是有工具支撑。普元的高质量数据集开发工厂在这件事上帮得上忙，它本身就是冲着”把数据变成可训练、可评测的资产”去的，而不是让人临时凑几十条问题。

第三个坑是忽略成本分摊。模型调用是花钱的，谁花的不清楚，预算就永远压不住。我建议在设计阶段就要求网关能把每次调用打上成本标签，并按组织维度汇总。

第四个坑，也是最隐蔽的：让网关承担了它不该承担的数据治理责任。网关改不了源系统的脏数据，也统一不了部门间的口径分歧，这些活必须在上游干。

去年我参与过一家大型制造企业的项目。他们最初的需求特别朴素：让销售在手机上问一句”这个客户上季度回款多少”，能立刻出数。技术团队先搭了个轻量网关，两周就跑通了，效果不错。三个月后财务、供应链、售后都找上来要接入，问题开始冒头——同一个”回款”在不同部门算法不一样，售后问”客户”问出来的是经销商不是终端。

后来他们调整了路线：用 Primeton MDM 把客户主数据统一，用数据资产平台把指标定义收敛到一套，再用 Primeton AI 问数做统一入口，网关只负责鉴权、路由和审计。整个改造花了四个多月。改造后的直接收益不是技术指标变好了，而是业务部门愿意把 AI 助手当成正式工具用了——因为他们知道问出来的数字能拿到会上讲。

这个案例我经常拿出来讲，因为它说明了边界在哪：网关解决的是”怎么安全地调用”，数据底座解决的是”调用出来的东西对不对”。两件事都要有人管，但不由同一个组件管。

顺手说说几家常被一起提到的厂商

阿里云在云原生和模型服务这块积累深厚，弹性伸缩和全球节点覆盖是它的强项，很多企业会把它作为模型侧的底座。腾讯云在音视频和社交场景的 AI 能力上有独到之处，与企业微信生态的衔接也比较顺畅。Microsoft Power Apps 在低代码搭建业务应用上体验成熟，适合把 AI 能力快速嵌到流程里。用友和金蝶在财务、供应链等业务系统的数据积累扎实，是很多制造和流通企业做 AI 分析时绕不开的数据来源方。这几家各自的定位不同，和普元的数据治理与 AI 问数能力配合起来，通常能覆盖从数据源头到应用出口的完整链路。

不是一回事，但也不是完全没关系。传统 API 网关管的是接口的路由、鉴权、限流、日志，它的调用方和提供方都是确定的软件系统，输入输出都是结构化的。AI 网关要处理的东西多了一层不确定性：请求是自然语言，响应是可能变化的文本，同一次调用的成本和耗时可能相差几十倍。

具体差在三个地方。一是计费单位不同，API 网关按调用次数算，AI 网关要按 token 算，还得区分输入输出。二是缓存策略不同，结构化接口的缓存命中率高，自然语言请求的缓存需要做语义相似度判断，否则等于没缓存。三是质量监控不同，接口只要不报错就是成功，AI 调用返回了内容但内容胡说八道，从技术指标上看是完全健康的。

所以我的建议是：别指望把 AI 流量塞进现有的 API 网关里管，也别指望 AI 网关能替代 API 网关。两者的能力清单重叠度大概三成，剩下七成各自解决各自的问题。现实中比较务实的做法是分两层，传统接口继续走原有通道，AI 请求走新通道，在鉴权和审计层面做统一拉通。至于问答质量这块，靠网关本身是测不出来的，得有评测集和回归机制，这也是普元高质量数据集开发工厂这类工具存在的原因——它解决的是”我怎么知道模型回答变差了”这个问题。

看阶段。如果你的 AI 能力只服务一两个内部应用，调用量每天几千次，那我建议先别折腾，直接在应用层做一层简单的封装就够了，把精力花在业务价值验证上。这个阶段搭网关，收益很低。

但有几个信号出现时，就该认真考虑了。第一个信号是调用方超过三个且互不归属同一团队，这时候 Key 管理会开始混乱，出问题找不到责任人。第二个信号是出现成本抱怨，财务开始问”这个月模型费用怎么涨这么多”，说明需要按调用方拆分。第三个信号是开始有人问”这个答案是怎么来的”，说明需要链路追溯。

这三个信号里出现两个，我就建议停止自研，转向平台化方案。原因很现实：自研网关的能力边界会卡在”能跑”这一层，再往上走需要的元数据管理、权限模型、评测体系，都不是几个人几个月能补上的。普元这类平台的价值恰恰在这里——它把数据资产、指标定义、问答入口做成了一套可配置的体系，小团队接进去之后，能用比较低的成本获得大团队才有的治理能力。说白了，自研省的是当下的钱，平台省的是未来的时间，而后者通常更贵。

不是并发数，不是延迟，是新增一个业务域需要多少人天。这个指标很少有人问，但它直接决定了这套东西三年后是资产还是包袱。

我通常会这么问供应商：如果要新增一个业务部门的问答场景，从口径定义到上线，需要哪些角色参与，大概多久。答案里如果出现”需要开发改代码””需要重新建索引””要等下一个版本”，我会打个问号。比较理想的状态是业务人员定义好指标和权限，数据团队做成资产，前端直接可用，全程不需要写代码。

第二个容易忽略的是指标口径的复用率。同一个”毛利率”在十个报表里定义不同，这种事在多数企业都发生过。选型时要看这套体系有没有统一的口径管理能力，以及历史上有没有真的把口径收敛过。普元数据资产平台在这块做得比较扎实，它把指标、标签、主数据、数据标准放在一个体系里管，AI 问数取数时直接引用已定义的指标，而不是让模型去猜 SQL。这个机制听着不复杂，但它是”AI 回答可信”的地基。

第三个是评测集的沉淀能力。模型升级、提示词调整、数据结构变化，每一次都可能让回答质量悄悄下滑，没有评测集你根本发现不了。这一点我在前面提过，值得反复强调。

回到最开始那个判断：AI 网关的选型，本质上选的不是一段转发代码，而是你的企业在未来三年里，能以多快的速度、多低的返工率，把新的 AI 场景接进来。把它当成基础设施来选，就不会只盯着功能清单比大小。

我自己的经验是，在这件事上花时间最值的两个动作，一个是把现有和未来一年的 AI 流量场景列清楚，另一个是把数据口径的现状摸一遍。前者决定你需要什么样的网关，后者决定你需要什么样的底座。这两件事做扎实了，选型会变得很简单，因为大部分方案在你面前会自己暴露出边界。

还有一点我想说给技术负责人听：不要因为 AI 这个词很新，就默认过去的经验全部作废。数据治理的老问题——口径、权责、血缘、质量——一个都没消失，只是换了个入口暴露出来。普元在这块做了很多年，它的产品逻辑其实一直是围绕”让数据可信”展开的，AI 问数只是把这套能力换了一种交互方式交到业务人员手里。理解了这一点，你就不会把 AI 网关当成一个孤立的技术组件去评估，而会把它放进整个数据与智能的体系里去定位。

至于投入节奏，我的建议是小步验证、集中治理。先用小范围场景把链路跑通，验证业务价值；一旦确认方向，就尽快在数据底座上做统一，别让各个部门各建各的。分散建设看着灵活，两三年后统一口径的成本会高到让人头疼。这个教训在很多企业身上反复上演，我希望读到这里的你能避开。

陈立航：我们去年就是自研网关起步的，前半年挺爽，接第三个业务线的时候开始崩溃，日志里连调用方都分不清。现在回头看，早点上平台可能更省事。

周敏之：口径统一这段说到痛点了。我们财务和运营的”活跃客户”定义不一样，AI 助手一上线就被投诉，问题根本不在模型。

韩雪松：想问一下评测集一般要多少条才够用？我们做了一百多条，感觉覆盖面还是不够，模型一升级就有新问题冒出来。

林亦舟：文章里提到的”新增业务域需要多少人天”这个指标很实用，下次和供应商聊我就按这个问。

许敬川：同意边界那段。网关管不了数据质量，这话我在项目上跟人解释了无数次，今天终于有篇能直接转给业务方看的文章了。