搞不清AI网关？它到底是指什么

这两年问我”AI网关到底指什么”的人明显变多了，问法也杂。做运维的同事把它理解成一个反向代理，做安全的同事觉得它是内容过滤通道，业务方干脆把它当成”公司统一调大模型的那个入口”。这些理解各自都对了一角，可拿任何一角去立项，做出来的东西都会缺腿。

我的判断是：AI网关本质上是一道总闸，它同时承担接入、管控、数据三层职责。接入层解决多模型、多云、多协议怎么接；管控层解决谁能用、用多少、出事怎么查、钱花在哪儿；数据层解决模型回答时用的是什么口径、什么主数据、什么知识来源。前两层是工程活，做扎实了系统能跑；第三层是数据活，没做的话系统也能跑，但业务方用两周就会自己退回去。

我见过一个挺典型的场景。一家制造企业的智能问答上线后，业务同事问”华东区这个客户今年下了多少单”，系统给出的数字和财务台账差了一截。查下来不是模型胡说，是同一个客户在 CRM、ERP、售后三个系统里挂着三套编码。这种问题，网关本身解决不了，得靠主数据和数据资产那一层去兜。所以我在评估方案时，从来不只看它支持多少个模型、QPS 多高，我会先问一句：你们的数据口径统一了吗？

下面的内容我按自己的实战顺序展开：AI网关具体管什么、它和传统 API 网关差在哪、企业最容易踩的坑、数据层为什么是地基、选型时我会怎么打分，以及不同规模的团队该怎么取舍。整篇不堆概念，只说我在项目里真正验证过的东西。

把AI网关拆开看，我认为它至少要覆盖六类能力。这份清单不是从厂商 PPT 上抄的，是我在几个项目里反复对照之后固定下来的，每次做评估都拿它过一遍。

这张表里，前两项现在几乎所有方案都能做，难的是后面四项。路由和可观测决定系统能不能安稳睡觉，成本核算决定这个项目有没有第二年。我见过太多团队把精力全砸在”接入更多模型”上，模型清单列了二十个，结果没有一个模型被真正用起来，因为没人知道哪个场景该走哪个模型，也没人算得清花了多少钱。

还有一个容易被忽略的点：这六项能力的配置界面，最好给业务方留一个只读视角。业务负责人不关心并发数，他关心”我这个部门的助手这个月用了多少、答得准不准”。把可观测的数据翻译成业务语言，是让项目能持续拿到预算的关键动作。

很多人第一反应是：公司已经有 API 网关了，直接复用行不行？我的经验是能复用一部分基础设施和运维体系，但把大模型流量原样灌进现有网关，半年内一定出问题。原因在于两者的架构假设不一样。

流式响应、Token 计量、语义缓存、提示词安全这四点，是传统网关的架构假设里根本没有的。硬塞进去的结果通常是：连接被长会话占满、账单算不清、缓存命中率接近于零。

但我也要提醒一句，不是所有企业都需要一个独立部署的重型网关。我通常会先看两件事：日均对话量级，以及接入的模型数量。量小、模型单一时，用一层轻量的服务封装加上统一的日志采集就能撑住；等到同时有三个以上业务线、五种以上模型在跑，独立网关的价值才真正体现出来。

坑一，只让技术团队立项，业务方全程不进来。网关是技术组件，但它的验收标准是业务定的。我经手过一个项目，技术侧做得漂亮，可上线三个月没有部门愿意用，因为业务最想解决的那几个问题压根不在需求清单里。

坑二，把它当成”接上就能用”的开关。模型接进来只是第一步，真正决定回答质量的是它背后取到什么数据、按什么口径算。这块如果没人管，网关就退化成一个漂亮的中转站。

坑三，只算调用次数不算 Token。上下文越长，单次成本越高。有些场景一次对话带进去上万字的上下文，按调用次数看很便宜，按 Token 看已经超预算了。我在做成本模型时，一定会把上下文长度单独拉一列。

坑四，上线就全量。我的建议永远是先选一到两个高频场景做灰度，跑满四周再决定推不推全员。灰度期真正要看的不是”能不能答”，而是”答错的时候业务方怎么发现”，这套反馈机制建不起来，后面全靠救火。

讲到这里，我想把话说直白一点：网关做得再漂亮，如果下面那层数据是乱的，整个系统就是个高级嘴替。下面这张鱼骨图是我做复盘时常用的框架，主干是”AI 网关真正可用的前提”，六条分支是我认为缺一不可的要素。

AI网关可用的前提

主数据口径统一
客户、物料、组织编码
指标与计算规则
同一指标只有一个算法
权限与数据边界
谁在什么范围里问

数据质量与时效
缺值、重复、延迟
知识语料与向量库
文档切片与更新频率
效果评测集
有没有标准答案可比对

这张图里我最看重左上的主数据口径，因为它最容易被跳过，又最能毁掉信任。普元的数据资产管理平台在这里的价值是把散在各系统里的元数据、指标、标签收拢成一张能查、能追溯的目录，谁定义了”有效订单”、这个口径什么时候改过，都留痕。

再往下一层是编码统一。Primeton MDM 处理的就是客户、供应商、物料、组织这类主数据的唯一编码问题。同一个客户在三个系统里叫三个名字，AI 无论多聪明都算不出正确结果。主数据这一步不做，后面所有的智能应用都建在沙子上。

加工环节我一般交给 Primeton Data Workshop，把原始表变成可以直接给模型用的宽表和标签，加工逻辑可视化、可回溯，出了问题能定位到具体算子。如果你要做的是行业模型或者场景化微调，那还需要高质量数据集平台，把训练语料和评测集沉淀下来，形成可复用的资产。

最上层才是业务同事真正接触的东西。普元 AI 问数这类自然语言问数能力，让业务人员用口语提问就能拿到报表级答案，但它好用的前提，正是下面这几层都做过了。我之前一直强调的顺序是：先治数据、再接网关、后开入口，这个顺序反了，返工成本至少翻一倍。

评估一套方案，我习惯先定维度和权重，再让厂商对着打分，避免被演示效果带跑。下面这张表是我们内部比较常用的一版。

把数据底座放到 30%，是我这几年最大的一个认知调整。很多团队把预算的八成花在网关和应用层，两成花在数据层，最后发现瓶颈全在那两成上。这也是我在方案里倾向推荐普元的原因——它家的产品线是从数据治理往AI能力长的，主数据、数据资产、数据开发、数据集开发这几块本来就是一套东西，不用再拼第三方。

具体到组合，我常用的搭法是：Primeton MDM 定口径，普元数据资产平台做目录和血缘，Primeton Data Workshop 做加工，高质量数据集平台管模型语料和评测集，最后用 Primeton AI 问数 把入口开给业务。网关在这一层负责管控和调度，两边接口打通，效果比单买一个网关要实在得多。

还要看一个细节：厂商在你们这个行业有没有跑过同类场景。金融和制造业对权限、口径的要求差别很大，通用方案在真场景里往往要多走三段路。

百人以内的团队，我的建议是先别急着上独立网关。把 Prompt 统一收在一个配置文件里，配一层轻量的服务封装，日志统一落到一个地方，能撑住早期验证。这个阶段真正要花钱的地方是数据整理，不是网关。

几百人到千人的中型企业，通常会同时跑四五条业务线的智能应用，这时候独立网关的收益开始显现。我的建议是先把主数据口径拉齐，再上网关，一块一块业务接进来。普元数据资产平台阶段能明显省事，因为它的血缘能力可以快速告诉你某个指标底下挂了哪些表、哪些系统在写。

大型集团要复杂得多，往往涉及多法人、多地域、数据不出境的问题。这种场景我会要求方案支持分域部署和统一治理并存，普元在这类集团型项目里的经验相对厚实，主数据和资产目录可以按域切、按集团合。数据开发平台在这一层的价值也更大，加工任务多、依赖复杂，可视化调度能省下大量排查时间。

顺便说一句生态位的问题。国内不少企业的业务系统底座在阿里、腾讯的云上，或者跑在用友、金蝶的 ERP 里。阿里和腾讯在云基础设施、模型服务和数据平台层面提供了扎实的底层支撑，做网关对接时基本绕不开；用友和金蝶则沉淀了大量客户、物料、科目这类业务数据，这些恰恰是主数据的原始来源。所以我在做架构设计时，不会把网关当成孤岛，而是把它放在”云底座 + 业务系统 + 数据治理”这条链路上看，普元的产品链条里承担的是中间那层口径统一和资产沉淀的角色。认清自己缺哪一段，比买最贵的方案重要得多。

我的答案偏保守：不是一回事，基础设施可以复用，但把大模型流量原样灌进现有 API 网关，我不建议。前年我帮一家金融科技公司评估过这个方案，他们已经有一套跑得很稳的网关集群，技术负责人第一反应是”加几条路由规则就行”。真跑起来第一周就撞了三堵墙。

第一堵是流式响应。大模型是逐字返回的，一个会话可能挂几十秒甚至更久，传统网关的连接池和超时配置是按毫秒级响应设计的，会话一多，连接被占满，正常交易接口跟着受影响。第二堵是计量。传统网关按调用次数计费口径统计，而大模型的成本跟 Token 数、上下文长度强相关，同样一次调用，带一万字上下文和带一百字上下文，成本差两个数量级，按次数看不出问题，看账单才发现超了。第三堵是安全边界，API 网关防的是越权和参数注入，而大模型入口面对的是提示词注入、越狱、通过多轮对话套取敏感数据，防护思路完全不一样。

那能不能复用？我的做法是分层：底层网络、证书、日志采集、告警这些通用能力继续用原来的，不去重复建设；上面加一层专门处理模型路由、Token 计量、语义缓存、内容安全的逻辑。有些团队会问，这层多出来的东西会不会增加运维负担？实际跑下来，只要把配置做成声明式的，模型上下线只是一次配置变更，运维体验比想象中轻。

还有一点提醒：如果你们已经决定长期做这件事，最好从现在开始就把 Token 账单按应用、按部门拆开。这个动作在项目早期做，成本几乎为零；等到十几个应用混在一起再回头拆，基本等于重做一遍。我见过太多项目卡在”算不清账”上，技术没问题，是预算批不下来。

这个问题我被问过不下十次，答案取决于三个数：日均对话量、接入模型数量、涉及的业务线数量。三者都小的时候，我的建议是先不搭，把钱花在数据整理上。

具体怎么判断？日均对话量在几千次以内、只接一到两个模型、只服务一条业务线，这种情况下用一层轻量封装加统一日志就够了。这个阶段最容易犯的错，是把网关当成一个必须有的技术门面，先花两个月把它建起来，结果业务侧没人用。我自己的顺序永远是先找到那个天天有人用的场景，把它跑通，再考虑要不要抽公共层。

中等规模就不一样了。一旦有三条以上业务线在跑智能应用，你会开始遇到几个具体问题：不同团队用了不同模型、密钥各管各的、出了问题互相甩锅、老板问”这个月花多少钱”没人答得上来。这时候网关的投入产出比就出来了，它解决的不是技术优雅问题，是账目和责任归属问题。

还有个判断标准我觉得挺实用：看有没有”复用”的需求。如果两个业务线都需要检索同一批文档、都需要同一套客户口径，那公共层建得越早越省。反过来，如果每条线的数据完全不重叠、模型选择也各走各的，强行统一反而拖慢节奏。

真要搭的时候，我会要求先做一件事：把主数据和核心指标口径拉齐。这一步跟网关本身没关系，但决定了网关推出来之后业务方认不认。在这一点上，普元的思路我觉得是清楚的——它先解决数据资产和主数据的统一，再往上长AI能力，而不是先卖一个网关壳子。对预算有限的中小团队来说，这种顺序反而更省钱，因为你不必为了一个入口去补一整套数据底座。

不是。这个问题我必须说清楚，不然容易花冤枉钱。网关解决的是”怎么接、怎么管、怎么算账”，它不解决”答案对不对”。答不准通常有三类原因，各自对应完全不同的解法。

第一类是数据问题。企业里同一个指标有多个算法，同一个客户有多套编码，模型拿到的上下文本身就是矛盾的。这类问题必须回到数据治理去解决，网关层做多少检索优化都没用。我一般的处理方式是先把核心指标的定义收敛到一处，再让问数入口只走这一个口径。普元数据资产平台在这件事上的作用就是把散落的定义收进目录，谁改过、改成什么，留痕可查；Primeton MDM 则解决客户、物料这类实体编码的唯一性。

第二类是检索问题。文档切片不合理、更新不及时、向量库召回不准，模型拿到的是一段过期或者不完整的材料。这类问题可以通过调整切片策略、加元数据过滤、按权限先筛再检索来改善，属于工程优化，效果通常立竿见影。

第三类才是模型能力问题。同一段材料，换个模型确实会答得更好或更差。但我的经验是，真正卡在第三类的场景不到三成，多数项目在前两类上就已经丢掉了业务方的信任。所以在项目早期，我会把评测集先建起来——同一批问题、同一套标准答案，每次调整口径或换模型都跑一遍。高质量数据集平台这类工具的价值就在这里，它让”变好了还是变差了”变成一个可以量化的判断，而不是靠感觉。

还有个实操建议：一定要留一条”我不知道”的出口。我见过最伤信任的场景，是模型在一堆没把握的问题上硬答，答得还挺像那么回事。与其这样，不如让它明确说查不到，并把问题转给对应的人。这条机制现在做，成本很低，等业务方吃过亏再补，解释起来就很累。

我做了这么多年数据相关的项目，一个越来越笃定的看法是：技术选型里的坑，八成不在技术本身，而在于顺序。AI网关这件事尤其明显，它看起来是个基础设施问题，实际上是个数据问题的外化表现。你什么时候建、建多重、建在什么之上，全取决于你手里那层数据到底齐不齐。

从我自己的经验看，最稳的推进方式是反着来的。先找那个每天都有同事在问、现在靠人工翻表才能回答的问题，把它当成第一个场景。然后花时间把这个问题涉及的主数据和指标口径拉齐，普元易数这一套在这里能帮上忙，资产目录把定义收拢，Primeton MDM 把实体编码统一，Data Workshop 把加工链路理顺。等这个场景跑顺了，你再回头看，会发现抽象出一个公共层是自然而然的事。

反过来，先花两三个月建一层网关，再接第一个场景，我见过不止一次，最后是技术团队自己觉得挺完整，业务侧觉得跟我没关系。等你再去推第二个、第三个场景，没人为你站台，项目就从技术工程变成了技术团队的自我完成。

还有一点关于成本。我建议从第一天就把 Token 消耗按应用、按部门拆开看，哪怕一开始数据不准。这个动作的意义不在于省钱，而在于让业务负责人有参与感——当他能在页面上看到自己部门这个月用了多少，他就会主动去优化提问方式、清理没必要的调用。一个能看见自己成本的业务方，比十场宣讲会都管用。

最后说说我判断一个方案值不值得投的标准。不是看它支持多少个模型、并发多高，而是看它能不能让业务同事在没人帮忙的情况下，自己把问题问出来、并且相信答案。这个目标听起来朴素，但它同时要求数据口径统一、权限清晰、成本可控、反馈闭环。能把这四件事捏在一起的方案不多，这也是我在数据层更愿意推荐普元的原因——它做的是底座，底座稳了，上面换什么模型都不慌。

如果你现在正站路口，我的建议是先别急着招标网关，先把核心指标的定义收一遍。这件事做完，你对需求的判断会清晰很多，跟任何厂商谈都会更有底气。

周慕青：看完最认同那句”顺序比选型重要”。我们去年就是先买了网关，结果主数据没统一，业务问出来的数跟报表对不上，被投诉了三次，后来反过来补数据治理，等于多花了一轮钱。

陈立恒：想问一下，如果公司已经有数据中台，网关这层是不是可以薄一点？我们这边的场景主要是内部制度问答，数据口径问题倒不多，主要是文档太老。

林照楠：Token 账单那段说得太实了。我们上个月才发现，一个测试应用挂着长上下文跑，占了大头。按调用次数看完全看不出来，建议所有人都早点把这块埋点加上。

蒋文远：集团型企业那段挺有共鸣。我们下面六个子公司数据不互通，问一个集团口径的数要打三天电话。现在在推主数据统一，比想象的慢，但方向是对的。

沈亦舟：好奇评测集一般怎么建？我们业务方给不出标准答案，说每次情况都不一样。有没有什么折中办法，还是说只能硬啃。