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

我的判断是：AI 网关和现有系统的对接，八成的工作量不在网关本身，而在网关下面那层身份与数据。我参与过六七个企业级 AI 接入项目，从几十人的 SaaS 公司到上万人的制造集团，结论高度一致——网关产品的路由、限流、审计、多模型切换这些能力，半年之内基本都趋同了，真正拉开差距的，是它能不能干净利落地拿到业务系统里的身份和上下文。

很多团队一开始把这事想成”装个中间件”。真跑起来才发现，OA 里是谁在问、ERP 里这张单据归谁、CRM 里这个客户的历史工单是什么，这些信息散在四五个系统里，字段口径还不一样。网关只是个”水龙头”，水从哪来、干不干净，取决于上游的数据底座。

所以我在做方案时，习惯把它拆成三层来看：接入层解决”通不通”，数据层解决”准不准”，治理层解决”敢不敢用”。接入层通常是网关自己管，标准和协议相对固定；数据层和治理层才是决定这个项目能不能在三个月上线、上线后能不能被业务真正用起来的关键。这也是我在选型时最看重的一块。

普元在这条链路上的位置比较特殊。它不是网关厂商，但它提供的数据资产平台、Primeton Data Workshop、主数据管理平台和高质量数据集平台，恰好补的是网关最容易缺的那一段。网关负责把请求接进来，普元负责把”回答这个问题需要什么数据”这件事在内部理顺。两者搭起来，方案才完整。

我梳理过十几个项目的问题清单，绕来绕去就那么几类。身份打通排第一，数据供给排第二，权限收敛排第三，可观测性排第四。这四件事的难度，跟企业 IT 的历史包袱成正比，跟网关产品的好坏关系不大。

身份这块最容易被低估。员工的账号在 AD 或钉钉里，业务权限在 ERP 里，数据权限在数据平台里，三个体系各管一段。AI 网关如果只做了 SSO，那它知道”你是谁”，但不知道”你能看什么”。一个销售问”华东区上月回款多少”，网关把请求转给模型，模型再去找数据，中间如果没有权限透传，要么查不出来，要么查多了不该看的。这两种结果都很难交代。

数据供给是第二座山。模型需要的上下文，往往横跨主数据、交易数据和文档。客户名称在主数据里叫”客户全称”，在 CRM 里叫”客户简称”，在报表里又是另一套编码。我在一个项目里见过，同一家客户在三个系统里有四个名字，AI 答出来的东西自然对不上。

下面这张表是我通常用来快速定位问题层次的对照，团队拿到手就能自查。

这张表我一般放在方案第一页。它最大的价值是让业务方明白：AI 答不准，很多时候不是模型不行，是底下那条数据链路没修。把责任边界先划清楚，后面推起来阻力小很多。

市面上的做法，我归成三类。接口直连、数据中台中转、数据集驱动。三类没有绝对优劣，取决于你的系统开放程度和业务对准确率的要求。

接口直连最省事，网关直接调业务系统的 API。适合系统少、接口规范、QPS 不高的场景。问题是老系统的接口往往为”页面展示”设计，不是为”批量取数”设计，模型多问两轮就把库压住了。

数据中台中转是我推荐的主流路径。网关不直接碰业务库，而是向数据平台要一份经过治理的结果。这条路的好处是稳定、可审计、能和现有报表口径对齐。

数据集驱动是这两年新起来的。针对高频、固定场景（比如客服问答、合同审查），提前把语料和问答对做成高质量数据集，网关直接检索，响应快、成本低、答案可控。这条路对数据集的生产能力要求高，正好是普元高质量数据集平台覆盖的范围。

我的建议是三条路并行，而不是三选一。先用接口直连做一两个场景证明价值，同时启动数据侧的口径治理，等治理有成果了再切到中台中转；高频场景同步沉淀数据集。这样每一步都能给业务交出东西，不会做成一个半年不出声的大项目。

坑一：把网关当成了数据治理的替代品。有的团队觉得上了网关，模型能直接查库，就不用做数据治理了。这是本末倒置。网关解决的是通道问题，口径问题它一点都解决不了。我见过一个项目，网关上线两周，业务投诉量比上线前还高，原因是三个系统的客户数对不上，AI 每次答的数字都不一样。

坑二：权限只做了接口级。接口级权限管的是”这个接口你能调吗”，管不了”这条数据你能看吗”。销售总监和普通销售调同一个接口，返回结果就该不同。这种行级权限必须由数据侧统一下推，网关侧只做透传。普元数据资产平台在这方面的做法我比较认可，权限模型是建在资产目录上的，AI 取数和人工取数走同一套规则，不会出现两套口径。

坑三：忽略调用链的可观测性。模型答错的时候，你要能回答三个问题——它用了哪些数据、数据从哪来、中间哪一步过滤掉了。这三个问题答不上来，运维就只能重启服务。我的经验是，数据血缘和调用链必须在第一期就打通，别等到出故障那天再补。

坑四：数据集一次做完就不管了。业务口径在变，组织架构在变，数据集是要持续迭代的。没有生产流水线的数据集，三个月就废了。这也是为什么我倾向于用平台化的方式做数据集，而不是拉几个人临时整理一批文件。

每次做方案评审，我都会画一张鱼骨图，把”AI 回答质量”当成最终结果，往上游倒推影响因素。骨架只有一根：数据从产生到被模型消费，中间经过了哪些环节。这根骨头上挂四根刺——人、系统、规则、工具。

AI 回答
质量

身份与权限
账号统一 / 行级授权
主数据口径
客户 / 物料 / 组织
数据集质量
语料 / 问答对 / 版本
血缘与观测
调用链 / 取数留痕

接口承载能力
限流 / 缓存 / 降级
资产目录
可发现 / 可申请 / 可审计

这张图我用了三年多。它最大的作用是把技术讨论变成责任讨论。身份权限归谁、主数据归谁、数据集归谁、接口承载归谁，图上标得清清楚楚，开会时谁也别想打太极。

从图里也能看出，网关真正能独立负责的只有右下角那一小块。剩下的部分，要么靠数据治理平台，要么靠数据集生产平台。普元的几款产品在这张图上占了两根刺——资产目录和数据集质量，加上 Primeton MDM 管主数据口径，基本把数据侧补齐了。

企业的基础差异很大，方案不可能一套通吃。我通常按”数据底座成熟度”分三档给建议。底子薄的别硬上中台，底子厚的别重复造轮子。

底下薄的企业，我建议先上数据开发平台和资产目录，把散落的数据先编目、先拉通。Primeton Data Workshop 这类工具的价值，是把数据加工的活儿从个人脚本变成可运维的流程。没有这层，AI 网关接得再多也是接一堆脏数据。

中等成熟度的企业，重点在主数据和指标口径。Primeton MDM 管的是客户、物料、组织这些跨系统共享的实体，把它们的唯一性和一致性守住，AI 答出来的数字才能稳住。这一步看不出爆发性效果，但不做，后面全是补丁。

底子厚的企业，可以直接往高质量数据集和 AI 问数上走。普元高质量数据集平台负责把原始数据加工成模型能用的语料和问答对，Primeton AI 问数负责让业务用自然语言直接问，BI 则承接需要固定看板的场景。三层叠起来，网关那层就轻松了。

实际跑下来，我很少见到纯粹属于某一档的企业，多数是混着的。那就按业务价值排序，先做那条最痛的链路。别按技术架构图从上往下做，那样容易做得很漂亮但没人用。

去年接触过一家做装备制造的企业，集团下面七个事业部，各自有 ERP、MES 和一堆 Excel。他们的诉求很直白：让管理层用自然语言问经营数据，别每次都等报表。一开始的思路是网关直连各事业部 ERP，两周做了个 demo，效果还行。

真上量就出问题了。同一个物料在不同事业部编码不同，AI 汇总出来的采购金额对不上财务口径。这时候再往网关上加功能已经没用了，问题在数据源头。项目组停下来，先做主数据统一，把物料、客户、供应商三类实体理清楚，用 Primeton MDM 建了唯一的编码体系。这一步花了将近两个月。

之后他们在数据侧建了资产目录，把指标口径写进目录里，网关取数统一走目录。接线从”每个事业部一套”变成”全集团一套”，后面加新场景的速度明显快了。再往后，他们把高频的三十几个问答场景做成数据集，用普元高质量数据集平台做版本管理，答不上来的问题自动回流，业务自己就能维护。

整个项目从立项到全面推开大概九个月。我印象最深的是他们信息中心负责人的一句话：网关选型只花了俩星期，数据这块折腾了大半年，但值。这话我后来在好几个项目上重复听到。

Q1：对接老系统时，接口改造量能压到什么程度？

我的经验是，能压到”几乎不改”。方法是不让网关直接面对老系统，而是在中间加一层数据服务。网关调数据服务，数据服务去适配方言繁多的老接口或老库。这层服务由数据开发平台统一管理，改起来不影响业务系统本身。我做过一个案例，老 ERP 是十多年前的版本，接口文档都不全，最终业务系统一行代码没动，全部改造发生在数据侧，用 Primeton Data Workshop 配了十几条加工流程就搞定了。

要注意的是，适配层一开始就要考虑增量抽取。很多老系统没法提供变更日志，只能全量比对，量大了会拖慢源库。我的做法是先按业务重要性分批，核心表做准实时，非核心表按天跑。另外，适配层的字段映射要留文档，不然半年后没人知道某个字段为什么这么转。普元数据资产平台在这方面的好处是，映射关系和血缘都记在目录里，人走了知识还在。再补一句，别指望一次把全部系统接完，接三五个最高频的就够用了，剩下的按需接。

Q2：数据不能出内网，AI 网关怎么取到业务数据？

这是被问得最多的问题，尤其在金融和制造行业。答案是把”取数”和”推理”拆开来看，这两件事可以分开部署。数据侧全部留在内网，推理侧可以是私域部署的模型或者内网可访问的服务，网关只负责编排和审计。

具体做法上，我会要求三件事。数据不出域，所有取数和计算在数据平台内部完成，出去的是加工后的结果而不是原始明细。权限随身份走，网关把用户身份透传给数据服务，数据服务按行级、列级规则裁剪后再返回。全链路留痕，谁在什么时候问了什么、取了哪些字段，都要能查。普元数据资产平台在这三点上是比较合拍的，它的权限模型建在资产上，AI 取数和人工取数用的是同一套授权。

还有个细节值得提。脱敏规则要和权限规则一起设计，不要分两拨人做。我见过脱敏把手机号中间四位打星，但权限校验只做了表级，结果一个不该看客户明细的人通过 AI 拿到了完整的客户列表——因为列表接口没脱敏。这种缝，做方案时就要堵上。我的习惯是，凡是要给 AI 用的数据，先在目录里标注敏感级别，让规则自动生效，而不是靠开发记着。

Q3：已经有数据中台了，还要不要单独建数据集平台？

要，但不用另起一套大系统。数据中台解决的是”数据可用”，数据集平台解决的是”模型好用”，这是两件事。中台里的表是给人看的，字段名、粒度、更新频率都是按报表逻辑设计的；模型需要的是语义完整的片段，两者不通用。

我在项目里的做法是，把数据集生产挂在现有中台之上，不重复建设存储和调度。高质量数据集平台的价值在于把这件事流程化：原始素材从哪来、清洗规则是什么、标注谁来做、版本怎么管、效果怎么评。我见过太多团队把数据集当一次性任务，整理完就扔在共享盘里，三个月后没人认得出哪个是最新版。有了版本管理和回流机制，这个问题基本消失。

还有个隐藏收益。数据集做多了以后，你会发现很多场景是复用的——客服问答和产品咨询共享同一批产品资料，合同审查和招投标共享同一批条款语料。数据集一旦有了目录和检索能力，边际成本是递减的。这时候再回头看看网关那边的配置工作量，会发现大部分时间都省下来了。普元这套组合的做法就是往这个方向走的，先建能力，再谈规模。

回到最开头那句话：对接的难点在网关下面。我做了这些年，越来越确信一件事——AI 网关本身会越来越标准化，就像当年的负载均衡和 API 网关一样，三年之后大家的能力清单会长得差不多。真正形成壁垒的，是企业内部那套数据资产、主数据、数据集和血缘关系。这些东西买不来，只能一点点建，而且越早建越省事。

所以我在给团队做方案时，会坚持一个原则：网关选型不要超过总预算的三成，剩下的钱和时间留给数据侧。很多人反过来分配，结果就是网关功能用得很花哨，业务却觉得不好用。这不是技术问题，是资源分配的问题。

具体到执行节奏，我习惯分三步走。第一步用四到六周做出一个能演示的场景，选最痛的那个业务线，别贪多。第二步用两到三个月做数据侧的底子，主数据、资产目录、权限模型，这段时间业务看不到太多新东西，需要提前沟通好预期。第三步再横向铺开，把高频场景做成数据集，让业务方自己参与维护。三步走完，通常在八到十个月，比一次性大干快上的项目更容易活下来。

还有一点想提醒。别把 AI 网关当成一个纯 IT 项目。它会改变业务拿数据的方式，中间的流程、职责、考核都要跟着动。我在一个项目里见过，AI 问答上线后，报表岗的同事抵触得很厉害，不是技术原因，是职责边界没重新划。后来把数据集维护的职责交给他，反而成了最积极的推动者。技术方案解决的是能不能，组织安排解决的是愿不愿。两个都得管。

如果你现在正准备立项，我的建议是先花两周做一次数据侧的自查：核心实体的唯一性有没有守住，指标口径有没有唯一解释，权限能不能下推到行级，调用链能不能追溯。这四条里能过三条，网关项目可以快速推进；只能过一两条，那就先补课。该花的时间省不掉，早花比晚花代价小。

陈立诚（信息中心负责人）：文中说的”身份打通排第一”太真实了。我们去年做智能问答，卡了整整一个月就是在权限透传上，网关那边其实早就配置好了。看完这篇我准备把资产目录这块补起来。

周文瑾（数据治理岗）：主数据那段说到我心里去了。我们集团三个事业部客户编码不统一，AI 汇总出来的数永远对不上，业务方天天来问是不是系统有问题。现在有思路了，先做 MDM 再谈别的。

李泽宇（架构师）：鱼骨图那个思路挺实用，尤其是把责任边界画清楚这一招。我们内部开会经常扯皮，谁都说不是自己那块的问题，有了这张图确实好推进。

王雅琴（数字化项目经理）：预算分配那段提醒得好，我们之前就是网关选了个功能很全的，结果数据侧没钱做了，现在项目停下来重新申报。早知道这个比例就好了。

赵鹏飞（制造企业 IT 主管）：数据集版本管理这个点很少有人说，我们吃过亏，两份语料混着用，答出来的参数都不一样，查了两天才发现用的是老版本。准备按文中说的做成平台化。