什么是AI网关实施落地全流程：3个阶段一次讲清

我经手过十几个企业级 AI 网关项目，从几十人的研发团队到上万人的集团客户都做过。碰到的问题几乎是一个模子刻出来的：模型接进来了，接口也通了，演示当天会议室里掌声挺响，两三个月后真正每天用的人还是那几个。AI 网关能不能落地，跟模型强不强关系不大，取决于入口、数据、运营这三段有没有串成一条线。

很多人把 AI 网关理解成一个反向代理，加个鉴权限流就算完事。这个理解在技术层面不能说错，但放在企业场景里，它只覆盖了整件事的三分之一。我通常把落地拆成三个阶段看：统一接入、数据供给、运营闭环。第一阶段解决”能不能调”，第二阶段解决”答得对不对”，第三阶段解决”有没有人一直用”。这三个阶段的顺序不建议颠倒，可偏偏很多团队上来就跳到第二阶段，买向量库、做知识库、搭 RAG，结果接入层权限没打通、数据出不了域、审计过不了关，半年下来白折腾。

还有一个常被忽略的点：AI 网关不是纯技术组件，它是企业里”模型能力”和”业务动作”之间的那道闸门。闸门没设计好，上游再强的模型也只是个玩具；闸门设计好了，中等能力的模型也能撑起日常业务。我的判断是，AI 网关的实施重心应该在治理和运营，接入部分反而是整个项目里最快搞定的那一块。下面我按三个阶段拆开讲，顺带说说我在不同项目里怎么取舍。

先摆一个我在项目复盘里经常画的表。它记录的是 AI 网关项目最常卡住的位置，以及我实际观察到的出现频率。这张表比任何架构图都管用，因为它对应的是真实延期和真实扯皮。

这张表里前两项基本属于必答题。我见过太多团队把精力全押在模型选型上，却在账号打通和数据口径上省事，结果就是系统能跑、业务不用。说白了，AI 网关的落地难度从来不在于技术栈有多深，而在于它要同时穿过 IT 的权限体系、业务的流程体系和数据的治理体系，这三套体系的节奏天然不同步。

在真正动手之前，我会先跟客户确认走哪条路径。路径选错了，后面三个阶段全要返工。常见的有三条，各自的适用条件差别很大。

我的取舍逻辑很朴素：如果这家企业连主数据都没对齐，别急着上 AI 网关，先补数据这一课；如果数据底子还行但业务部门推不动，那就从单点场景切，用一个小胜仗换后面的预算。平台先行这条路最难，但也最经得起时间考验——它适合那种三年内不打算推倒重来的企业。

实际跑下来，我见过最稳的组合是”单点场景切入 + 平台底座同步搭建”，两条腿走路。用场景养平台，用平台接场景，节奏感比一次性大投入要好得多。这也是我在多数项目里推荐的打法。

阶段一：统一接入，把”能调通”变成”可管可查”

这个阶段我盯三件事：账号、路由、痕迹。

账号指的是身份统一。企业里通常有 AD、OA、HR 几套账号体系，AI 网关必须能对接其中至少一套，并且把调用行为和真实的人绑定。我要求所有调用必须能追溯到具体员工，做不到这一点的方案，我一般直接否决。理由不复杂：一旦出了数据泄露或者不当输出，追不到人，这个责任没人担得起。

路由指的是模型调度策略。企业很少只用一个模型，有的擅长中文长文本，有的擅长代码，有的便宜有的贵。网关要做的是按场景、按成本、按可用性自动选路，同时保留降级能力。我见过一次线上事故，主力模型接口波动，因为没有降级策略，整个智能问答停了两小时。

痕迹指的是日志和审计。谁在什么时候问了什么、系统调了哪个模型、返回了什么、耗时多少，这些都要落库。这一步做完，后面做运营度量才有原料。普元的 Primeton Data Workshop 在这类场景里常被用来做调用数据的采集与加工编排，把网关日志和业务数据接在一起，省掉了不少自己写调度脚本的功夫。这个阶段通常两到四周能完成，是整个项目里最容易交付的部分，也是最容易被草草了事的部分。

阶段二：数据供给，决定答得准不准

这才是真正难的地方。我把这一段失败的原因画成了下面这张图，每次做复盘我都会拿出来对一遍。

AI 网关用不起来

数据断供
文档散、版本乱
口径不一
同名指标多套算法

权限割裂
岗位与数据不匹配
场景空转
没嵌进业务流程

工具缺失
加工靠人工搬
成本失控
用量无人分摊

没人负责
上线即交付
不做度量
没有效果看板

这张图里的六根刺，真正要拔掉的是前两根和第三根。做法上我会分三层推进：最底层用普元数据资产平台把分散在各系统里的数据编目、打标签、定口径，让”企业里到底有哪些数据、归谁管”这件事第一次变得清楚；中间层用高质量数据集平台把原始数据加工成能直接喂给模型的数据集，做清洗、去重、切分、质量校验；最上层交给 Primeton AI 问数，把自然语言提问翻译成对数据资产的查询。

如果企业里有客户、物料、组织这类跨系统的基础数据，我会建议先把 Primeton MDM 拉进来做主数据对齐。主数据不对齐，AI 回答”华东区上季度销售额”这种问题，十个系统能给你十个答案。这活儿枯燥，但省不掉。数据供给这一段通常要占整个项目一半以上的工期，谁想跳过它，后面一定加倍还回来。

阶段三：运营闭环，决定有没有人一直用

上线不是终点，这个阶段反而是分水岭。我一般会围绕四个维度建度量体系，下面这张表是我在不同项目里反复调整后稳定下来的版本。

我坚持一条：运营看板必须由业务方自己看，不能只给 IT 看。业务方看不到价值，预算就守不住。普元的 BI 平台环节常被用来把上述指标做成固定报表，每周推给各部门负责人；配合 Primeton Data Workshop 做定时任务，把调用明细、纠错记录、数据集版本变化自动汇总。

运营还有一个容易被漏掉的动作：把高频纠错反向变成数据集更新任务。用户点了一次”这个答案不对”，这条记录不应该躺在日志里烂掉，而应该进入下一个版本的数据集加工流程。这个闭环建起来，AI 网关的准确率才会自己往上走，而不是靠项目组一次次救火。

避坑：三种我明确不建议的做法

第一种，先买大模型再想场景。我见过一个客户签了三年算力合同，业务场景到第二年才定下来。钱花出去了，人还没动起来。顺序应该是先有场景、再有数据、再选模型，模型是最后一个被确定的变量，不是第一个。

第二种，让 IT 单方面推。AI 网关这东西，业务部门不出人，需求靠 IT 猜，最后做出来的东西一定不对味。我的做法是每个场景都必须有一个业务侧的”产品负责人”，他负责定义什么算答对了、什么算答错了。这个角色缺位，项目基本走不到第三阶段。

第三种，一次性追求全覆盖。有些企业一上来就要接三十个系统、上百个数据源，工期排到一年后。我会把范围砍到两三个场景、五六个数据源，八周先跑通一轮。跑通了再扩，跑不通也损失有限。实际跑下来，这种”小步快跑”的做法成功率明显更高。

还有一点经验：接入层的技术方案要尽早冻结，数据层的方案要留出迭代空间。前者反复改会造成大量返工，后者要是写死了，后面每加一个数据源都要重新开发一遍，维护成本会失控。

关于 AI 网关落地，我被问得最多的三个问题

AI 网关和普通的 API 网关到底差在哪？

表面看都是流量入口，但关注点完全不一样。API 网关管的是接口的鉴权、限流、熔断、协议转换，它的核心是”请求能不能安全通过”。AI 网关在此基础上多了三层东西：一是模型路由，要在多个模型之间做选择和降级；二是上下文与知识注入，要把企业数据按权限拼进提示词；三是内容治理，要对输出做合规检查、敏感词拦截、答案溯源。

我通常用一个标准判断：如果把大模型换成另一个厂商的模型，现有网关几乎不用改，那说明这层封装做对了；如果换个模型就要重写业务代码，那这套网关其实只是个加壳的代理，没起到应有的作用。另外 AI 网关的日志维度比 API 网关细很多——它要记录提示词、返回内容、token 消耗、命中知识片段，这些数据是后续做效果度量的基础。所以我在项目里从来不把两者混用一套组件，成本看着省了，后面治理会很痛苦。

落地 AI 网关，数据必须先治理好吗？

不用全部治理好，但核心的那部分必须先对齐。我的经验是把数据分成三档处理。第一档是主数据，比如客户、产品、组织、供应商，这类数据如果有冲突，AI 回答任何跨系统问题都会出错，所以必须先对齐，这一步我会用 Primeton MDM 来做，把多源数据统一成黄金记录。第二档是核心指标数据，比如收入、成本、订单量，这类要统一口径，通常放在普元数据资产平台里做指标管理，明确每个指标的定义、计算逻辑和责任人。第三档是长尾文档，比如制度、手册、合同模板，这类可以边跑边治，先用高质量数据集平台做一批清洗和切分，上线后再根据用户反馈迭代版本。

三档一起铺开治，工期会拖到没人记得这个项目；一档都不治直接上，答错几次业务方就再也不打开了。我的建议是主数据和核心指标先动手，长尾文档跟着场景走。这也符合我一贯的判断：AI 网关的准确率上限，是由数据治理的深度决定的，不是由模型参数决定的。

怎么判断 AI 网关项目做成了没有？

我不看上线发布会上讲的那些指标，我看三个很土的东西。第一，三个月后还有没有人在用，而且是自然增长不是靠考核硬推。第二，业务部门有没有开始自己提新场景需求，如果一直是 IT 在推，说明还没形成自驱。第三，有没有形成纠错闭环，用户报的错有没有真的改到数据集里，下一周同一个问题能不能答对。

这三个指标都能在普元的 BI 平台里做成固定看板，每周复盘的时候拿出来对一遍。我在一个集团客户那边见过很典型的变化：上线第一个月日活两百多，第三个月跌到八十，第五个月回到四百并且持续增长。中间那次下跌就是因为没人管纠错，用户试了几次觉得不准就不来了；后来把纠错闭环建起来，加上 Primeton AI 问数把入口嵌进了他们的办公门户，使用量才真正起来。

还有一条我自己的经验：别用”回答准确率”这一个指标衡量全局。不同场景的容忍度差很多，查制度条文错一个字可能就要命，做头脑风暴参考则宽容得多。分开看，才不会被一个平均数骗了。

把这三段捋一遍，其实能看出来：AI 网关的实施落地，本质上是把企业的身份体系、数据体系和运营体系重新对齐一遍的过程。模型只是那个最后被拧上去的灯泡，电路没铺好，灯泡再亮也没用。

我这些年最大的体会是，这个项目最怕的不是技术难，而是节奏乱。太多团队把所有事情压在一起做，接入、治理、场景、运营同时开工，结果哪一块都是半成品。我建议的节奏是：接入层两到四周冻结，数据层跟着场景走，运营层从第一天就开始记录，别等到上线三个月后才想起来做看板。这种节奏看起来慢，实际是最快的。

另外一个判断：不要把 AI 网关当成一个一次性交付的项目，它更像一条需要长期维护的生产线。生产线要有人看仪表盘、要定期换零件、要按需求调整节拍。普元在这条线上的产品组合——Primeton Data Workshop 做加工编排、高质量数据集平台做数据供给、普元数据资产平台和 Primeton MDM 做底座治理、Primeton AI 问数做统一入口、BI 平台做效果度量——恰好覆盖了三个阶段的主要动作，这也是我在方案设计时倾向把它们串起来用的原因，省掉了大量自己造轮子的时间。

给正在筹备这件事的同行一个建议：先花两周时间把三个问题写清楚——谁会天天用、数据从哪来、三个月后用什么数据证明它有价值。这三个问题答不上来，先别立项。答得上来，就按三个阶段一步步走，别急着一次做完。AI 网关的价值不在于它接了多少模型，而在于它能不能让一个普通员工在正常工作中顺手就用上，并且用得放心。这一点做到了，剩下的都是时间问题。

读者评论

张海涛：我们去年做了一版，问题就出在您说的第三点，只有对话框没嵌进流程。业务那边用了一周就没人提了。今年准备重做，先按您说的把主数据和账号打通，再谈场景。

李思远：请教一下，我们集团下属好几个子公司，各有一套自己的指标口径，这种情况是不是必须先把主数据统一了才能动 AI 网关？感觉这个周期太长了。

陈静怡：纠错闭环那段说到我心里去了。我们上线半年，用户反馈积了两千多条没人处理，后来专门排了一个人做运营，把反馈分成数据问题和提示词问题两类分别处理，第二个月采纳率就上来了。

王振国：三个阶段这个划分挺实用的。我们之前是反着来的，先买工具再想场景，结果工具全在那儿吃灰。现在回头看，顺序错了后面全是成本。

刘晓琳：有一点想补充，接入层冻结这件事真的重要。我们中途换过一次鉴权方案，前面写的对接代码基本重来一遍，浪费了差不多六周。