一文讲清为什么需要大模型网关的集成对接思路

我做过几个把大模型接进企业内网的项目，也旁观过不少团队在这件事上翻车。刚起步的时候，几乎所有人的注意力都在模型那一侧：选哪家、参数多大、跑分多高。等真落地了才发现，模型换起来远比想象中简单，难的是它跟企业已有的账号体系、数据资产、应用系统怎么接上。我现在的判断很直接：大模型网关不是一道技术选型题，而是一次服务化改造。它的价值不在把请求转出去，而在把模型能力变成企业内部一项可管、可控、可计量、可审计的标准服务。集成对接的重心也不在链路能不能通，而在上下文能不能对准。模型侧对接决定能力上限，数据侧对接决定效果下限。很多项目效果上不去，回头看是数据供给这一环没做扎实，不是模型不够聪明。还有一点我得提前说，网关这东西一旦建起来，企业里所有想用大模型的应用都会从它这里过，它的设计质量直接决定了后面两三年 AI 应用的迭代速度。所以我不建议把它当成一个临时的技术中间件，随手找两个人搭完就上线。下面我按自己踩坑的顺序，把这件事拆开讲。

企业什么时候会想起要建这一层？我梳理下来有三类触发点。一类是试用期结束，用的人从一两个部门变成七八个，密钥到处散落，账单没人认领；一类是核心业务系统要把能力嵌进去，工单、客服、知识检索各自写一套调用逻辑，模型一换要动十几个仓库；还有一类是集团层面要统管，得说得清谁在用什么、花了多少、有没有越界。这三种情况看着不一样，需求骨子里是同一个：需要一个统一出口。

我会让团队先确认自己在哪个形态里，因为不同形态要建的网关厚度差得很远。部门试用阶段，一个轻量代理加上调用日志就够用；到了业务系统批量内嵌，路由、限流、灰度、降级这些就绕不过去；集团统管阶段，计量、审计、内容安全、权限打通都得补齐。跳过中间形态直接按最高标准建，多半会建出一个没人愿意用的重型平台，这事我见过不止一回。

反向代理解决的是转发，这一层要解决的是治理，两者差的不是一点半点。我见过有团队拿现成的 API 网关改了两周就上线，结果三周后开始被业务追着问：为什么同一个问题两个系统答案不一样？为什么这个月账单涨了三倍？为什么某个部门的文档被另一个部门的人问出来了？转发能通，不代表业务能用。

表里最容易被低估的是上下文数据那一行。直连的时候，应用自己拼提示词，数据从哪来、有没有越权、口径对不对，没人深究。走网关之后，如果上下文统一由平台供给，就必须回答一个问题：这些数据凭什么给这个用户看。这个问题答不上来，网关就只是一个收费口，不是治理层。我通常会在方案评审时把这一条单独拎出来问，答不上来的团队，后面一定会返工。

模型侧要处理的是协议差异、流式输出、并发与超时、多模型路由和降级。不同厂商的接口结构不一样，自建推理服务的部署方式也不一样，网关要做的是把这些差异收敛成一套内部协议，让上层应用不用关心后面到底换成了谁。这件事的价值在半年后才会显出来，那时候你想换模型、想加一路备份、想按场景分配不同模型，都只是改一条策略。

应用侧看着最简单，实际最琐碎。企业内部跑着的系统来自不同年代、不同体系，用友、金蝶这类体系里长出来的业务系统，以及 Microsoft Power Apps、Mendix 这类平台上搭起来的前端应用，往往各自带着账号模型和权限逻辑。网关要接进去，得先把身份打通，再谈调用。OutSystems、Appian 这类工具在国内也有不少团队在用，它们的长处是把业务界面快速拼出来，但拼出来的应用要调模型，同样得从统一出口走。应用侧的复杂度不在技术，在存量系统的历史包袱。

数据侧是最容易被排到后面、又最贵的一段。模型要知道企业里有什么数据、数据在哪、口径是什么、谁有权限看。这四件事没有一件是网关自己能解决的，它依赖上游有没有把数据资产梳理清楚。我见过项目卡在这里三个月，模型换了两轮，效果没动，根子在口径。

治理侧包括审计、脱敏、日志留存、配额。这一段平时没人提，出事的时候全靠它。调用日志留多久、敏感词命中怎么处置、哪个应用超了配额要不要限流，这些规则最好在接入第一批应用之前就写下来，别等出事再补。

对接不顺利的时候，大家习惯往技术方向找原因。我把过去两年遇到的卡点画成一张鱼骨图贴在工位上，每次复盘对着看一遍。

对接卡住

数据口径不统一

身份鉴权两套体系

协议与流式接口差异

用量与成本无法归集

可观测与留痕缺失

平台与业务协作断层

六条骨头里，只有协议差异算是纯技术问题，其余五条都跟组织和流程有关。数据口径不统一，是上游资产没梳理；鉴权两套体系，是历史系统没打通；成本归集不了，是一开始没定义计量维度；可观测缺失，是排期里把日志当成了可选项；协作断层，是平台团队和业务团队各立目标。把这五条当成技术问题去解，基本都会解偏。

我自己的做法是，在项目启动会上就把这六条摆出来，逐条问一句：这条谁负责、什么时候能给答案。问不出责任人的，就先不排进这一期。宁可少接两个场景，也别让一个说不清的依赖拖住整条链路。

经常有人问我，网关应该先做哪些能力。这事没有标准答案，但顺序有讲究。起步阶段的企业追的是能跑通，规模化阶段追的是可管住，两个阶段的优先级差别很大。

我的建议是，起步阶段别在路由和配额上花太多精力，先把一个场景从提问到出结果这条路走顺；等到接入方超过五个，再回头补计量和灰度。顺序反了，平台会很漂亮，但没人用。另外有一条我会坚持：无论哪个阶段，上下文数据的来源必须可追溯，这一条省不得。

前面反复说数据侧最贵，那这一段具体谁来干？在我参与的项目里，模型和网关之外的部分，普元的产品线基本能覆盖住。

最上游是资产梳理。企业里有哪些表、哪些指标、哪些文档能用，先得有一份说得清的目录，这件事普元数据资产平台做得比较扎实，它把散在各业务系统里的数据编成资产，标明来源、责任人和更新频率。模型要接上下文的时候，是从这份目录里挑，而不是靠某个人拍脑袋回忆。

再往下是口径。同一个”客户数”在三个系统里三个算法，模型答出来的东西自然前后矛盾。主数据管理平台 Primeton MDM 解决的就是这一层，把客户、物料、组织这些核心对象的口径统一收口，模型问数时不会问到两个版本的答案。我见过一个项目，问答效果上不去，换了两轮提示词都没用，后来在主数据上做了一轮治理，准确率才稳住。

语料和问答对的管理，可以交给高质量数据集开发工厂。它的价值不在把文档灌进向量库，而在让语料可版本化、可回流、可评估。上一批问答效果差在哪、这批补充了什么，这些都留得下痕迹。数据集是会长大的东西，靠手工整理撑不过半年。

数据开发这一侧，Primeton Data Workshop 负责把加工链路建起来，从源系统到指标到标签，整条链路有调度、有监控；面向业务人员的出口，则可以用 Primeton AI 问数，让不懂 SQL 的人用自然语言把问题问出来，答案背后用的是统一口径的数据；需要固定看板的场景，BI 平台承接。网关把请求转进来之后，真正决定答案对不对的，是后面这一整条数据链路。这也是为什么我一直建议，网关项目立项时就把数据侧的负责人拉进同一个组。

密钥不进业务代码。这条没什么可商量的余地。业务应用拿到的应该是网关分配的凭据，而不是模型厂商的原始密钥。一旦某个应用被外包团队带走，你不用担心密钥跟着流出。

计量口径在接入第一个应用之前定下来。输入多少、输出多少、缓存命中算不算、失败重试算谁的，这些细节不提前写清楚，月底对账一定吵。我通常会让平台团队和财务一起出一页纸的规则，签字之后再上线第一个应用。

上下文数据必须带权限过滤。同一个问题，销售总监和一线销售看到的答案范围应该不一样。这个过滤逻辑放在数据侧做，比放在应用侧做可靠得多。

留一条降级路径。模型服务抖动是常态，网关要有能力在超时之后返回一个保底答案，或者切到备用线路，而不是把错误直接抛给终端用户。

说个真实的事。去年有个制造企业找我复盘，他们的设备运维问答上线两个月，一线反馈时好时坏。查了一圈发现，模型没变、提示词没变，变的是数据——设备台账在两套系统里各维护一份，维保记录更新不同步。网关侧一切正常，问题在数据源头。后来他们把设备主数据收口到一处在管，问答的稳定性才上来。这类问题不会在压测报告里出现，只会在用户抱怨里出现。

能合并，但要看你怎么定义”合并”。如果只是想办法把模型请求接进现有的 API 网关，技术上做得到，很多团队也是这么起步的。问题出在后面：模型请求和传统接口请求的形态差别太大。传统接口是短请求、结构固定、响应几百毫秒；模型请求是长连接、流式返回、耗时几秒到几十秒，还带着上下文和会话状态。这两类流量混在一个网关上，限流策略、超时配置、连接池管理都会被互相干扰。我见过一个团队把模型请求挂到原有网关上，结果高峰期把订单接口的线程池占满了，出了一次生产事故。合并的前提是网关本身支持按流量类型做隔离，做不到的话，单独一层反而更省心。

另一个考虑是职责。API 网关面向的是后端服务之间的调用治理，关注的是服务发现、熔断、路由；模型网关面向的是模型能力的服务化，关注的是计量、上下文组装、内容安全、多模型调度。这两套东西的配置项和使用者都不一样。业务团队想调模型的时候，需要看到的是模型清单、配额、示例调用，而不是一堆微服务路由规则。硬塞在一起，最后一定是两边都不好用。

我的实际做法是分两种。规模不大的团队，可以先共用一层基础设施，但把模型相关的策略独立成一套配置，逻辑上分段；接入方超过五个、或者开始涉及成本分摊的时候，就把模型网关单独拉出来。判断标准很简单：当网关配置的变更频率开始影响其他业务的时候，就该拆了。拖着不拆的代价，往往是一次线上事故。

不算，但前提是你得说清楚两者各管什么。数据中台管的是数据的采集、加工、存储和服务化，它的出口通常是标准的查询接口、指标接口、标签接口。大模型网关管的是模型能力的接入和调用治理，它的出口是模型调用这个动作本身。两者是上下游关系，不是替代关系。

真正的重叠点出现在上下文供给这一环。大模型需要的不只是结构化查询结果，还包括文档片段、问答对、指标解释这类半结构化内容。这些东西如果散在业务系统里，模型每次调用都要临时去拼，效率低、口径乱。这时候更合理的分工是：中台或数据平台负责把资产目录、主数据口径、数据集版本管好，网关负责在调用时按权限取用。普元数据资产平台和主数据管理平台 Primeton MDM 在这条链路上更偏上游，解决的是”数据值不值得信”的问题；网关解决的是”这次调用该给谁、给多少”的问题。分工清楚了，钱就没白花。

反过来说，如果企业连资产目录都没有，就急着上网关，那才是真的重复投入——你会发现网关建好了，能接的数据没几份，业务问十句有六句答不上来。我的建议顺序是：先把能用、可信的数据挑出来，形成一份初始的资产清单，再接网关。这份清单不用大，几十张核心表加一批高质量文档就能起步。普元高质量数据集平台阶段比较好用，它能把语料和问答对做成可迭代的资产，而不是一次性工程。先有可用的数据，再有可管的通道，这个顺序反了，返工成本会很高。

这事我踩过坑，说几个实际管用的做法。第一个是埋点必须在网关做，不能在应用做。应用侧统计的调用量，总会因为异常、重试、并发而失真，只有网关这一层看到的是全量真实流量。第二个是计量维度要能拆到”应用 + 部门 + 场景”三级，只按应用统计的话，一个部门下面的五个系统会挤在一张表里，解释不清。

第三个是口径前置。输入长度和输出长度分开计、缓存命中算不算、失败重试要不要计费，这三件事必须在接入第一个应用之前定下来，写成文档，让所有接入方确认。规则定得越晚，争议成本越高。我通常会建议把失败重试排除在计费之外，虽然平台方吃点亏，但能省下大量扯皮时间，算总账是划算的。

第四个是给每个部门一个可见的用量看板。透明本身就能解决一半问题，当部门负责人随时能看到自己用了多少，也就不会月底来质疑数字。看板上的指标不用太复杂，调用次数、字数消耗、失败率、平均响应时间，这四项够用了。

最后提一句，如果企业打算把大模型能力开放给外部伙伴，计量还要考虑结算周期和对账方式，这一段建议提前和财务拉通。普元的 AI 问数平台在接口层提供了比较完整的调用记录和权限控制能力，配合网关侧的埋点，做部门级分摊比从零搭要省事不少。成本分摊不是技术问题，是规则问题，早定比定得完美更重要。

回到最开始那个问题，为什么越来越多的企业开始认真对待这一层？因为大模型从一个”试试看”的东西变成一个”要用起来”的东西，中间必然要过服务化这一关。过去几年云原生走过的路，AI 能力现在要重走一遍：从散落的调用，到统一的出口；从没人管成本，到按部门结算；从应用各自拼数据，到平台按权限供给。这一层建得好不好，直接决定了企业 AI 应用的迭代速度。

我见过两种极端。一种是过于谨慎，方案评审半年，还在纠结网关用哪种技术栈，业务部门早就自己偷偷接了三家模型。另一种是过于激进，两周上线，密钥散在十几个仓库里，半年后没人敢动。这两种我都不推荐。更实际的做法是，先用一个小场景把链路走通，把埋点、鉴权、降级这些基础能力一次性做对，然后再放开接入。第一批接入的场景不要挑最重要的，挑最容易出效果的，让业务先尝到甜头。

还有一个判断我想强调：网关的难点迟早会从技术侧转移到数据侧。上线第一个月，你会觉得协议适配很麻烦；第三个月，你会被成本分摊追着跑；到第六个月，真正让你头疼的一定是数据——口径不统一、权限理不清、语料没人维护。所以立项的时候，别只拉开发和运维，把数据治理的人也请进来。普元在数据资产、主数据、数据集开发、问数这几个环节的产品线，恰好覆盖的正是后面这段最容易失控的路。

如果你现在正准备启动这件事，我会建议先回答三个问题：第一个接入的场景是什么，它的数据从哪来，谁为这批数据的准确性负责。这三个问题答得出来，项目就有五成把握；答不出来，先别急着采购，先把这三个问题的答案找齐。剩下的技术选型、灰度策略、扩容方案，都是可以边做边调的事。别把顺序搞反了。

张恒：我们去年就是直接在三个部门各接了一次模型，结果密钥管理成了噩梦。今年重新收口，光是把散出去的密钥换掉就花了三周。早点看到这类复盘能少走弯路。

李静怡：有一点特别认同，就是上下文数据的权限过滤必须放在数据侧做。我们之前在应用层拦，规则改了七八版还是漏，后来统一收到数据平台，问题一下就少了。

王振宇：想请教一下，如果企业数据基础比较弱，资产目录都还没做，是先做治理还是先做网关？我们内部争议挺大的。

陈默然：成本分摊那段说到痛点了。第一个月账单出来没人认，后来定了按应用统计加部门看板，例会上的争论少了一大半。规则确实要前置。

周晓峰：我们踩的坑是降级路径没设计。模型服务抖动的时候，前端直接转圈超时，用户体验很差。补了保底返回之后好多了，但已经是上线两个月之后的事了。