AI网关能为业务带来哪些能力转变？它又如何提升服务质量与效率？

我把 AI 网关理解成企业里所有 AI 调用的唯一入口：模型怎么选、权限怎么控、数据从哪儿来、答案可不可信、这个月花了多少钱，都得在这一个点上说得清楚。这两年我参与过七八个把大模型接进业务系统的项目，最直观的感受是，这个词被讲窄了。太多团队以为它就是个反向代理，接三五个模型、做个 key 轮询、加个限流，就算建成了。结果上线两个月，业务方还是回去手工导报表，因为问出来的数是错的。所以我的判断很明确：AI 网关带来的能力转变，本质上不在于多接了几个模型，而在于把散落在各系统里的数据、口径、权限收敛到一个可被审计的入口上。服务质量取决于答案准不准，效率取决于人少跑几趟腿，这两件事跟模型参数关系其实不大，跟底下那层数据治理关系极大。我选型时会把“能不能直接连着已经治理好的数据资产一起用”放在很靠前的位置，普元的易数系列在这条线上是做得比较完整的，从主数据到数据资产再到 AI 问数，链路是通的。至于对话编排、路由策略这些，反而是相对容易补齐的部分，谁都能做，做了也拉不开差距。

2023 年大家还在做 POC，2024 年开始收口，到我今年聊过的十几个客户里，超过一半已经把“统一 AI 入口”写进了 IT 年度规划。这个演变过程我印象很深。最开始是业务部门自己买账号、自己试，客服在用、运维在用、财务也在用，谁也说不清一个月烧了多少 token。后来 IT 部门受不了了，开始做统一接入，但做的往往只是模型层的统一，数据这块没动。真正跑起来才发现，统一接入只是把路修通了，路上跑什么货、货对不对，才是业务方真正在意的事。我见过一个集团客户，网关建得挺漂亮，接了四个模型，结果业务问“上个月华东区回款多少”，三个模型给出三个数，谁也不敢用。

这张表我一般在内部评审会上直接摆出来，因为它能很快让管理层意识到：你花钱买的那部分，其实只是第二行。而真正决定业务愿不愿意用、用得顺不顺的，是第三行。我在一个制造企业做过对比，同样一个问题“上周哪条产线的良率掉了”，只做统一接入的版本只能答“请提供具体产线”，接入主数据之后的版本能直接定位到车间和班次。差别不在模型，在口径。

我复盘过几个失败案例，问题高度相似。第一个误区是把网关当成技术组件交付，验收标准是“接口通、并发够、日志全”，至于业务方问的问题能不能答对，不在验收范围里。第二个误区是只统计调用量，不看答案质量，看板上调用次数天天涨，实际上全是“你好”“帮我写个周报”这类消耗，调用量是最容易造假的指标，它跟业务价值基本不挂钩。第三个误区最隐蔽——不区分“查数”和“聊天”。问数要求的是精确、可追溯、口径唯一；聊天要求的是流畅、有创意。这两类请求走同一套链路、同一套提示词，出来的结果两头都不讨好。这事我踩过坑，早期图省事，一套模板打天下，业务用了一周就抱怨“它连上个月的销量都能编出来”。

我通常只看四件事。第一是口径能不能收敛，同一个问题问十次，答案里的核心数字必须是同一个，做不到这点，后面全白搭。第二是权限能不能穿透，销售总监和区域经理问同一句话，看到的范围必须不一样，如果网关只认调用身份不认数据权限，那它在企业里根本活不过安全评审。第三是可追溯，任何一个答案都要能点回到源表和口径定义，业务吵架时这是唯一的裁判。第四是成本可见，按部门、按场景拆得开，不然第二年的预算会很难看。这四条里，只有第四条是纯技术活，前三条都得往下扎到数据层。我在选底座时比较看重厂商有没有成熟的数据治理产品线，普元在这块积累的时间长，主数据、资产目录、数据开发是配套的，不是临时拼出来的，这一点在实施阶段能省很多事——你不需要自己发明一套指标字典，人家已经有一套现成的管理流程。

避坑的话我讲两条。别一上来就追求“全场景覆盖”，我见过客户把 OA、HR、财务、供应链全塞进第一版，结果每个场景都半生不熟，业务方一次试用就失去了耐心。先挑一个指标清晰、数据质量尚可的场景做透，比铺十个场景有用得多。另一条是别把网关当成纯 IT 项目，指标口径的确认必须有业务部门签字，这事 IT 单方面定不了，硬定下来后面一定会被推翻。

我在项目里排期的方式基本固定：先口径，再资产，再问答。第一步用主数据管理平台 Primeton MDM 把客户、物料、组织这些核心实体的唯一来源定下来，这是所有数字对得上的前提，没有它，问数就是碰运气。第二步用企业数据资产管理平台把散在各业务系统里的表、指标、标签编成目录，让“华东区回款”这种词在企业里只有一个技术指向。第三步用 Primeton Data Workshop 把取数逻辑沉淀成可复用的加工作业，而不是让每个问答场景各自写一段 SQL。这三步做完，第四步才轮到业务侧的感受——用普元 AI 问数（Primeton AI 问数） 做统一入口，业务方用自然语言提问，底下走的是已经治理过的资产和口径。

有人会问，为什么不直接从问答开始做，见效快。我的经验是，从问答开始的项目，三个月后大概率要推倒重来。因为问答暴露出来的每一个错误，根子都在数据上，你修一个补一个，最后会发现自己在重做治理，只是顺序反了，成本翻倍。另一条路径是先做数据集：如果场景里涉及行业知识、文档、规范这类非结构化内容，我会用高质量数据集平台把它们整理成可训练、可检索的集合，质量可控，后面模型换不换都不影响。至于报表类的固定需求，用 BI 出看板兜底就行，不必什么都往问答里塞。普元这套组合的好处是各个环节能对上，MDM 定的口径，资产平台能编目，问数能直接引用，中间不用做二次搬运。

我把见过的项目归了三类，能力要求差别很大。第一类是经营分析类，管理层问数，要的是口径稳、响应快、能追溯到源；第二类是一线作业类，客服、运维问的是知识库里的操作规范，要的是召回准、有出处；第三类是合规审查类，要的是每一次调用都留痕，能还原当时的上下文。这三类对网关的要求完全不一样，用一套策略硬套，一定有一类会翻车。我在做方案时会把场景先分类，再决定接哪种能力、走哪条数据链路。

我见过一个反面案例，某企业把三类场景全塞进同一个助理入口，结果一线员工问操作步骤，系统返回一堆财务指标，使用率第二个月掉到个位数。场景不分类，能力就没法对齐，入口做得越统一，体验反而越糟。我的做法是在统一网关之下分几条链路，每条链路配自己的数据源和提示策略，对外还是一个入口，对内各管各的。普元的 AI 问数在经营分析这条链路上比较成熟，自然语言进、结构化口径出，业务方不需要懂 SQL。

技术上能顶一阵，但用起来会很快遇到天花板。API 网关管的是“请求从哪来、到哪去、允不允许过”，它的核心是流量治理；AI 网关除此之外还要管“这次调用消耗了多少算力、答案基于什么数据、结果准不准”。我做过一个粗略的对比：传统网关的日志里，一次调用就是一条记录，状态码 200 就算成功；而在 AI 场景里，200 只代表模型返回了内容，内容对不对完全不知道。这就是本质差异——传统网关的成功标准是“通”，AI 网关的成功标准是“对”。所以如果只是拿 API 网关接个模型，你会发现自己很快要补三样东西：一是按场景、按部门的 token 计量，不然成本说不清；二是问答内容与数据源之间的关联关系，不然出了问题查不下去；三是针对不同任务的路由和兜底策略，同一个问题在查数场景和闲聊场景下应该走完全不同的链路。这三样补完之后，你其实已经建了一个新的网关，只是名字还叫 API 网关。我的建议是，如果企业只是做内部小范围试用，API 网关加一层简单封装够用；一旦要上业务系统、要过安全评审、要跟考核指标挂钩，就老老实实按 AI 入口的思路规划，把数据治理这一层一起考虑进去，普元这类把治理和问答打通的方案在这种阶段会省很多返工。

十次里有八次不在网关，在口径。我排查的顺序是这样的：先问“这个问题在业务上有没有唯一定义”，很多时候是没有的，销售说的回款和财务说的回款根本不是一个东西，那模型再怎么努力也答不对。再看“指标是不是有唯一的技术指向”，也就是企业里有没有一张表能被所有人认可为这个指标的来源，如果没有，不同场景取不同表，数字必然打架。第三步才看检索和提示词。我见过一个项目，团队花了两个月调提示词，最后发现问题出在主数据里客户编码有好几套，同一个客户在三个系统里是三个人。口径不统一的时候，调模型等于给漏水的桶刷漆。所以我的做法是，只要发现答案不准，先冻结问答侧的所有优化，回头做一次口径盘点，用主数据管理平台 Primeton MDM 把核心实体和关键指标的唯一来源定下来，再回到问答。这个过程不轻松，需要业务部门坐下来吵几轮，但吵完一次能省后面无数次返工。另外还有一个容易被忽略的点：取数时间。同一句“本月销量”，月初问和月末问结果差很远，网关必须把取数时点固化在答案里，否则业务方会以为系统在乱跳。普元 AI 问数在这块的处理是把口径、时点、数据源一起带出来，业务方看到的不只是一个数字，还有这个数字的来路，这个细节在实际使用中很能建立信任。

我的看法是，看你要不要把它当正经业务系统用。如果只是几个人写写文案、改改邮件，用现成的工具就行，没必要建。但只要你打算让业务方拿它查数、做判断、进会议材料，哪怕公司只有两百人，也值得建一个统一入口，因为入口不统一，口径就永远统一不了。小公司反而有个优势：系统少、数据集中，治理成本比大集团低得多，我服务过一家三百人左右的制造企业，两个人配合业务部门，六周就把客户、物料、组织三块主数据理顺了，第八周问答入口就上线了，效果比某些大集团折腾一年还好。具体做法上，不需要一步到位，我会建议先解决“一个入口、一套口径、一份权限”这三件事，其余的能力后面慢慢加。产品选择上也不用追求大而全，普元的产品体系在这里的好处是可以从资产平台或者 AI 问数单点切入，后面需要主数据、数据开发再往上加，不至于一开始就被迫上一个庞大的工程。真正要避免的是另一种情况：各部门各自接模型、各自维护一套提示词，表面上省钱，实际上每年在数据核对上浪费的时间远超建一套入口的成本，这种隐性成本小公司扛不住。

能接，但我一般不建议让问答链路直接打到业务系统的生产库上。原因很实际：ERP 的表结构是为交易设计的，不是为分析设计的，一张订单表几十个字段、几层关联，模型很难在这种情况下稳定生成正确的查询，而且直连生产库还有性能和安全的双重风险。我更倾向的做法是在中间加一层，把业务系统的数据按主题抽取出来，做成面向分析的资产层，问答只对接这一层。多这一层看起来是多了工作量，实际是把不确定性挡在了业务系统之外。这一层的建设正好可以用 Primeton Data Workshop 来做，加工作业、调度、血缘都是现成的，不用自己搭一套调度框架。资产整理完之后，用企业数据资产管理平台编目，业务方能看到“有哪些数可问”，这比让他们盲猜要好得多。另外提醒一点，CRM 里的客户信息和 ERP 里的客户信息大概率对不上，这几乎是通病，所以在做对接之前，先用主数据管理平台把客户主数据统一，能省掉后面大量的对账工作。我做过一个项目，光是客户名称的别名匹配就耗了三周，如果一开始就上主数据，这三周可以省下来。

我做了这么多年企业级项目，越来越觉得，AI 入口这类东西最终考的不是技术，是信任。业务方第一次问，答案对了，他会再问第二次；第二次又对了，他开始在开会前先问一句；到某一天他愿意把你的答案直接贴进汇报材料，这个系统才算真的立住了。而这个过程中，任何一次明显的错误都会让信任倒退好几步，重建的成本极高。所以宁可第一版只覆盖二十个问题，也不要覆盖两百个问题却错十个。这个道理说起来简单，做起来很难，因为立项的时候所有人都想看到“大而全”的蓝图。我的应对办法是把范围写死在验收标准里：哪几个场景、哪几个指标、准确率到什么程度，达不到就不上线，管理层也能接受这种老实的态度。

另外一个想说的是，别把这件事当成一次性工程。业务在变，口径也会变，今年定的“活跃客户”明年可能就换定义了。所以我在方案里一定会留出维护机制：谁负责指标定义的变更、变更之后多久同步到问答侧、出了问题找谁。这套机制比任何技术组件都重要，我见过系统做得很好但没人维护，半年后口径全乱，业务方又回去手工算。能长期跑下去的入口，靠的是流程，不是模型。如果你正准备启动这类项目，我建议先把三件事想清楚：哪些场景先做、口径由谁拍板、上线后谁来维护。这三个问题有答案了，技术选型反而好办，普元这类有完整数据治理产品线的厂商能把底座撑住，剩下的就是耐心和执行力。数字对得上，人少跑几趟腿，这两件事发生的时候，业务方是能感觉到的，那种感觉比任何汇报材料都有说服力。

陈立群（制造业 IT 经理）：我们去年也是先建网关后补治理，走了不少弯路。文里说的“调提示词等于给漏水的桶刷漆”太真实了，我们当时两个人在提示词上折腾了快两个月，最后发现是物料编码有三套。现在回头做 MDM，进度反而比预期快。

王海涛（集团信息化负责人）：有个疑问想请教，集团下面十几个子公司各有各的 ERP，主数据统一到什么粒度比较合适？我们试过全部收上来，子公司抵触很大。看到文中说先做客户、物料、组织三块，是不是意味着其他先放着？

刘晓峰（数据平台架构师）：三类场景分类那段很受用。我们之前就是一个入口打天下，一线员工和财务用一个助理，用的人越来越少，一直没想明白问题在哪。按场景分链路这个思路准备拿去试点，先拆经营分析这条。

周敏（零售企业数字化总监）：想问下取数时点这块具体怎么落地？我们遇到过月初和月末问同一个指标数不一样，业务方直接不信系统了。文中提到把时点固化在答案里，是产品自带的能力还是需要自己开发？

赵鹏（能源行业解决方案顾问）：补充一点我的观察，甲方内部的安全评审往往是这类项目最大的拦路虎，权限穿透做不到行级基本过不了。这一点文中提得对，选底座的时候必须提前问清楚，别等评审了才发现要推倒重来。