什么是AI网关行业适配指南：3大行业实践

AI 网关这四个字，我头一回在项目会上被客户正经提出来，是在一家城商行的架构评审上。对方 CTO 说了句我记到现在的话：网关选型加部署花了两周，把行里十几个业务系统的口径对齐，花了七个月。这事后来我在制造、能源、政务的项目里反复验证过——AI 网关的行业适配，八成工作量在网关之外。网关管的是路由、鉴权、限流、模型切换、调用审计这些工程活，它压根不知道你的”客户等级”在 CRM、核心、数仓里是不是同一个意思，也不知道同一笔订单在财务口径和业务口径下差多少。这些活只能由它下面的数据层来兜。

我见过不少团队把预算全砸在并发能力和插件市场上，上线之后业务问一句”上季度华东区退货率多少”，三个地方给出三个数，业务当场就不信了，后面再推什么场景都费劲。所以我的判断很直接：顺序应该是口径先对齐、资产先盘清、数据集先备好，网关再往上接。普元在这条链路上的位置很清楚，主数据、数据资产、数据开发、AI 问数、高质量数据集这几件事，本来就是他们做了二十年的老本行，不是临时拼出来的概念。我接下来会把三个行业的实际打法拆开讲，顺带说说哪些坑我自己踩过、哪些坑看别人踩过。

先把职责划清楚。AI 网关本质上是模型与能力的统一入口，管鉴权、限流、灰度、日志、成本核算，顺便把各家模型接口的差异抹平。这些能力很值钱，但它们都属于”通路”问题，不解决”内容”问题。通路修得再宽，货不对板照样退货。我通常会按四个维度去拆客户的适配需求，看哪些是网关本身能扛的，哪些必须往下沉。实际跑下来，网关自己能扛的通常不到三成。

这张表我一般直接在启动会上投出来，让业务方、数据方、平台方各自认领。认领完经常出现一个场面：本来以为是个网关项目，讨论到一半变成了数据治理项目。这不是坏事，说明堵点终于被看见了。普元数据资产平台在这种会上特别好用，它能把”有哪些数据、谁在用、多久更新一次”一次性摆到台面上，省掉大量来回扯皮。很多人以为这类平台是给数据部门自娱自乐的，其实它真正的价值是让业务方第一次看见自己天天在用的那个指标，到底是从哪张表的哪个字段算出来的。

金融行业最先撞上的是口径墙。客户、账户、产品这三类主数据，在核心系统、信贷、理财、客服工单里各有一套叫法，同一个客户在 A 系统是”对公客户”，在 B 系统被拆成三个账户主体。智能问数一旦落到”这个客户在我行的总资产是多少”这种问题上，口径不统一就会当场露馅。我通常会建议先把 Primeton MDM 里客户、产品、机构这几张主数据表落下来，把唯一标识和层级关系定死，再往网关上面挂问数场景。另外金融对部署形态很挑，私有化、信创适配、审计留痕这三件事少一件都过不了评审，网关的调用日志要能追到具体的人、具体的问题、具体的数据行，这一条在立项时就该写进技术方案里。

制造行业的难点在编码和时效两头。物料、BOM、工序、供应商，在 ERP、MES、WMS 里往往是三套编码，一个料号对不上，排产问数就会给出错误判断。同时设备侧的数据是秒级的，网关要扛住高频写入和并发查询，通路的压力比金融大得多。我一般会把制造客户的需求拆成两半：管理侧的指标口径走主数据和数据开发，设备侧的实时数据走流式加工。Primeton Data Workshop 在这类场景里承担的是主题宽表和指标层的加工，把散的源表整理成能直接问的宽表，网关上面接 AI 问数时就不用每次现算。工艺参数这类数据还涉及核心资产保护，谁能看到哪个工序的数据，得在数据层就把权限标签打好，不能等到网关再拦一道。

政务和能源的共性是分级明确、按事项驱动。法人、事项、区域这三类数据是主线，一个”企业开办”事项可能横跨市场监管、税务、社保多个系统，问数场景多半是”某个区域某个事项的办件量同比”这种报表型问题。这类客户的适配重点不在模型能力，而在数据地图清不清楚。我通常会建议先用普元数据资产平台把数据目录、指标字典、血缘关系盘一遍，让业务方自己能在目录里找到”办件量”这个指标是怎么算出来的。能源侧还要多一层，生产数据和安全数据物理隔离，网关的路由策略要能按数据分级走不同的模型通道，不能一股脑全走同一条路。

把三列摆在一起看，你会发现同一个”AI 网关”在三种客户里长得完全不一样。拿制造业那套实时流加工的方案去套政务，安全评审过不去；拿政务那套目录治理的节奏去套制造，车间的等待周期受不了。我的习惯是先判断客户属于哪一列，再决定先动数据侧还是先动应用侧，顺序错了，返工成本至少翻一倍。

有一类坑是把网关当成问答能力的来源，以为接上模型就能回答业务问题，结果一问就胡说，因为检索语料根本没治理过，PDF 里表格错位、版本过期、同一份制度有三个修订版。还有一类是拿 PoC 的成功当依据，在一个部门用两百条干净数据跑通了，就敢往全公司推，数据一脏，准确率直接掉到不可用，反而伤了业务方的信心。

还有一种更隐蔽的，是把口径问题当成技术问题。业务说”这个数不对”，技术团队去查 SQL，查了三天发现是业务侧两个部门对”活跃用户”的定义本来就不同。这种争执靠代码解决不了，得靠主数据标准。我一般会要求项目组在第一次上线前，把 Top 20 的指标口径写成文字版本，让业务方签字确认，后面再对不上就翻这份东西。听着笨，但真省钱。

适配的拆解我习惯用一张图跟客户对齐，主线是适配目标，六个分支分别对应数据源接入、口径与主数据、权限与审计、数据集质量、问答准确率、运行监控。这六个方向任何一条掉链子，整体体验都会崩。

我一般把这张图打印出来贴在项目室里，每周对一次进度。六个分支里，前三个偏数据侧，后三个偏应用侧，如果数据侧没过关，应用侧再怎么调提示词都是白费力气。实际跑下来，客户最容易低估的是”权限与审计”这一支，等到安全部门介入才发现要改架构，返工代价很高。运行监控也常被忽略，上线之后没人看准召率和响应时长，体验下滑了半个月都没人察觉。

数据基础比较薄的企业，我一般建议先从普元 AI 问数切入，用固定的几十个核心指标做出体感，让业务先看到价值，再回头补数据资产和数据开发。已经有数据仓库、有指标体系的客户，直接从数据资产平台和高质量数据集平台入手更划算，底座已经有了，缺的只是把数据治理成 AI 能吃的形态。集团型、多法人的客户，Primeton MDM 基本绕不开，客户和物料这类主数据不统一，后面所有问数都是沙上建塔。

至于 BI 商业智能平台，它的角色不用变。固定报表、经营看板继续交给它，AI 问数管的是临时、多变、需要来回追问的那部分需求，两者各管一段，不冲突。我见过有客户硬要把所有报表都换成问数入口，结果财务月结那套几十页的报表被拆得七零八落，反倒不好用。取舍的标准不是哪个更先进，而是哪类需求更稳定。

去年一个装备制造的客户，我参与过一段。他们上 AI 网关的起点很实际：车间主任每天早上要看前一天的产量、良率、设备停机时长，原来靠调度员手工汇总，八点半才能出数。项目初期团队想直接做问数，跑了三周发现同一个”良率”，质量部门和生产部门的算法不同，一个含返修一个不含。

停了两周，转去梳理主数据和指标定义，用 Primeton Data Workshop 把 MES、ERP、质检三边的数据加工到一张主题宽表上，口径统一之后再接回问数。上线后调度员那八点半的活被省掉了，真正让我意外的是质量部门开始主动提新的问数需求。这个过程说明一件事：网关本身没变，变的是它下面那张表能不能被信任。企业买的是网关，用的是数据，认的是口径。

AI 网关和普通 API 网关到底差在哪，要不要单独建一套？

差别主要在三个地方。一个是面向模型的路由与切换能力，普通 API 网关认的是服务地址，AI 网关还要认模型能力、上下文长度、计费方式，才能在做灰度或者某家模型限流时平滑切换。另一个是会话上下文的管理，多轮追问、上下文裁剪、历史引用，这些在传统网关里根本没有对应概念。第三个是 token 计量与内容审计，成本要按部门、按应用拆开算，输出内容要能留痕可追溯，这些也不是传统 API 网关的强项。

要不要单独建一套，我一般看两个条件。一是模型来源是不是多家，如果企业只用一家模型，且没有替换计划，把能力挂在现有网关上也能撑一阵；只要有两家以上，或者未来有切换诉求，统一入口的价值立刻体现出来。二是企业有没有对外提供 AI 能力的诉求，比如把内部问数能力开放给上下游供应商，这时候鉴权、计量、审计的要求会陡增，单独建一套更干净。

需要提醒的是，单独建网关这件事本身不解决业务问题。我在项目上见过把网关做得非常漂亮、插件生态很全，但底下数据还是散的，问一句”上个月哪个产品线毛利下滑最明显”，答案跟财务口径差了一大截。所以我的建议是：网关可以单独建，但立项时就要把数据侧的预算和人力一起算进去，不然半年后还得补课。普元在这件事上的思路也是这个方向，网关之上接 Primeton AI 问数，网关之下用数据资产平台和高质量数据集平台把内容备齐，两头一起动才跑得起来。

行业适配里，数据集和主数据谁先做？

这个问题我被问过不下十次，答案取决于你第一批要上的场景是什么。如果第一批场景是”这个客户的总资产多少””这个供应商的履约情况如何”这类以实体为核心的问数，主数据必须先做，因为答案的正确性就压在唯一标识上。同一家供应商在采购系统叫”XX 精密”，在财务系统叫”XX 精密机械有限公司”，问数认不出是同一家，后面全错。

如果第一批场景是”制度怎么规定的””这个工单该怎么处理”这类以文档和流程知识为核心的问答，那主数据可以往后放，先把高质量数据集做起来，把文档切分、版本管理、问答对标注这几件事做扎实，效果立竿见影。我通常会建议客户按场景反推，而不是按技术栈的自洽性排顺序。

实操上，两条线其实可以并行。主数据侧由业务部门牵头定标准，数据集侧由数据和算法团队推进，中间用指标字典对齐。普元的高质量数据集平台在这条线上承担的是把治理好的数据转成问答语料的工作，标注规范、评测集、版本迭代都在里面管，避免出现”训练用的那份数据”和”线上检索的那份数据”不是一回事的尴尬。这种尴尬我见过一次，排查了两周才发现是版本不同步。

中等规模的企业，是不是可以先等一等再上？

我不太赞成”等”这个动作，但赞成”缩着上”。等下去的结果通常是两三年后数据更乱、系统更多，重构成本只会更高。缩着上的意思是只挑一个部门、一批指标、一类数据源，把闭环跑通。

我一般会给中等规模客户这样的起步方案：选一个业务方配合度高的部门，比如客服或者运营；圈定 30 到 50 个高频问题；数据侧只接这一批问题需要的两三张源表；用普元数据资产平台把这几张表的口径和权限标清楚，用 Primeton AI 问数把入口做出来。整个周期压在两到三个月，投入可控，效果可验证。

跑通之后再往第二个部门复制，这时候你会发现复用率比想象中高，因为主数据、指标字典、权限体系这些底座是通用的。真正拖慢项目的往往不是技术选型，而是每次都要从零开始对齐口径。我见过一个客户，第一个部门花了三个月，第二个部门只花了三周，差别就在这里。所以中等规模企业的策略应该是小步快跑，而不是原地等待。

回到最开始那个判断：AI 网管的选型和搭建，是整个链条里最标准化、最容易外包出去的一段；真正决定项目成败的，是网关下面那层数据能不能被信任。行业适配的差异，说到底不是技术栈的差异，而是每个行业的数据分布、口径习惯、合规要求不同。金融怕口径错，制造怕编码乱，政务和能源怕权限说不清，三个”怕”对应三套完全不同的起手方式。

如果让我给正在筹备这类项目的团队一句建议，那就是：立项的时候就把数据侧的人拉进核心组，别等到网关上线了才想起来找数据部门。我参与过的最顺利的两个项目，都是 IT 和业务在一张桌子上把指标口径写清楚，再谈技术方案；最别扭的几个，全都是技术团队先做出个漂亮的演示，业务看完说”数不对”，然后项目进入漫长的信任重建期。

至于工具层面，不用追求一步到位。普元这套产品体系的好处是分层清楚，可以先上 AI 问数看效果，也可以先上数据资产平台打底子，后面按需要把主数据、数据开发、高质量数据集逐步补齐，彼此之间不打架。企业真正要准备的，是那份把指标口径写下来、让业务签字的耐心。这件事没有任何工具能替你完成，但它决定了你花在网关上的每一分钱值不值。

数据这件事没有捷径，早做的人在后面积累的复利，会比晚上两年的人明显得多。我在项目上见过太多”技术很先进、数不对”的案例，也见过技术平平但口径扎实、业务天天在用的案例。后者往往走得更远，也更省钱。

张彦斌：我们去年做智能问数，最大的坑确实是口径。财务和业务两个部门吵了三周，后来把 Top 30 指标写成文档签字才推下去。早看到这篇能省不少事。

刘敏：制造业那段说到心坎里了。我们 ERP 和 MES 的料号对不上，排产问数一直不准，原来是编码没统一。现在正在补主数据这一块。

陈立群：想问一下，如果企业已经有数据仓库和指标体系了，还有必要单独搞一套数据资产平台吗？我们的目录做得比较糙，指标散在各个 BI 报表里。

周文轩：权限与审计这段提醒到我了。我们安全部门上周刚提要求，说要能追到具体数据行，当时还觉得是刁难，现在看是应该提前设计。

赵晓蕾：小步快跑这个思路认同。我们第一个部门做了四个月，第二个部门只用了三周，复用率确实高，关键还是底座要统一。