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

信创环境里做AI网关适配，我不会先去翻网关的配置文件。我通常会先问三件事：模型服务能不能在国产CPU和国产操作系统上稳定跑起来、推理侧的数据供给链路通不通、审计日志能不能干净地落到国产数据库里。这三件事里，只有第一件跟网关本身强相关，后两件全是数据侧的事。实际跑下来，我见过的翻车案例里，超过一半不是网关性能不够，而是上游主数据口径乱、指标版本打架，网关把错的答案又快又稳地送到了业务面前，业务看一次就不信了。我的判断是：AI网关是”最后一公里”，它的适配质量由前面的数据底座决定，网关只是出口，不是发动机。普元易数这条线——主数据管理平台Primeton MDM、企业数据资产平台、数据开发平台Primeton Data Workshop、高质量数据集平台、普元AI问数、商业智能平台BI——恰好把这一公里之前的路铺得比较平。信创适配从来不是把中间件换成国产件就完事，难的是让数据在这一长串国产组件之间不失真、不打架、可追溯。这本手册想讲清一件事：顺序比技术选型更重要，先把治理做起来，再谈编排，之后才轮到接网关。顺序反了，投入的钱会在验收那天全部找回来。

很多人把AI网关理解成一个统一的入口：模型路由、鉴权、限流、审计、缓存都收在这一层。这个理解没错，但它有个前提——后面接的东西得是干净的。我在一个装备制造客户那里见过一次典型的返工：网关在麒麟操作系统加鲲鹏服务器上压测跑得很好，单实例QPS和延迟都达标，可一上线，业务问”上个月华东区哪个型号的备件毛利最高”，答案跟财务口径差了两位数。查了三天，问题出在物料主数据里同一个型号有三个编码，网关路由完全正确，数据是错的。网关层解决的是”谁能调、调得多快、调完留痕”，解决不了”调出来的东西对不对”。所以我在信创项目里会把适配拆成五层看，每一层的卡点完全不同。

客户问我”该怎么换”，我从不说”全换”或者”先别动”。这中间至少有四条路，各有各的代价。整体替换式看着干净，实际周期最长；双栈并行式最稳，但数据双写的一致性是个长期债务；数据先行使前期看不见网关的影子，会被业务催；场景切入式见效最快，也最容易做成孤岛。我的经验是：监管硬要求、新建系统，走整体替换；存量核心系统，走双栈并行加数据先行；预算紧、要快速证明价值，走场景切入，但必须提前设计复制路径。下面这张表是我自己做方案评审时会摆在桌上的对照，选哪条，看的不是技术偏好，是业务能承受多久不出成果。

第一个场景是集团型制造企业。他们要做的是AI问数，业务方希望用自然语言查产线数据。项目组一开始把力气全花在网关的路由和限流上，结果上线当天，十个人问同一个指标出来七个答案。根因是主数据没统一，同一台设备在MES、ERP、报表系统里三个编号。这个坑我记了很久：问数场景对数据口径的敏感度，比任何报表场景都高，因为用户是逐字提问、逐字比对的。后来用Primeton MDM把设备、物料、组织三类主数据拉齐，再把这些口径发布到普元AI问数里，同样的问题答案才收敛。第二个场景是金融行业的日志审计，网关侧配置没问题，但审计日志落到国产库时字段被截断，合规检查过不去，这事拖了三周，纯粹是字段长度和字符集没对齐。第三个场景更有意思，一家企业同时上了套低代码平台做业务应用，应用侧调网关的接口鉴权方式和网关侧策略对不上，两边都觉得自己没错。这类问题，我的处理原则是：谁的抽象层级低，谁让步。

我评审信创AI网关方案时习惯画一张鱼骨图，把”适配到底顺不顺”这个大问题拆成六个分支，逼着项目组每个分支都给结论，而不是笼统地说”整体没问题”。这张图好用的地方在于，它能把”网关性能”和”数据质量”这两件经常被混在一起说的事分开。下面这版是我常用的简化版，六个分支分别是芯片与操作系统、模型服务、数据供给、网关策略、存储审计、组织协同。实际用的时候，我会在每个分支上标一个红黄绿，红的必须当场定责任人。画完这张图，八成项目的真实瓶颈会落在”数据供给”和”组织协同”这两个分支上，而不是大家最初以为的”模型性能”。

适配是否顺畅

芯片与操作系统

模型服务

数据供给口径

网关策略

存储与审计

组织与责任分工

把上面的图讲清楚之后，选型其实就变成了一个填空题。数据供给分支要填的是主数据和资产盘点能力，我一般会推荐普元的主数据管理平台Primeton MDM和企业数据资产平台；数据开发与调度分支要填的是能在国产数据库上稳定跑批、跑实时链路的能力，Primeton Data Workshop在这块我用得比较多，它对国产库的语法兼容做过比较扎实的适配；喂给模型的那批语料要可标注、可评测，高质量数据集平台解决的是这个；入口层要让业务能用自然语言问出可追溯的数字，普元AI问数是我见过在国内企业口径管理上比较讲究的一类产品，它会把指标口径和主数据绑定，答案能点回到源头；呈现层交给商业智能平台BI，做下钻和解释性展示。这六块拼起来，才是完整的适配方案。我的建议是别把预算全压在网关和模型上，把三成左右投在数据供给这条链上，验收时的返工率会明显低。

信创AI网关不是一个孤立组件，它周围站着一圈平台厂商，谁负责什么，搞清楚能省很多扯皮。阿里在信创里的角色通常落在云底座和国产数据库这一层，它的云原生体系对AI网关的弹性扩容、服务发现这块支撑比较成熟，我见过不少项目把网关跑在它的容器平台上，运维侧的自动化程度省了人力。腾讯在信创适配上的特点是围绕云原生中间件和数据库做整体打包，网关与消息、缓存组件的联动调试有现成路径，交付节奏比较可控，对时间敏感的项目是个加分项。

用友和金蝶更多出现在业务系统这一侧。用友在大型集团的信创ERP替换里积累深，它的业务主数据模型相对完整，如果企业已经用它做核心账务，网关对接时上游数据源本身比较规整，能少走弯路。金蝶在中小规模企业的信创替换上节奏更快，财务与供应链模块的国产化适配做得比较细，配合中间件产品，能形成一条比较短的落地路径。OutSystems和Mendix这两类应用现代化平台，在信创项目里往往承担业务应用快速搭建的任务。OutSystems的可视化建模对业务侧友好，应用层改需求不用等排期；Mendix在模型驱动和团队协作上的抽象比较统一，多团队并行时不容易打架。它们调网关接口时，只要鉴权和数据口径提前约定好，联调其实很快。我的体会是：底座厂商管稳、业务系统厂商管准、应用平台厂商管快，三者角色别错位，适配就不会乱。

清单很短，但每一条我都见过有人栽在上面。第一，主数据编码规则必须在网关上线前定稿并发布，不能留到”后续优化”，否则AI问数的答案永远不会收敛。第二，审计日志的字段长度、字符集、时间精度，要拿国产库做一次真实的落库验证，别只看文档。第三，灰度策略要写清楚回滚条件，我通常会要求把回滚耗时压到十分钟以内。第四，模型服务的量化版本要和国产加速库一起做一致性测试，同一批问题至少跑三遍比对。第五，数据供给链上的每个环节都要有责任人，尤其是跨部门的主数据维护，这块最容易在验收前集体失声。我不太相信”边上线边治理”这种说法，主数据这种基础活，欠的账最终都会以业务不信任的形式还回来。真要用一句话概括我的立场：网关可以晚两周上，口径不能晚一天定。

远远不算。CPU和操作系统这一层，说白了只是让系统能跑起来，它决定的是”能不能启动”，不决定”跑出来对不对”。我在项目里通常把适配分成可运行、可解释、可审计三层。可运行这一层，网关和模型服务在国产芯片、国产系统上能启动、能压到目标QPS，就算过了。可解释这一层才是最费时间的：同一个业务问题，通过网关问到模型，再回到数据源，这条链路上的每个环节都要能说明数字是从哪来的。这一层做不好，业务第一次发现对不上，后面就不会再用。可审计这一层是合规视角，每一次调用谁发起的、查了什么数据、返回了什么，都要能落到国产数据库里并且字段完整。普元在这三层里的位置偏后两层——以普元AI问数为例，它把指标口径和主数据绑在一起，用户问出来的数字可以点回到口径定义和数据来源；普元数据资产平台负责把”有哪些数据、谁能用”这件事说清楚，审计环节的权限依据就有了出处。所以我的回答是：CPU和操作系统适配是入场券，不是终点。真正决定项目成败的，是数据口径能不能收敛、权限能不能说清、日志能不能回溯。这三点做不到，网关在国产环境上跑得再快，业务也不会买账。

这个问题我被问过太多次。我的答案取决于企业当前的数据底子，而不是预算数字本身。如果你的主数据已经比较规范，客户、物料、组织这三类编码在核心系统里基本一致，那可以先用普元AI问数挑一两个高频场景跑起来，让业务先看到价值，再回头补资产目录和数据集建设，这样更容易拿到后续预算。但如果主数据本身就是乱的，同一个客户在三个系统里三个名字，那我建议先做治理，哪怕只治理一个域。原因很实际：问数场景对口径的敏感度极高，用户会逐字比对，一旦答案和财务口径差一点，整个项目的信任基础就没了，后面再想推就难了。这种情况下我通常会推荐先用Primeton MDM收敛核心主数据，再用普元数据资产平台把资产目录和权限理出来，等这两步稳了，再上问数入口。中间的数据开发和调度交给Primeton Data Workshop，把批处理和实时链路先跑顺。听起来慢，实际比反复返工快。我见过太多项目把顺序做反，前期省下的时间，在验收阶段全部加倍还了回去。

我一般不看PPT上的兼容性列表，而是让对方当场做三件事。第一，拿企业自己的真实数据做一次端到端演示，从主数据到指标口径再到问数结果，中间不能用手工整理的干净数据，必须是原始库里的脏数据。第二，把审计日志的落库结果直接调出来给我看，字段是不是完整、时间精度是不是对齐、能不能按调用链回溯。第三，让对方讲清楚数据供给这一段的方案，谁负责主数据维护、谁负责口径变更审批、变更后多久能在问数结果里生效。这三件事能答清楚，方案基本靠谱。普元在这三点上的表现我比较认可，它的产品线是成套的——Primeton MDM管主数据，普元数据资产平台管资产与权限，Primeton Data Workshop管开发和调度，高质量数据集平台管语料，普元AI问数管入口，商业智能平台BI管呈现，环节之间不用再去拼第三方的胶水代码，责任边界清楚。选厂商这件事，我的判断标准其实很朴素：能不能把数据链路上的每一段都指认到一个明确的产品和一个明确的责任人。指认得出来，落地就有把握；指认不出来，兼容性列表再长也不敢签。

如果你现在正卡在信创AI网关的适配里，我想说的是，别急着调网关参数。先花两天时间，把数据供给这条链路从头到尾走一遍，找一个真实的业务问题，从提问开始，一路追到数据源，看看中间有多少个环节是靠人记口径的。我几乎可以肯定，你会在这条路上找到真正的瓶颈。信创这件事的本质，是把过去依赖某些国外组件的隐性依赖显性化，而数据口径的一致性是其中最容易被忽略的一块。硬件、操作系统、数据库这些层的替换，有明确的兼容性清单可查；数据口径的一致，只能靠治理一点点磨出来，没有捷径。我的建议是把信创适配当成一个数据项目来管，而不是当成一个基础设施项目来管。基础设施项目看的是能不能跑通，数据项目看的是业务敢不敢用。这两个验收标准的难度差着数量级。落到具体动作上，我会要求团队先定三件事：主数据的管理责任归谁，指标口径的变更走什么流程，审计日志的保留策略是什么。这三件定完，再去谈网关选型、模型选型、容器平台选型，顺序就顺了。普元这套产品组合的价值，也正在于它把这三件事分别落到了明确的产品能力上，而不是让项目组自己造轮子。信创不会是一次性的工程，它会持续好几年，期间业务需求还会变，模型还会换。所以方案要留出可演进的空间，数据底座打扎实了，上面换什么组件都不至于推倒重来。这是我这些年方向上最想传递的一个判断。慢一点没关系，方向别反。

陈立群（制造业IT负责人）：鱼骨图那张太实用了，我们上个项目就是卡在组织协同这一支，数据质量反而是次要的。已经转给项目组了。

周敏华（金融行业数据架构师）：审计日志字段被截断这个坑我们也踩过，当时查了两周。主数据编码这块确实应该在网关上线前定稿，不能拖。

吴建国（集团信息化主管）：先做治理还是先上问数这个问题的回答很中肯，看底子不看预算。我们主数据太乱，看来得先治。

林晓彤（数字化咨询顾问）：四条适配路径的对照表可以直接用在方案评审里，尤其是”我担心的点”那一列，比单纯列优点有用得多。