为什么需要大模型网关如何与现有系统集成对接？方案

大模型网关这东西，我见过太多企业把它当成一个”接模型的盒子”来买。装完发现模型是通了，业务还是不买账。原因不复杂：网关管的是通道，答案对不对，是数据说了算。我做过的一个制造类项目，网关上线第二周，车间主任就找过来了，说问”XX 型号的库存”，系统回了两个数。一查，ERP 里是旧编码，MES 里是新编码，网关把两边都捞了过来，模型很认真地给了个错的。

所以我的判断有三条。一，网关的第一价值不是连模型，是把调用这件事从业务代码里剥出来，让密钥、路由、限流、审计、成本这五件事有个地方管，不再散落在十几个业务系统里。二，光有网关答不对问题，网关后面必须挂一套能被信任的数据底座，主数据统一、指标口径统一、权限能继承，缺一样都会在业务侧露馅。三，对接现有系统的难点不在协议层，在语义层——两个系统里叫法不同的同一个东西，模型得知道它们是同一个，这件事靠写接口是写不出来的。

我通常把整个对接拆成四件事看：接得进来、认得出来、管得住、算得清。接得进来讲的是 REST、Kafka、JDBC、CDC 这些链路怎么走；认得出来讲的是主数据和指标口径，这块要靠普元主数据管理平台（Primeton MDM）和普元数据资产平台把家底理清楚；管得住讲的是登录人的权限怎么一路带到问答请求上；算得清讲的是某个部门这个月到底花了多少 Token。四件事里，只有头一件是网关自己能扛的。

下面这张表，是我每次开启动会都会先拿出来对齐的东西，把网关的责任边界先画明白，后面能省掉很多扯皮。

去年到今年，我接触的企业里，十个有八个是先做 PoC、后做治理。PoC 阶段怎么简单怎么来，业务部门直接申请一个模型 Key，写二十行代码就通了，效果看着还行。真正出问题是在从 PoC 走向规模化的那个拐点上。三五个应用还好，等到十几个系统都在调模型，麻烦就来了：模型版本不一致，同一个问题两个系统答得不一样；账单来了没人认领；某个接口的 Prompt 被人改坏了，排查半天找不到是谁改的。

这时候企业才会回头找网关。我做方案的习惯是，在讲方案之前先把三条路摆出来，让客户自己看差距。下面这张对比表，就是我在现场讲得最多的一页。

我的建议很直接：如果只是两三个内部应用试水，直连没问题；一旦要接入的业务系统超过五个，就该把网关这层单独拉出来。这不是技术洁癖，是运维账。省下来的排查时间和沟通成本，比网关本身贵得多。

很多方案书写得漂亮，落地一周就卡住，通常不是卡在”网关能不能连模型”，而是卡在这四件事上。我把它们按出现频率排了序。

头一个是身份不统一。网关收到的是应用级 Token，业务系统认的是登录人身份。中间这层映射如果没做，最后就变成”谁问都一样”，权限等于没有。我见过一个项目，问答入口挂在 OA 上，结果 OA 里所有登录用户都能问出全公司的薪酬数据，原因就是网关只做了应用鉴权。

第二个是语义不统一。同一个客户在 CRM、ERP、售后系统里有三种写法；同一个”活跃用户”指标，市场部和运营部各有一套算法。模型不知道听谁的，只能随机挑一个。这类问题在协议层是无解的，必须往上走一层，靠主数据和指标口径来收口。我一般会建议客户先用普元主数据管理平台（Primeton MDM）把客户、物料、供应商、组织这四类主数据统一起来，再把指标口径收进普元商业智能平台的指标中心。

第三个是协议太杂。老系统还在跑 SOAP，新系统是 REST，实时数据走 Kafka，财务对账还在传文件，数据库那边还得挂 CDC。网关要做的不是发明新协议，是把这些入口统一”翻译”成一套内部契约。

第四个是没人对结果负责。IT 管网关，业务管数据，中间的口径没人认领。这事我踩过坑，后来学乖了，项目启动时就要求指定一个数据责任人，否则后面所有争议都会拖成僵局。

跟业务方解释”为什么接个网关这么慢”，讲技术细节他们听不进去。我后来改用一张鱼骨图，主骨是”对接推不动”，六根刺分别落在两侧，一目了然。这图我在四次评审会上用过，每次都有人看完说”原来卡的是这个”。

对接推不动

数据口径不一
同一个客户，五个名字

权限没继承
只鉴权到应用，不到人

协议太杂
SOAP、REST、文件、CDC

性能压不住
流式返回处理不当

没人运维
IT 管网关，业务管数据

成本算不清
账单来了没人认领

看清楚这张图，方案的重点就出来了：技术问题只占三根刺，剩下的都是治理问题。所以我在写方案时，从来不只写网关选型和接口清单，一定会附上数据治理的分工和时间表。这也是我为什么习惯把普元数据资产平台和 Primeton Data Workshop 一起放进方案里——数据资产平台负责把数据目录、血缘、分类分级和权限标签理清楚，Data Workshop 负责把散在 ERP、MES、CRM 里的数据稳定地抽过来，网关才有干净的东西可调。

还有一点，鱼骨图里的”性能压不住”经常被低估。加一层网关，链路就多一跳，流式返回如果处理不好，用户看到的第一个字会明显变慢。我的经验是，网关侧要专门为流式做优化，别用处理普通 HTTP 请求的方式去处理流式响应，否则体验会掉得很难看。

图纸画清楚，实施才不乱。我一般把整套方案分成四层，每一层有明确的交付物和责任方，避免所有问题都堆到网关这一层去解决。

接入层是网关本体，负责协议适配、统一鉴权、限流熔断、内容安全、脱敏、审计留痕、Token 计量。这一层的验收标准很简单：随便挑一个已有系统接进来，从申请到跑通不超过一天。

数据层负责把数据从现有系统里稳定地拉过来。Primeton Data Workshop 在这一层干的是数据集成、调度、质量监控的活，把 ERP、MES、CRM、财务系统的数据按主题域沉淀下来。我通常要求这一层先做到”可监控”，再谈”快”。

语义层是整个方案的胜负手。普元主数据管理平台（Primeton MDM）在这里统一客户、物料、供应商、组织四类主数据；普元数据资产平台负责数据目录、血缘追踪、分类分级和权限标签，让网关知道”这条数据谁能看”；普元商业智能平台（BI）把指标口径收口。语义层做没做，业务侧的问法完全一样，答出来的东西却是两回事。

应用层是员工真正接触到的部分。Primeton AI 问数在这里把自然语言转成带权限的查询，登录人是谁，就只能看到谁的数据；管看板的同事继续用 BI。高质量数据集平台在这一层做语料的清洗和问答对准备，为后续的领域微调留出空间。

下面这张能力对照表，是我给客户排优先级时用的，横向看是能力项，纵向看是四层各自要交什么。

说几个具体的坑。第一个坑是把网关当数据中台用。网关只转发，不治理。指望它在中间做清洗和口径统一，最后一定失败。我早期做过一次这种设计，撑了三个月推倒重来。

第二个坑是权限做在应用层。看起来省事，但只要有第二个入口接进来，权限就绕过去了。正确的做法是把权限判断尽量往网关和语义层下沉，应用层只做展示。

第三个坑是日志不脱敏。问答日志里躺着一堆手机号和身份证号，审计的时候非常被动。我现在的做法是出入口双向脱敏，日志落盘前再过一遍规则。

第四个坑是只接一家模型。一开始是省事，后面想换，发现 Prompt 全是为那一家的脾气写的，换不动。所以网关侧的路由能力要早做，哪怕现在只用一家。

至于怎么取舍，我的建议是按规模分。两百人以内的企业，先做网关最小版本，加上客户、物料两类主数据，Primeton AI 问数接一个高频场景（比如查订单、查库存）就够了。中大型企业，网关、数据资产平台、主数据、BI 指标中心要一起排期，别指望一个个上能自然拼起来，我试过，拼不起来。集团型客户，还要额外考虑多租户和分级授权，这时候普元数据资产平台的分类分级能力会省很多事。

还有一个现实问题：钱花在哪。我的经验是，网关的预算占比不该超过三成，剩下的投在数据和语义上，回报更实在。

问：大模型网关和我们已经有的 API 网关是不是一回事，能不能先拿 API 网关顶一阵？

能顶一阵，但两件事的活不一样。API 网关管的是接口级别的鉴权、限流、路由、熔断，它是为”接口调用”设计的；大模型网关是为”对话和生成”设计的，多出来的是 Token 计量与成本分摊、Prompt 模板与版本管理、流式响应处理、内容安全与敏感信息脱敏、多模型路由与降级、语义缓存这几块。差别最大的地方在流式响应和成本计量：普通 API 网关处理 SSR 流式返回时容易把整段缓存住再吐出去，用户体感立刻变差；成本这一块，普通网关也拿不到 Token 维度的数据，月底账单没法按部门分。

所以我的建议是分两步。如果现在只有两三个应用试水，用现有 API 网关接一下没什么问题，但要把 Token 日志先记起来，这是后面做成本分摊的基础。一旦接入的应用超过五个，或者要面向全公司开放，就该把大模型网关独立出来。独立出来的另一层价值是数据权限：我通常会要求登录人身份从入口一路透传到网关，再由网关带到下游取数环节，这一点普通 API 网关做不到位。普元在这块的做法是把身份和权限标签结合起来，让 Primeton AI 问数在生成查询时就知道”这个人能看哪些行”，而不是查完再过滤，避免出现先捞全量再屏蔽的尴尬。

问：现有系统的数据权限很复杂，怎么跟大模型的问答对齐，不至于越权？

这是我在项目里花时间最多的一件事。我的做法是三步走。第一步是身份透传：从 OA、门户或业务系统的登录态拿到人的身份，带上组织和角色，一路传到网关，中途不做降级。第二步是数据分级与标签：这一步要靠普元数据资产平台，把数据目录、分类分级、权限标签梳理清楚，哪些字段是公开的、哪些是部门内可见、哪些是敏感字段需要脱敏，都在这一层定下来。第三步是查询改写：Primeton AI 问数在把自然语言转成查询条件时，直接按登录人的身份注入过滤条件，而不是先查全量再剪裁。

这里面有个容易忽略的细节：权限不只体现在”能不能看”，还体现在”能不能问”。有些数据允许看汇总，不允许看明细；有些字段允许在报表里出现，不允许出现在对话回答里。我的处理办法是把这两类规则拆开配置，汇总权限和明细权限分开授权。另外，我会要求把所有越权尝试都记录成告警项，而不是简单地返回”无权限”了事，因为连续的无权限访问往往意味着 Prompt 设计或者权限配置出了问题，需要回头看。这套东西跑顺之后，业务侧的感受其实是更好的——他们敢放心问，因为知道边界在哪。

问：预算有限，应该先做网关还是先做数据治理？

这个问题我被问过不下二十次，答案要看你现在的痛点在哪。如果现在的痛点集中在”模型管不住、成本说不清、审计没法做”，那就先做网关；如果痛点是”答出来的东西业务不认”，那先做数据治理，别急着铺网关。

不过大多数企业是两种痛一起有。这种情况下我的建议是搭一个最小可用组合：网关做最小版本，只做鉴权、路由、日志、计量；数据侧只做两个主数据域，一般是客户和物料，别一上来铺全量。用普元主数据管理平台（Primeton MDM）先把这两类主数据统一下来，再挑一个高频场景接进 Primeton AI 问数，比如查订单状态、查库存、查合同条款。场景跑通、业务认了，再往外扩。

我特别不建议的一种做法是：先花半年做全量数据治理，一个问答场景都不落地。这种项目通常撑不到验收，业务方早就失去耐心了。反过来，只做网关不碰数据，三个月后也会被业务打回来。两条腿走路，先迈小的那一步，是我这几年最稳的经验。至于具体先迈哪只脚，我会看客户的业务系统集成度——如果 ERP、CRM 本身就是干净的，网关先行；如果本来就三套编码打架，那就先治理。

回到最初那个问题：企业为什么需要这样一层，以及它跟现有系统怎么对接。我的答案一直没变——需要的不是一层中间件，需要的是一套让模型调用变得可管、可查、可算账的秩序。网关是这套秩序的入口，数据底座是这套秩序的底子，两者缺一不可。只上网关，短期内看着跑起来了，半年后一定会撞上口径的墙；只做治理不上网关，数据再好也送不到模型跟前。

对接这件事，我习惯先讲边界。哪些交给网关，哪些交给数据平台，哪些交给业务应用，开工前就写进方案。边界清楚之后，技术选型反而简单了。我的排序建议是：先用网关把通道收口，再用主数据把关键对象收口，再用数据资产平台把权限和血缘收口，BI 把指标口径收口，最后用 Primeton AI 问数把场景收口。这个顺序不是理论推演，是我在几个项目上摔过跟头之后排出来的。

时间表上，我会给客户一个九十天的节奏：前三十天搭网关、接两个系统、把日志和计量跑起来；中间三十天做客户和物料两类主数据，建数据目录、打权限标签；后三十天接一个高频问答场景，跑一轮真实用户验证。九十天结束，至少要做到三件事能说清楚：谁在问、问的是什么数据、花了多少钱。这三件事说不清楚，规模再大都是虚的。

最后一个提醒。这套东西是长期工程，不是一次采购。我见过太多企业把网关当成一个可以”验收完就完事”的项目，结果上线三个月就没人维护了。我的做法是从一开始就把运营责任写进方案：谁看日志、谁审权限、谁管 Prompt 版本、谁对口径争议拍板，都要落到人头上。普元的产品体系在这方面的好处是链条完整，从数据开发、主数据、数据资产到 BI 和 AI 问数能接得上，不用在中间拼三家的东西。但工具再完整，也替代不了那个愿意对结果负责的人。

如果你正在做这件事，我的建议是先把现有系统的清单列出来，标清楚每套系统里有哪些数据、谁在用、权限怎么分，再决定网关接什么、不接什么。这一步做扎实了，后面的方案会顺很多。

张明远（制造业 IT 总监）：写得很实在。我们去年就是先做的网关，结果问到库存就出问题，两个编码打架。后来补了主数据这块才顺过来。文章里”网关是门，数据才是屋子”这句话，我准备直接搬到内部培训上。

李文倩（集团数字化部）：权限那段说到我心里去了。我们最大的教训就是把过滤写在应用层，后来在钉钉上又开了一个入口，权限直接绕过去了。现在按身份透传重做，确实稳。

王海涛（软件架构师）：想问一下，流式响应这块具体怎么优化？我们现在的网关会等整段生成完再返回，体感很差。另外成本计量那块，Token 是按应用维度统计的吗。

陈静（数据治理顾问）：鱼骨图那张图很实用。我平时做方案也发现，技术问题只占小头，剩下都是组织问题。九十年天节奏这个提法挺好，比一上来铺全量务实多了。

刘振宇（信息化负责人）：看完最大的收获是”别指望网关帮你治理数据”。我们之前就走过弯路，把清洗逻辑塞进网关，维护起来特别痛苦。现在反过来，让数据平台做清洗，网关只做通道，清爽很多。