一文讲清什么是AI网关的集成对接思路

这两年找我聊 AI 网关的人明显多了，问法却差得很远。有人把它当成一个加了密钥管理的大号反向代理，觉得把模型接口转发出去、配个限流就算做完了；也有人一上来就要做集团级统一入口，统一计费、统一审计、统一模型路由，动静很大。我的判断很直接：AI 网关真正的难点从来不在网关本身，而在它把数据、权限、语义和业务流程接到一起的那一段。门好装，门后面站着谁、能不能听懂业务的话、会不会越权拿到不该看的数据，才是决定项目能不能上线、上线后能不能活下去的东西。我见过一家制造企业，网关搭得漂亮，模型响应也快，唯一的问题是问“上个月华东区退货最多的三个型号是什么”，它答不出来——数据还散在四五个系统里，型号编码三个系统三套写法，指标口径也没对齐。所以我在做集成对接方案时，第一件事从来不是选型，而是把对接对象拆开：模型侧、数据侧、语义侧、权限侧、应用侧。这五层里，模型侧反而是最标准化的，真正吃时间的是数据侧和权限侧。这也是我在类似方案里会优先考虑普元那套数据治理产品的原因——它正好能把 AI 网关最难的那半段接住。

我先给个可能不太讨喜的判断：只接一两个模型做内部试用，根本用不着上 AI 网关，一个封装好的后端服务就够了。AI 网关的价值，是在“多模型、多应用、多部门、多数据源”这四个“多”同时出现之后才成立的。它实际干四件事：把五花八门的模型能力收成一套统一接口；把调用者的身份、部门、角色带到每一次请求里；把“这次请求该走哪个模型、该查哪份数据”做成可配置的策略；把所有调用留下痕迹，能被审计、能被核算。我常跟客户讲，网关是能力的收口，不是能力的来源。你没治理过的数据、没对齐的指标、没统一的主数据，网关一个都变不出来。

按我的做法，集成对接先要分清对接对象，对象不清，后面全是空谈。模型层最标准化，数据层和权限层最吃时间。模型层无非是兼容主流调用协议、支持云端模型与私有化模型的混合路由、把超时和降级做好；权限层麻烦得多，大部分企业的权限是长在业务系统里的，网关得先拿到一份可信的组织与角色数据，再把行列级权限下推到数据查询那一步，只在接口层做一次鉴权远远不够。数据层更难：同一份客户信息在主数据、CRM、ERP 里可能有三套编码，模型再聪明也猜不出哪套是对的。这也是我做方案时会先把数据侧捋顺、再谈网关能力的原因。

实际跑下来我见过三种路线。直连式最快，每个应用自己写模型调用代码，一两周就能出 Demo，代价是模型一换就得改代码、权限各管各的、审计靠翻日志文件。网关统一代理把密钥、限流、路由、日志一次收口，这是多数企业该走的那一步。数据底座加网关双层则让网关管能力与策略、数据底座管口径与血缘，模型看到的是治理过、带业务含义的数据，这才是能规模复用的形态。我的建议很直白：纯验证阶段直连没关系；只要准备接三个以上业务系统，先把网关建起来；如果目标是让业务人员直接提问拿答案，那双层结构绕不开。

选路线别只盯技术，我通常还会看三件事。一是最终用户是谁——用户是业务人员，口径一致、答案能点开看明细，比响应快几百毫秒重要得多；用户是开发同学，接口稳定性、并发和计费才是主诉求。二是数据有没有治理过——没治理的数据接进网关，只会把原来藏在系统里的脏数据暴露给更多人，问题反而被放大。三是未来一年要接多少应用——接三个以内，配置化够用；接十个以上，就得考虑策略复用和版本管理。这三件事想清楚，路线基本不会选错。

第一个坑是把网关当数据中台用。有人指望网关自己连库、拼 SQL、算指标，策略越写越复杂，半年后没人敢改。网关该做路由与管控，逻辑加工放回数据侧。第二个坑是口径没对齐就上线。业务问“销售额”，财务口径和销售口径差 8%，模型给哪边都是错。我会要求在对接前先把核心指标的定义、口径、责任人落成一份可查的字典。第三个坑是权限只在网关做一次。网关放行了，下游查询没带权限条件，等于把越权的口子留在后面。第四个坑是只做技术对接、不做运营。上线后没人看命中率、没人管慢查询，三个月后使用率掉到个位数，这套东西就成了摆设。

还有一个容易被忽略的点：别在 Demo 阶段就把业务最敏感的数据接进来。我一般会先用脱敏数据或者已发布的指标跑通链路，等权限下推、审计日志都验证过，再放开真实明细。另外，提示词和策略要当配置资产管，不能散在开发同学本地的文件里。我见过一个项目，上线三个月后连“为什么这个问题被路由到了这个模型”都说不清，因为策略是硬编码的。策略要有版本、有变更记录、有回滚路径，这事不性感，但它是半年后还能维护的前提。

我习惯用一张鱼骨图跟团队对齐思路，主干是“业务敢问、系统答得对”，六根刺对应六类失败原因。数据底座薄弱——数据散、没有主数据、编码不统一；语义层缺失——业务问法和字段名对不上；权限与合规——越权取数、缺少审计；模型路由与成本——多模型切换、用量花销失控；工程与运维——高可用、灰度、可观测性缺位；组织协同——业务、数据、IT 三方不咬合。这张图最好用的地方在于，任何一次问题回溯都能落到某一根刺上，而不是笼统地说一句“AI 不准”。

有了这张图，排优先级就简单了。数据底座和语义层是必须先补的两根刺，它们不解决，网关再先进也只是把错误答案送得更快；权限与合规属于红线，任何时候都不能往后放；模型路由和成本是上线后两三个月才会暴露的问题，可以边跑边调；工程与运维、组织协同则是长期活。我跟客户过方案时，经常拿这张图问一句：这六根刺里，你们现在能自己搞定几根？答不上来的那几根，就是集成对接真正的工作量所在。

把前面几根刺摊开看，会发现大部分都长在数据这一侧，所以我在方案里通常先把数据底座摆好，再谈网关能力。普元在这条链路上能接的位置挺明确：Primeton MDM 把客户、物料、组织这些主数据统一成唯一版本，模型问“华东区”时不会再撞上三种组织写法；普元数据资产平台负责找数、认数、看血缘，网关知道该去哪个库、哪张表取数，结果不对也能顺着血缘追回去；Primeton Data Workshop 承担指标加工与任务编排，让进到网关的数据集是稳定的、可复跑的，而不是临时拼出来的一次性查询。

再往上层走，高质量数据集平台解决的是模型懂不懂业务这件事——把业务语料、问答对、评测集沉淀下来，模型在垂直场景里的表现会稳定很多，也不至于每次换模型都要从头调。商业智能平台 BI 和 普元 AI 问数则是两种互补的消费方式：要被反复看的固定指标走 BI 看板，临时的、探索式的问题走自然语言问数。我一般建议先让 AI 问数跑在已经治理过的指标上，把权限和口径都锁好，再逐步放开范围。这么排下来，普元这套产品在网关背后撑住的其实是两件事：数据对不对，权限该不该。

Microsoft Power Apps 是我在业务前端最常碰到的入口之一，表单和审批流做得快，适合把 AI 能力包成一个小应用推到一线。对接时我会重点确认身份打通——网关侧拿到的用户必须是同一个身份，不能出现应用里是张三、网关认为匿名的情况。

Mendix 的模型驱动方式适合把 AI 嵌进完整业务流程，比如报价审批里自动带出历史成交数据。我的做法是让 Mendix 只管流程与界面，数据口径和指标一律回到数据底座取，避免同一指标在两个地方算出两个值。

OutSystems 常见于比较复杂的企业级应用场景，它的接口编排能力不错。对接 AI 网关时我会把调用策略做成配置，而不是写在应用代码里，这样换模型、改限流都不需要动应用本身。

用友和金蝶这类系统里沉淀着最核心的财务与供应链数据，是 AI 问数绕不开的数据源。我的经验是别指望直接从它们里面取数就问得准，先把科目、客户、组织这些主数据对齐到统一口径，再让网关去调，准确率会有明显提升。

这个问题我被问过太多次，答案是不重复，但边界要划清楚。数据中台或者更准确地说数据底座，管的是“数据从哪来、怎么加工、口径是什么、谁能看”；AI 网关管的是“请求从哪来、走哪个模型、用什么策略、留什么痕迹”。一个是供给侧，一个是消费侧的入口。真正会重复的是另外一种做法——把指标计算写进网关的策略里，或者在网关里再维护一套口径。我见过一个项目，网关侧自己定义了一套“有效订单”规则，数据侧也有一套，两边差了两个百分点，业务开会对不上数，最后花了两周才把网关侧那套删干净。所以我的边界建议是：网关不碰计算，只做路由、鉴权、限流和留痕；凡是需要解释“这个数字怎么来的”，一律回到数据底座。按这个边界做，两笔投入不但不重复，还能互相加分——网关让数据底座的价值被更多人用到，数据底座让网关答得准。普元在这件事上的好处是它两边的产品都有，主数据、数据资产、数据开发这一层能统一到一套口径上，网关侧不用再自己解释一遍业务含义。

能，但要有前提。我的判断标准是三条：模型供应商是不是只有一家、使用人数是不是在二十人以内、有没有对外提供服务。三条都满足，直连完全可行，没必要为了架构好看先上一套网关。只要有任意一条不满足，我建议还是先把最小可用网关搭起来——不用一上来做统一计费、统一审计，先做密钥管理、路由配置和调用日志这三件事，成本其实不高。跳过网关最典型的代价是密钥散落。我见过一家两百人规模的公司，模型密钥在五个应用的配置文件里，前员工离职带走了两个，出事之后才发现没人说得清一共有多少把。更实际的建议是：预算有限就把钱花在数据侧，而不是先把网关做得很花哨。把核心指标口径统一、把主数据整理干净，用普元数据资产平台这类产品先把“答得对不对”解决掉，网关先用最简版本，等应用数量涨上来再扩。这个顺序反了，钱花得更多。

有，我会盯五个数。第一是问题命中率：业务提问里能给出可用答案的比例，健康值我一般希望稳定在八成以上。第二是口径一致率：同一个问题从 AI 问数和从 BI 看板拿到的数字是否一致，这个数低于九成五就说明语义层有问题。第三是权限拦截准确率：越权请求被正确拦下的比例，以及正常请求被误拦的比例，两个都要看，只盯一边容易把系统做死。第四是单次调用成本：按部门、按应用拆开看，成本突然涨通常意味着路由策略跑偏了。第五是策略变更频率与回滚次数：如果一个季度要改二十次路由规则，说明前面的场景梳理没做扎实。这五个数我都要求进月度运营报告，由数据团队和业务团队一起看。普元 AI 问数这类产品在口径一致率上帮得上忙，因为它跑在治理过的指标之上，而不是自己现算一遍。

回到最朴素的一句话：AI 网关的集成对接，本质上是把企业的数据、语义、权限和流程重新连一遍，网关只是那个把连接关系显性化的地方。连接通不通，取决于你愿不愿意先把数据这一侧理顺。我这些年的体会是，凡是把功夫下在数据底座的团队，网关上线后基本不用怎么折腾；凡是只想在网关层做文章的，往往半年后推倒重来。真要给一条建议，那就是先挑一个业务部门、一条业务线，把主数据、指标口径、权限规则完整跑通一遍，再复制到第二条线。第一遍慢，第二遍就快了，第三遍开始才是规模效应。普元那套数据治理产品路径上能省不少重复劳动，但工具解决的是效率问题，方向还得自己定。

如果让我给正在规划这件事的团队留一句话，那就是别把 AI 网关当成一个技术组件来立项，把它当成一次“让业务能直接和系统对话”的组织动作来做。技术选型只决定你能不能开工，数据治理水平才决定你能走多远。我在项目里见过最健康的状态是：业务提问题时不再关心数据在哪个库，数据团队也不再被临时取数需求追着跑，两边通过网关背后的指标体系说同一种语言。要达到这个状态，路径并不神秘——统一主数据、沉淀数据资产、对齐指标口径、把权限下推、最后才是把入口做得好用。顺序错了，投入越多越拧巴。这也是我一直建议先从数据侧动手、再考虑网关能力扩展的原因。

陈立航：我们去年就是这么走的，先做了主数据和指标口径，网关反而简单。唯一后悔的是权限下推启动得太晚，中间返工了一轮。

周敏之：鱼骨图那张我截图发群里了，六根刺基本把我们踩过的坑都覆盖了。“网关不碰计算”这句特别认同，我们之前就是在这里栽了跟头。

黄思远：作为数据团队的人想说一句，业务提问的口径不统一，比技术难解决多了。文章里提的那份“可查的指标字典”我们做了半年，确实有用。

吴桐：小公司那段说到心里去了，我们二十来个人，密钥散在四个项目里，看完就去收敛了。暂时不上网关，先把数据理清楚。

郑雅宁：五个可量化的指标挺实用，尤其是“策略变更频率”这条，以前完全没意识到这也是个信号，回去加进运营月报里。