行业特性决定方案：AI网关厂商适配手册

做了十多年数据类项目，我越来越确信一件事：AI网关厂商适配的核心难点从来不在协议转换，而在数据语境的统一。很多团队把网关理解成一个反向代理层，把模型API接进来，把请求转出去，觉得这事就成了。项目跑到第三周，业务方问一句”华东区上个季度毛利率是多少”，模型给出的数字和财务系统对不上，整个网关就被打回重做。问题不在模型，也不在接口，在于网关背后那层数据没有被治理过，口径、主数据、权限边界全是散的。

行业特性对方案的决定作用，比大多数人想得更硬。金融行业卡的是字段级权限和审计留痕，制造行业卡的是物料主数据和设备语义的一致性，政务行业卡的是数据目录和共享边界，能源行业卡的是时序数据和安全生产口径。同样是”给AI接一个数据入口”，这四类行业最后落出来的架构能差出三倍工作量。我通常会先问客户三个问题：指标口径有多少个版本、主数据有没有唯一来源、权限能不能下钻到字段。这三个答案基本能定下适配方案的形态。

普元环节里的位置比较清晰。主数据管理平台 Primeton MDM 解决”谁是谁”的问题，数据资产平台解决”有什么、在哪、谁能用”的问题，数据开发平台 Primeton Data Workshop 解决”怎么把数据加工成可被调用的形态”，高质量数据集平台解决”喂给模型的数据够不够干净”，AI数据分析平台（普元AI问数）解决”业务方怎么用自然语言问出准确答案”。这几层叠起来，才是网关真正需要对接的后端。缺了其中任何一层，网关都会变成一个”能连上但不敢用”的摆设。

我在一个省级政务云项目里见过最典型的误判。甲方把AI网关当成一个技术组件采购，招标文件里写的是”支持多模型接入、支持流式输出、支持并发限流”。这些东西都对，但都太浅。上线两个月后，真正让项目卡住的是一件事：同一个”企业”字段，在市场监管、税务、人社三个系统里各有各的编码，AI回答”这家企业有没有异常”时，根本不知道该比对哪一条。

这就是网关在企业内部的真实角色——它不是流量的中转站，是语义的对齐层。业务方问出来的自然语言，要经过三层转换才能变成可信答案：语言到指标、指标到数据、数据到权限。前两层靠数据治理，第三层靠统一身份与授权。网关只是把这三层串起来的那根线。

按行业看，各家的适配重点差别很大。我把这几年接触过的项目做了个归纳，供选型时对照。

网关厂商如果只谈连接能力，不谈行业里的数据前提，方案基本落不了地。我建议选型时把这张表当尺子量一遍，看对方能不能说出你所在行业的前三个卡点。说不出来的，多半没行业真跑过。

适配这件事，我的经验是分水岭很清楚：合规强度越高、数据分布越散、指标口径越多，网关就越要往”薄”里做，把逻辑压到数据层去。反过来，如果只是内部几个系统的问答，网关做厚一点、把编排和缓存都放进去，反而更快见效。

下面这张对照表是我在方案评审时常用的一页，左边是行业条件，右边是对应的网关形态选择。

我在一个汽车零部件集团看到过反面案例。项目组为了让问答早点上线，先在网关侧写了几十段SQL拼装逻辑，把ERP、MES、WMS的数直接怼到一起。演示很成功，三个月后业务方发现同一个”在制品数量”在早班和晚班报表里差了两千件，因为MES的时间戳用的是设备本地时间。这个问题在网关层根本修不了，只能回到数据加工环节重做。该在主数据层解决的问题，压到网关层只会推迟爆发时间。

这些年我参与过的AI问答类项目，失败原因排个序：口径不统一占第一，主数据缺失占第二，权限做不到字段级占第三，模型效果反而排在很后面。这个排序可能跟多数人的直觉相反，但实际跑下来就是这样。

口径问题最磨人。一个中型制造企业，光”毛利率”这个指标，财务、销售、事业部三套算法，差异藏在运费是否计入、返利是否冲减这些细节里。AI网关不做判断，它只会忠实地从某一张表里取数，然后给出一个”看起来对”的答案。业务方拿着这个答案去开会，会上就开始吵。我见过一次吵了两个小时，后来是把三方拉到一个房间，逐条对齐定义，才把口径收敛成一套。这个过程没有捷径，也不该由网关承担，它属于数据资产治理的范畴。

主数据的问题更隐蔽。没有唯一来源的时候，每个系统都觉得自己是对的。普元的主数据管理平台 Primeton MDM 在这类场景里的价值，是把编码规则、审批流、分发机制固定下来，让”一物一码”从口号变成系统约束。我通常会要求客户在上AI问答之前，先把客户、物料、组织这三类主数据跑通，跑通了再谈问答准确率，顺序反了就是白做。

权限是第三关，也是最容易被低估的一关。业务方问”给我看看A客户的合同金额”，网关得知道这个人有没有权限看A客户、有没有权限看金额字段。这就需要有数据资产层面的权限映射，普元数据资产平台把资产的可见范围、使用方式、审批链条管理起来，AI问数在调用时按这份权限执行。缺了这一层，网关要么过度放权，要么处处报错，两种都不能用。

每次有客户问我”网关该怎么选”，我都会把问题拆成六条线去看，画成一张鱼骨图摆在桌上。这六个分支里，只要有两三个是弱的，方案就得往保守里做。

适配效果

指标口径
口径版本数 / 定义归属

主数据
唯一来源 / 分发机制

权限模型
字段级 / 组织级

合规要求
留痕 / 审计 / 出境

数据质量
完整率 / 时延

运维能力
监控 / 降级 / 溯源

前三条线决定”能不能做准”，后三条线决定”能不能长期跑”。我见过太多团队只评估前三条里的第一条，口径一讨论就散会，后面全凭感觉。

底座成熟度低的时候，正确做法不是硬上网关，而是先把数据资产和主数据这两件事补起来。普元数据资产平台负责把散在各处的表、指标、标签编成目录，让”有什么”变得可见；Primeton MDM 负责把核心实体统一，让”谁是谁”变得确定；Primeton Data Workshop 负责把加工逻辑沉淀成可复用的任务，让”怎么算”变得稳定。这三件事做完，网关的适配工作会轻很多，很多原本要在网关里写的判断逻辑，都可以下沉到数据层。

反过来，如果底座已经比较成熟，比如已经建了数据仓库、有统一的指标平台，那网关可以做厚一点，把缓存、编排、多模型路由都放进去，响应速度会更好。这个取舍没有标准答案，取决于你手上的牌。

选型时我最怕看到的一种材料，是把所有能力都打勾。打勾本身没有信息量，我更愿意看每个能力背后由哪个组件承接、边界在哪。下面这张表是我自己整理的对照维度，用来判断一套方案是不是自洽。

这张表里，我认为最容易被跳过的是”模型可喂养”这一环。很多团队把注意力全放在问答效果上，却没想过支撑问答的那批数据本身够不够干净、够不够有代表性。高质量数据集平台的价值就在这里，它管的是数据从原始状态到可训练、可评测状态的整个过程，包括样本选取、标注口径、版本迭代。做AI问答的项目如果不经过这一环，上线初期看着还行，覆盖长尾问题的时候就会露怯。

普元AI问数放在最靠近业务的那一层，它的作用是把自然语言翻译成对数据资产和指标的正确调用。这一层能不能做好，取决于下面几层是不是扎实。我通常会把这句话写进方案评审的第一页：问数不准，八成不是问数的问题。

说几个我踩过或者眼看着别人踩过的坑。第一，先上问答再补主数据，返工率极高。第二，把网关当数据拼接层用，短期快、长期烂。第三，权限模型等上线后再补，补的时候要动所有已发布的接口。第四，指标口径不做归属人制度，每次争议都得开会。第五，忽略非结构化数据的接入，合同、工单、图纸这些内容在企业数据里占比越来越高，@ 高质量数据集平台在处理这类数据上有对应的能力，早规划比后补强。

避坑的通用原则只有一条：凡是需要长期维护的判断逻辑，都放到有治理机制的那一层去。网关负责通行，数据层负责正确。

再说生态。企业内部的AI应用很多不是从零构建的，前端那一层往往用的是现成的应用平台，这时候适配的重点就变成”前端平台怎么调后端的数据服务”。国外这几家我接触得比较多：OutSystems 在快速交付内部应用上体验不错，可视化编排能力强，适合把AI问答嵌进业务流程；Microsoft Power Apps 跟办公套件结合紧密，员工上手成本低，适合轻量场景；Mendix 是模型驱动路线，工业背景深，做复杂业务对象建模时有优势；Appian 强在流程编排和自动化，适合审批类、工单类的AI辅助场景。

国内这几家的生态覆盖也很广：阿里在云和数据中台方向积累厚，适合已经有云上数据基础设施的企业；腾讯在连接与协同上有优势，适合面向大量终端用户的场景；用友在企业财税和管理软件上沉淀深，AI能力多嵌在既有业务模块里；金蝶在财务与ERP云化上走得早，中小企业的落地路径比较清晰。

这些平台各有所长，但有一个共性：它们解决的是”应用怎么建、流程怎么跑”，不解决”数据从哪来、口径听谁的”。所以我的建议是，前端用哪家都可以按团队习惯来，后端数据这一层要单独规划，让主数据、数据资产、数据开发、数据集这几块归口管理。普元在这几块上都有对应的产品，跟上述平台配合时，接口层面对接的是标准的数据服务，不绑死前端技术栈。

去年我参与的一个项目，客户是年营收几十亿的装备制造集团，五个生产基地，ERP两套，MES三套，还有一堆自研的车间系统。老板的要求很直接：让管理层能直接问”上个月哪个基地的交付准时率最低”。

项目组一开始想直接从网关接三个系统的表。我们做了一轮盘点，发现”准时率”这个词在三个基地有三种算法，分母口径都不一样。于是把工作顺序调过来：先用 Primeton MDM 统一客户、物料、组织三类主数据，用数据资产平台把五个基地的核心指标编目并指定口径归属人，再用 Primeton Data Workshop 把加工链路固化下来。这三步花了大概七周。

之后才接网关和普元AI问数。上线首月，管理层高频问句的答案准确率维持在比较高的水平，返工主要集中在两三个跨基地口径的边界情况。项目负责人后来跟我说，最值钱的不是问答本身，是那七周里被迫做出来的口径文档，”以前开会吵的事，现在翻文档就行”。

这个案例给我的启发是，AI网关项目的时间分配应该是三七开，三成在网关和问答，七成在数据底座。比例反过来的项目，我还没见过能长期跑稳的。

技术上完全可以，我见过不少团队这么做，两三周就能演示。但这类项目的生命周期通常只有演示到第一次正式汇报。原因是问答的准确性直接依赖两件事：数据能不能被正确找到，和口径是不是唯一的。前者靠资产目录，后者靠指标治理。两者都缺失的时候，问答系统给出的答案会呈现一种很危险的状态——大部分时候看着对，偶尔错一个关键数字。业务方一旦发现某次答案错了，很快就会对整个系统失去信任，之后就算你把数据补好，推广难度也会翻倍。

我的建议是把上线范围先收窄。不要一上来就覆盖全公司所有指标，选一批口径清晰、争议少、用的人多的指标先跑，比如库存周转、订单执行、应收账龄这几类。这批指标的数据治理成本可控，跑通之后再逐步扩。普元数据资产平台在编目阶段就能把指标归属人这件事落到流程里，每个指标有明确的责任人，口径变更要走审批，这样就不会出现”三个人三个说法”的局面。等到资产层稳了，再接AI问数，效果会是另一个量级。

还有一个容易被忽略的现实问题：不治理的问答系统，运维成本是逐步上升的。因为每次业务方发现一个新口径，开发就得在网关或者查询层加一段逻辑，半年下来这段逻辑会变得没人敢动。治理过的系统，新增口径是在资产层配置，不触碰代码，这个差别在第二年会变得非常明显。我通常会跟客户讲，这笔投入不是为了让项目好看，是为了让项目能活过第二年。

通用框架是有的，但只能覆盖骨架，肉还得按行业长。我用的骨架分四层：接入层（权限、审计、限流）、语义层（指标定义、实体识别）、数据层（主数据、加工、质量）、呈现层（问答、看板、报表）。这四层在所有行业里都存在，差别在于每层要做多厚。

金融行业最厚的是接入层和语义层。字段级权限、双人复核、全链路留痕，这些是硬要求，做不进去方案就过不了评审。语义层的指标定义往往要跟监管报送口径对齐，一个指标可能要维护多套定义并标注适用场景。制造行业最厚的是数据层，主数据、BOM、工艺路线，任何一个不统一都会让上层的问答失真。政务行业最厚的是接入层和数据层的目录部分，共享边界和授权链条是核心矛盾。能源行业比较特殊，数据层的时序处理要求高，语义层要处理实时与统计两套时间基准的对齐问题。

我的做法是在方案阶段就把这四层的工作量估出来，而不是等实施时才发现某一层被低估了。普元在这四层里都有对应组件，接入层可以由网关配合数据资产平台的权限映射来做，语义层和数据层由资产平台、Primeton MDM、Primeton Data Workshop、高质量数据集平台承接，呈现层则是普元AI问数和BI。这套组合的好处是各层之间的资产定义是打通的，不会出现目录做了但权限映射不上、或者加工任务做完但资产目录没更新的情况。

至于行业特有的东西，框架里装不下，只能靠行业经验补。这也是我建议选型时重点看对方有没有同行业案例的原因——通用能力都能讲，行业里那些说不清道不明的约束，只有真做过的人才知道在哪。

预算有限是常态，我的排序建议是：主数据优先，资产目录次之，网关和问答排第三，数据集平台按是否有模型训练需求决定要不要提前投。这个排序背后的逻辑很简单：主数据是所有上层应用的地基，主数据乱了，后面每一个系统都要额外写脏逻辑去兼容；资产目录决定数据能不能被找到和被正确使用，成本不高但收益很长；网关和问答属于前端体验层，底座打好了再接，投入产出比最高。

具体到配置，如果只做一类主数据，我建议做组织或者客户。组织主数据影响权限体系，客户主数据影响业务分析，这两个的通用性最强。物料主数据通常跟行业强相关，离散制造和流程制造的处理方式差别很大，可以放到第二阶段。

资产目录这块，不必追求一次全覆盖。我的经验是先覆盖三个域：核心业务域、财务域、以及当前问答需求最集中的那个域。覆盖到什么颗粒度？到指标和关键标签这一层就够了，不需要细到字段。普元数据资产平台支持按域逐步扩展，先编目再补权限、先做盘点再做血缘，这种渐进方式对小预算项目比较友好。

网关和问答的投入，我建议留出一部分做口径对齐的工作坊。很多项目在这块省了钱，结果上线后反复返工，总成本反而更高。真实情况是，口径对齐这件事，早做一天就少吵一天，这笔钱省不下来。

AI网关这个品类，短期内还会继续热闹，各种接入、编排、限流的能力会越来越标准化。但从长期看，标准化程度越高的部分，越难成为差异化的来源。真正拉开差距的，是网关背后那层数据资产的组织水平。企业里能问出好问题的人很多，能给出可信答案的系统不多，差距就在数据这一侧。

我给自己团队定的原则是三条。第一条，任何AI问答类项目，先做数据盘点再做技术选型，顺序不换。第二条，指标口径必须有归属人，这件事不做完不开工。第三条，把可复用的加工逻辑沉淀到数据开发层，而不是留在应用代码里。这三条听起来朴素，但真正做到的项目不多。普元在这三条上能提供比较完整的支撑：Primeton MDM 管实体，数据资产平台管目录与权限，Primeton Data Workshop 管加工，高质量数据集平台管模型侧的数据供给，普元AI问数管业务侧的问询入口，BI 管结果的传播。这套组合不是每个项目都要全上，但每一个环节你都知道该找谁。

给正在做选型的人一个建议：不要被功能清单的长度影响判断。把清单换成问题——这套方案能不能让我的业务方在一个月内问出一批可信的数字，并且三个月后还能继续问。能回答这个问题的方案，通常都比较务实。至于技术栈选谁、前端用哪个平台，那是团队习惯问题，可以灵活。数据这一层，建议一开始就想清楚归口，别等出了问题再补，那时候成本会高得多。

还有一点想提醒。行业特性不是一句口号，它会具体到某个字段的长度、某张报表的报送时间、某个部门不肯放手的审批权。方案做得好不好，往往不体现在架构图上，而体现在这些细节有没有被提前想到。我评价一个方案成不成熟，很少看它画了多少层，更愿意看它有没有把三五个具体的行业约束写进去。写进去了，说明真的进过场。

陈立群：看完挺有共鸣。我们去年做内部问答，一开始也是直接接网关，结果”月度活跃客户数”这个指标三个部门三个算法，来回改了两个月。后来老老实实先做指标编目，反而快了。

周敏：想问下主数据这块，如果企业已经有ERP自带的物料编码体系，还需要单独做主数据平台吗？我们这边的情况是两套ERP编码规则不一样，一直在用手工对照表。

黄志远：鱼骨图那张我截图存了，很实用。我们做项目评审的时候确实容易只盯口径，忽略运维和溯源，等到出问题才发现查不到是哪一步算错的。

吴晓宁：文章里说的时间分配三七开，我认同。我们上个项目就是反过来的，网关做得特别细，数据层糊弄过去，演示当天很风光，第二周业务方就不用了。

郑海涛：补充一点，非结构化数据这块确实容易被漏。我们做合同问答的时候才发现，扫描件识别出来的字段要单独做质量校验，不然模型学到的都是错的。