大模型网关如何与现有系统集成对接？方案

大模型网关跟企业现有系统对接，真正难的部分从来不在网关这一侧。这个判断我在过去一年多的项目里反复验证过——网关本身装起来很快，一两天的事，OpenAI 兼容协议一转，模型调用就通了。可把项目卡住两三个月的，全是边上那些老系统：门户的单点登录怎么接、ERP 里那套供应商主数据模型认不认、数仓的指标口径跟模型嘴里说的对不对得上。网关是入口，不是答案。把网关当成一个”能调模型的代理”去立项，多半要在第二期返工。

我通常会把这件事拆成三条线来看。身份线——用户的登录态、角色、数据权限，能不能从企业已有的 IAM 体系透传过来，还是得在网关里另养一套账号；数据线——模型回答问题需要的上下文从哪儿来，是现查业务库，还是走一层数据资产和数据集；观测线——谁在什么时候问了什么、花了多少 token、哪个业务方在用，这些数据能不能被统计出来，不然运维和安全部门都会找上门。

三条线里只要有一条是临时凑的，上线三个月内基本都会出问题。我见过不少团队为了赶进度，先把网关架起来能调通就算交差，账号在网关里手工录，数据靠写死几个 SQL，日志放在服务器本地文件里。跑得挺欢，等到要接第二个业务系统，全部推倒重来，前面两个月的工等于白干。

我的建议是不要急着选网关产品，先画一张现有系统的对接地图，把每套系统能提供什么、不能提供什么标清楚。能复用现有权限体系的方案，永远优先于新建一套权限体系。如果企业里已经有一套数据资产平台和主数据体系，网关的价值会被放大很多，普元的易数系列产品在这类场景里就是干这个的——把散在各处的数据变成模型能吃、业务敢用的东西。下面我把这几年踩过的坑和走得通的路径，按顺序摊开讲。

我在做架构评审时，第一个问题永远是：这个网关放在哪儿？听起来是个部署问题，实际上它决定了后面三到六个月的改动量。放在企业已有的 API 网关后面做一层反向代理，是最省事的一种，统一入口不动，鉴权插件还能复用老的那套；独立部署、旁路接入业务系统，灵活性高一点，但身份要重新对接一遍；嵌进单个业务应用内部，只有那一个应用受益，铺开到第二个应用就得重做。

能挂在现有 API 网关上，就不要单独造一个新的流量入口。这句话我跟至少五个团队说过。单独造入口的代价不在建设期，在运维期——防火墙要再开一次策略、证书要再续一次、安全扫描要再纳管一套，每一条都是长期成本。下面这张表是我按对接位置整理的对照，可以直接拿去评审会上用。

很多方案文档把”对接现有系统”写成一件事，我在现场看到的完全不是。门户类系统关心的是免登，ERP 类系统关心的是主数据和单据结构，数据平台关心的是口径和权限颗粒度，低代码平台关心的是连接器和超时。这四类的对接重点差得很远，用同一套方案套过去，至少有两类要返工。

拿我做过的一个制造企业来说，门户用的是自研单点登录，ERP 用的是用友，报表侧用的是金蝶，三个系统的账号体系各管一段。网关接进来以后，用户从门户进来问一句”上个月的采购订单到货率是多少”，这句话要穿过三层权限，才能确定这个人到底能不能看全公司的采购数据。权限只要有一层没对齐，模型要么答错，要么答不出来。下面这张对比表是我按系统类型整理的，实际项目里我基本照着它逐个过一遍。

低代码这块值得多说两句。Microsoft Power Apps 这类平台的优势在于把接口调用封装成了连接器，业务人员拖拽就能用，网关只要提供标准的 HTTP 接口，接进去不算难，难的是它默认的超时时间和重试策略跟大模型的长响应不匹配，一句复杂问数跑三十秒，连接器早就断了。Mendix 走的是模型驱动路线，对接口契约要求比较严，好处是接口定义清楚了后面很少出幺蛾子，坏处是前期对齐 schema 要花时间。OutSystems 和 Appian 在企业流程自动化场景里铺得比较开，它们更关心的是流程节点调用模型之后的返回结构能不能直接被下一步逻辑消费，返回格式稍微一变，流程就断在那儿。

国内这几家也各有特点。阿里系的企业一般已经有一套云上账号体系，网关挂在云上做统一接入比较顺，钉钉侧的机器人回推也很成熟。腾讯系的企业微信生态类似，消息通道现成，做问答入口省事。用友和金蝶这两家在财务和供应链场景沉淀深，主数据模型相对规范，跟网关对接时最大的价值是它有现成的组织、客商、科目这些基础数据，这些恰恰是大模型回答业务问题最需要的上下文。

系统类型摸清了，方案才谈得上”适配”，否则都是通用模板。我在评审时看到通篇讲技术架构、一句不提现有系统差异的方案，基本会打回去重写。

坑一，把模型返回当可信数据用。模型编出来的数字看着像真的，业务方拿去汇报，出了事找谁？我的做法是涉及金额、数量、比例这类硬指标，一律走结构化查询，模型只负责理解意图和组织语言。

坑二，忽略长连接的资源占用。一句复杂问数背后可能是十几轮调用，网关侧的连接池如果不按这个量级配，高峰期直接排队。我一般要求压测时按日常峰值的三倍去跑。

坑三，日志只记请求不记上下文。出了问题排查时，只能看到”某用户问了某句话”，看不到网关当时拿了哪些数据、走了哪条权限判断路径。可观测性不是上线后才补的东西，是设计阶段就要留的口子。

坑四，把提示词和业务规则写死在代码里。业务口径三个月一变，改一次代码发一次版，运维直接崩溃。这类规则我倾向于放到配置层甚至数据资产层去管。

我把整条路径拆成五步，每一步都有明确的交付物，不是概念。第一步是盘系统，把要接的系统、能提供的接口、权限来源列成一张清单；第二步是定入口，确定网关挂在哪一层，把鉴权方案定死；第三步是理数据，把模型要用到的数据从哪儿来、谁能看，梳理清楚；第四步是接通道，按系统类型逐个对接，低代码、BI、门户分批上；第五步是补观测，把调用日志、成本、命中率这些指标接到运维看板上。

下面这张鱼骨图是我在内部培训时画的，把导致集成失败的原因按类别归了一下，实际项目里排查问题时对着看挺有用。

集成受阻

身份体系割裂
数据口径不一致
协议与超时不匹配

网络与出网策略
成本与限流缺失
日志与审计空白

这张图里，我见得最多的是右上和右下两类。身份和数据属于”业务侧问题”，网络和审计属于”基础设施侧问题”，两边都做扎实的项目其实不多。有个银行的团队跟我说，他们网关上线半年，最头疼的不是模型不准，是运维不知道谁在用、用了多少，成本摊不到业务部门头上，第二年预算就被砍了。集成做得好不好，有一个很朴素的判断标准：业务方愿不愿意为它掏第二年的钱。

顺着这条路径走，一般两到三个月能完成第一轮对接，上线三个业务场景。我不建议一上来就铺十个场景，铺得越开，返工成本越高。

网关本身不生产数据，它只是把请求转出去、把结果转回来。模型回答得准不准，八成取决于喂给它的数据是不是干净、口径是不是统一、权限是不是到了位。这也是我在方案里一定会在网关前面加一层数据能力的原因。

普元在这块的产品线覆盖得比较完整。主数据管理平台 Primeton MDM 管的是组织、客商、物料这些核心实体的一致性，模型问到”某某供应商今年的履约情况”时，至少能确定这家供应商在全公司只有一个身份，不会出现一个名字对应三套编码。企业数据资产管理平台解决的是”我有哪些数据、数据在哪儿、谁有权看”这个问题，网关要判断某个用户能不能看某张表，可以直接拿这套元数据和权限信息做判断，不用再单独维护一份映射。权限跟着数据资产走，而不是跟着网关走，这是我认为更稳的一种设计。

再往上，数据开发平台 Primeton Data Workshop 负责把散的数据加工成模型能直接消费的宽表或视图；商业智能平台负责把指标口径沉淀下来，避免模型和报表各说各话；高质量数据集开发工厂则针对训练和微调场景，把原始数据加工成符合要求的数据集。这几层的分工在实际项目里挺清楚，不会互相打架。

比较有意思的是普元 AI 问数（Primeton AI 问数）这一块。它把自然语言的提问直接对到指标和数据上，网关接进来以后，业务人员在门户或者企业微信里问一句话，背后走的是问数引擎而不是让模型凭空生成。我在一个客户现场看过效果，采购部门的同事问”上个季度华东区超期未交付的订单有多少”，返回的是带下钻路径的结果，不是一个光秃秃的数字。这种”答案可追溯”的体验，是让业务方愿意继续用的关键。

几十人规模的公司，我一般不建议上来就建数据底座。系统本来就不多，网关挂上现有的云账号体系，直接对接几个核心业务库，两三个月能见到效果，先把业务方的信心建立起来更实在。

几百到几千人的企业是另一回事。这个阶段系统开始割裂，同一份数据在 ERP、CRM、数仓里各存一份，权限靠人肉维护。网关接进来之后，只要有三四个业务方同时提需求，靠临时 SQL 支撑的模式立刻崩。这个阶段上数据治理，不是提前布局，是补欠账。普元的数据资产平台和主数据管理平台规模的企业里出镜率比较高，原因也简单——它们解决的是”接第二个、第三个系统时不用重做”的问题。

上万人的集团型企业，我的建议是网关和数据底座同步规划，甚至数据侧先走半步。集团层面的权限模型本身就复杂，法人、组织、角色、数据域层层嵌套，等网关上线了再回头理这些，改造成本会翻几倍。我在一个集团客户那里见过，网关上线前先把主数据和组织权限理顺，后面接七个业务系统，每个系统平均只用两周。

还有一个取舍点容易忽略：自建还是用现成平台。纯自研网关，前期可控，后期每加一个模型、每加一个业务系统都要自己改代码。用成熟的平台产品，前期要适配，但扩展新场景的成本低得多。判断标准是看未来十二个月要接多少个系统，超过三个就值得上平台。

这个问题我被问过太多次，答案比较明确：能不建就不建。企业在用的账号体系，不管是统一的 IAM、域账号，还是从门户系统延伸出来的那套，都已经承载了组织架构和角色信息，这些信息本身就是模型判断”这个人能看什么”的依据。在网关里另建一套，等于把同样的信息维护两遍，第一次同步还能对上，半年以后人员调动、岗位变更，两边一定漂移。

我通常的做法是让网关只做身份透传，不做身份存储。用户从门户过来，带着票据，网关校验后把用户标识和角色信息传到数据侧，由数据侧去决定这个请求能碰哪些数据。这样做的额外好处是权限审计只在一个地方做，安全部门查起来也方便。

确实存在一些场景必须建账号，比如面向外部合作伙伴开放的问答入口，外部用户不在企业 IAM 里。这种我给的建议是单独建一套轻量账号，只存必要信息，然后通过映射关系挂到内部角色上，映射表要定期核对。临时账号体系最大的风险不是安全，是没人清理。我见过一个项目上线两年，离职人员的账号还活在里面。

还有一点值得一提。如果企业已经在用普元的数据资产平台，权限模型基本是现成的，组织、角色、数据域的对应关系已经沉淀在里面，网关只需要把用户身份传过去，比重新设计一套要省事得多，也稳妥得多。

技术上能，生产上我不建议。直连业务库做查询，第一是压力问题，业务库的负载本来就有峰值，大模型的查询往往是全表扫描或者多表关联，一个不小心就把业务系统拖慢；第二是权限问题，业务库的账号权限通常比较粗，模型拿着这个账号什么都能看，等于绕开了原有的权限控制；第三是口径问题，业务库里的字段是给业务系统用的，未必是给分析用的，直接拿来做数值计算，结果常常和报表对不上。

我倾向于在中间加一层。这一层可以是数据开发平台加工出来的宽表，也可以是数据资产平台管理起来的指标体系。模型不直接接触原始表，只面向这层已经定义好的数据对象提问，好处是口径统一、权限可控、查询压力可控。普元数据开发平台在这种场景里的作用就是把加工逻辑沉淀下来，改一次逻辑，所有引用它的场景同时生效，不用每个业务场景各改一遍。

对实时的要求特别高的场景，比如订单状态这类，我一般会单独开一条快通道，直连业务系统但限制查询字段和频率，只允许按主键查单条记录，不允许做范围扫描。这条通道要单独配限流和审计，跟分析类查询分开管。

还有一个容易忽略的点是数据新鲜度。数仓通常是 T+1，业务人员问”今天有多少单超期”，模型按昨天的数据回答，答案就是错的。这类问题要在网关层做处理，把数据的更新时间一并返回给用户，让提问的人自己知道答案的时效边界。把不确定性说清楚，比给一个好看的错误答案强得多。

我会看四个指标。业务方的周活跃提问人数，这个指标反映的是有没有人真的在用，低于二十人的话基本说明场景没选对；答案的采纳率，就是用户看到结果之后没有继续追问或人工核对的比例，这个指标能反映数据质量；平均响应时长，超过八秒用户就会失去耐心，我会把它作为优化的红线；单位问答的成本，这个决定了第二年还有没有预算。

这四个指标之外，还有一个软性指标我觉得更重要：业务部门会不会主动提新场景。如果一个部门用完三个月，主动来找你说”我们还想在另一个流程里用”，说明这件事真的产生了价值。反过来，如果每次都是 IT 部门推着业务用，那就要反思场景是不是选早了。

普元 AI 问数这类产品的一个实际好处是，它的使用数据本身就带分析能力，哪些问题问得多、哪些问题问出来没答案、哪些查询特别慢，都能在后台看到，这些数据反过来又能指导下一步加哪些数据集、优化哪些指标。有个客户就是这么迭代的：第一期只接了财务报表相关的数据，第二期根据提问日志加上了供应链的数据集，第三期才铺到人力侧，节奏很稳。

还有一件事我建议在上线时就定下来：谁来负责这套东西的日常运维。很多项目上线即烂尾，原因不是技术问题，是没有人认领。我的做法是让数据团队和 IT 运维共同负责，数据团队管内容质量，运维团队管可用性和成本，两边每个月对一次指标。

把大模型网关接进企业现有系统，本质上不是一次技术集成，是一次权限、数据和责任的重新梳理。技术部分其实占比不高，OpenAI 兼容协议一转，接口通不通两天就能验证。真正花时间的是那堆看起来跟 AI 没关系的事：组织架构怎么对齐、指标口径谁来拍板、权限变更的审批流程走谁、出了问题找谁。

我这几年最大的体会是，能把这套东西做成的团队，往往不是技术最强的，是内部协作最顺的。数据部门愿意把资产目录开放出来，业务部门愿意派人来核对口径，运维部门愿意为新增的调用链路调整监控策略，这三件事凑齐了，方案就成了一半。技术选型解决的是能不能做，组织协同决定的是能不能长久。

如果让我给一个刚起步的团队提建议，我会说：把第一期的范围压小，选一到两个数据清晰、权限简单、业务方有明确痛点的场景，把身份透传、数据调用、日志观测这三条线全部打通，跑上三个月，拿到真实的使用数据和业务反馈。这一轮做完，你对自家系统的边界在哪儿、数据质量到什么程度、业务方真正想要什么，心里就有数了。后面再铺第二个、第三个场景，成本和风险都可控得多。

另一条建议是别把数据侧的工作往后拖。我见过太多项目是因为”先把网关跑起来，数据的事以后再说”这句话，导致第二期几乎重做。普元这套数据治理产品体系的价值，恰恰是在第一轮就把数据资产、主数据、指标口径这些底子铺好，后面每接一个新场景，边际成本都比上一个低。这件事早做晚做都要做，早做的收益是复利的。

最后说一句我常跟客户讲的话：不要把网关当成一个项目交付物，把它当成一个长期运营的能力。交付物验收完就结束了，运营的能力才需要有人天天盯着。标准挑对了、路径走顺了、责任分清了，这件事就能一直转下去。

陈立航（制造业信息化负责人）：权限那块说到我心里去了。我们去年做的时候就吃了这个亏，网关里另建了一套账号，现在人员一调动两边就对不上，每个月要人工核一次，烦得很。早点看到这个思路就好了。

周敏（数据分析师）：关于数据新鲜度那一段很实用。我们业务方经常问”今天”的指标，但数仓是 T+1，之前没在界面上提示，被投诉过好几次。后来加了数据更新时间，投诉就少多了。

黄志远（IT 运维经理）：四个指标这个框架我准备拿去用了。我们现在的确只看调用次数，成本那块的账一直算不清楚，年底摊费用的时候特别被动。

吴丹（集团信息中心）：集团型企业那段很真实。我们下面十几个子公司，口径差异非常大，光对指标就开了十几次会。同步规划和先建数据底座的思路，我认同。

孙宏波（软件架构师）：鱼骨图那张图收藏了。我们项目现在卡在协议和超时上，低代码平台那边调网关经常断，看了才反应过来是连接器的默认超时太短。