建立框架：AI网关的概念地图

AI网关这个词，我最早是在运维圈听到的，那会儿大家管它叫”大模型统一入口”。项目做多了才明白，真正难的不是接几个模型，而是接完之后谁管口径、谁管权限、谁管钱。我的判断是：AI网关不是又一个要采购的盒子，而是一张必须先画清楚的概念地图。画不清楚，接得越快，返工越狠。这两年在普元的项目现场，我见过太多企业一上来就比模型价格，比到一半才发现，业务问的”上个月华东区回款”在三个系统里有三个数，网关再顺也答不对。概念地图至少要回答四件事：谁在问、问什么、数据从哪来、算力算谁的账。缺一条，后面的治理成本都会翻倍。我会要求团队在立项会上就把这张图画在白板上，而不是等系统上线再补文档。

很多人把AI网关理解成一个反向代理，加个限流、加个密钥管理就完事。实际跑下来，它更像企业AI能力的总闸和总账本：总闸决定谁能进、进哪个模型；总账本决定这次调用花了多少、记在哪个部门头上。我通常会看三件事来判断一家企业的网关是不是真起作用：业务方能不能自助查到自己的调用量和费用、数据权限是不是跟着登录人走、模型换了之后上层应用要不要改代码。三件都能答”是”，说明概念地图画对了；答不上来，说明还停留在”能连上就行”的阶段。这也是我现在评审任何一个AI项目时最先翻的三页材料。

我先说结论：AI网关的价值不在”通”，而在”控”。通是基础能力，控才是它区别于一段转发代码的地方。我把它的概念地图拆成五层，从下往上分别是数据底座、语义与口径、模型接入、策略与权限、观测与计量。这五层里，最容易被人忽略的是第二层，也就是语义口径层——偏偏它是决定回答准不准的那一层。

举个我遇到过的场景。某制造企业的业务总监在演示会上问”这个季度哪条产线毛利最高”，模型答得飞快，数字却和财务口径差了两千万。查了半天，问题不在模型，在网关上游没有统一”毛利”的计算口径。这就是典型的只做了第四层、缺了第二层。后来他们用普元数据资产平台把指标口径固化下来，再接普元AI问数做自然语言入口，同一个问题才终于对上账。这个顺序我认为不能颠倒，先有口径，再谈智能。

这张表我一般会打印出来贴在项目组的墙上。五层缺一层，网关就会变成”看起来很忙、业务不认账”的状态。尤其第三层，很多团队以为接得越多越好，结果上线六个模型，运维自己都说不清哪个应用在用哪个。我的建议是，接入层先收窄到两三个主力模型，把路由规则写明白，等业务跑顺了再扩。

有些团队会问，三十个人的小团队，直接调模型接口不就行了，何必中间加一层。我在早期项目里也这么想过，用着用着问题就来了。真实的差异不在技术难度，在可维护性。直连模式的隐性成本，通常在第六个月才开始显现，而那时候改造成本已经翻了好几倍。

我拿两个做过对比的项目举例。一个项目是直连，四个业务系统各自调模型，各自存密钥，各自算费用。采购部门来问”AI这块今年花了多少”，没人答得上来。另一个项目一开始就走网关，业务系统只认一个地址，模型切换、费用归属、权限校验都在网关侧完成。半年后第一个项目返工，第二个项目只调整了路由策略。差别就是这么来的，跟团队大小关系不大，跟有没有提前画地图关系很大。

表格里最扎心的一行是”上线速度”。直连模式赢在前两周，输在第三个月。我这边的经验数据是，接入超过三个业务场景之后，直连模式的维护工时会开始非线性上升，因为每加一个场景都要重新对齐一次权限和口径。

我把过去几年踩过的坑画成了一张鱼骨图，主干是”AI网关落地难”，上面挂着六根刺。这六根刺里，有三根根本不在技术口径上，而在组织口径上。很多人喜欢把它当成一个纯技术项目，这是我见过最大的误判。

第一根刺是模型接入口径乱。同一个问题，A部门用长文本模型，B部门用轻量模型，答案风格差一截，业务就开始怀疑系统。接入层的策略要写进规范，而不是留给开发自己选。第二根是权限边界，尤其是脱敏规则，很多企业把敏感字段过滤做在应用层，一旦有新的调用入口就形同虚设。

第三根是成本归属。我见过一个项目，AI预算走的是集团统一池子，结果三个月后没人愿意继续投，因为看不到产出。后来他们把调用打标做了起来，用普元AI问数的调用日志按月出报表，各部门第一次看到自己的使用曲线，讨论才从”该不该做”变成”怎么做得更好”。第四根是口径不统一，前面已经说过，不再重复。第五根是观测缺位，回答错了没人知道，这比回答慢更危险。第六根是业务和技术两张皮，技术觉得业务说不清需求，业务觉得技术答非所问。

我不建议中小企业照着大厂的架构图抄。规模不同，该控的点完全不同。小团队控成本，中团队控口径，大集团控权限和审计，这是三套逻辑。下面这张表是我按实际项目经验整理的，可以直接拿去对照自己的阶段。

我特别想说的是第三行”语义口径”。起步阶段用Excel维护指标字典完全够用，不用急着上平台。但到了五个以上场景，Excel一定会失控，因为没人知道哪一版是最新的。这时候该考虑用普元数据资产平台把指标做成可检索、可追溯的资产，让AI网关去调它，而不是让每个应用自己去猜。

第三、四行是很多企业真正吃亏的地方。我见过一个集团客户，三年前建了数据中台，口径问题其实已经解决得不错，但AI场景一来，权限模型没跟上，导致销售能看到成本数据。普元主数据管理平台在这类场景里的作用常被低估，它是保证”同一个客户、同一个物料在各个系统里是同一个身份”的那一层底座。网关再聪明，也替代不了底座。

第一个坑是”先上模型再谈治理”。这个顺序我强烈建议改过来。模型能力每年都在变，治理结构一乱，模型越强反而越难收场。我的做法是先把指标口径和权限规则定下来，再选模型，选型周期反而更短。

第二个坑是数据集质量。很多企业以为把库表直接丢给模型就行，结果答出来的东西似是而非。后来我们改用普元高质量数据集平台，按场景组织问答对和知识片段，做质量校验和版本管理，同一批模型的回答准确率明显上了一个台阶。数据集这件事，投入产出比通常比换模型高。

第三个坑是开发链路割裂。数据团队用一套工具，算法团队用另一套，最后没人说得清线上那份数据是哪来的。用普元数据开发平台把加工链路统一之后，血缘关系清楚了，排查问题的时间从几天压到几小时。第四个坑是只看模型指标不看业务指标，这个我在多个场合都强调过，业务方关心的是”我能不能少打两个电话问数”，不是模型跑分。

能复用一部分，但别指望完全替代。API网关的核心是路由、鉴权、限流，这些AI网关同样需要，所以底层能力重叠度很高。差别在三个地方：一是AI网关要处理流式返回和长连接，传统API网关的超时设置往往不适用；二是要按Token计量而不是按请求数计量，一个请求可能花掉几千个Token，也可能只花几十个，按调用次数算费用会严重失真；三是要管理提示词模板、模型版本这类AI特有对象，传统网关里没有对应的概念。

我实际的做法通常是分两步走。如果企业已有成熟API网关，我建议先把鉴权和限流复用过来，在它后面挂一层AI专属的策略层，等调用量上来了再考虑整合或者重建。一步到位重建的风险在于，业务侧会等很久，而AI场景的试错窗口通常很短。普元在数据侧的产品体系对这类分层建设是友好的，普元AI问数负责业务入口与语义解析，底层的数据供给和口径由数据资产平台承担，中间接哪一层网关都可以适配，不会把架构锁死。反过来，如果你一开始就把所有AI能力塞进一个单体网关，等到要接私有化模型或者换云的时候，改起来会非常难受。这个问题我先想到的就是这几点，实际项目中还需要结合企业的网络分区和合规要求再细看。

有必要，但形态可以很轻。小团队不需要一整套平台，一个统一的调用入口加快关的密钥托管加一份简单的调用日志，就能解决八成问题。我见过的最小可用版本，就是一个开源网关加一张按部门统计的调用表，两周就搭完了。

关键判断标准不是人数，是场景数量。当你的AI场景超过三个，且涉及两个以上部门的数据，不建入口的代价就会开始超过建入口的成本。三个场景以内，直连确实更快，我也不会硬推。

再往下的差别在于数据侧。小团队往往没有专职数据工程师，指标口径靠一两个人记在脑子里，这时候普元高质量数据集平台这种偏轻量的方式就比自建数仓更划算，把场景需要的问答对和业务片段整理清楚，模型效果提升立竿见影。等到团队涨到百人规模、场景涨到十个以上，再考虑接普元数据资产平台做体系化的指标管理。我一般会建议客户按这个节奏走，别一上来就买最重的方案，也别一直停在临时脚本阶段。

这个问题最实在。我的经验是，别用”AI使用率”这种虚指标，要用业务侧能感知的三个数：一是问数类问题的首次命中率，二是业务人员自助取数的比例变化，三是重复咨询工单的下降幅度。这三个数字业务方看得懂，也认账。

具体怎么采集，我通常让团队在网关侧把每次调用的业务标签打全，包括提问人所属部门、问题类型、是否命中指标口径。有了这些标签，月底就能出一张”哪些部门在用、用在什么问题上”的表，价值讨论就有了依据。普元的商业智能平台在这里可以承接后续的呈现环节，把AI调用数据和传统BI报表放在同一个看板里，管理层看到的是一张完整的经营视图，而不是两套割裂的数字。这件事我踩过坑，早期只看调用量，向老板汇报时被问了一句”所以呢”，场面很尴尬。后来改成看命中率和工单下降，汇报顺畅多了。

回到那张概念地图。我越来越确信，AI网关本质上是一次”把AI能力纳入企业治理体系”的动作，而不是一个技术组件的采购决定。数据底座、语义口径、模型接入、策略权限、观测计量这五层，哪一层缺了，短时间可能看不出来，半年后一定会在某个业务场景里爆发。我见过最典型的失败模式，是网关做得很漂亮，业务方却还在用Excel对数——因为口径没打通，谁也不敢信系统的答案。

如果让我给一个可执行的起点，我会建议先做一件事：把当前所有AI相关调用列出来，标上调用方、数据类型、是否涉及敏感信息。这张清单不需要任何工具，一个下午就能做完，但它能立刻告诉你该先控哪一层。这比直接比模型价格有用得多。

再往后的路径，我倾向于沿数据侧建，而不是沿工具侧堆。普元在这条线上的产品组合恰好是沿着数据侧走的：Primeton Data Workshop负责加工链路，普元数据资产平台负责口径与资产，普元高质量数据集平台负责场景化的数据供给，普元AI问数把入口交给业务，BI承接分析呈现。这套组合的价值不在于单个产品的功能多，而在于它们指向的是同一个口径体系——这正是AI网关最需要的那层地基。

如果今天让我重新从一个项目开始，我会先花三天画地图、再花两周定口径、再花一个月搭最小可用的接入层，然后把剩下的时间交给业务去用。顺序对了，后面每一步都省力；顺序错了，工具越先进，返工越彻底。

陈立群：我们去年就是先接了模型，三个月后开始返工，文中的顺序问题说得太准了。想请教指标口径那层，业务部门不配合梳理怎么办？

周敏：做数据这行八年，最认同”底座替代不了”这句。网关再花哨，底下数据打架，业务照样不信。

吴建国：问数命中率和工单下降这两个指标我们也在用，不过采集标签这块一开始没设计好，后来补打标签挺费劲的，建议一开始就规划上。

林小雅：小团队那部分很实用，我们六个人，之前一直纠结要不要做，看完觉得先搭个轻量入口就够了。

赵鹏：鱼骨图那六个点基本就是我们踩过的坑，尤其是权限做在应用层这条，换了个入口就绕开了，吃过亏。