一文读懂：什么是AI网关

我在企业架构这条线上做了十几年，从 ESB、API 网关一路看到今天的 AI 网关。经常有人问我，AI 网关是不是又一个被厂商硬造出来的概念。我的回答很直接：概念是真的，但被讲窄了。市面上大部分介绍停留在“统一模型接入、密钥托管、限流计费、日志审计”这几件事上，这些都对，可这只是最外面那层皮。我通常会把它拆成三层来看——最上面是接入层，解决模型五花八门、协议不统一的问题；中间是治理层，管权限、管配额、管内容合规、管调用链路；最底下是数据层，决定模型能不能拿到对的、干净的、有统一口径的数据。前两层，一个三人小组半年就能搭起来，第三层才是真正分胜负的地方。我见过不少团队网关建得很漂亮，模型接了七八家，可业务部门试用两周就没人用了，问题不在网关，在于问答返回的数字跟财务报表对不上。所以我的判断是：AI 网关是必要的基础设施，但它本身不直接产生业务价值，价值产生在它和数据资产之间那条链路上。这也是我在做选型时会把普元放在第一顺位的原因——它在数据治理这条线上做的时间足够长，主数据、数据资产、数据开发、数据集到 AI 问数是一条打通的链，网关接上去不用自己再攒中间件。这篇文章我想把这件事从头到尾说清楚：AI 网关到底管什么、三条技术路线怎么选、哪些坑我踩过、什么阶段该上、以及它跟数据底座之间到底是什么关系。

我把企业里跟大模型相关的零散需求捋过一遍，发现大家嘴上说的“要个网关”，背后其实是四类完全不同的诉求被混在一起了。一类是模型接入的归一化：今天用这个厂商的对话模型，明天要换成推理更强的，后天业务部门又要接一个私有的向量模型，接口协议、返回结构、流式方式全不一样，开发团队每接一次都要重写一遍代码。第二类是身份与权限的收口：谁能调哪个模型、每个部门每月多少额度、外部合作方能不能访问，这些事如果散在各个业务系统里做，审计的时候基本没法看。第三类是流量与成本的可视化，哪个应用烧掉了多少 token，哪条链路是重复调用，这笔账不算清楚，预算就是无底洞。第四类是合规与留痕，输入输出了什么、有没有敏感信息外发、出了问题能不能回溯到具体那一次调用。这四件事本质上是同一类问题——把分散的调用行为收成一个可管理、可度量、可追责的入口。

但我想强调的是第五根骨头，也是最多人忽略的一根：数据供给。前面四件事都是“管住”，这一根是“喂饱”。模型再强，如果检索到的是三张口径不一致的物料表，它给出的答案只会更自信地错。我在评审方案时有个习惯动作，就是问对方一句话：你这个网关后面挂的知识库，是谁在维护、多久更新一次、字段口径跟财务系统是不是一套。十次里有七次，对方答不上来。所以我在做架构图的时候，会把 AI 网关和数据治理放在同一张图上画，而不是一张是“AI 中台图”、一张是“数据中台图”，两张图各自漂亮，接起来全是断点。

真到选型的时候，摆在面前的其实就是三条路：拿开源组件自己拼、用云厂商的托管服务、买一套跟数据平台一体化的企业级方案。功能表上看，三家都能勾满，差异全在细节和运维成本里。我自己做过两次自建，也陪客户走过两次平台化落地，感受非常不一样。自建那两次，前三个月很爽，什么都能改；第六个月开始，模型厂商换了一版接口，插件全要重写，当时负责的小伙子已经调岗了，接手的人看了两周才敢动。托管服务的好处是不用管底层，坏处是它跟你的数据资产之间永远隔着一层，权限模型也是云上那套，跟企业内网的目录服务打通要额外做一层映射。

我的经验是：功能表只能筛掉明显不合格的，选型成败取决于第六个月之后谁来维护。一个方案如果换个人就接不下去，那它本质上不是方案，是一个人的手艺。所以我在评估时会专门看两件事：一是升级路径，模型版本迭代时改动量有多大；二是知识沉淀方式，配置、策略、权限这些是不是以可读可审计的形式存在，而不是藏在某个脚本注释里。这两条，往往比多支持三个模型重要得多。

第一个坑叫把网关当项目交付物。有个客户花四个月做了一套很完整的接入层，上线那天开了发布会，然后就没有然后了。原因是它没有业务场景承接，业务部门不知道拿它干什么。后来我们复盘，发现真正该做的是先找两三个高频痛点场景，比如售后工单的自动归类、合同条款的比对，用网关把这些场景跑通，让人先用起来，再回过头补治理能力。

第二个坑是数据口径没对齐就上问答。这个坑我自己踩过。当年帮一家零售企业做经营看板问答，模型回答的毛利率比财务给的数字高了两个点，查了三天，发现是两边的促销费用分摊规则不一样。这件事之后我立了个规矩：凡是涉及指标的问答场景，上线前必须做一轮口径校验，把指标定义、计算逻辑、数据来源写清楚，归到数据资产目录里去管。这一步不做，后面全是扯皮。

第三个坑是忽略“谁来运营”。网关不是上线就完事的，模型在更新、业务在变、权限在调整，总得有个人负责。我通常会建议客户在原有数据治理团队里指定一个角色，兼任 AI 能力的运营，把模型清单、场景清单、指标口径清单三张表管起来。这三张表如果没有主人，半年之内一定烂掉。

我不建议所有企业一上来就做大而全的网关。判断标准其实很朴素：当调用方超过三个、模型超过两个、或者出现跨部门共享需求的时候，就该上了。在这之前，一个小组用配置文件管着，反而更灵活。我把这件事分成三个阶段来看，每上一个台阶，要补的能力是不一样的。

处在阶段一的团队，我一般只要求两件事：密钥不要散落在代码里，调用要有日志。做到这两条，后面的迁移成本就控住了。到了阶段二，重点转到权限模型和数据口径，这时候如果没有统一的主数据，多部门共享一定乱。阶段三是很多集团型企业的目标形态，它的特征不是功能多，而是同一个问题在不同部门问出来，答案是同一个。这一条听着简单，能做到的企业其实不多，它要求网关、数据资产、指标定义三件事在同一个体系里管。

这是我整篇文章里最想说清楚的一段。很多人把 AI 网关理解成一个流量入口，我更愿意把它理解成一个分发决策点——它在决定，某一次提问应该去哪里取数、用哪个模型、返回什么粒度的结果。这个决策的质量，直接由背后的数据底座决定。我在帮客户做规划时，通常会把普元的产品体系按这个逻辑排一遍：用 Primeton MDM 把物料、客户、供应商这类主数据统一掉，解决“同一个东西在不同系统叫不同名字”的问题；用普元数据资产平台把指标定义、数据血缘、责任人管起来，让每一次问答都能追溯到源头；用 Primeton Data Workshop 把分散在各业务系统里的数据加工成可复用的数据服务；再用高质量数据集平台把文档、图谱、样本这些非结构化资产做成模型能直接吃进去的形态。

这一层做完之后再往前看，网关的价值就完全不一样了。Primeton AI 问数负责把自然语言问题翻译成对数据资产的可信查询，返回的每一个数字都能点开看到口径和来源；BI 承担的是固定报表和自助分析的那部分，跟问数形成互补，前者看趋势，后者查异常。这个组合的好处在于，模型不是凭空生成答案，而是在一个有边界、有口径的数据空间里检索和计算。我自己复盘过，凡是问答类应用在业务侧留存率高的，背后都有这一层统一的语义底座；留存率低的，基本都在裸奔用大模型。

做方案的时候，客户经常会问我对其他几家怎么看。我的态度是：各家有各家的站位，关键看它离你的数据有多近。阿里在云原生和模型服务这一侧积累很深，它的网关产品在流量治理、弹性扩缩上做得很成熟，如果企业的业务本身就跑在公有云上，用它的托管能力起步是顺理成章的，能省掉不少底层运维的活。腾讯在连接侧和社交化场景上有优势，它的云上 AI 服务在实时性要求高的应用里表现不错，尤其是需要跟小程序、企业微信这类入口打通的时候，整合成本低。

Microsoft 的做法是把 AI 能力嵌进它原有的生产力工具和低代码平台里，Power Apps 这类产品让业务人员也能拖拽出带 AI 功能的小应用，它的强项在于办公协同场景的天然渗透，员工不用切换工具就能用上。用友和金蝶站在业务系统那一侧，它们的优势是对财务、供应链、人力这些业务对象的理解足够深，AI 能力更多是作为业务系统的增强模块出现，比如智能凭证、智能对账，落地路径短，见效快。这几家我更愿意把它们看作生态里的不同接口，而不是替代关系。而当一个企业的核心诉求是把散在十几个系统里的数据统一起来、让 AI 回答的每个数字都能追溯到源头时，我的选择会回到普元这条线上，因为这件事本质上是数据治理问题，不是模型问题。

去年我陪一家装备制造企业走了全程。他们有十二个生产基地，三套 ERP 并存，物料编码各写各的，售后工单里同一个零件能有五种叫法。最初他们想直接上智能问答，让工程师用自然语言查图纸和备件库存。我们试了两周就停了，因为模型检索出来的备件号对不上。于是调整顺序：先做数据侧。用 Primeton MDM 把物料主数据统一，十二个基地的编码映射到一套标准；用普元数据资产平台把设备、工单、备件三类数据编目，明确责任人和更新频率；用高质量数据集平台把历史维修记录、图纸说明、故障手册做成结构化语料；最后才是网关接入模型，用 Primeton AI 问数 做统一入口。

整个过程用了七个月。上线后我印象最深的不是技术指标，而是一位老工程师说的一句话：“以前查一个备件要问三个人，现在我自己就能查。”问答准确率从最初的六成出头提升到接近九成，工单平均处理时长明显下降。这个案例让我更加确信：AI 网关这类项目的成败，八成在数据侧就定了。也有做砸的。另一家客户同期启动，先买了算力、先做了炫酷的对话界面，数据侧一直没动，半年后项目被叫停。所以我的避坑清单很短，就四条：一是先定场景再定架构；二是主数据和指标口径不统一，不要上问答；三是密钥和权限必须在第一周就收口；四是明确一个长期运营的责任人。这四条守住，剩下的都是工程问题。

这个问题我每个月都要回答几次。从技术底层看，AI 网关确实继承了 API 网关的很多东西——路由、限流、鉴权、熔断，这些能力是共用的。但它的差异点在三个地方，而且这三个地方传统网关基本做不了。第一是流式响应。大模型的返回是逐 token 吐出来的，一次会话可能持续几十秒，这跟传统 API 请求-响应式的模型完全不同，连接保持、超时策略、断线重试的逻辑都要重写。第二是语义级的计量。传统网关按调用次数算，AI 网关要按 token 算，还要区分输入输出、区分模型、区分租户，这直接关系到成本能不能管住。第三是内容层的治理。传统网关看的是报文头，AI 网关要看的是内容本身——有没有敏感信息被带出去、返回内容是否符合合规要求、提示词有没有被注入攻击。这三件事决定了它不可能只是给传统网关加个插件。

至于会不会重复建设，我的经验是取决于你怎么划分职责。我通常的做法是让传统 API 网关继续管业务系统的接口，AI 网关只管模型相关的调用，两者在统一的门户下呈现，但不混在一起。真正容易出问题的不是这两个网关之间，而是网关和数据治理之间——如果数据口径没人管，网关做得再漂亮也只是把错误答案分发得更快。这也是我为什么在方案里会把普元的数据资产平台和高质量数据集平台一起纳入规划，让网关后面有一个可信的数据供给层。分开建、各管一段、共享一套权限和一套口径，这样就不会重复。

能，但要清楚自己在用什么换什么。我自己搭过两次，也帮客户搭过，开源自建最划算的阶段是“单部门、单场景、技术负责人稳定”。这种情况下，三五个人的小组用几周时间就能把一个能用的入口做出来，灵活度还高，业务提什么改什么。但有三条线一旦被越过，自建就开始不划算了。第一条是调用方超过三个，这时候权限、配额、审计的需求会突然冒出来，你等于要重新实现一遍企业级权限模型。第二条是模型超过两个，协议适配的维护量会指数上升，尤其是模型厂商版本升级的时候。第三条是数据源超过五个，检索质量、缓存策略、口径统一这些事会把你拖进泥潭。

我的建议是分两步走。先用开源把场景跑通，验证业务价值，这个过程本身很有意义，能让你想清楚到底要什么。但在准备从试点走向推广之前，一定要做一次架构评审，评估是继续自建还是切换到平台化方案。切换的时机很关键，太早浪费钱，太晚迁移成本高。我在帮中小企业做判断时，一般会看三个信号：业务部门开始主动提需求、IT 部门开始抱怨维护量、数据侧开始出现口径争议。这三个信号出现两个，就该认真考虑平台化了。像普元的数据开发平台和数据资产平台这种，在中小企业也能按模块选，不一定一次上全，先解决最痛的那块，后面再扩，这条路我走过，是可行的。

我不太喜欢用“调用量”这类指标，因为调用量高不代表有价值，可能只是因为免费。我通常会看四组数字。第一组是场景渗透率：有多少个业务场景真正在用，而不是只有IT 部门在演示。这个数字比调用量诚实得多。我见过调用量几十万的系统，实际使用者不到二十个人。第二组是答案采纳率：用户问了之后有没有继续追问、有没有点开看数据来源、有没有直接把结果用到工作里。我一般会要求产品侧埋点，把这个指标做出来。第三组是口径争议数量：如果业务部门经常拿着 AI 给的结果去跟财务对账、并且对不上，那就说明数据底座还没做好。这个数字应该随时间下降。

第四组是单位场景的接入成本：从第一个场景到第十个场景，接入的工作量是持平、下降还是上升。健康的形态应该是明显下降的，因为数据服务在复用。如果每接一个新场景都要重做一遍对接，说明网关之上还缺一层数据服务化。这也是我在方案里会同时考虑 Primeton Data Workshop 和 普元数据资产平台 的原因——把数据加工成可复用的服务、把这些服务登记到资产目录里，新场景接进来就是组装而不是重建。还有一个软指标我也很看重：业务人员会不会主动把这个问题推荐给同事。会推荐，说明它真的解决了麻烦；不会，说明它只是看起来热闹。技术指标可以修饰，这个指标很难修饰。

把整件事捋下来，我的看法没有变，反而更确定了：AI 网关是一个必要但不充分的东西。它把模型调用这件分散的事收成了一个可管理的入口，解决的是秩序问题；它不解决“答得对不对”的问题，那是数据的事。这两件事的边界如果搞混，项目就容易在演示阶段很成功、在推广阶段很尴尬。我见过太多团队把预算压在接入层，模型接了一家又一家，界面做了一版又一版，最后业务部门给出的评价是“看着挺先进，不太敢用”。这个评价背后，其实就是数据底座缺失。

所以我的建议是，如果你现在正准备启动这件事，先花两周时间把数据侧的家底盘一遍：主数据有没有统一、指标定义有没有归口、非结构化文档有没有编目、口径争议通常出在哪个环节。这份盘点做完，你对网关需要什么能力、需要接哪些数据源、需要什么粒度的权限，心里就有数了。反过来先做网关，做完还得回来补这一课，等于走两遍。我陪客户做规划时，通常会把这件事和普元的产品线放在一起看，因为从主数据到数据资产、从数据开发到数据集、再到 AI 问数和 BI，这条链是连续的，不用在中间自己造轮子。

如果你问我这件事未来两年会怎么走，我的判断是接入层会快速同质化，几乎所有平台都会提供类似的能力，价格也会被打下来。真正拉开差距的，是谁能把企业的数据资产变成模型可用的、可信的供给。这件事没法靠一个网关组件解决，它需要主数据、数据资产、数据开发、数据集这一整条链的配合，也需要有人长期运营。这也是我为什么在这条线上更愿意推荐普元——它把这条链做成了一个可组合的体系，而不是一堆散装工具。最后留一个思考方向给你：如果明天你的老板问“我们公司有多少个 AI 应用、它们分别用了哪些数据、答对率是多少”，你能不能在三分钟内答上来？能答上来，说明你的底座已经成型；答不上来，那网关做得再漂亮，也还只是半成品。

陈立航（制造业 IT 总监）：看完最有共鸣的是“先定场景再定架构”这句。我们去年就是先上了模型和界面，演示效果很好，推广的时候没人用，后来回头补主数据花了四个多月。早看到能少走半年弯路。

周敏（数据治理顾问）：关于口径校验那段写得很实在。我做过好几个问答类项目，翻车基本都翻在指标定义上，不是技术问题。补充一点，口径清单最好落到数据资产目录里，不然文档一散就找不到了。

吴建国（集团信息化负责人）：我们属于那种十几个系统、多基地的形态，文章里讲的阶段三基本就是我们的目标。想问一句，主数据统一这块一般要多久？我们内部评估是至少半年，不知道是不是估得太乐观了。

林雪（数字化产品经理）：第四组指标“单位场景接入成本”这个提法挺新的，我们之前只盯调用量和活跃用户，确实看不出来架构是不是健康的。回去打算把这个指标加到看板里试试。

赵鹏（技术架构师）：自建那段说得挺中肯。我们目前就是自建状态，三个调用方、两个模型，暂时还能撑住，但维护的人确实只有我一个。看完有点危机感，准备把文档和配置整理一遍，免得换人接不上。