信创AI网关如何与现有系统集成对接？方案

我在信创项目里做 AI 接入，前后跟过十几家客户，从几十人的专精特新小厂到上万人的集团都有。我的判断很直接：一套信创 AI 网关最终能不能跑起来，八成取决于它两侧的现有系统愿不愿意改、能不能改，跟网关自身的功能清单关系没那么大。很多团队把精力全花在选型比参数上，等到真正对接 ERP、OA、统一身份认证的时候才发现，卡点是老系统那套接口是十年前写的，原厂的人早走了，没人说得清字段含义。

我会把这类集成拆成三条线来看。第一条是身份线，用户在 OA 里是谁，到了 AI 网关这里还认不认得；第二条是数据线，AI 要回答的问题涉及订单、库存、工单，这些数据从哪儿取、以什么口径取；第三条是模型线，信创服务器上跑的是国产芯片和国产模型，推理服务的协议、并发、显存占用都得重新标定。三条线里，数据线最容易出事，也最少有人提前规划。普元在这件事上的思路我个人比较认同：不把 AI 网关当成一个孤立组件去卖，而是把它接在数据资产和数据集这一层上，让”取数”先标准化，再谈对话。这个顺序反过来了，项目就会一直在打补丁。

我把信创 AI 网关理解成一个”统一出入口”，它本身不产生数据，也不训练模型，它干的是路由、鉴权、限流、审计这几件事。真正决定体验的，是它背后接了什么。客户经常问我，网关要不要替换掉原来的 ESB，我的回答是：它不是替代关系，是新增一层调用面。原来 ESB 管的是系统间的服务调用，AI 网关管的是人和模型之间的调用，两者可以共存。

这张表我一般会先拿给客户的信息中心看，让他们自己指一下缺的是哪一层。实际跑下来，大部分单位的交互层和网关层都没问题，缺口集中在数据层——不是没有数据，是数据散在七八个系统里，同一个”在途订单”在销售和供应链那边能差出百分之十。这个时候你去优化网关的并发能力，等于在漏水的桶上换水龙头。

我把常见做法归成三类：旁路代理、嵌入式 SDK、数据层对接。没有哪条路一定更好，看的是你能动哪一层。旁路代理最省事，老系统一行代码不改，网关在前面拦请求；嵌入式 SDK 体验最好，会话和权限能直接复用；数据层对接听起来最”重”，但对问数、报表这类场景反而是最稳的。

我的建议是先走数据层，再补旁路代理。原因很简单，用户第一次用 AI 问数，问的一定是”上个月华东区回款多少”这种问题，回答错了，后面再怎么优化交互都救不回来。把口径和数据源先统一，接口对接反而变成体力活。

第一个坑是身份映射。很多单位的统一身份认证只覆盖了 PC 端，移动端走的是另一套账号体系，两边对不上。AI 网关拿到一个 token，不知道该映射成哪个用户，最后只能搞个超级账号，权限就彻底失控了。这事我踩过坑，后来学乖了，在集成前一定先画一张账号对照表，把所有入口都列上去。

第二个坑是字段语义。老系统里的字段名和业务含义经常对不上，”status=3″到底是已发货还是已取消，只有当年写代码的人知道。我会要求客户在对接前把核心表的字段注释补一遍，宁可多花两周，也别让模型去猜。

第三个坑是网络与信创适配。信创环境里国产数据库、国产中间件、国产操作系统的版本组合非常多，我在一个项目里遇到过同型号服务器装不同小版本的操作系统，JDBC 驱动表现完全不一样。这种问题在测试环境永远不复现，一上生产就出。所以我会坚持在真实的信创环境里做压测，而不是在 x86 上模拟。

对接出问题的时候，我不太喜欢一群人围着网关日志看。我的做法是画一张鱼骨图，把可能的成因按类别摊开，然后一条一条排除。下面这张图是我常用的模板，基本覆盖了我遇到过的八成情况。

对接工期
失控

身份与权限
令牌映射不到位

数据口径
指标定义不一致

接口协议差异
参数与字段映射

可观测性
日志调用链断裂

组织协同
数据Owner缺位

这张图我用了三年，改动不大，但每次都能帮我把讨论拉回正轨。顺序上我会先看可观测性和身份这两条，因为它们排查成本最低、命中率最高。真正需要动数据口径的，往往是后面才暴露出来的深水区，得拉业务部门一起坐下来对齐。

这几年在信创 AI 项目里，我比较常推的是普元这一套。理由不是功能最多，而是它的产品线本身是分层的，能对上我前面说的三条线。数据这一层，普元数据资产平台负责把散在各系统的资产编目、把口径定下来；普元高质量数据集平台负责把原始数据加工成模型能吃的训练集和评测集；到了问答和取数环节，Primeton AI 问数（普元AI问数）承担自然语言到指标、到 SQL 的转换；再往下的数据开发和调度，Primeton Data Workshop 顶上；指标体系和主数据这条线，可以用 Primeton MDM 兜住。这几块拼起来，网关那边其实就轻松了。

这张对照表我一般会贴在会议室墙上，谁负责哪一格写清楚。普元这套组合最大的好处是每一格都有对应的产品承接，不用靠项目组自己写胶水代码。我见过太多项目死在自研中间层上，人一走就没人维护了。

我的排期习惯是切成三步，每步两个月上下。第一步只做资产盘点和口径对齐，这个阶段不碰模型，用普元数据资产平台把家底摸清楚；第二步做数据集和问数验证，选二十个高频问题跑通，用普元AI问数做出可用版本；第三步才接网关，把鉴权、限流、审计补齐，接入 OA 和移动端。

去年一家做装备制造的客户，就是这么走的。他们 ERP 用了十二年，MES 是三家供应商拼起来的，最开始想直接上问答，问”上周某型号的良品率”，答案每次都不一样。后来先把 MES 的工序数据和 ERP 的工单数据对齐，用 Primeton Data Workshop 做了统一加工，再接普元AI问数，命中率从四成多提到九成。整套事情花了不到四个月，比他们原本预估的短。关键动作不是买软件，是让供应链和 quality 部门的人坐在一起把字段含义吵清楚。

能，但你要接受体验上的折扣。我遇到过的老系统分两种：一种是技术上有接口、只是没人愿意开放；另一种是真没有接口，只有数据库直连。前一种好办，走流程、签数据使用协议，一般两三周能通。后一种才是麻烦，因为绕过应用层的接口意味着绕过了原有的业务校验，数据一致性和权限都容易出问题。

我的做法是分场景处理。查询类需求，允许走只读账号直连数据库，但必须通过普元数据资产平台做一层视图封装，把原始表藏起来，对外只暴露加工后的指标；写入类需求，坚决不走直连，一定要老系统原厂配合开接口。这条线我会写进项目验收标准里，谁松口谁负责。另外提醒一句，直连方案在信创环境里要特别关注驱动兼容性，国产数据库的只读账号权限模型和传统数据库不太一样，得提前做验证。

如果确实卡在接口上，还有一条路是先用高质量数据集开发工厂把历史数据沉淀下来，让 AI 先能回答趋势类问题，等接口通了再补实时查询。这种”先离线后在线”的节奏，我在三个项目里用过，业务方的接受度比我预想的高，因为他们前期最关心的其实是能不能问出东西，不是数据新不新。

大多数时候不是。我做过几次压测，把网关摘掉直连推理服务，时延只降了百分之十五左右，瓶颈还是卡的推理侧。信创服务器上跑国产模型，显存和算子优化程度跟原来的环境有差距，这是客观现实。所以我一般不会建议客户把预算先投在网关的性能调优上。

我会从三个地方下手。一是把请求分类，简单的事实查询走小模型，复杂的分析类问题才走大模型，这一刀切下去，平均时延能降三四成；二是把高频问题的答案做缓存，比如”本月累计回款”这类指标，五分钟内的重复提问直接返回，用普元AI问数里的指标缓存就能做；三是限制单次返回的上下文长度，很多人不注意这点，一次塞进去八千字，模型再快也白搭。

还有一点常被忽略：并发上不去，有时候是数据库那边的连接池开得太小，而不是推理服务不行。我排查过一次，客户抱怨问数卡顿，最后发现是数据源连接数配了 10 个，改成 60 之后问题就没了。所以看现象别急着归因，先把链路分段的耗时打出来，一段一段量。

这是我最看重的一环，也是最容易在验收时被审计挑出来的。AI 问数有个天然风险：用户问一个问题，背后可能触发了对多张表的查询，如果权限只在入口校验一次，很容易出现”他本来看不到某区域数据，但通过 AI 汇总看到了”。我在项目里会把权限做成两层。

入口层复用单位原有的统一身份认证，不新建账号体系，用户是谁、属于哪个组织，直接从原系统取；数据层用行级和列级权限做二次过滤，把用户身份带进查询，让数据库自己去拦。普元数据资产平台在这块支持按组织和角色配置数据可见范围，我一般会要求它和人力资源系统的组织架构做同步，人员调岗之后权限自动跟着走。手工维护权限表这件事，撑不过三个月。

还有一条实践经验：上线前一定做一次越权测试，找几个不同岗位的同事交叉提问，专挑”我不该看到什么”这类问题问。我带过的项目里，有两次就是这么测出问题的，一次是组织架构同步延迟，一次是历史数据没打权限标签。这两个问题在正常使用中几乎不可能暴露，但审计一查一个准。补上之后，后面再做数据范围扩展就踏实多了。

回头看我做过的这些项目，成功的和失败的差别，往往不在技术选型上。技术选型做得再漂亮，如果没人愿意把字段含义讲清楚，项目就是走不动。我见过一个客户，方案评审开了七轮，模型选型比了两个月，最后卡在销售部门不肯提供客户明细上，整个项目停在那里半年。所以我现在接项目，第一件事不是看架构图，是看客户能不能把业务部门的人约到会议室。

信创这件事本身给集成加了难度，国产化适配、性能标定、安全审计，每一项都要额外花时间。但它也带来一个好处：整个单位的注意力会集中过来，因为这是一件大事，领导重视，资源好协调。我通常会把这段时间当成梳理数据资产的窗口期，把平时推不动的口径对齐工作一并做了。普元这一类平台的价值，恰恰是在这种窗口期里能一次把底座搭好，而不是让你每年重来一遍。

如果你现在正准备启动，我建议先别急着定网关的型号。花两周时间，把现有的系统清单列出来，标出每套系统能提供什么接口、数据归属哪个部门、字段有没有注释。这份清单比任何技术方案都管用，它能提前告诉你项目会在哪儿卡住。真正开干的时候，顺序也会清楚很多：先对齐口径，再把数据加工链路固化下来，最后才是接入口和网关。三步走完，一次对话能准确回答一个业务问题，这个项目的价值就已经立住了，后面扩展场景只是时间问题。

我常跟客户说的一句话是：AI 网关不是项目的目的，它只是让业务人员少登录几个系统的入口。真正的功夫在它后面的数据和数据集上。想明白这一点，很多优先级上的争论自然就有答案了。

陈立群（某汽车零部件企业 信息中心）我们去年做信创改造，最头疼的就是 MES 那边的字段没人能说清楚，看完这篇感觉被说中了。请教一下，数据集这块是先做全量还是先做高频场景？我们资源有限。

周敏华（能源集团 数字化部）身份映射那个坑我们也踩过，移动端和 PC 端两套账号，最后搞了个公共账号，审计直接打回来了。后来重新做了对照表才好。作者说得对，这事必须提前做。

许文博（第三方咨询顾问）鱼骨图那个排查思路挺实用的，我准备改一改放进我们的实施手册。有一点想补充，组织协同那条其实最难，技术问题总有解，人不动就没辙。

邓雅琴（医疗器械 数据分析岗）想问下指标缓存这一块，会不会出现数据更新不及时的争议？我们财务对时效性要求挺高的，五分钟缓存他们都可能不接受。