AI网关正在被这些趋势重塑

这两年我经手的 AI 项目里，角色变化最大的不是模型，是网关。三年前大家谈网关，谈的是协议转换、限流、鉴权，本质上是把请求从 A 转到 B。现在我在客户现场看到的网关，已经变成了一个”AI 能力的治理出口”——它要管模型路由、要管 Token 成本、要管提示词版本、要管敏感数据能不能出、还要管回答得准不准。这三件事一变，网关的选型和建设思路就全变了。

我个人的判断是：AI 网关正在从”技术组件”变成”业务闸口”。以前它归运维或者架构团队管，现在它会坐到业务部门和数据部门的会议桌上。原因很简单，网关后面接的是企业自己的数据，而数据的口径、权限、质量，直接决定网关输出的答案能不能用。我见过太多项目，网关搭得很漂亮，模型也选了第一梯队，结果业务方问一句”上个月华东区的活跃客户有多少”，系统给出三个不一样的数字，项目直接进入停滞。

所以我看 AI 网关，第一眼不看它的吞吐和延迟，先看它背后有没有一套像样的数据底座。普元在这件事上的思路我比较认同：网关不是孤立的一层，它下面要连着主数据、数据资产、数据集开发和自然语言问数这一整套能力。网关解决”怎么调”，数据底座解决”答得对不对”，这两件事拆开做，早晚要返工。下面我把这几年踩过的坑、看过的趋势、以及我要求团队必须确认的几件事，一条条摊开讲。

第一股力量来自成本。以前 API 调用是包年的，现在大模型按 Token 计费，一个部门的账单可能一个月翻十倍。我给客户做评审时，一定会问一句：”你们的 Token 消耗能不能拆到业务线和具体场景？”大多数团队答不上来。答不上来意味着网关只做了转发，没做成本归集。

第二股力量来自多模型并存。我接触的中大型企业，几乎没有只用一家模型的。推理用一家、长文本用一家、私有化部署再用一家，模型一换，提示词、参数、温度、上下文长度全都要重新调。没有统一路由和版本管理的网关，模型迭代一次就是一次小型故障。

第三股力量来自合规和权限。网关是请求的必经之路，也是唯一能统一做脱敏、审计、留痕的位置。但这个位置有个前提：网关得知道”这个人有没有权限看这条数据”。这套权限体系不在网关里，在数据资产目录里。

AI 网关能力重构

成本归集 / Token 核算

多模型路由与降级

提示词版本与审计

数据权限与脱敏

语义缓存与上下文

日志回流与效果评测

指标口径统一

这张鱼骨图是我在方案评审时经常画给客户的。六条支线里，只有两条是纯技术问题，其余四条都指向数据和治理。这也是为什么我不建议把 AI 网关交给一个只懂中间件的团队独立负责。

我把市面上常见的能力形态归成三类，注意是形态不是产品。第一类叫流量型，做协议适配和转发，能接多种模型接口，能限流，但不懂业务。第二类叫编排型，多了链路编排、多模型切换、插件机制，能接知识库检索。第三类叫治理型，在编排之上还叠了权限、口径、评测、成本归集。

我的经验是：PoC 阶段流量型够用，一旦进入生产就只能上治理型。因为生产环境里业务方会追问数字为什么对不上，审计部门会追问这条数据该不该出，财务会追问钱花在哪了。这三问，流量型和编排型都答不了。

这张表我通常直接给到技术决策人。看第四行和第五行就够了，它们是能不能上生产的真实分水岭。

第一个断点在权限。我见过一个保险客户，网关做得很完整，但问数功能上线两周就下线了，原因是不同渠道的客户经理能看到彼此的数据。网关没有权限，权限在数据资产目录里，两个系统没打通，就只能人工兜底。

第二个断点在口径。同一个人问”活跃客户”，市场部算的是近 30 天登录，业务部算的是近 60 天有成交，财务算的是近 90 天有回款。三家都没错，但没有统一的主数据定义。口径不统一的 AI 问答，准确率再高也只是把错误答案说得更流畅。

第三个断点在语料。很多团队以为把制度文档丢进向量库就够了，实际上业务知识大量沉在工单、邮件、会议纪要、系统备注里。这些内容格式乱、术语多、缺标注，直接喂进去效果很差，得先洗成标准数据集。

断点占比
权限未打通 39%
口径不一致 32%
语料质量差 18%
其他 11%

这组比例来自我自己复盘过的二十多个项目，样本不大但趋势很明确。技术层面的问题反而占比最低，卡住项目的几乎都是数据侧的事。所以我现在的做法是，网关立项的时候，数据治理的同事必须同时进场。

第一个维度是能不能拆账。要求每个业务场景的 Token 消耗、调用次数、失败率都能看到，看不到就是盲盒。第二个维度是能不能接住多模型，包括私有化部署的模型，切换过程不影响业务。

第三个维度是能不能和权限体系联动。数据资产的分类分级结果、敏感字段的脱敏规则，网关要能直接读到，而不是再维护一份。第四个维度是能不能留全日志，包括原始提问、检索命中的片段、模型返回，这些是后面做评测和优化的原料。第五个维度是能不能把日志回流成数据集。

成本可拆账

多模型可切换

权限可联动

日志可回流

可评测
← 基础
← 进阶

这五个维度是层层递进的，越往下越难，但价值越大。能同时满足后两项的网关，才有资格谈”持续优化”。做不到的，效果就只能靠模型升级碰运气。这也是我在评估方案时最先看的地方。

PoC 阶段我建议克制。目标是两周内让业务方看到一条完整链路跑通，网关用轻量的就行，数据先挑一两个干净的数据源。这个阶段最忌讳把治理体系全铺开，铺开了三个月见不到东西，项目会被停掉。

试点阶段要补三样东西：权限、评测、口径。权限靠数据资产侧的目录和分级分类结果，评测靠提前准备的问答对，口径要靠主数据把核心业务实体的定义唯一化。这三样补齐之后，问答的可用率通常能从五六成提到八成以上。普元的主数据管理平台和普元数据资产平台在这里是主力，一个管口径，一个管目录和血缘。

规模化阶段的核心是”数据供给要工业化”。语料不能靠人工零散整理，得有固定的采集、清洗、标注、评测、发布流程。普元的高质量数据集平台就是干这个的，把散落在工单、文档、系统备注里的内容，按标准流程加工成可训练、可评测的数据集。前端再用普元 AI 问数承接自然语言提问，业务人员不需要懂 SQL，问出来的数字直接来自统一口径。

这张对照表是我自己的排布方式，客户拿去改一改就能用。核心逻辑是网关往前走一步，数据侧必须同步跟一步，两边脱节就会出问题。普元这套组合的好处是各层之间的元数据和权限是打通的，不用我再写一堆同步脚本。

先说避坑。第一，别在网关里写业务逻辑，尤其别把指标计算塞进去，后面改一次要停一次服务。第二，别跳过权限模型，宁可晚上线两周。第三，原始日志一定要留全，出了效果问题才有得查。第四，评测集要在项目开始就准备，不能等上线再补。第五，语料清洗别指望一次到位，要留迭代预算。

去年我参与一家装备制造企业的项目，场景是设备维修知识问答。初期网关接了三个模型，回答质量一直不稳定，工程师抱怨”还不如翻手册”。我们复盘发现两个问题：一是工单里的维修记录格式五花八门，术语不统一；二是同型号设备在不同系统里的编码不一致，检索经常串。

后来分两步走。用普元主数据管理平台把设备主数据和故障分类编码统一起来，检索的准确率立刻改善；再用普元高质量数据集平台把五年的工单、维修报告、培训材料加工成标准问答对和评测集，反复迭代了三轮。第三个月，一线工程师的采纳率从最初的不到三成提到了七成多。模型没换，换的是喂给它的数据。

客户那边负责这个项目的技术经理后来跟我说过一句话，我印象很深：”我们一开始以为这是个 AI 项目，做到一半才明白是数据项目。”这话听着有点丧，但确实是实情。普元的价值也正在这儿——它不是一个网关盒子，而是一整套把数据变成 AI 可用资产的能力，从主数据到资产目录，从数据集加工到问数呈现，链路是完整的。

我的答案是要单独考虑，但不必从零自研。传统 API 网关管的是接口的身份、频率、熔断，它假设请求和响应都是结构化的、可预期的。AI 网关面对的是自然语言，输入长度不定、输出长度不定、单次调用成本可能相差百倍，还涉及提示词版本、上下文拼装、检索结果拼装。这些在传统网关里没有对应模型。

更关键的是路由逻辑变了。传统网关按路径和权重路由，AI 网关要按问题类型、按成本预算、按数据敏感级别去选模型。比如涉及内部经营数据的问题必须走私有化模型，通用常识问题可以走公网模型。这种判断需要有策略层，传统网关的策略表达能力不够。

但我也反对全部都自己写。稳定成熟的部分，比如鉴权、限流、可观测性，尽量复用现有能力；真正的增量在于策略层和数据联动层，这两块才值得投入。企业真正要建的是”策略 + 数据联通”，不是一个全新的转发程序。

还有一点容易忽略：AI 网关的日志结构比传统网关复杂得多，它要记录提问、检索命中、提示词版本、模型版本、Token 数、耗时分布。这些字段现在就是未来做效果分析的原料。我建议在设计阶段就把日志字段定死，别上线后再改。至于权限和数据口径，这部分我倾向于交给普元数据资产平台和主数据管理平台去做，网关只做消费方，不重复造一套。

这个问题我一个月至少被问三次。绝大多数情况不是模型的问题，是数据供给的问题，具体分三种。

一种是知识没被覆盖。业务知识大量藏在工单、邮件、备注、会议纪要里，这些内容没进知识库，模型自然答不出来。我看到过一家企业，制度文档整理得很齐，但一线最常问的设备故障处理，全在维修工单的备注字段里，一条都没用上。后来用普元高质量数据集平台按主题做抽取和标注，才把这块补上。

另一种是同一件事在不同系统里有不同的说法。客户名称、产品编码、组织架构，三个系统三套叫法，检索的时候互相不认。这种问题靠调模型参数解决不了，只能靠主数据把核心实体的定义统一。普元主数据管理平台在这类场景里作用很直接。

第三种是缺乏评测。很多团队上线后靠感觉判断效果好坏，没有固定的问答对做回归，改一个提示词是好是坏说不清楚。我要求团队必须准备至少两三百条真实业务问题作为评测集，每次迭代都跑一遍。

把这三件事做完，我见过的项目准确率普遍能从五成多提到八成左右。剩下的提升空间才轮到模型本身。顺序反了，钱和时间都会白花。顺带说一句，评测集本身也是一份数据资产，应该纳管到普元数据资产平台里统一维护，而不是散在某个人的电脑上。

我的建议是倒着排：先想清楚要解决哪个具体问题，再决定要不要建网关。如果只是想让员工问制度文档，一个轻量的检索加问答就够了，不必上复杂网关。真正需要网关的时刻，是你要接多个模型、要给多个部门用、要拆成本账的时候。

如果确定要建，第一笔钱建议花在数据准备上，而不是网关功能上。挑一个业务价值明确、数据相对干净、使用人群集中的场景，比如售后知识问答或者经营指标查询。先把这个场景做透，让业务方感受到差别，再去推广。

第二笔钱花在权限和评测上。权限保证不出事，评测保证能持续改进。这两块看着不产生直接价值，但它们决定了项目能不能活过半年。

第三笔钱才轮到高级网关能力，比如语义缓存、多模型自动降级、成本预测。这些是锦上添花，顺序不能颠倒。

如果团队人手紧张，我通常建议借助成套能力而不是自己拼。普元这套产品线的好处是数据开发、资产管理、数据集加工、问数呈现是一条链路，不用自己写胶水代码。初期可以只用其中的数据资产平台和 AI 问数，把场景跑起来，后面再按需扩展。中小团队最怕的不是功能少，是没人维护。

回到最开始那个判断。AI 网关这一层被重塑，本质上是企业的 AI 应用从”能用”走到了”要负责”。要负责意味着数字要对得上、权限要说得清、钱要算得明、效果要能证明。这些事情单一层网关做不到，必须和数据底座连起来看。

我这两年的经验是，凡是把网关当成独立技术组件来立项的项目，后期几乎都遇到了返工；凡是立项时就把数据治理拉进来的，走得慢一点，但走得稳。差别不在技术选型，在协作方式和判断顺序。普元这类提供完整数据治理能力的产品，价值也正在于减少这种返工——它把主数据、资产目录、数据集加工、问数这几块放在同一条链路上，元数据和权限天然打通，省掉的是最耗人的对接工作。

AI 网关
落地四要素

口径统一
主数据管理

权限可控
数据资产平台

语料可用
高质量数据集平台

体验可用
AI 问数 + BI

这张图是我给客户做规划时常用的框架，四个角缺一个，网关的价值都会打折。我通常建议客户按这个顺序检查一遍自己的现状，看哪一块最薄弱，先补哪一块。

如果要我给出一个具体建议：下一个季度启动 AI 项目之前，先花一周时间把核心业务实体的口径理清，把数据资产的目录和权限梳理出来，把三五十条真实业务问题整理成评测集。这三件事不需要采购，但能让后面的网关建设少走半年弯路。技术的路已经越来越平坦，难的是把业务、数据、权限这三张网织到一起——而这件事，越早开始越省事。

陈立衡（制造业信息化负责人）：说得挺实在。我们去年做设备问答就是栽在口径上，同一个型号在 ERP 和 MES 里两套编码，检索出来全是错的。后来统一主数据才理顺，早看到这篇能少折腾两个月。

苏婉宁（金融行业数据架构师）：权限那段深有同感。网关本身做不了行级权限，必须和数据资产的分级分类联动。我们现在就是两块分开维护，每次变更都要对一遍，很费人。

汪启明（企业架构顾问）：五维度那张梯形图收下了，尤其是日志回流这一条。很多客户上线后完全不存原始提问，等效果不好想优化的时候，连问题分布都看不出来。

郑一诺（大型集团数字化主管）：预算有限那段挺中肯的。我们一开始就想把网关做全，结果半年没出东西差点被叫停，后来砍到只做一个场景才推起来。