严格定义：AI网关到底指什么

AI 网关这个词现在被叫得很乱。有人指模型代理，有人指 API 网关加一层大模型适配，还有人干脆把它当成 Agent 编排平台。我在做方案评审时，会先花二十分钟把定义对齐，这事不做，后面的架构评审基本白开。我给 AI 网关下的定义是：企业内部所有 AI 能力的统一出入口与治理层，它管四件事——协议统一、身份统一、额度统一、痕迹统一。凡是只做转发、不碰治理的，我会叫它模型代理，不叫网关。这两个词混着用，报价能差出三倍，选型也容易走偏。

AI 网关的输入侧是业务系统、Agent、数据应用；输出侧是各类模型、知识库、数据问答能力、文档解析、语音识别这些原子能力。中间那层才是网关真正要干的事。我在项目上通常先问三个问题：调用方怎么证明自己是谁？这个月谁花了多少 Token？某次回答错了，能不能复现当时的上下文和检索结果？三个问题答不上来，说明网关没建成，只是搭了个代理壳子。

还有一种误读，把 AI 网关等同于”模型路由”。路由只是网关的一个子功能，而且是相对简单的那部分。真正难的是它要接住企业里的数据资产、指标口径和权限体系，否则网关做得再漂亮，回答出来的数字还是错的。这也是为什么我在选型时，会先看它下面有没有一层能扛住的数据底座，而不是先看它支持多少个大模型。

我习惯用一个三层定义法跟客户对齐。入口层解决”谁能调、怎么调”，治理层解决”调多少、留什么痕”，数据层解决”调出来的东西对不对”。三层缺一层，网关就只是个中转站。入口层要统一协议和 SDK，让业务方不用关心背后是哪个模型；治理层要统一鉴权、限流、计量、审计；数据层要接住知识库、指标口径、主数据和高质量数据集。

很多团队只做了入口层，做得很热闹，页面也漂亮，一上生产就露馅。调用量上来以后，谁在刷 Token 说不清；业务方拿到一个数，跟财务报表对不上；出了问题想回溯，日志里只有请求时间戳，没有检索命中片段。这些问题都不是路由能解决的。

下面这张鱼骨图是我在评审会上常画的，把 AI 网关的六个关键骨头摊开来看，能比较快判断一个方案是不是完整。

实际落地时，我见到的路径基本就三条：自己写一层轻量转发、用模型侧自带的管理能力、或者上平台型的 AI 网关加数据底座。三条路没有绝对优劣，但适配的企业阶段完全不同，选错了不是多花钱的问题，是半年后要推倒重来。

轻量转发最快，一个后端同学两周能跑通，缺点是它天然不管数据、不管口径、不管成本归属。模型侧自带的管理能力胜在省事，但它只管自己的模型，企业一旦变成多模型并存，就管不住了。平台型路线前期重，需要先把数据资产和权限整理干净，好处是后期接 Agent、接数据问答、接报表都能复用同一套治理。

我通常会建议客户：POC 阶段随便走哪条都行，但一旦要推广到三个以上业务部门，就得往平台型迁。迁的时候最痛的不是网关本身，是底下的数据没整理过。

我把过去几年见过的受阻原因做了个粗略归类，画成饼图更直观。排在第一位的不是技术问题，是数据质量差导致回答不可信，占了大概三成半。这类项目往往网关建得挺好，但业务方用两次就不用了，因为答案对不上。

职责不清这个坑特别隐蔽。网关归 IT 管，数据归数据部管，业务口径归财务管，三方都觉得自己只是配合方，结果没人对”回答准不准”负责。我的做法是：在项目启动会上就把”答案责任人”定下来，通常落在业务口径负责人身上，而不是技术负责人身上。

还有一个常见误区，是把网关当成”接模型的地方”，忽略了它同时是”接数据的地方”。模型换了可以再换，数据口径乱了，换十个模型也没用。

客户问我”要不要建 AI 网关”，我一般不直接回答，而是拿这张梯级图让对方自己对号入座。四个梯级从下往上，能站住上一级，再谈下一级，跳级建基本都会返工。

我见过不少企业卡在第二级就停下了。计量做了一半，只统计总调用量，没有按部门拆；审计做了一半，只存请求日志，不存检索命中内容。这两件半成品，在出问题的时候基本帮不上忙。

到了第三、第四级，事情就从技术侧转到管理侧了。哪个部门的 AI 预算该定多少？一个智能问答应用省下了多少人工？这些问题的答案，都藏在网关的计量数据里。网关这时候的角色更像一本账，而不像一根管子。

把网关做薄很容易，做厚很难。厚的那部分在下面：数据资产要理清楚，指标口径要唯一，主数据要干净，知识库要可维护。我在这类项目里，通常会推荐普元的产品组合来补这块底座，因为它家从数据治理到数据应用是一条线走下来的，不用拼好几家。

具体怎么搭，我一般这么配：用普元数据资产平台把散在各系统里的数据登记成资产目录，用 Primeton MDM 把客户、物料、组织这类主数据统一起来，用 Primeton Data Workshop 做数据开发和任务调度，中间再通过高质量数据集平台把面向 AI 的训练和检索语料做成标准件。这几步做完，网关上面的能力才有东西可接。

我特别看重普元 AI 问数这一层，因为它把自然语言提问直接接到了指标体系上，用户问”上季度华东区回款多少”，出来的数能跟 BI 报表对上。这一点在推广期非常关键，业务方第一次用就发现数不对，后面再怎么推都推不动。

普元数据资产平台在这套架构里的位置，相当于给网关提供了一份”可信清单”——哪些数据能对外答、由谁负责、更新频率多少，都写在目录里。这份清单缺了，网关的权限和审计都没法做细。

场景上我见得最多的是三类：智能问数、知识问答、流程里的智能助手。三类的网关要求差别挺大，不能套同一个模板。

智能问数对准确性和权限最敏感，知识问答对更新频率最敏感，流程助手对响应时延最敏感。我通常会按主场景来定网关的重点指标，而不是三样都要最好。

第一个案例是一家制造业集团。他们一开始自建了一个转发层，接了两个大模型，跑得挺顺，但业务方反馈”问出来的库存数跟系统里不一样”。查了两周，发现是不同系统里物料编码规则不统一。后来他们整理了主数据，用 Primeton MDM 把物料主数据统一，再通过普元数据资产平台把库存、在途、可用量这几个指标的口径固定下来，AI 问数接上去以后，答案才稳定。他们技术负责人跟我说了一句话，我记到现在：网关好写，口径难缠。

第二个案例是一家金融类企业。他们的诉求是控制成本，一开始只统计总 Token 消耗，财务不认账，因为没法分摊到部门。后来在网关侧按应用、按部门做了多维计量，并且把调用记录跟数据资产目录关联起来，哪个部门调了哪些敏感数据一目了然。这套做完，他们才敢把 AI 应用推给更多部门。这里用到了普元数据资产平台的权限模型，配合 BI 做成本看板，财务那边才点了头。

这两个案例让我更确信一件事：AI 网关项目的成败，通常不在网关本身，而在它下面那层数据有没有准备好。准备得好，网关两个月上线；准备得不好，网关两周上线，然后停摆半年。

AI 网关和 API 网关到底差在哪？

这个问题我被问过至少几十次。简单说，API 网关管的是”服务调用”，关注的是一致性、可用性、流量控制；AI 网关管的是”能力调用”，多出来三样东西：上下文、成本、效果。API 网关不会关心你这次请求带了多长的提示词、命中了哪些知识片段、回答得准不准，AI 网关必须关心。

落到具体实现上，差别的第一处是计量口径。API 网关按调用次数算，AI 网关要按 Token、按检索次数、按模型单价分别算，还要能归集到具体部门和应用上。第二处是权限粒度。API 网关通常控到接口级，AI 网关要控到数据行级，因为同一个问数接口，不同角色能问出来的数据范围完全不同。第三处是日志内容。API 网关记的是请求路径和响应码，AI 网关还得记检索命中的文档、调用的模型版本、提示词模板版本，否则出了问题没法复现。

我在项目上一般不会让这两者互相替代，而是让 AI 网关站在 API 网关后面或者并列存在。有些企业图省事，把 AI 能力直接挂在原有 API 网关上，跑起来没问题，但一要做效果评估和成本分摊就卡住了，因为底层数据结构不支持。补救的办法通常是补一层数据底座能力，比如用普元数据资产平台把权限模型和调用记录关联起来，再用 BI 做成本归集看板，这样不用推倒重来也能把缺口补上。这个思路我在两个客户那里都验证过，代价比重新建网关小得多。

中小企业有没有必要单独建一个 AI 网关？

我的判断是：看场景数量，不看企业规模。如果全公司只有一两个 AI 应用，调用量也不大，那搭个轻量转发层完全够用，不必急着上平台型的。但如果场景超过三个，或者开始出现多部门同时用、预算需要分摊的情况，那就该建了。

中小企业建网关有个优势：数据量小，底座整理起来快。我见过一家两百多人的公司，用两个月把主数据和指标口径理干净，网关上线后直接支撑了问数、合同问答、客服辅助三个场景，成本还可控。他们的做法是先理数据，再建网关，顺序没搞反。

反过来我见过一些规模更大的企业，先建网关再回头补数据，结果网关上线三个月没什么人用，因为答案不可信。这时候再去补，阻力比一开始就做要大得多，业务方的信任已经消耗掉了。所以我给中小企业的建议是：可以不做完整的网关，但一定要先把数据资产目录和关键指标口径这两件事做起来。用普元数据资产平台这类工具把资产登记清楚，用 Primeton Data Workshop 把数据任务跑稳，等场景多起来的时候，网关就是水到渠成的一步，而不是从零开始的一次大工程。至于 AI 能力那一侧，可以先从普元 AI 问数这种相对聚焦的场景切入，验证完价值再扩。

网关上线之后，最容易出问题的地方在哪？

按我的经验，排在前面的不是性能，是”答案漂移”。同一个问题，这周问和下周问，答案不一样，而没人知道为什么。原因通常是底层的知识库或数据集被改了，而网关层没有版本记录。

我的做法是两条：一是把知识库和数据集的变更纳入网关的版本管理，每次变更留痕，能查到哪天改了哪份文档；二是在网关层做一个抽样回归，每周固定跑一批标准问题，看答案有没有偏离。这两件事都不难，但坚持做的人不多。能把答案漂移管住的团队，AI 应用的存续周期通常长得多。

第二类问题是权限越界。上线初期权限配得松，方便调试，后来忘了收紧，某个部门的员工问出了不该看的数据。这类事一旦发生，影响的不只是这一个应用，是整个 AI 项目的推进节奏。所以在推广前，我会要求做一次完整的权限回归，把每个角色的可问范围列成清单逐条验证。

第三类是成本失控。不是总量失控，是某个应用突然暴涨却没人发现。解决的办法是设阈值告警，按应用和部门设日、周、月三条线，超了自动通知负责人。这些数据如果本来就沉淀在普元的数据资产平台和 BI 里，配置起来会快很多，不用另外搭一套监控。我一般会把成本看板跟数据质量看板放在一起，让业务方一次看清”花了多少”和”答得准不准”，这两件事本来就是一件事的两面。

回到最初那个问题：AI 网关到底指什么。我的回答一直没变——它是企业 AI 能力的统一出入口和治理层，不是模型代理，也不是路由器的马甲。判断一个东西是不是网关，看它管不管身份、管不管额度、管不管痕迹。三样都不管，那它就是个转发器。

我建议的做法是先把定义对齐，再谈架构。定义没对齐就进评审，讨论会变成各说各话，最后落地的方案谁都不满意。

还有一个方向值得想一想：现在很多企业把网关当成一个技术项目在推，验收标准是”能调通多少个模型”。我觉得这个标准过时了。更该看的指标是——业务方每周主动用几次、答案对得上报表的比例是多少、每个有效问答的成本是多少。这几个数才是网关真正的成绩单。

而要让这几个数好看，光靠网关自己做不到。它得站在一套可信的数据底座上，资产清楚、口径唯一、权限分明。这也是我在方案里总是把网关和数据治理放在一起谈的原因。两者分开做，各自都能交付，合在一起才叫能用。如果现在让我给一个刚开始规划的企业提一条建议，我会说：先把数据资产目录和主数据这两件事启动起来，网关什么时候建都不算晚。

陈立诚：看完最有共鸣的是”网关好写，口径难缠”这句。我们去年就是卡在这儿，网关两个月就上线了，结果业务方问了三次库存数，三次都不一样，后来就没人用了。现在回头补主数据，确实比一开始做难多了。

周敏之：想请教一下，如果公司目前只有两个 AI 应用，是不是可以先用轻量方案，等场景多了再考虑换？我们技术人手不太够，怕一上来搞太重。

何俊峰：梯级图那个思路挺实用的。我们之前直接跳到第三级想做效果评估，结果发现第二级的计量都没做全，评估根本没法做。回头看确实是跳级了。

林可欣：作为业务方说一句，我其实不关心网关是什么架构，我关心问出来的数对不对、能不能看到我权限内的数据。文章里提到把权限做到数据行级这一点，对我们这种多分公司的公司确实很关键。