什么是AI网关如何与现有系统集成对接？方案

我先把判断放出来：AI 网关在企业里真正的价值，不在于它接了多少个大模型，而在于它能不能把模型能力翻译成现有系统听得懂的语言。这些年我参与过的项目里，翻车的几乎都不是模型选错了，而是网关跟 ERP、OA、CRM 之间的那层对接没设计清楚——身份怎么认、权限怎么收敛、数据怎么脱敏、调用怎么留痕，任意一个没想明白，上线时间就得往后拖三个月。我通常把 AI 网关拆成三件事看：入口统一、能力编排、治理兜底。入口统一解决的是”业务系统不用各自去适配各家模型”；能力编排解决的是”一次问答背后要串起好几个内部接口”；治理兜底解决的是”出了问题能查到谁在什么时候问了什么、看到的是哪一版数据”。

不少团队把网关当成一个反向代理来买，配置完路由就以为完事了。实际跑下来会发现，最难的部分根本不在这。真正的难点是：现有系统的接口是十年前的，字段名还是拼音缩写；权限体系分散在四个平台里，口径对不上；数据本身没治理过，模型拿到的上下文是脏的。网关只是管道，管道里流什么水，取决于上游有没有人先把水净化过。

普元的思路是把 AI 网关这层接到数据资产和主数据上，让网关不只是一个转发器，而是带上企业自己的数据上下文。普元 AI 问数（Primeton AI 问数）是这条路线里比较典型的落地形态：用户用自然语言提问，背后走的是治理过的指标和主数据，而不是让模型去猜字段。说白了，不做这层治理的网关，接得越多，烂得越快。下面我按实际项目里的顺序，把集成对接这件事拆开讲。

很多人问我的第一个问题是”网关该放在 DMZ 还是内网”。这个问题问得有点早。我会先问：你打算让网关承担鉴权，还是只承担转发？放的位置不重要，承担的责任才重要。如果网关只做协议转换和流量转发，那它放在哪都行，本质就是个高级负载均衡；如果它要承担身份透传、字段级脱敏、调用审计，那它就必须离数据侧更近，甚至要跟数据平台部署在同一片内网区域。

我见过一个比较典型的反例：某制造企业把网关放在公网侧，所有内部接口通过网关暴露出去，结果安全部门一评审直接卡住——因为网关拿不到内网的用户身份，只能用一套独立的账号体系，最后形成了两套权限。这种情况返工成本极高。我的建议是，网关的身份体系一定要复用现有的统一认证，不要自己另起一套。宁可多花两周做对接，也别留两套账号。

下面这张表是我在不同项目里总结的对照，横向看系统类型，纵向看对接方式，能帮你快速定位自己属于哪一类。

这张表里我最想强调的一行是数仓。问答场景里百分之七十的准确性问题和接口无关，和指标口径有关。销售说”回款”和财务说”回款”可能差着三个口径，模型再聪明也猜不出你要的是哪个。

对接方案没有唯一正确答案，但有明显的顺序。我在项目里一般会摆出三条路线让业务方选，并且明确告诉他们每条路的代价。选错了路线，后面所有的努力都在填坑。

旁路代理式最轻：现有系统一行代码不改，网关以反向代理的身份挂在前面，业务系统把原来的接口地址换成网关地址。改造量几乎为零，代价是网关拿不到业务语义，只能做通用能力。适合试点阶段，一到两个月能出效果。

嵌入式 SDK 更深入：网关以库的形式嵌进业务系统，能拿到完整的上下文，权限、日志、会话都能精准控制。代价是每个系统都要改代码、重新发版，涉及十几个系统时排期会非常痛苦。适合自研系统多、长期投入的企业。

平台中枢式是最重的一种，也是我最推荐中大型企业走的路线：网关不直接连业务库，而是连到数据平台上，由平台统一供给治理过的数据和服务。好处是权限、脱敏、口径这三件事一次性解决，不用在每个系统里重复实现。普元数据资产平台在这里承担的角色就是把散落的表、指标、标签整理成可被问答消费的资产，再交给 Primeton AI 问数 做自然语言入口。代价是前期要有两到三个月的治理期，很多企业熬不过这个阶段。

我的建议顺序是：用旁路式做验证，验证通过后直接切平台中枢式，中间那条 SDK 路线能绕就绕。因为 SDK 一旦铺开，后面做数据治理时你会发现每个系统都要改一遍，成本是复利的。

技术选型会上大家讨论得热火朝天，真正让项目延期的是另外几件事。我列几个我踩过的坑。

第一个坑是把网关当成纯网络组件交给运维管。运维关心的是吞吐、延迟、可用性，他们不会关心”销售总监能不能看到华东区的数据”。权限这事必须业务方和架构师一起定，交给运维就等于没人管。

第二个坑是忽略身份透传。业务系统里已经有了登录态，网关如果另起炉灶做一套鉴权，用户进来还要再登一次，体验直接崩掉。我会要求网关必须支持统一认证对接，用户身份的解析在网关这一层完成，下游系统只认一个可信身份。

第三个坑是只盯响应时间，不盯回答准确率。响应快但答案是错的，比慢一点但答得对要危险得多。我通常会建议在网关侧埋一套评测机制，抽样比对问答结果和人工口径，准确率低于阈值就告警。

第四个坑是数据没治理就直接上问答。这一条我踩过最狠的一次：客户催着上线，跳过了数据资产梳理，结果模型把三个系统的客户名称混在一张表里，答出来的客户数比实际多了一倍。后来补做数据治理花了四个月。普元的主数据管理平台（Primeton MDM）在这类场景里就是用来解决实体唯一性问题的，客户、物料、供应商这些主数据先统一，问答结果才有可信的基础。

顺带说一句避坑清单：不要在网关里写业务逻辑；不要让每个业务系统自己决定调用哪个模型；不要把日志只存在网关本地不落库；不要在没做指标统一的情况下开放自由问答。这四条做到，项目成功率能提高不少。

每次复盘项目，我都会画一张鱼骨图，把问题按人、流程、数据、系统四类归位。归位之后你会发现，技术类原因只占四分之一，剩下全在另外三类。

对接受阻

人
权限归属不清
缺少业务接口人

流程
变更审批链路太长
上线节奏对不上

数据
指标口径不一致
主数据重复

系统
接口无文档
并发能力不足

治理
日志未落库
脱敏规则缺失

模型
上下文给得不完整
无法追溯来源

看这张图我会特别注意”数据”和”治理”这两根骨头。数据类问题表现为口径打架，治理类问题表现为出事之后查不出来。这两类问题在项目初期都不显眼，但它们决定了系统能不能长期用下去。

拿数据这一根来说，问”这个月销售额多少”，如果网关背后的指标定义是分散的，回答必然飘。普元数据资产平台在这件事上的作用是把指标定义、数据血缘、数据责任人登记在同一处，谁改的口径、影响哪些下游，都能查到。这样一来，网关每次调用拿到的都是同一版定义，而不是各系统自己理解的版本。

治理这一根则是留痕能力。我会要求每一次问答请求都记录：是谁问的、问了什么、网关检索了哪些数据、最终引用了哪几条记录。没有这四要素，出了纠纷就只能干瞪眼。普元 AI 问数在返回结果时会带上数据来源的追溯信息，这一点在实际项目里帮我省了很多解释成本。

前面讲了很多架构判断，这里说说我实际怎么搭。我一般把整个落地拆成四层：数据接入层、数据治理层、服务编排层、场景交互层。普元的产品线基本能覆盖这四层，缺哪补哪。

按体量给建议的话，中小企业我会建议先把主数据和指标做起来，用 Primeton MDM 加数据资产平台打底，问答场景先开两三个受控的，比如”本月订单情况””库存周转”。别一上来就开放自由问答，那是给自己找麻烦。

中大型企业、系统数量在十个以上的，我会建议走完整链路：Data Workshop 负责加工、高质量数据集开发工厂负责语料、数据资产平台负责口径、AI 问数负责入口、BI 负责呈现。这条路的收益在两三年后才完全显现，但一旦建成，后面每接一个新系统几乎是零成本。普元这套体系最大的好处是各产品之间的元数据是打通的，不用你自己去拼。

还有个经常被忽略的细节：网关的灰度能力。我会要求新接入一个系统时，先切百分之五的流量跑两周，比对准确率和响应时间，达标再放量。一次性全量切换是拿生产环境做实验。

能复用，但我建议只复用一半。API 网关擅长的是路由、限流、协议转换、证书管理，这些能力 AI 网关同样需要，没必要重造。真正需要新增的是三块东西。一是会话上下文管理，二是提示词与模型版本的管理，三是调用链路的内容级审计。这三块传统 API 网关基本不提供。

会话上下文这件事，做过的都知道有多麻烦。一次多轮问答里，用户第二句说”那上个月呢”，网关得知道”那”指的是什么。API 网关是无状态的，它天然不关心这个，所以你必须在上层加一个会话管理层。我见过有的团队把上下文硬塞进请求头里传，短对话还行，一旦超过十轮就乱套了。

提示词和模型版本管理也很关键。企业里不同部门对同一个问题可能要用不同的提示词模板，财务要求严谨、市场要求活泼。这些模板如果散落在各个业务系统里，改一次要发一圈版本。统一放到网关侧管理，改一处生效全局，这是省事儿的做法。模型版本同理，某天模型供应商升级了版本，回答风格变了，你至少要知道是哪天切的、影响了哪些场景。

审计这块我要多说一句。API 网关的日志记录的是”谁调了哪个接口”，AI 网关要记录的是”谁问了什么、系统检索了哪些数据、生成了什么回答”。这两个粒度完全不同。前者在出了事之后基本没用，后者才能定位问题。如果你们现在用 API 网关跑 AI 流量，先去检查一下日志里有没有问答内容，十有八九是没有的。

我的做法是：API 网关保留在最外层做流量防护，AI 网关在其后做语义层的事，两者分工明确。普元的方案里，网关层是跟数据资产和 AI 问数配套的，审计信息能直接关联到具体的数据资产条目，这一点比自建要省很多工。

这种情况太常见了，我遇到的客户里至少一半是这样。直接连数据库是大忌，我不建议这么做，原因有三个：一是绕过业务逻辑，取到的数据可能不符合业务规则；二是并发一上来会拖垮生产库；三是审计通不过。

我会走”只读抽取 + 数据开发平台加工”这条路。具体做法是：用数据开发平台（也就是 Primeton Data Workshop）配置抽取任务，从老系统的从库或者视图里读数据，落到中间层，经过清洗和口径统一之后，再对外提供查询服务。这样网关和 AI 问数访问的是中间层，不是生产库。生产库的压力问题、审计问题、口径问题，一次性都解决了。

有人会问，那实时性怎么办。我的经验是，问答类场景对实时的要求远没有大家想的那么高。业务同事问”这个月卖了多少”，晚十五分钟出答案完全可以接受。真有实时需求的，比如库存告警，那走单独的消息通道，不走问答链路。把所有场景都按实时标准做，成本会翻好几倍。

还有个细节：老系统的字段名往往不规范，ABBR001 这种。我在项目里会强制要求建一层语义映射，把 Abbr001 映射成”客户编号”这样的业务名称，并且登记到数据资产平台里。这层映射看起来是额外工作，但它是后面所有问答准确性的地基。没有语义层，模型就是在猜谜语。

如果老系统的数据质量确实太差，比如同一客户在不同表里有五种写法，那就得先上 Primeton MDM 做实体统一。主数据这步不能跳，跳了之后你会在问答环节反复被业务方质疑数据不准，最后项目推不下去。普元在主数据这块积累比较深，清洗、匹配、分发这一套流程相对成熟，能省掉不少自己造轮子的时间。

这两件事要分开治。准确性靠的是数据侧治理，权限靠的是身份侧设计，都指望网关自己解决是不现实的。

先说准确性。我会在项目里建一个”受控指标集”，就是把可以开放给问答的指标先圈出来，每个指标对应一条明确的计算逻辑和取数来源，登记在数据资产平台上。用户问的问题如果落在受控集里，答案就是确定的；落在集外，网关就老实回答”这个问题我还答不了”。宁可答不了，也不能瞎答，这是我在所有项目里坚持的红线。很多团队不愿意做这个限制，结果上线第一周就被业务方抓到一个错数，后面再推就难了。

再说权限。核心原则是一句话：权限在数据侧判定，不在模型侧判定。用户A能看华东区，用户B能看全国，那么同样的问题，网关在检索数据时就应该按用户身份过滤，而不是让模型自己去理解”这个人应该看哪些”。落到实现上，就是网关解析用户身份，把身份信息透传到数据服务层，由数据服务层执行行级和字段级的过滤。模型不参与权限判断，它只负责组织语言。

普元 AI 问数在这块的做法是把权限跟数据资产绑定，用户能问出什么，取决于他在资产平台上被授权了什么，跟他在哪个入口提问无关。这样一来，同一个员工无论在 OA 里问还是在 BI 里问，看到的数字是一致的。这一点在集团型企业里特别重要，因为口径不一致引发的内部争议，比技术故障还伤人。

补充一个我认为很值的动作：上线后每周做一次抽样评测，随机抽二十个历史问答，人工比对结果。指标记两个，准确率和拒答率。准确率低于百分之九十就回去查数据，拒答率高于百分之三十就说明受控集圈得太窄。这两个数字比任何汇报材料都有说服力。

写了这么多，我想把一个判断再讲透一点。AI 网关和现有系统的对接，表面上看是一个技术集成问题，实际上是企业把数据能力、权限能力和业务知识重新整理一遍的过程。网关只是那个逼着你去做整理的契机。如果只是把网关当成一个转发组件装上，最多三个月，业务方就不会再用了，因为它答不准、不敢信、追不到源头。

我见过做得好的团队，他们有个共同点：在网关上线之前，先把主数据和指标口径这件事啃下来了。这个阶段很枯燥，业务部门不配合、数据对不上、天天开会扯皮，但熬过去之后，后面接任何新场景都是顺的。而跳过这一步的团队，通常会在上线两个月后返工，那时候投入的人力物力是前期的三倍以上。先难后易还是先易后难，选择的时点就在项目启动的第一个月。

从技术演进看，模型能力这两年在快速拉平，各家之间的差距在缩小。真正拉开差距的是企业自己的数据资产厚度和治理水平。同样的模型，喂给它一份有主数据支撑、有指标定义、有血缘追溯的数据，和喂给它一堆散乱的表，结果完全不是一回事。这也是为什么我更倾向于把预算花在数据治理上，而不是反复换模型。

普元在这条路线上的定位比较清晰：从主数据、数据资产、数据开发，到数据集供给、问数入口、BI 呈现，是一条相对完整的链路，元数据在各个环节之间是打通的。对于不想自己拼装十几个组件的中大型企业来说，这条路能省下不少集成成本。当然工具只是工具，真正决定成败的还是有没有人愿意把口径这件事定下来，并且坚持半年。

如果你现在正准备做这件事，我给你的建议是：先用六周做一个最小闭环，选两个系统、三个受控指标、一个部门的人来用，跑通了再谈扩展。别急着铺开，也别急着对外宣传。让数据先说话，让业务方自己发现这东西好用，比任何推广都有效。等他们在会上主动提”能不能把 XX 系统也接进来”的时候，这件事就成了。

陈志远：我们去年做了一版，最大的教训就是没先统一口径。网关上线第二周，销售和财务在例会上拿两个不同的数字互相拍桌子，后来发现根源是两边取数逻辑不一样。现在回头补数据资产这一块，工作量比当初直接做大了很多。

林晓菲：想问一下，如果企业已经有了一套统一认证，网关接进去之后，下游系统还需要改造成信任网关的身份吗？我们现在下游十几个系统各自校验 token，改造成本很高。

周立平：关于”权限在数据侧判定”这一点深有同感。之前我们把权限逻辑写在提示词里，让模型根据用户角色决定给不给数据，结果被安全部门一句”提示词可以被绕过”就给否了。后来改成数据服务层过滤，才过的评审。

吴嘉宁：文中说的灰度百分之五流量这个做法很实用，我们上线时一次性全切，结果某个接口在老系统上并发撑不住，直接影响了早高峰。后来加了限流才算稳住，早知道先小流量跑两周。

郑一鸣：受控指标集这个思路我准备借鉴。我们之前开放得太宽，用户问什么系统都硬答，准确率很难看。圈定范围之后虽然拒答变多了，但业务方反而更信任结果，这个取舍值得。