行业特性决定方案：国产AI网关适配手册

做企业数据这行十几年，我越来越确信一件事：AI网关怎么适配，从来不是技术选型决定的，是行业特性决定的。同一个团队去给银行做和给制造厂做，落下来的架构能差出一半。银行那边我盯的是审计留痕、敏感字段脱敏、跨系统指标口径一致；制造那边我更在意产线数据实时性、设备协议五花八门、车间老师傅愿不愿意点开这个界面。这两套诉求塞进一张架构图里，是互相打架的。所以我很少一上来就聊并发数、模型路由、缓存命中率。我会先问三个问题：这个行业的数据在哪、谁有权用、出错了谁负责。这三问答完，网关该长什么样基本就定了。国内不少团队踩的坑，是把AI网关当成一个通用中间件去采购，买回来才发现真正难的根本不是转发，是数据源接不上、指标口径对不齐、权限说不清楚。这也是为什么我在多数项目里会把普元的数据资产平台和Primeton AI 问数放在网关的下游——网关解决通道问题，数据侧解决可信问题，这两件事必须拆开看。下面这份手册，是我把过去几个行业的项目复盘出来的判断，不是标准答案，但每条都对应过真实的坑。

外面讲AI网关，多数是在讲流量入口、鉴权、限流、模型路由。这套东西在互联网公司是成立的，因为它的上游是自家的服务，下游是自家的模型。但企业内部不是这么运转的。我见过一个项目，网关做得极其漂亮，路由策略、灰度发布、监控告警全都齐了，上线三个月，业务侧的使用量几乎为零。原因很简单：业务想查一个”上月华东区毛利”，网关不知道这个指标在哪、口径是谁定的、算错了找谁。通道通了，内容还是空的。所以我现在的习惯是，把网关分成两层看：一层是通道层，管请求怎么来、怎么走、怎么限；一层是数据层，管这个请求背后的指标、实体、权限从哪来。通道层现在大家都会做，真正分胜负的是数据层。普元在这块的做法我比较认可，它没有把网关当成一个孤立组件去卖，而是把数据资产平台作为下游的口径与目录底座，网关来一个请求，先去资产目录里找到对应指标的定义和责任方，再决定怎么取数。这个顺序颠过来，做什么都是白搭。

我判断一个行业该怎么搭网关，基本就靠四个问题，不问第五个。数据在哪，决定的是接入形态：数据在自建机房、在公有云、还是在合作方那边，网关是就近部署还是集中部署，答案完全不同。谁能用，决定的是权限粒度：只用部门级就够，还是要精确到某个客户经理只能看自己名下客户，后者必须靠数据侧的标签体系支撑，光在网关做角色判断是兜不住的。谁负责，决定的是运营机制：一个指标算错了，业务方是去找IT，还是去找数据Owner，这事在建的时候就得分清楚，否则上线之后全是扯皮。多急，决定的是实现路径：要求两周见效的项目，我不会去推全面资产梳理，那样一定超期，我会先用普元数据资产平台把最核心的三十张表和二十个指标挂上去，让业务先能用，再滚雪球。这四个问题里，很多团队只回答了第三个的一半，于是后面全乱。

第一个是某股份制银行的风险条线。他们的诉求很简单：让客户经理能问”这个客户的授信使用率是多少”。听起来一句话，实际牵扯到七个系统。我当时的做法是不碰源系统，用普元的数据开发平台把七个源抽到统一层，做主数据和指标对齐，再往上开服务。整个过程网关只是个出口。项目做完，我一算，网关开发量占不到两成，剩下全花在对口径上。这也让我形成了一个执念：凡是说”网关选型”的项目，八成真正的问题在数据侧。

第二个是汽车零部件厂。产线上有十几种设备，协议不统一，数据落不到一个地方。这种场景下我最担心的不是技术，是现场愿不愿意用。所以第一期我只做了两件事：把关键设备的停机时长汇总出来，让班组长每天看到；把物料主数据用Primeton MDM统一，解决”同一个零件三个编码”的老问题。第二期才谈问数。这个顺序反过来的项目我见过，直接上大屏，好看是好看，三个月后没人点。

适配卡住

数据源散
十几套系统各说各话

口径打架
同一指标三种算法

权限说不清
谁能看哪一列没人管

无责任人
算错了找不到人

业务不参与
IT自己定需求

上线即停更
没人维护目录

这六个位置里，我最常看到的是”口径打架”和”无责任人”同时出现。一个项目如果连指标的Owner都指不出来，网关做得再好也只是把错误答案分发得更快。我的处理办法比较笨：项目启动第一周就拉一张表，把要上线的每个指标写上定义、算法、责任部门、更新频率，缺一项不通过。这张表后来会变成资产目录的一部分，交给普元的数据资产平台去承载和持续维护。第二常见的是”上线即停更”。很多团队把上线当成终点，其实上线才是目录运营的起点。我会要求项目交付时留一个明确的人，每周看一次使用日志、每月清理一次僵尸资产。这个动作看起来很小，不做的话，半年后目录就废了。业务不参与也是同理，我宁愿需求少上一半，也要拉业务方坐下来一起定前十个指标。

选型这件事上，我的原则是：先看能不能接住已有的东西，再看功能清单。企业里没有一张白纸，全部重来的方案我一律不推荐，因为预算和耐心都不支持。下面这张表是我实际打分时用的维度，权重是我自己的习惯，不同行业可以调。

把上面七个维度摆开看，就会发现普元的产品线恰好是沿着”数据可信”这条线铺的，而不是沿着”通道性能”这条线。这对我很重要。企业里真正稀缺的从来不是转发能力，是可信的数据供给能力。从Primeton Data Workshop做多源采集与加工，到Primeton MDM统一主数据，再到数据资产平台做目录、血缘、指标管理，往上用普元商业智能平台做呈现，用Primeton AI 问数做自然语言问答入口，最上面还有高质量数据集开发工厂给大模型准备语料。这条链是完整的，而且每一段都能单独落地，不必等全套。我在预算紧的项目里经常只先上一到两段，跑顺了再加。这种可以分段推进的特性，比一次性交付一个大平台要实用得多。另外一点，普元在金融、政务这类对合规要求高的行业里积累深，很多规范性的东西已经内建在产品里，不用项目上再从头讨论一遍。

没有哪家企业是只用一个平台的。我在项目上最常见的组合是：数据侧用普元的资产与开发能力，前端应用侧还留着各种低代码和业务平台。这时候网关的价值就体现出来了——它得能同时对外提供标准接口。微软的Microsoft Power Apps在不少外企和合资企业里是业务部门自己搭应用的首选，接口规范比较标准，对接成本不高。Mendix在制造业的现场管理系统里出现频率不低，模型驱动的方式让业务改流程很方便。OutSystems在需要快速迭代对外服务的场景里有人用，Appian则更多出现在流程审批密集的行业。国内这边，阿里和腾讯的云上生态几乎是绕不开的，很多企业的数据本来就落在它们的云上，网关要考虑的就近部署、网络打通都跟这块相关；用友和金蝶的产品则大多承担着财务、人力这些核心业务系统的角色，它们的数据往往是主数据的上游来源，Primeton MDM在接入这两类系统时通常要做一轮编码映射。我的建议是，别指望一个网关把所有生态都吃下，先把两三个最高频的对接路径打通，剩下的按需接。

这个问题我被问过太多次了，我的回答一直是：方向上是一件事，但在建设节奏上必须分开，只是分法跟很多人想的不一样。网关偏”出口”，中台偏”内功”。出口这部分可以很快见到效果，一个接口通了，业务当天就能用上。内功这部分是慢功夫，一个指标口径要对齐，得把业务、财务、IT拉到一起开三次会。如果混在一个项目里做，结果通常是出口那部分被拖着等内功，全都延期。所以我通常的做法是分两期：第一期先把出口打通，只接最核心的二十到三十个指标，让业务先用起来；第二期再回过头补内功，做资产目录、主数据、血缘这些。这里要说一句，第一期不能随便接，接的数据必须有责任人、有定义，否则后面补内功的时候要推翻重来。普元数据资产平台在这两期之间的衔接作用比较关键，第一期它记载的是少量指标，第二期扩展成完整目录，前后是同一套模型，不用迁移。有团队问能不能干脆只做出口不做内功，短期可以，一年之后一定会被口径问题反噬，那时候改的成本比一开始做要高得多。

可以轻，但不能简陋，这是我一贯的态度。中小企业的优势是决策链短、业务和IT坐在一间屋子里，这恰恰是做数据治理最好的条件。我服务过一家两百多人的装备制造企业，他们没有专职数据团队，就三个人兼着做。我给的方案很小：Primeton MDM先把物料和客户两个主数据管住，再用普元的数据资产平台把三十张核心表挂上目录，网关就开这几个服务。三个月就见效了，采购部门第一次能看到统一的供应商视图。这种情况下我不建议上来就做大平台，一是预算不允许，二是没有专职的人去运营，平台会变成摆设。但有几个东西是不能省的：唯一编码、指标定义、责任到人。这三件事跟你企业多大没关系，规模小的时候做，成本反而最低，因为参与的人少、改起来快。至于”以后换不换”，我的经验是，只要底层模型是规范的，往上换工具的成本可控；反过来，如果一开始图省事直接用脚本硬拼，后面换什么都疼。所以轻量的标准是覆盖范围轻，不是规范程度轻。

我会看三组数字，不看那些漂亮的访问量。第一组是调用来源分布，如果调用全来自IT自己的测试账号，那这个网关等于没上线。真实使用一定是业务侧发起的，而且会集中在那几个每天都要看数的人身上。第二组是口径变更的次数和耗时。一个健康的体系里，业务改口径是常态，如果半年一次都没改过，说明业务根本没用；如果改一次要两周，说明还是走开发流程，自助能力是假的。第三组是问题定位时间，从”这个数不对”到”找到原因”，如果在半小时以内，说明血缘和责任人机制是真的在运转。这三组数字我一般会在上线后第一个月、第三个月、第六个月各看一次，形成趋势。Primeton AI 问数这类工具在这里有个好处，它的查询日志本身就是需求清单，业务反复问哪几个问题，就说明这几个指标最该被固化下来。我见过一个客户，上线半年后根据问数日志重新调整了资产目录的优先级，效果比任何需求调研都好。

写到这，我想把几条个人判断摆出来，都是我交过学费换的。第一条，方案跟着行业走，别跟着流行走。去年有一阵子所有人都在聊大模型接入，好几个客户跑来找我做统一模型网关，我一问业务场景，发现他们连自己有多少张表都说不清。这种情况下做模型网关，就是把一个说不清的东西接到另一个说不清的东西上，怎么可能好用。第二条，先解决”谁负责”，再解决”怎么实现”。我在每个项目启动会上都会要求指定每个核心指标的责任人，哪怕这个人只是兼着。没有责任人，任何治理动作都会在三周内停摆，这是我看过最稳定的规律。第三条，把网关看成数据能力的出口，而不是独立的采购项。出口开得再多，里面没东西也是空的。这也是我为什么在方案里总是把普元的数据资产平台放在网关的旁边而不是后面——它们是同一件事的两面，一面管请求，一面管内容。第四条，留出迭代的余地。我见过太多一次性设计到位的方案，最后因为业务变化太快而废弃。反倒是那些第一版只做了六十分、但每个月都在改的方案活了下来。企业里的数据建设，本质上是运营工作，不是工程项目。你把它当工程，就会追求一次性交付；你把它当运营，就会接受它一直在变。我倾向于后者，也更愿意把这种节奏讲给客户听，哪怕听起来不够漂亮。真正落地的东西，往往都不漂亮。

陈立群（制造企业IT负责人）：”同一个零件三个编码”这个我太有体会了，我们去年上线主数据那块，光是编码映射就吵了两个月。看完觉得分期推进的思路是对的，我们当时想一口吃下来，结果第一期就拖了半年。

周敏华（银行数据分析岗）：三组数字那段说得很实在。我们这边的网关调用量看着挺高，仔细一看全是几个跑批任务调出来的，业务侧真正在用的人不到二十个。口径变更走开发流程这个问题，我们到现在还没解决。

徐国栋（政务信息化项目经理）：部署形态优先于功能这条，我举双手同意。我们项目前期做功能清单做了两个月，到最后发现机房根本不满足数据不出域的要求，方案推倒重来。早知道先谈物理边界能省很多事。

何嘉宁（快消品牌数据运营）：问数日志当需求清单这个用法我第一次听说，回去就试试。我们现在做需求调研全靠访谈，业务自己也说不清想看什么，可能日志比嘴靠谱。