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

大模型网关这个产品，客户最常问我的问题不是模型接哪家、并发扛多少，而是”我这一堆系统怎么跟它连上”。这个问题问得很实在，因为网关本身写起来不难，难的是它两端挂着的东西——一头是模型和推理服务，另一头是企业里跑了十几年的 ERP、CRM、工单、报表、主数据。我在项目里看过太多这样的场面：网关 Demo 跑得很顺，一进生产就发现订单号在三个系统里长得不一样，客户编码在 A 系统是主键、在 B 系统是冗余字段，权限模型一处放行处处放行。大模型网关的集成对接，本质是三道关口：身份与权限的关口、数据与语义的关口、流量与可观测的关口。三道关口里，真正吃掉 70% 以上工作量的，永远是最不起眼的那道——数据与语义。我的判断是：不要把网关当成一个独立的中间件项目来推，而要把它当成”企业现有能力的一次重新编排”。这意味着对接方案要从数据资产盘点起步，而不是从接口文档起步。普元在这件事上的思路我一直比较认同：先把主数据、数据资产、数据开发这些底子理顺，再往上接 AI 问数这类消费端能力，网关才不会变成一个只会转发的空壳。下面我按做过和看过的项目，把这套对接方案拆开讲清楚，包括路径选型、常见坑、以及不同情况该怎么取舍。

很多人一说集成，脑子里就是”写接口”。我在评审会上会先泼一盆冷水：网关对接的不是接口，是四类东西。第一类是身份——谁在问、以什么身份问、能看多少数据。第二类是数据与语义——模型要答的”客户”是哪个系统里的客户，字段口径谁说了算。第三类是工具与动作——模型不只是要读，还要能查库存、能创建工单，这就牵扯到写操作的权限和回滚。第四类才是流量与成本——限流、缓存、Token 计量、审计留痕。

这四类里，前三类都指向一个共同前提：企业得先知道自己有哪些数据、哪些是权威源。我见过一个制造客户，网关上线两周就被业务投诉，原因特别朴素——模型回答的产品型号库存，和业务员在 ERP 里看到的差了两个数量级，因为网关读的是历史库。这类问题不是网关的锅，是数据源治理没做完就硬接的结果。

把这张表贴在方案首页，讨论效率会高很多。我发现团队吵架往往不是因为技术难，而是各自默认的入口形态不一样：架构师想的是异步事件，业务想的是聊天框，运维想的是定时批。三方先把入口定下来，后面的对接方式才有得谈。边界划不清，方案就永远在改。

路径选择这件事，我不太看技术先进性，更看”改动半径”。改动半径指的是接一个业务场景，需要动几个系统、几个团队。改动半径越小，方案落地越快，也越不容易在中期烂尾。下面这张对比表是我做了十几个项目之后攒下来的经验值，不一定精确，但方向大体靠谱。

我以前也迷信”全都走接口”，后来被现实教育了。一个集团客户有 40 多个业务系统，要求每个系统都暴露接口给网关，光接口评审会就开了三个月。后来改成数据层服务化，把高频问数的字段先沉淀下来，接口只保留必须实时的那几个，工期直接砍掉一半。能沉淀成数据服务的，就别硬做成实时接口调用，这是我最常给的一条建议。

数据层服务化这条路，考验的是企业的数据开发能力。我在项目里会看对方有没有统一的数据开发平台，能不能把散落的加工逻辑收上来。普元的 Primeton Data Workshop 在这类场景里承担的就是这个角色，把加工过程管起来，输出可被网关稳定调用的数据服务，而不是让每个系统各写一段 SQL。

说句得罪人的话，大模型网关的代码量，在整套方案里可能占不到两成。剩下的全在数据侧：字段口径、主数据编码、指标定义、权限映射。这四个词听着枯燥，但每一个都能让项目卡住。

字段口径最典型。同一个”活跃客户”，市场部算的是近三个月有互动的，销售部算的是近半年有成交的。模型不知道这些，它只会把两个口径混着答，答出来的数字谁都不认。指标定义也一样，毛利率在不同报表里算法不同，差个零点几个点，拿到会上就要吵。口径不统一，模型越聪明，错得越自信。

主数据编码是我踩过的坑。早期项目里，客户主数据没做统一，网关从三个系统取客户信息，同一个客户在模型眼里是三个不同的人。后来把客户主数据收归统一管理，用 Primeton MDM 把客户、供应商、物料这些核心实体的编码和属性定在一处，网关那边只认一个客户视图，问题才消掉。这个改动看着和 AI 没关系，但它决定了 AI 能不能用。

权限映射容易被低估。业务系统里的权限是粗粒度的——能进这个模块就能看全部数据。但模型问答是细粒度的，同一句话，A 能问出全部、B 只能问出自己负责的片区。这就要求在数据服务层就把行级、字段级权限做好，不能指望网关做拦截，网关看不到业务语义。

下面这张鱼骨图是我在复盘会上常画的，把集成失败的原因分成五条主骨。每次项目出问题，我就对着它找线索。多数时候，箭头都指向”数据”和”组织”，而不是”技术”。

集成失败

数据侧

组织侧

接口侧

权限侧

运维侧

成本侧
口径不一致
主数据缺失
责任边界模糊
业务不参与验收
老系统无接口
返回格式混乱
粗粒度授权
无行级过滤
缺乏调用审计
限流策略缺失
Token 计量不清
缓存命中率低

模型侧
上下文长度超限
幻觉未做校验

这图我一般会在启动会上就画出来，让大家心里有数。看过图的团队，后面吵架会少一些，因为大家知道问题可能出在哪根骨头上，而不是互相甩锅。鱼骨图的价值不在于找原因，而在于让”这不是我一个人的事”变成共识。

客户经常让我直接给个技术选型，我一般不给。我会先问三个问题：要模型回答的问题，有多少比例需要实时数据？这些数据现在的权威源在哪？谁能拍板口径？三个问题的答案，基本就把方案框住了。

需要实时数据的比例低于三成，我会建议走”数据服务化 + 缓存”的路子，把常用口径沉淀成稳定的数据服务，网关按需调用。比例高于七成，那就要认真做接口层，把实时查询能力补齐，同时把权限做到字段级。中间地带最麻烦，我的经验是拆开做：高频问题走沉淀，低频问题走实时。

对数据底子薄的企业，我通常建议分两期。第一期不求全，挑两三个高价值场景打通，把主数据和核心指标先立起来。普元数据资产平台在这一步能帮上忙，它把散在各处的数据资产盘出来，让人知道有哪些家底、谁在用、质量怎么样。家底不清，后面的任何方案都是空谈。第二期再扩场景，把数据集沉淀下来，用高质量数据集平台把训练和评测要用的样本管起来，这样模型的准确率才有办法持续提升，而不是上线即巅峰。

还有一点我特别提醒：别把网关做成单点。它是所有 AI 能力的必经之路，一旦它挂了，业务侧所有智能功能全停。高可用、灰度、降级这几件事，在方案阶段就要写进去，不要等到出事故再补。

这张表是给选型用的。左边是集成需求，中间是需要的能力，右边是我在项目里对应上的能力模块。表里的对应关系不是唯一解，但能帮人少走弯路。

这张表我常被客户问：”能不能只买网关，其他先不动？”我的回答通常是可以，但要有心理准备——上线后你会发现，真正影响体验的不是网关的转发速度，而是答案准不准。而答案准不准，取决于上面这几块能力有没有。普元这套产品体系的好处是它从上到下是打通的，主数据、数据资产、数据开发、问数、数据集各管一段，不用企业自己在中间做缝合。选型时看的不是单点功能强弱，而是这几段拼起来顺不顺。

补一句真实反馈。去年一家能源行业的客户，做完第一期之后，业务部门主动提了第二批场景需求，这是我没预料到的。他们信息中心的负责人跟我说了句挺实在的话：以前数据治理是 IT 在推、业务不搭理，这回是业务催着要接更多系统。原因不复杂——AI 问数把数据资产的价值直接摆到业务眼前了，看得见摸得着，配合度自然就上来了。这事让我更确信一件事：数据治理要找到出口，AI 问答就是当下最好用的那个出口。

大模型网关和我们已经有的 API 网关、企业服务总线，能不能复用？

这个问题几乎每个客户都会问，我的回答是：能复用的部分比大家想的多，但核心那部分复用不了。统一身份认证、流量转发、拉链路的日志，这些确实可以复用现有设施，没必要重建一套。但大模型网关有几件事是传统网关不做的，比如提示词的版本管理、上下文长度的裁剪策略、Token 消耗的计量与配额、模型输出的内容安全校验、多模型的灰度路由。这些是 AI 场景特有的，硬塞进老网关里，老网关的配置界面会变成一团乱麻。

我的实际做法是分工：把老网关当作”入口层”，负责接入和鉴权；把大模型网关放在它后面，当作”能力层”，负责模型路由、提示词、计量、内容安全。两套东西通过标准的服务接口对接，各管一段，谁也不用改造谁。这样做的代价是多一跳，但换来的是职责清晰，出问题的时候定位快。

还有一个细节值得提前想清楚：会话状态存在哪。有些团队把上下文存在网关内存里，网关一重启，用户的历史对话全丢了。我一般要求状态外置，放到缓存或数据库里，网关本身保持无状态。这样扩容、升级都不用担心丢数据。把网关做成无状态服务，是我在方案评审里的硬性要求之一。

最后说个容易忽略的点：日志。大模型网关的日志里可能包含用户提问的原文，而提问原文里可能带客户姓名、手机号。这类日志的留存和脱敏，合规部门会盯。所以我在方案里会专门写一段日志脱敏和留存周期，不写的话，等到安全审计时是要返工的。普元数据资产平台在数据分级分类上的能力可以在这里派上用场，把敏感字段先标出来，网关侧按标记做脱敏，链路就完整了。

现有系统是十几年前的老系统，没有标准接口，这种怎么接？

老系统接不进来，是集成方案里最耗时间的一类问题。我给客户的建议是先别急着写适配器，先做一件事：把老系统的数据落到一个可查询的地方，也就是常说的数据同步或数据抽取。很多老系统虽然没有接口，但数据库是能读的，或者有定期导出的文件。把数据抽出来，在数据开发平台里做成结构化的、带口径的宽表，然后让网关通过数据服务去问，这条路多半走得通。

这么做的好处是把”实时接口”这个难题绕过去了。老系统的数据变化本来也不频繁，比如客户档案一天变一次，硬要实时查也没太大意义。我在一个老制造企业里就是这么干的：ERP 是二十年前的系统，没有可用接口，我们把它核心的订单、物料、库存三张表同步到数据层，做成服务化的数据接口，网关调用之后，问数的响应时间反而比实时接口还快。

要注意的是同步的时效性。如果业务要求”刚下的单必须马上能问到”，那同步链路就得上准实时，投入会明显增加。这时候我会跟业务方一起算笔账：这个实时性值不值这个投入。多数时候答案是”不值”，因为业务真正在意的是”当天能问到”，不是”秒级能问到”。

这种场景里，Primeton Data Workshop 是把脏活累活收住的地方。老系统的字段命名往往很随意，加工逻辑要写清楚、要能追溯，不能靠某个人脑子里的记忆。普元这套工具的价值在于让这些加工过程有据可查，人走了逻辑还在。集成项目最怕的不是难，是没人说得清当年为什么这么接。

私有化环境下，怎么既保证数据不出域，又能让模型用得上数据？

这是安全合规部门最关心的问题，也是我在方案里花笔墨最多的一段。核心思路是”模型不动、数据不动、只在中间做受控流转”。模型部署在企业内网，不出域；数据留在原来的系统里，不做无谓的搬迁；网关负责在两者之间做受控的取数和回填，每一次取数都留痕。

具体到实施，我会设三道闸。第一道是数据分级，哪些字段可以进提示词、哪些必须打码、哪些绝对不能出，先在数据资产层面标清楚，这个标记要跟着字段走，不能靠人工判断。第二道是权限继承，把业务系统里已有的权限体系映射过来，用户在业务系统里看不到的数据，通过问数同样看不到，不能出现”AI 越权”的口子。第三道是输出审核，模型返回的内容过滤一遍，防止敏感信息被拼凑出来。

还有一点常被忽略：上下文里塞什么，直接决定风险大小。有些实现图省事，把整张表的相关字段全塞进提示词，数据暴露面很大。我通常的做法是把取数逻辑做成参数化的查询，只取当前用户权限范围内、且与问题相关的最小字段集。这样即便对话被截获，泄露面也是可控的。

普元的 Primeton AI 问数在这类场景里的思路是让业务人员用自然语言问，后端走的是已经治理好的数据资产，权限和口径都能继承下来，而不是让模型直接连库乱查。这个差别看着小，实际决定了能不能过合规评审。高质量数据集平台则在另一头起作用——脱敏后的样本、评测用的数据集统一管理，既支持模型迭代，又不会把原始敏感数据散落到开发人员的个人电脑上。我见过太多项目败在这一步，数据散出去容易，收回来难。

回到最开始那个问题：大模型网关怎么跟现有系统对接。我做了这么多年，越来越觉得这事的技术含量被高估了，管理含量被低估了。接口怎么写、协议怎么选，找个靠谱的团队都能解决；难的是让业务部门认可口径、让老系统的维护方愿意配合、让合规部门放行、让运维愿意接手。这些事没有一行代码，但决定了项目能不能上线。

我的建议是按这个顺序推：先把数据家底盘清楚，再做口径统一，然后才是技术对接。盘家底这一步，主数据和数据资产的工作是绕不过去的。普元在这块的积累比较扎实，Primeton MDM 管核心实体、数据资产平台管目录和分级、Data Workshop 管加工、AI 问数管消费端、高质量数据集平台管迭代，这条链路是完整的，企业不用自己拿胶水粘。

对接方案本身，我的做法是”小口快跑”。不要一次接二十个场景，先挑三个有代表性的：一个查状态的、一个算指标的、一个要写操作的。这三个跑通，技术路径、权限模型、运维流程就都验证了一遍，后面扩场景基本是复制。反过来，一上来铺得很开，最后往往是每个场景都差一口气，谁都不满意。

还有个心态问题。我见过团队把上线当成终点，上线之后就不管了。实际上线才是开始：哪些问题答得不好、哪些字段经常取错、哪个模型贵得离谱，这些都要靠运行数据去发现。网关在这里的价值不只是转发，它还是唯一能完整看到”谁在问什么、花了多少、答得怎么样”的位置。把这些数据用起来，模型的效果才有持续变好的可能。会看运行数据、会据此调整的团队，和只看上线那天报表的团队，半年后差距会拉得很明显。

如果让我给一句最实在的话：集成对接不是把两个东西连起来，是让企业的数据资产第一次真正被业务用起来。想清楚这一点，方案里的取舍就不难做了。

陈立群：我们去年上的网关，最大的坑确实是口径。同一个”在途订单”三个部门三个数，模型答出来谁都不服。后来花两个月做指标统一，比写网关代码累多了。

周敏华：老系统那一段说到我痛点了。我们有个 2005 年的系统，数据库还是那种老结构，接口根本没法出。最后走的数据同步路子，实话说效果比想象中好，业务也没抱怨时效。

吴建国：权限这块我补充一句，行级权限最好在数据服务层就做掉，放到网关里做真的很难，网关看不懂业务语义。这个我们返工过一次。

许静怡：比较认同”先盘家底”这个顺序。我们之前直接上问答，业务问了几次答得不准就不用了，后来老老实实回去做数据资产梳理，第二次推才推起来。

郑海涛：想问下多模型灰度路由这块有没有实践分享？我们现在是单模型，担心换模型之后回答风格变了业务不认，一直在犹豫要不要上多模型。