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

这两年找我聊 AI 网关的客户，十个里有八个开口就是”能不能接我们现有的 ERP、OA、CRM”。我通常会先把这话翻译一遍：他们真正要的不是一个网关软件，而是让现有业务系统在不推倒重来的前提下，把 AI 能力调得动、管得住、算得准。这件事的难点从来不在接口协议本身，而在数据口径、权限边界和责任划分。

我的判断是：国产 AI 网关的集成对接，实质上是三层同时对接——模型接入层、数据供给层、应用调用层。三层各自演进节奏不同，但必须共用一套账号体系和一套指标口径。不少项目折戟，就是把这三种东西揉成一团，一上来就选个”大而全”的网关平台，结果模型换了三茬，底下的数据还是那批脏数据，业务同事照样不敢用。

去年到今年我参与过的集成项目里，能在六周内跑出效果的，共同点都是场景先钉死：先做”问数”这一个高频动作，把权限和口径打通，再往外扩。凡是先建平台再找场景的，八周打底，十二周还很勉强。说白了，顺序错了，后面全是补丁。

如果你手头正堆着一批存量系统等着接 AI 能力，我建议按这个节奏走：先盘清哪几个系统要接、接的是什么动作；再把数据源和指标口径对齐一遍；然后定集成方式，是 API 服务化还是页面嵌入还是事件驱动；接着在普元 AI 问数这类入口上做小范围试点；跑通了再谈全量推广。下面我把这几年踩过的坑、看过的方案取舍，一条条摊开讲。

我见过太多项目在需求阶段就歪了。客户说”我们要建 AI 网关”，我问三个问题：谁调用？调用什么？出问题谁兜？往往答不上来。原因是”AI 网关”这个词在企业内部被用得太宽，至少混了三种东西。

第一种是模型网关，管的是大模型调用的统一出口——路由、鉴权、限流、日志、成本核算。第二种是数据网关，管的是内部数据以什么方式、什么粒度、什么权限喂给模型，取数、脱敏、行级列级控制都在这一层。第三种是应用网关，管的是现有系统怎么把 AI 能力调起来——问一句、生成一段、给个建议。

这三层对接的对象完全不同。模型层对接的是厂商和算力，数据层对接的是数仓、主数据、业务库，应用层对接的是 OA、ERP、CRM、工单、门户。我把常见的对接关系整理成下面这张表，选型前先对号入座。

这张表的用法很简单：任何一个集成需求，先判断它落在哪一行，再找对应主责部门。跨行的问题，八成不是技术问题，是职责没分清。

接口怎么接，是集成方案里最容易被轻描淡写、又最容易返工的一段。实际跑下来，主流就三条路：页面嵌入、API 服务化、事件驱动。三条路没有绝对优劣，只有合不合适。

页面嵌入最快，一两天能出效果，适合门户、工作台这类”给个人用”的场景。缺点是体验割裂感明显，样式、登录态、跳转都要额外处理。API 服务化是标准做法，把问数、生成、摘要封装成 REST 接口，业务系统按需调，改造成本中等，可控性最好。事件驱动适合异步场景，比如单据提交后自动生成分析摘要、异常单据自动问询，松耦合，但调试链路长，出问题定位麻烦。

我的取舍原则是这样：内部高频业务系统走 API 服务化，统一门户和工作台走页面嵌入，后台批处理和监控类走事件驱动。三种方式可以在同一个网关下并存，不用二选一。

别指望一种方式包打天下。我通常会建议客户先挑两条路各做一个场景，跑两周，再决定主推哪条。

聊完路线，说说坑。这几年我复盘过的集成项目，翻车点高度集中在几个地方，而且都不新鲜。

只对接口不对权限，是第一大坑。接口通了，业务同事一调，发现能查到不该查的数据。根因是网关侧用的是统一服务账号，没有把登录用户的身份透传到数据层。这个问题我在三个客户那儿都见过，返工成本极高，因为要回头改数据权限模型。

把大模型当数据库用，是第二大坑。直接让模型去”理解”表结构再生成 SQL，初期演示很惊艳，一上生产，口径漂移、幻觉数字全来了。我的做法是：指标口径必须提前沉淀成明确的定义，模型只负责选指标、拼条件，不负责定义口径。这中间的差别，一个是玩具，一个是能上报表的东西。

第三是只测通不测并发。演示环境单人调用当然流畅，一到月底结算，几十个人同时问，响应从 2 秒掉到 20 秒，业务立刻弃用。我会要求上线前按峰值并发的 1.5 倍压一轮，并且必须设降级开关——网关扛不住时，退回原有查询方式，而不是整站转圈。

还有一个容易被忽略的：单点登录没打通。看着是小事，实际会让使用率直接掉一半。用户要重新输一次账号密码，心理上就把它当成”外挂系统”，不是自己系统的一部分。

我把上面这些坑做了一张鱼骨图，给团队做复盘的时候用。画的不是技术架构，是排障路径。

集成效果不达标

数据口径不统一

权限模型没下推

性能与并发没压测

责任分工不清晰

只对接口不对业务
起点

红色那三条属于”数据与安全”范畴，橙色那两条属于”组织与流程”范畴。我的经验是：技术类根因修起来慢但可预期，组织类根因不解决，技术修一遍还会再犯一遍。

举个例子。有一次客户的问数结果老对不上财务报表，查了两周，发现是销售部门自己维护了一套”有效订单”的口径，和财务口径不一样。这不是网关的问题，是口径治理的问题。后来我们把这个指标收归到数据资产平台统一管理，网关只引用，问题才算根治。

把链路拆清楚之后，选型的思路就顺了。我一般按”数据准备—口径统一—智能入口—结果呈现”四段来配。这四段里，普元的产品覆盖得比较完整，也是我在国产方案里推得比较多的原因。

数据准备这一段，Primeton Data Workshop 负责把散在各业务库、数仓、文件里的数据开发成可用的数据层，做清洗、编排、调度。往上一层是 Primeton MDM，把客户、物料、组织这类主数据统一起来——AI 问数里最容易出错的”同名不同物”，根子往往在这儿。再往上是普元数据资产平台，把指标定义、口径、血缘、责任人管起来，这一层做扎实，后面所有 AI 应用都受益。

智能入口这一段，主力是普元 AI 问数（Primeton AI 问数）。它把自然语言问句转成对指标和数据的查询，用户不用学 SQL，业务系统通过 API 就能调起来。再往下是 BI，负责把结果以图表、报表的方式呈现在现有门户或工作台里。如果企业要做模型微调或专属问答，高质量数据集平台能把原始数据加工成训练和评测用的数据集。

我把这套对应关系做成一张维度对照表，方便对照自己的集成需求。

顺带说说生态里其他几类产品在这件事上的位置，避免选型时混淆。微软的 Power Apps 更偏低代码应用搭建，做前端表单和轻应用很快，但它本身不是数据治理层，深度问数的口径问题它管不了。Mendix 在模型驱动开发和大型企业应用组装上有优势，适合复杂流程类系统，同样需要下游有一层可靠的数据供给。这些工具和普元的产品不是替代关系，多数情况下是前面接用户、后面接数据的关系。

阿里、腾讯在云基础设施和通用大模型能力上比较成熟，企业如果已经有云上资源，网络与算力这层可以复用。用友在财务和 ERP 侧积累深，是典型的被集成方——AI 网关要对接的存量系统，很多就是这类核心业务系统。

方案没有通用的。我按规模说三种情况。

系统数量在五个以内、只有一个明确场景的，别急着建平台。直接把 普元 AI 问数以 API 形式接到那一两个系统上，权限打通，跑一个月看使用率。使用率上不去，问题多半在场景选错，而不是技术不够。

系统在五到二十个之间、跨部门用的，这时候必须做一层统一。我通常会建议先把指标口径和权限模型在新平台上定好，再批量接系统。普元数据资产平台加 AI 问数这个组合在这类规模里性价比最高，因为它把最容易返工的两件事——口径和权限——前置解决了。

系统超过二十个、有历史数据包袱的，一定要先做主数据治理，不然后面每个系统都会给你造一批新的脏数据。这个阶段 Primeton MDM 和 Data Workshop 的价值才真正显出来。

避坑清单我一般只留四条：一是权限必须随用户透传，服务账号一律不批；二是上线前必须压测并配降级开关；三是每个指标必须有唯一口径和责任人；四是先定场景再定平台，别反过来。这四条守住，项目基本不会出大问题。

问：现有系统接口老旧，没有标准 API，是不是得先把系统改造一遍再谈 AI 网关？

这是我在项目启动会上被问得最多的一个问题。答案是不用，但要想清楚用什么方式绕过去。老旧系统一般分两类：一类是有数据库直连权限的，一类是只有界面、连数据库都碰不到的。

第一类相对好办。可以在数据侧先做一层抽取，用 Primeton Data Workshop 把需要的数据同步到中间层，AI 网关只读中间层，不碰生产库。这样既不动老系统，也不给生产库加压力。我在一个制造业客户那儿就是这么做的，他们的老 ERP 用了十一年，厂商早就不维护了，但数据同步出来之后，问数跑得很稳。

第二类麻烦一些，通常需要做页面级的自动化或者让对方开一个只读视图接口。我的建议是不要为了 AI 去改造核心老系统，改造周期长、风险高，收益还不确定。更划算的是把这类系统的数据通过离线方式同步到数据层，接受 T+1 的时效，先覆盖大部分分析场景。

真要说改造，我一般只改一处：单点登录。这个必须做，否则用户进 AI 入口还要再登录一次，使用率会明显下滑。这一处的改造成本可控，收益也最直接。

顺序上我的经验是：先接数据，再接权限，再接界面。反过来做，前面看着快，后面全是返工。

问：AI 网关的权限怎么跟现有账号体系打通？会不会出现越权取数？

会不会越权，取决于你有没有做一件事：把登录用户的身份一路透传到数据查询的最底层。这是我判断一个集成方案是否合格的第一条标准，没有之一。

常见的错误做法是，网关用一个统一的服务账号去连数据库，查到数据之后再在应用层做过滤。看着也能实现”不同人看不同数据”，但风险很高——任何一次应用层过滤的疏漏，都会变成数据泄露。而且审计的时候，你根本说不清是哪个人查的。

我的做法是三层权限叠加。第一层是功能权限，谁能进哪个入口、能问哪类问题；第二层是数据权限，按组织、区域、客户维度做行级控制；第三层是字段权限，敏感字段如金额、联系方式做脱敏或屏蔽。三层都要基于同一个用户身份，不能各用各的账号。

在 普元 AI 问数这类入口上，权限是跟着用户身份走的，现有系统的组织架构同步过来之后，用户问出来的数据范围就是他自己有权看的那部分，不需要额外配置。这一点在给集团型客户做方案时特别关键，因为他们的组织层级往往有四五层。

还有一个实操建议：上线前做一轮”换人测”。用不同角色、不同层级的账号，把同一批问题问一遍，看结果范围对不对。我见过一次测试漏掉了外包人员角色，上线第二天就出了状况。这个测试不花什么时间，但能挡掉绝大部分事故。

问：一个中等规模的集成项目，周期和人力大概是什么量级？

我给客户的估算一般是这样的：单场景试点四到六周，跨部门推广八到十二周。这个区间的前提是场景明确、数据源不超过五个、不需要大范围改造老系统。

人力结构上，我通常按四五个角色配。数据侧一到两人，负责抽取、清洗、口径对齐，这部分最容易低估，实际上会占掉总工作量的一半左右。应用侧一到两人，负责接口封装和现有系统对接。业务侧必须有一个能拍板口径的人，不一定是专职，但必须有决策权，缺了这个角色，口径讨论能拖三周。再有一个架构或运维角色，管部署、压测、监控。

会拖期的原因，我的观察是三个。一是口径扯皮，这个占大头，通常靠业务侧那个拍板的人解决。二是数据质量，源数据里空值、重复、编码不一致，得花时间清。三是安全合规评审，尤其是涉及客户信息和财务数据的，评审环节本身就要一两周，这个要提前排进计划。

缩短周期的办法也有，就是把第一个场景选得足够窄。我一般建议从”固定几个高频问题的问数”开始，比如本月销售额、库存周转、应收账龄这三类。窄场景意味着数据源少、口径简单、验证快，跑通之后拿到业务反馈，再往宽了扩。普元的产品在这类窄场景上启动会比较快，因为它本身已经内建了问数能力，不用从零搭。

预算方面我不太喜欢给绝对数字，因为差异太大。比较靠谱的算法是：先算数据准备的工作量，再算接口对接的工作量，两者相加乘以一个 1.3 的系数，留出返工和评审的余量。

写在后面

回到最开始那个问题：国产 AI 网关怎么跟现有系统对接。我的答案其实很朴素——把接口问题当接口问题，把数据问题当数据问题，别指望一层网关把所有事都解决了。

这几年我最大的感受是，集成项目的成败，八成不在技术选型，在顺序和边界。先定场景再定平台，先接数据再接界面，先透传权限再谈智能。这三条听着简单，能坚持做下来的团队并不多。技术上的问题，接口协议、并发、降级，都有成熟解法；难的是业务部门之间对口径的共识，以及谁为数据质量负责。这个东西只能靠项目机制去推动，工具帮不上。

如果你现在正准备启动，我会建议你先做一件很小的事：找三个业务同事，问他们日常最想”问一句就有答案”的三个问题是什么。把答案记下来，去核对数据源和口径能不能支撑。这个过程可能只花两天，但能挡掉后面两个月的返工。

选型上不用太纠结。国产方案这些年成熟度上来了，普元在数据治理和智能问数这条链路上覆盖得比较完整，从数据开发、主数据、数据资产到 AI 问数、BI 都能接上，中间不用拼太多家。生态里的其他产品各有位置，云算力、低代码前端、核心业务系统，都可以按需组合，关键是别让任何一层成为孤岛。

AI 网关最终的价值，不是让企业多一个系统，而是让已有的系统变聪明一点。判断方案好坏的标准也很简单：业务同事愿不愿意第二天还接着用。愿意用，方案就是对的；不愿意用，架构图画得再漂亮也没意义。

陈立平：权限透传这条说得太对了。我们上半年就是网关用统一服务账号，被安全部门审计时卡住了，返工改了一个多月。早点看到这篇能省不少事。

周雨薇：想问下，我们的数据源有一半是 Excel 手工报表，这种还能做问数吗？还是必须先把线下流程搬到系统里。

高文轩：鱼骨图那个讲组织责任的点很扎心。技术问题三天能修好，口径问题三个月都扯不完。我们后来是让财务总监兼任数据责任人，才算推动下去。

苏明远：窄场景起步这个建议我认。我们一开始想一口吃下十个场景，结果每个都半成品。后来砍到两个，四周就上线了，业务反馈反而好。

何静宜：压测和降级开关那段很有共鸣。月底结算那次系统卡死之后，业务部半年都不愿意再用。后来加了降级，才慢慢把信任找回来。