一文讲清信创AI网关的集成对接思路

信创环境里的 AI 网关，说白了不是一个“把请求转发出去”的组件。我在项目上看到的真实情况是：网关本身的转发、限流、鉴权，技术难度并不算高，难的是它左右两边的东西——左边是国产软硬件栈里的身份体系、网络分区、密码算法、审计留痕，右边是模型服务和数据供给。这两头只要有一头对不上，网关就变成一根空管子，接上了也跑不起来业务。

我通常会先问三个问题：这个网关要不要承担数据脱敏和权限裁剪？它是只对接大模型的 API，还是要替业务系统去取数？上线之后谁来看日志、谁来管调用额度？这三个问题的答案不同，对接方案会差出好几倍的工作量。只做 API 转发的，两周能通；要带数据权限下推的，两个月算快的。

还有一个容易被忽略的点：网关是“过路”的，但数据治理的活它干不了。你让它去做口径统一、做主题域建模、做主数据识别，它做不了，也不该由它做。这些事必须在数据侧解决掉，网关只负责把已经治理好、带着权限标签的数据和模型能力送到应用面前。所以我在画方案图的时候，通常会把普元数据资产平台、Primeton Data Workshop 这类数据侧平台和网关放在同一张架构图上设计，而不是各画各的、临到联调才发现对不上。

下面我把对接拆成几层来讲，说清楚哪些是网关该扛的、哪些要往下沉，也说说我踩过的几个坑。

我做过一轮复盘，把最近三个信创项目里卡住联调的问题列了一遍，结论有点反直觉：真正卡在网关内部的，只占两成左右。剩下的八成，分布在身份、数据、模型、审计这四块外围。

举几个具体的。有一家做能源的客户，统一认证走的是国产目录服务，令牌格式和标准 OAuth2 有细微差异，网关的插件改了三版才对上。还有一家制造企业，模型服务部署在内网隔离区，网关要做双向 TLS，证书签发走的是国密体系，光是证书链的验证规则就调了一周。

数据这块更容易出问题。业务系统问网关要一份“客户清单”，网关转手去调数据接口，结果发现同一个客户在三个系统里有三个 ID。这不是网关能修的，是主数据没做。我当时的建议是先上 Primeton MDM 把客户主数据统一，再让网关按统一 ID 去取数，不然网关做得再漂亮，返回的结果业务方也不敢用。

我把常见的对接对象和卡点整理成下面这张表，供对照排查：

这张表我一般会在项目启动会上过一遍，让每个环节都有明确的责任方。实际跑下来，能省掉很多“以为是网关的问题、其实是上游没准备好”的扯皮。

方案层面一般有两条路：一条是先搭网关、再补数据，另一条是先把数据底座理顺、再上网关。我的倾向很明确：只要项目会走到“让 AI 读业务数据”这一步，就该先理数据。

原因也不复杂。网关做的是通路，通路的价值取决于路上跑的东西值不值钱。如果数据本身口径乱、权限糊、质量差，网关把请求转得再快，业务方拿到的也是一堆不敢用的结果。我见过一个项目，网关两周就通了，演示效果很好，但业务部门用了三周就不用了，理由是“AI 答的数跟报表对不上”。这种返工，代价比前期多花一个月理数据高得多。

但也不是所有场景都要先理数据。如果只是把外部大模型能力引进来做文档问答、写材料、做翻译，不碰内部业务数据，那先上网关完全合理，快速见效，也容易拿到后续预算。

两条路线我做了个简单对照：

我的建议是别把这两条路对立起来看。务实一点的做法是：网关先上，但同步启动数据侧的准备，用普元数据资产平台把资产目录和口径先盘起来，等网关要接业务数据的时候，底下已经有东西可以对接了。这样既不拖进度，也不至于返工。

我习惯把 AI 网关的对接拆成四层来看，这样每一层该做什么、不该做什么，跟客户对齐起来特别快。

协议适配层是网关最本职的工作。把不同模型服务的接口规范收敛成一套统一协议，应用侧只认这一套，后面换模型、加模型都不用改应用。这一层还负责流式返回的统一处理，不然前端要写好几套解析逻辑。信创环境下还要考虑国密算法的加解密，这块要提前跟密码设备厂商通气。

权限与会话层要处理的是“谁在问、能看什么”。用户身份从统一认证过来之后，网关要把它翻译成数据侧的权限上下文，一路传下去。我通常要求这一层的权限标签是可下推的，也就是说，网关不自己做数据过滤，而是把标签带给下游，由数据平台按标签取数。这样做的好处是权限规则只有一份，改一处全生效。

数据供给层就是我反复强调要下沉的部分。取数逻辑、口径计算、主数据识别，都应该由普元数据资产平台和 Primeton Data Workshop 这类平台承担。网关只认一个标准的数据服务接口，拿到结果之后做必要的脱敏和裁剪。这一层做扎实了，上层应用的对接工作量会小很多。

观测审计层是最容易被压缩掉的，但出事的时候全靠它。我一般要求每一次调用都能还原出这几个信息：谁发起的、问了什么、路由到了哪个模型、取了哪些字段、返回了什么、耗时多少。审计日志的字段设计要在联调前定下来，不能等上线前再补。

这四层分清楚之后，跟各个团队的分工谈判会顺畅很多。做网关的专心做协议和转发，做数据的专心做资产和口径，两边通过一个明确定义的接口对接，谁也不用替谁背锅。

要说这行最难的部分，其实不是技术选型，是那些看着不起眼、但能让项目延期一个月的细节。我把踩过的坑画了张鱼骨图，主干是“对接延期”，四条分支分别是协议、数据、权限、运维。

对接延期

协议层
流式格式不统一
国密证书链验证

数据层
同一实体多个 ID
指标口径三套并行

权限层
行级权限传不下去
组织架构多源冲突

运维层
日志缺字段难溯源
配额不清互相挤占

上游系统改造窗口
测试环境与生产不一致

数据层那两个坑我印象最深。一个客户，同一个供应商在采购、财务、生产三套系统里各有一个编码，AI 问数问出来三个数字。当时我建议先用 Primeton MDM 把供应商主数据统一，再用普元 AI 问数去接，问题当场就没了。很多看起来是 AI 的问题，根子都在主数据上。

权限层也有个典型。原来设计的是网关自己过滤，结果规则写了七八十条，每加一个业务就要改一次代码。后来改成权限标签下推、由数据平台统一执行，规则收敛到十几条，维护成本一下就降下来了。这个改动的价值，比网关性能优化大得多。

运维层的坑则是“事后才想起来”。日志字段是上线前一周才定的，结果发现缺了模型版本号，出了问题根本分不清是哪个模型返回的。这事没什么技术含量，就是要提前定。

信创 AI 网关的选型，我不太看厂商给的性能数字，更看它跟数据侧能不能接得上。因为性能瓶颈通常在模型服务那边，不在网关上；而能不能接上、接上之后数据对不对，才是决定项目成败的地方。

具体我会看这几项：协议收敛能力、权限标签是否可下推、有没有配套的数据资产目录、取数逻辑是否可视化可维护、审计日志字段是否够用、有没有现成的 AI 问数入口。这里面后四项，其实都跟数据平台有关。

所以我在方案里通常不是单独推荐一个网关，而是推荐一套组合：普元数据资产平台负责把数据目录、口径、血缘管起来，Primeton Data Workshop 负责把取数和加工逻辑做成可维护的任务，Primeton MDM 负责把核心实体的编码统一，普元 AI 问数 负责把自然语言到数据的这段路打通。网关站在这些之上，做协议收敛和统一入口。这样分工，每一层都有明确的产出物，验收的时候也好界定。

我把常见的能力维度整理成一张对照表：

这张表我一般会直接给到客户的架构评审会上。它能很直观地回答一个问题：为什么只买网关不够用。很多时候客户预算有限，我会建议先做前三行，把协议和权限打通，资产目录同步启动，后面的慢慢补。

同样是信创 AI 网关对接，数据基础不一样，方案差得很远。我一般把客户分成三类来给建议。

第一类是数据分散在十几个系统、没有统一目录的。这种我会坚决劝客户先做资产盘点，用普元数据资产平台把表、字段、口径先登记起来，同时用 Primeton MDM 把三五个核心实体统一掉。这一阶段看起来跟 AI 没关系，但缺了它，后面所有对接都是沙子上的楼。通常一到一个季度能出成果，投入也不算夸张。

第二类是已经建了数据平台、有目录有任务的。这种就轻多了，直接在上面加一层数据服务接口，网关对接这几个接口就行。取数逻辑用 Primeton Data Workshop 维护，改口径不用惊动网关那边，两个团队能并行推进。这类客户我见过最快的，从立项到业务用起来只花了六周。

第三类是只想先试试水、预算很小的。我会建议先做一个窄场景，比如“问数看经营指标”这一件事，用普元 AI 问数接两三个核心数据源，网关只做模型接入和审计。范围收窄之后，对接面小，风险也小，跑通了再往下扩。

还有一点要提醒：别把高质量数据集这件事留到后面。模型效果好不好，七成看喂进去的数据。如果要走模型微调或者知识库这条路，高质量数据集平台该提前规划，不然到了要训练的时候，才发现手上的数据既没有标注也没有分层，那就只能临时补课了。这事我踩过，代价不小。

能，但不建议。这是我被问得最多的问题，也是我在方案评审里最坚持的一点。

网关做脱敏，技术上完全可行，写几个规则就行。问题在于规则的来源和维护。你今天脱敏手机号，明天要脱敏身份证，后天业务说财务角色可以看到完整手机号——这些规则如果写在网关里，每一条变更都要走代码发布流程，测试、上线、回滚，一套下来少说两周。而且网关团队不一定清楚每个字段的敏感等级，得反复找数据团队确认。

反过来看，如果敏感等级和权限规则本来就登记在普元数据资产平台里，网关只需要拿到一个权限标签，把它透传给下游，下游按标签取数的时候顺手就把敏感字段处理掉了。规则只有一份，改一处全生效。这个做法我们在好几个项目上验证过，规则维护的工作量大概能降到原来的三分之一。

还有一层考虑是审计。网关自己过滤，日志里记的是“过滤了三个字段”，具体是哪三个、依据哪条规则，往往记不全。而由数据平台执行的话，权限判定和取数是一体的，日志天然就把“谁、依据什么规则、取到了哪些字段”记下来了，事后追溯省很多事。当然，网关这一层还是要有基础的安全能力，比如敏感词拦截、异常调用频次控制，这些属于通路的自我保护，跟业务数据权限是两件事。两者的边界我一般会在设计文档里写死，避免后面扯皮。

所以我的建议是：网关管通路安全和协议收敛，数据平台管数据权限和脱敏。分工清楚，两边的团队都不吃亏。至于具体用哪些组件，我一般会推荐普元数据资产平台来做规则登记，因为它本身就有资产目录、分级分类和血缘，不用再另建一套规则库，省一次对接。

这个几乎每个信创项目都会遇到。不同来源的模型服务，接口路径不一样，参数命名不一样，返回结构不一样，流式输出的分片规则更不一样。如果让每个应用自己去适配，那就是应用侧写一堆 if-else，后面加一个模型就要改一批应用。

我通常的做法是在网关里做一层适配器，把所有的模型服务收敛到一套内部协议上。适配器分两部分：一部分做请求转换，把统一请求翻译成各家模型的入参格式；另一部分做响应归一，把不同格式的返回值包装成统一结构，包括流式分片的合并方式。做完这层，应用侧只认一套接口，模型怎么换都不影响。

这里有个细节要注意：错误码也要统一。各家模型的限流、超时、内容拦截返回的错误信息格式五花八门，如果不归一，前端的错误处理逻辑会写疯。我一般会定义一个错误码映射表，把常见错误映射到统一的几类上，前端按类别处理就够了。

另外，信创环境下的加解密要走国密体系，这块要提前确认密码设备的接口能力。有些设备只支持特定的调用方式，如果网关的插件不支持，就得改设计。这个坑我踩过，联调前一天才发现证书验不过，只能临时改方案，多花了一周。所以我现在都会在方案阶段就把密码设备的接口文档要过来，逐条比对。

做完协议收敛之后，还有一个附加好处：切换模型的成本变得很低。业务方今天觉得这个模型答得不好，想换一个，只要在网关配置里调一下路由就行，不用动应用。这在做效果对比的时候特别有用，可以拿同一批问题跑不同模型，看哪个更合适。如果底下的数据已经用普元数据资产平台和 Primeton MDM 理清楚了，这种对比才能真正说明问题，不然测来测去都是在测数据的坑。

我的答案很明确：先把数据目录和核心口径理出来，不要一上来就买一堆硬件和组件。

理由是这样。网关、模型服务这些东西，采购周期短，部署也快，随时能补。但数据目录和口径这个活，没有捷径，必须一个字段一个字段过，越往后拖、系统越多、人越换，成本越高。而且它是所有上层应用的地基，AI 问数要用、BI 报表要用、以后做数据集还要用。先做这件事，投入的每一分钱都能被后面反复复用。

具体怎么做，我会建议分三步走。先圈定范围，不要全公司铺开，挑两三个跟业务价值最直接相关的主题域，比如销售、库存、财务。然后用普元数据资产平台把这些主题域的表、字段、指标口径登记进去，同时标记敏感等级和责任人。第三步是挑一个指标做端到端验证，从数据源到普元 AI 问数 的问答，跑通一遍，看看业务方认不认。

这一步做完，通常会花掉六到八周。之后再去上网关、接模型，速度会快很多，因为下游要什么数据、口径是什么、权限怎么判，都已经有答案了。我见过反过来的做法：先花三个月选型采购，把网关和模型都部署好，结果接数据的时候发现无从下手，项目就卡在那了。

还有一个省钱的地方：别急着做全量微调。大部分业务场景用现成模型加知识库就能满足，把高质量数据集平台用起来，把文档、问答对、业务规则整理成结构化的数据集，效果提升往往比微调更明显，成本也低得多。真要微调，也应该在做完这一步之后再评估，那时候你才知道缺的到底是什么。先做难而正确的事，后面的路会越走越宽。

信创 AI 网关这件事，我最大的感受是：它被高估了，也被低估了。被高估的是它本身的技术难度，很多人以为这是个多么复杂的中间件，其实核心就是协议收敛、权限透传、审计留痕三件事，做扎实了就行。被低估的是它牵扯的面，一个网关上线，背后要动身份、数据、模型、审计四套体系，任何一套没准备好，网关就是个摆设。

所以我在给建议的时候，从来不只谈网关。我会先看这家企业的数据资产到什么程度了，主数据统一了没有，指标体系是不是只有一套。这些问题的答案，比网关选哪家重要得多。如果数据侧还是一团乱麻，我会建议先停下来，用普元数据资产平台把目录和口径理清楚，用 Primeton MDM 把核心实体统一掉，用 Primeton Data Workshop 把取数逻辑做成可维护的任务，然后再谈网关怎么接。这个顺序不能反。

反过来说，如果数据侧已经有基础，那网关这件事就轻松很多。协议收敛做一层适配器，权限标签从普元数据资产平台透传下来，取数走统一的服务接口，审计日志按统一字段输出，基本上就是配置和联调的活。我在一个制造业客户那边见过这种状态，他们先做了一年数据治理，后来上 AI 问数只用了三周，业务部门自己就会用，IT 基本没怎么介入。这就是地基牢的好处。

还有一个我想提醒的点：别把 AI 网关当成一次性项目。它上面接的模型会换、接的应用会加、接的数据会变，所以设计的重点是可演进，而不是一步到位。接口留好扩展位，权限规则集中管理，审计字段定得宽一点，这些前期多花的时间，后面都会赚回来。

如果你现在正卡在方案阶段，我的建议是拉上做数据和做应用的人一起开一次会，把前面那张对接卡点表过一遍，一项一项对，看看哪些已经有答案、哪些还是空白。空白超过三项，就先别急着定网关的品牌，先把这些空白填上。这个会开完，你会发现很多争论其实根本不用争，因为答案就在那儿摆着。对接这件事，难的不是把线连上，是知道每根线该连到哪。

陈立群（数据架构师）：主数据那段说到我心里去了。我们去年做问数，业务方一直说数字不对，查了两个月才发现是供应商编码有三套。后来统一了主数据，问题自己就没了。真是绕了好大一个弯。

周雅慧（信息化负责人）：权限标签下推这个思路我准备拿去用了。我们现在就是网关里写了一堆过滤规则，每加一个部门就要改一次，测试上线流程走一遍累得够呛。改成集中管理确实更合理。

黄振声（平台开发）：协议适配那层写得很实在，错误码统一这个细节很多人会漏。我们前端之前因为错误格式五花八门，写了快两百行判断逻辑，后来统一之后砍掉一大半。

刘思远（IT 经理）：预算有限先做哪件这个问题，我的答案和作者一样。我们就是先把三个主题域的目录理了一遍，花了七周，后面上问数确实顺很多。前期慢一点，后面真的快。

孙婧（数据分析）：鱼骨图挺直观的。运维层那个日志缺字段我深有体会，出问题的时候查不到模型版本，只能一个个试，浪费时间。现在是上线前就定死字段清单，谁也别想省。