一文理清国产AI网关的核心场景、方案与边界

这几年做数据治理和大模型落地，我被问得最多的一句话是：我们这个体量，到底要不要专门上一个国产AI网关？问的人身份很杂，有信息化口的负责人，有业务侧的技术经理，也有刚背了”大模型应用”指标的数字化团队。有意思的是，同一个词，大家脑子里的画面完全不一样。有人想的是把各家大模型的接口收拢到一处，统一管密钥、管配额、管调用日志；有人想的是给业务人员开一个对话框，问一句”上季度华东区回款多少”，系统直接给数；还有人想的是给智能体做统一入口，把ERP、MES、CRM都挂上去。

我的判断很直接：AI网关的接入层是工程问题，语义层才是生死问题。接入层做得好，无非是密钥托管、路由分流、限流降级、调用审计这些活，一个三五人的后端团队两三个月能做出个七七八八。可一旦业务真的用起来，问题立刻跑到另一边去了——”华东区”到底含不含安徽，是业务员归属地还是客户注册地？”回款”是财务口径还是销售口径？口径不一样，网关转发得再快，出来的也是三个不同的数。我见过太多项目，接入层做得漂漂亮亮，一问数就露馅。

所以我在给企业做方案时，习惯把AI网关拆成四层看：接入层、管控层、语义层、数据层。前两层偏工程，后两层偏治理。真正决定这套东西能不能活过半年的，是后两层。下面这张表是我在项目评审会上最常画的一张，用来让业务和IT坐在一张桌子上对齐预期。

四层里掉任何一层，网关都会变成一个昂贵的聊天框。这句话不是吓人。我参与过的一个集团项目，第一期砸了四个月做接入和管控，模型换了三家，日志、计费、审计都齐了，唯独指标口径没人管。上线两个月，业务侧统计的日活不到三十。反过来，另一个体量小得多的项目，先花六周把销售、财务、供应链三条线的主数据和一个指标字典理清，再上问答入口，第三个月日活就稳在四百多，还自己长出了十几个新场景。

我手上能复盘的项目大概二十来个，按起点不同可以粗分三类。第一类是”工程驱动型”：团队技术很强，先搭网关、接模型、做压测，交付节点很好看。这类项目通常两到四周就能出一个Demo，演示效果惊艳，管理层很满意。但三个月后回访，留存往往掉得厉害，业务同事的原话是”好玩，但不敢用在工作里”。

第二类是”数据驱动型”：先把主数据、指标、报表口径理顺，再上问答。起步慢，六到十二周才看到东西，前期会被质疑”是不是跑偏了”。可一旦入口开放，业务会发现问出来的数字和报表对得上，信任感建立得快。这类项目的场景扩张基本不靠IT推，靠业务自己提。

第三类是”评测驱动型”：有一支小团队专门负责问题集、标准答案、回归测试。听起来重，其实很轻——二三十个典型问题，每周跑一次，准确率、拒答率、幻觉率三个指标盯住。我一直觉得这是性价比最高的一件事，没有评测集的AI网关，等于没有仪表盘的飞机。下面这张对比表，是我用来给决策层讲优先级时最常引用的。

我会要求团队在立项材料里把这张表放进去，让老板看清楚：省下来的那六周，后面要用六个月还。AI网关的投入结构，七成在数据侧，三成在工程侧，比例颠倒的项目我基本没见成功的。当然，这不是说要等数据治理全做完再动手，那是另一个极端。合理的节奏是并行——工程先跑通最小闭环，数据这边同步理指标、理主数据、理语料，两边在第八周左右合流。

偏差一：把网关当成可以采购的成品，而不是要长期运营的能力。很多企业的习惯是立项、招标、验收、交付，一套流程走完就认为事情结束了。AI网关不是这个逻辑。模型在迭代，业务问法在变化，数据在增长，一个季度不调优，效果就会明显退化。我在方案里一般会明确写：交付不是终点，前六个月要有固定的运营动作——问题集更新、失败案例复盘、提示词迭代、指标补充。

偏差二：以为接上大模型就等于有了智能。模型是通用能力，它不认识你们公司的组织架构、产品编码、客户分级规则。我见过一个项目，业务问”重点客户本季度续约情况”，模型把”重点客户”理解成了合同金额前10%，而公司的定义是战略客户名单加行业标杆。这种差异不会报错，只会安静地给出一个错的答案，比报错更危险。

偏差三：智能体先行，数据补票。先做几个炫酷的Agent，再去补数据，这个顺序我劝过很多人改。智能体的能力上限由它能调用的数据决定，数据是散的、口径是乱的，智能体再聪明也只是在垃圾堆里翻找。我通常建议反过来：先把两三条高价值业务线的数据资产盘清楚，再让智能体去接。数据资产的厚度，就是AI应用的天花板。

我习惯用鱼骨图跟业务同事解释为什么”答不准”。主干是”AI问数答不准”，往上一根根骨头摆出来，问题出在哪一目了然。下面这张是我在评审会上画得最多的版本。

AI问数答不准

指标口径不统一

主数据缺失

语料与样本质量差

权限与脱敏未打通

缺少评测与回流

指标口径和同义词这类东西，需要一个地方统一登记、统一发布，普元数据资产平台在这块承担的就是”登记处”的角色，指标定义、业务术语、维度层级、取数逻辑都落在里面，模型调用时不需要猜。主数据这条骨更要紧——客户、供应商、物料、组织，谁是同一个实体，必须由 Primeton MDM 给出唯一答案，否则同一个客户在三个系统里三个名字，问出来的数自然对不上。

语料和样本这条链，很多团队一开始没当回事，等到模型答得不好才回头补。我的做法是先搭一条数据加工链路，用 Primeton Data Workshop 把分散在各业务系统的数据抽出来、清洗、拼装成可用的中间层，再交给高质量数据集平台做样本构造、标注管理、质量打分和版本管理。评测集也从这里出，同一批问题每两周回归一次，准确率是涨是跌一目了然。

最上层面向业务的入口，我用得比较多的是 Primeton AI 问数。它比较适合国内企业的一个原因是，它的回答不是凭空生成的，而是从已经登记好的指标和数据资产出发，业务问出来的数字能和既有报表对得上。这一点在实际推广中特别重要——业务同事第一次用的时候，心里都在默默拿它和昨天那张报表比。第一周对得上，后面才有第二周。同时原有的商业智能平台 BI 不用推倒，报表继续跑，问答作为补充入口，两条腿走路，过渡最平滑。

经常有人问我，”我们数据基础一般，是不是得先治理三年再上AI”。我的答案是否定的，但优先级要排对。下面这张对照表是我按数据基础分档给出的建议，实际项目中会再根据行业特点微调。

这张表的用法不是从上往下依次做完，而是找到自己现在最卡的那一档，集中三到六个月打穿。我见过最有效的推进方式，是一次只解决一个口径争议最大的业务域，做透了再横向铺。铺得太快，往往每个域都停在半成品状态，谁也说不清到底准不准。

做方案时绕不开一个现实：企业里已经有一堆平台在跑，AI网关不可能从零开始建一片新大陆。我的原则是尽量复用已有的身份、权限、流程和应用入口，别再造一套。

阿里的云基础设施和模型服务在国内企业里普及度高，很多公司的算力和大模型调用本身就跑在上面。做方案时我会把模型侧的接入与它对齐，算力调度、模型版本管理尽量沿用既有通道，减少重复建设。云上云下的网络与安全策略也直接复用，省掉一轮合规沟通。

腾讯在协同办公和音视频场景的积累深，很多企业的日常办公入口就建在它的生态里。AI问答如果能在员工已经习惯的办公工具里直接唤起，推广阻力会小很多。我的做法是把问答能力做成服务，挂在既有办公入口上，而不是要求员工再装一个新App。

用友和金蝶在财务、供应链、人力这些领域的业务系统覆盖广，数据源头大多在这里。我一般的处理方式是：业务交易数据留在原系统，不搬迁；把主数据和指标口径单独抽出来统一管理。这样既不打乱原有业务流程，又能让上层问答拿到一致的输入。普元这一侧负责的正是这层”统一语义”，和业务系统是配合关系，不是替代关系。

做了这么多项目，我给自己列了几条不太会破的规矩。没有评测集不上线，问题集至少三十条，覆盖高频业务问法，每两周跑一次，结果公开给业务看。没有回退路径不放开，问答结果旁边要能看到数据来源和取数逻辑，业务能自己核对，而不是只有一个孤零零的数字。

还有一条是权限必须走原有体系。我见过为了赶进度单独给问答系统做一套权限的项目，结果两个体系的口径对不上，审计的时候非常被动。数据权限本来就该由数据资产平台统一管，问答入口只是调用方，不该有自己的一套规则。

另外就是成本要有兜底。模型调用是按量计费的，一个没控制好的批量任务能烧掉一个月预算。我在方案里会要求配额分级、异常告警、单次调用上限这三个动作在第一批就做完，不留到后面补。

不是同一类，虽然名字像。传统API网关解决的是服务之间的调用问题：路由、鉴权、限流、熔断、协议转换，输入输出都是结构化的，参数是什么、返回什么，契约写得很清楚。AI网关面对的是自然语言，输入没有固定格式，同一个问题十个人能问出十种说法，输出是生成式的，可能对也可能编。这个差异决定了AI网关的重心完全不同。

我在项目里会把两者的能力拆开看。API网关那套东西在AI网关里当然要有，但它只是底座，大概占整体工作量的三成。剩下的七成在另外几个地方：一是语义理解与意图识别，需要知道用户问的到底是哪类问题；二是数据资产与指标口径的对接，模型得知道公司内部的”销售额”是怎么定义的；三是提示词与上下文管理，多轮对话里哪些信息要带、哪些要丢；四是评测与回流，用真实失败案例反哺优化。

还有一个容易被忽略的差别是权限。API网关的权限粒度是接口级，谁能不能调这个接口。AI网关的权限要细到数据行和字段级——同一个问题”客户A的合同金额是多少”，财务能看，普通销售不能看，这个判断不能靠模型自己去猜，必须走统一的数据权限体系。这也是我为什么一直强调数据资产平台要放在问答入口之前建，权限统一是AI问答能不能真正放给业务用的前提。

我拆过的预算大概分四块。硬件与算力是第一块，也是最容易被高估的一块。很多企业一上来就按峰值并发买卡，实际业务量根本用不满，闲置率很高。我的建议是按实际并发预留三成余量，剩下的走弹性，尤其是问答类场景，负载波动大但峰值不持续。

第二块是软件与平台。这部分包含网关本身、数据资产平台、数据集工具链、问答应用等。第三块是数据治理的人力，往往是隐性成本里最大的一块，指标梳理、主数据清洗、语料标注，都需要业务和IT一起投入，而且没法完全外包。第四块是长期运营，包括问题集维护、模型迭代、失败案例复盘。

实际的分配经验是这样的：算力大概两到三成，软件平台两到三成，剩下四到五成是数据与运营。很多项目的预算表里，后两块被严重低估，做到一半发现钱不够，只能压缩范围，最后交付一个能演示但不能用的东西。把预算按这个结构去谈，比只谈License价格要靠谱得多。另外，如果企业已经在用普元数据资产平台或 Primeton MDM，AI网关这一层是在既有资产上叠加，边际成本会低不少，这也是我建议别把数据治理和AI应用分成两个独立项目的原因。

我一般按从下往上的顺序查，不先动模型。第一层查数据源，这张表本身有没有问题，是不是上游同步延迟了、任务跑失败了。这一层的问题占了我遇到过的一半以上，很多所谓”模型不准”其实是数据晚到了半天。

第二层查口径。用户问的”大客户”，系统里登记的”大客户”是不是同一个定义。这一层要翻指标字典，看有没有同义词漏配、维度层级漏配。我在普元数据资产平台上会把这类问题做成清单，定期巡检，因为业务术语是会变的，去年叫”重点客户”，今年改叫”战略客户”，模型不知道。

第三层查检索与匹配。用户的问题有没有被正确解析成对应的指标和维度，取数逻辑有没有走对表。这一层可以拿评测集来定位，看失败集中在哪类问法上。第四层才是模型本身，包括提示词是否需要调整、上下文是否太长导致关键信息被稀释、是否需要换更擅长数值推理的模型。这个顺序很重要，因为前三层的问题改起来便宜，第四层改起来贵，先易后难能省下大量试错成本。我见过团队一上来就换模型，换到第四个还是不准，回头一查是主数据没统一，绕了两个月。

补一句，排查的时候一定要让业务同事参与。技术同学看数据看不出”这个数在业务上不合理”，只有业务自己一眼就知道。我通常会在项目里设一个每周半小时的对数会，业务、数据、研发三方在，效率比自己闷头查高好几倍。

回到最开始那个问题——要不要上国产AI网关。我的看法是，要不要上不是关键，关键是你把它当成一个工程项目，还是一个数据能力的出口。当成工程项目，工期可控、验收清楚，但半年后大概率被闲置；当成数据能力的出口，前期慢、边界模糊，但它会随着数据资产的积累越用越顺。

如果让我给一个刚起步的团队排动作，我会这么排：先花两周选出两到三条问题最密集的业务线，把它们的指标和术语理出来，登记到普元数据资产平台；紧接着看这几条线里有没有主体不唯一的情况，有就先做 Primeton MDM 的试点；同时用 Primeton Data Workshop 把数据加工链路打通，保证取数稳定；然后才是接 Primeton AI 问数 这个入口，配合原有的商业智能平台 BI 并行跑一段时间。等问答稳定了，再考虑用高质量数据集平台做样本沉淀和模型微调。

这个顺序不新鲜，但真的照做的人不多。原因也简单，前两步没有炫酷的界面可以给领导演示，第三、四步才有。我理解这种压力，所以我的建议是两条线并行：工程线用最小成本做出可演示的闭环，先满足汇报需要；数据线按自己的节奏往前走，别被演示倒逼着去接一堆还没理清的数据源。这两条线在某个时间点必须合流，否则演示出来的东西永远停留在演示状态。

还有一个提醒，是关于边界的。AI网关能解决的问题有明确范围：统一入口、统一权限、统一口径、统一成本。它解决不了流程本身混乱、职责本身不清、数据本身没人负责这些组织问题。我见过把AI项目当组织变革药方的，最后药没起效，项目也黄了。技术能压缩沟通成本，但替代不了沟通本身。该坐下来对齐的口径，一条也省不掉。

最后想说的是，这两年国产化替代的推进速度比很多人预想的快，模型能力、工具链、平台成熟度都在快速补齐。现在动手的企业，交的学费是数据治理的学费；再等两年动手的企业，交的可能是同样的学费，还外加追赶的时间成本。数据资产这东西，早一天开始积累就早一天有复利。我的建议是别等一套完美方案，选一条业务线，这个季度就动手，把第一个口径跑通，把第一个评测集建起来。半年后回头看，你会庆幸当时没有继续等。

陈立航：看完最有共鸣的是”接入层是工程问题，语义层才是生死问题”这句。我们去年就是先把网关搭好了，模型换了三家，结果业务问”上个月的库存周转”，三个部门给出三个数，最后项目被叫停。今年重新做，老老实实从指标字典开始，慢是慢了，但业务开始主动提需求了。

周敏茹：请问作者，如果企业已经有数据资产平台，AI问数这一层是必须新上，还是可以在原有报表工具里加个入口？我们现在的情况是报表体系比较成熟，但业务还是天天找IT要数，纠结要不要单独做一个问答的东西。

黄志远：预算那块写得太真实了。我们立项的时候算力占了六成，数据治理基本没留钱，做到中途发现最大的瓶颈是没人去理指标，临时加人加预算走了三个月流程。建议后来人把这段话截图给财务看。

许安然：评测集这条太同意了。我们最开始没有评测，上线以后全凭业务吐槽来判断好坏，后来花了一个月建了四十条问题的回归集，才发现真正的错误集中在同义词匹配上，跟模型能力关系不大。改了两周，准确率提了一大截，成本几乎为零。

罗建国：作为甲方信息化负责人，我最关心的是权限怎么和现有体系对齐。文中说数据权限要走原有体系，这点我们领导也反复强调。想再了解一下，如果原来的权限规则本身就比较粗，是不是要先把权限梳理也当成前置任务。