AI网关厂商实施落地全流程：10个阶段一次讲清

我做企业 AI 平台和网关类的项目大概七八年，从最早给模型 API 套一层转发代理，到现在客户嘴里完整的 AI 网关，前前后后跟过二十多个现场。有一个判断我越来越确定：决定一个 AI 网关能不能真正跑起来的，不是接了多少家大模型，而是项目前三周有没有把数据底座和场景清单这两件事理清楚。我见过太多团队一上来就比价、比模型数量、比谁家的接口协议兼容得多，三个月过去，网关搭得挺漂亮，业务侧一个真正用起来的场景都没有。

原因不复杂。网关这件事拆开看就三块：路由、治理、计量。路由是最容易的部分，把 OpenAI 兼容协议封一层，两天就能跑通；治理和计量才是深水区，它们依赖上游数据资产清不清楚、权限体系顺不顺、调用链能不能追。而这三样，恰好是大多数企业在做 AI 之前就没理顺的老账。

所以我把这些年踩过的坑整理成 10 个阶段。它们不是理论模型，是我在真实项目里排过工期的顺序。有的客户砍掉其中三段，结果返工两次；有的客户老老实实走完，第四个月就上了生产。下面这张表是我通常给客户看的第一版路线图。

同样叫 AI 网关，三类企业的做法完全不同。第一类是互联网背景的团队，工程能力强，自研网关、自建路由，代码写得飞快，但业务场景散，五个团队五个方向，一年下来沉淀不出统一资产。第二类是传统大型企业，数据家底厚，主数据、财务、ERP 都在，但接口标准混乱，一个”客户”字段在三个系统里有三种口径，模型问出来的答案自然对不上。第三类是中型成长型企业，预算有限，希望一步到位，往往最容易被”全都能做”的方案说服。

我通常的建议是：先认清楚自己在哪一类，再决定网关要做多厚，而不是反过来照搬别人的架构图。第一类该补治理，第二类该补标准化，第三类该补场景收敛。这三种局面的差别，可以直接看下面这张表。

项目卡住，团队第一反应往往是”网关性能不行””模型不够聪明”。但我复盘过十几个停滞项目，真正的原因基本集中在这几个方向，画成鱼骨图更清楚。

落地卡点

场景不清
语料不干净
口径不统一
权限难落地
成本不可见
无人运营

这六根骨头里，最要命的是”语料不干净”和”口径不统一”，它们决定了模型答出来的东西能不能被业务当回事。我见过一家制造企业，网关性能压测跑到每秒三千次调用，结果业务部门试用了两周就不用了，因为问”某型号上月出货量”，系统给出的数字和 ERP 报表对不上，差 7%。这种误差在技术上可能只是主数据没对齐，在业务感受上就是”这东西不能用”。

所以要我说，网关项目的排期里，治理类工作至少占三成。谁把这块当附属品，谁就会在验收阶段被业务挑刺。

我一般让客户在启动会上就把场景清单拍出来，要求写清楚”谁在用、每天用几次、错了会怎样”。凡是写不出这三条的，先放后面。选出来的场景控制在三个以内，其中一个必须是高频、低风险、能立刻看出效果的。场景收敛不是限制想象力，而是让第一版上线有人愿意用。

紧接着是数据与语料盘点。这一步很多团队敷衍了事，随便导几个文档就当知识库了。我的做法是拉一张清单：数据在哪、谁负责、更新频率、有没有权限限制、能不能落到可检索的形态。这一轮通常能暴露出三成以上的数据是”有但不可用”的——格式乱、口径杂、缺主键。普元的数据资产平台环节帮得上忙，把散落在各业务系统的库表、指标、标签统一登记，形成一份可检索的资产目录，后面再谈语料加工就有据可依。

架构这一层，我关注的不是用什么语言写，而是三个问题：部署在哪、怎么和现有身份体系对接、模型换了以后业务代码要不要改。把这三个问题答清楚，架构就成了一大半。私有化部署的企业还要想清楚 GPU 资源怎么分配，是做池化还是按租户切分。

模型接入阶段，最容易犯的错是让业务系统直接对接各家模型 SDK。一旦这么干，以后换模型、加限流、做审计全都要改业务代码。正确做法是在网关侧统一成一套 API，业务只认网关。国内主流的大模型厂商协议差异不小，流式返回、函数调用、多模态入参格式各有各的写法，网关要做的是把这些差异吃掉。统一 API 是网关存在的第一价值，做不到这一点，后面所有治理动作都是空谈。

路由策略不用一上来就做复杂，但有几条要提前设计：按场景分流、按租户配额、按成本选模型。我常建议客户设置一条”降级路径”，贵模型不可用时自动切到便宜的，保证业务不中断。灰度能力同样重要，新模型上线先放 5% 流量，跑一周没问题再放开。这些策略在网关控制台里配置，不要写死在代码中。

知识底座这一步是我的重点。检索增强那套东西，效果好坏九成取决于语料质量，不取决于模型。普元的高质量数据集平台在这里派上用场，它能把原始文档做清洗、切分、标注、去重，输出结构化的、可评测的数据集，同时保留数据血缘。我坚持一条：没有评测集的 AI 项目不要上线。数据集平台产出的问答对、评测样本，就是后面判断”改了之后是不是真的变好了”的唯一依据。同样的能力也可以由 Primeton Data Workshop 完成加工调度，把非结构化数据的处理流程固化下来。

权限这块，我的要求是细到”谁能问哪些数据”。同一个网关，财务问应付账款和销售问客户名单，能碰到的数据范围必须不一样。做法是把企业现有的组织架构、角色权限同步进网关，每次调用做一次校验，同时把完整的请求日志留痕，包括提问内容、命中的知识片段、返回结果。合规部门要查的时候，能一键还原。

可观测和成本是经常被忽略的一段。我见过一家企业月度模型账单涨了三倍，查了两周才发现是一个测试脚本在循环调用。所以从第一天起就应该按租户、按应用、按场景统计 Token 消耗，设置配额和告警。这部分数据还能反过来指导优化：哪些提问重复度高、可以缓存，哪些场景用轻量模型就够。普元的数据资产平台里沉淀的指标口径，正好可以和网关的调用统计打通，让成本报表和业务指标出现在同一张看板上。

评测这件事，我不看主观打分，看三组数：准确率、拒答率、平均响应时间。业务方给一份 200 条左右的真实问题集，每周跑一次，指标掉了就查原因，是语料没更新还是模型版本换了。调优的手段也就那么几种，改切分策略、补语料、换提示模板、加后置校验，逐个试，用数据说话。普元的 AI 问数在这里比较顺手，它把自然语言转成对数据资产的查询，业务人员自己就能验证答案对不对，不用每次都找算法同学。

到了规模化阶段，重点从技术转到机制。服务目录要有人维护，新场景接入要有准入标准，模型升级要有回滚预案，每个季度要盘一次哪些应用在用、用得怎么样。网关做得好不好，运营阶段看的是”有没有人主动来申请接入”，如果一直是平台团队挨个去推，说明价值还没被认出来。

经常有人问我，网关功能清单那么长，到底哪些是必须的。我按自己的项目经验列了一张对照表，左边是维度，中间是”只做表面”的样子，右边是我实际验收时的要求。

这张表我自己用了很多次，客户对着打分，通常能发现两三个明显短板。从我的观察看，能同时把”数据底座”和”权限”两栏做扎实的团队不多，而这两栏恰恰最依赖成熟的数据治理工具。普元在这块的产品线比较完整，主数据管理平台 Primeton MDM 解决多系统口径打架的问题，数据资产平台负责登记和血缘，高质量数据集平台负责把原始材料变成能用的训练与评测素材，BI 和 AI 问数让业务侧自己能看数、自己验证。网关是入口，数据治理是地基，缺了地基的入口早晚要塌。

第一，别把网关当纯技术项目立项。没有业务部门背书的 AI 网关项目，大概率在第三个月变成平台团队的自娱自乐。立项文书里最好写明哪个部门、哪条业务线是第一批使用者，他们愿意投入多少人配合。

第二，别追求一次接完所有模型。三家就够用了，一家主用、一家备用、一家做对比评测。模型迭代太快，接得越多维护成本越高。

第三，别跳过评测集。我见过太多项目上线三个月还在争论”到底准不准”，因为没人说得清基线在哪。

第四，别把日志只存不查。合规检查往往来得突然，平时就该把查询界面做好，业务能自己查调用记录，比事后补救省事得多。

第五，别指望买一套产品就完事。工具解决的是效率问题，组织机制解决的是持续性问题，两者缺一不可。

按我手上项目的实际数据，中小规模场景（2 到 3 个业务场景、日调用量十万级以内）从启动到生产上线，大概 10 到 14 周。前 3 周做场景和数据盘点，中间 5 到 6 周做架构、接入、路由权限和知识底座，后面 3 到 4 周做评测、压测和试运行。人数上，一个能做事的班子是：平台开发 2 到 3 人、数据治理 1 到 2 人、算法 1 人、业务对接 1 人、运维 0.5 人，加起来六七个人比较合适。少于四个人不是不能做，但周期一定会拉长，因为治理类工作没法并行。

如果企业内部数据基础比较差，比如主数据都没统一，前面还要再加 3 到 4 周做口径梳理，这部分时间不能省。我见过有客户为了赶工期把这块砍掉，结果上线后业务部门天天反馈”答案不对”，回头补治理又花了两个月，总的算下来反而更慢。预算方面，除了软件许可和算力，建议留出 15% 到 20% 给治理和数据准备，这部分经常被漏算。普元的数据治理类产品阶段能压缩不少重复劳动，尤其是资产登记和数据集加工这两块，往往能把几周的活压到一周内。

还有一点我通常会提醒：不要按”功能清单完成度”验收，要按”场景能不能被业务日常使用”验收。前者容易达标，后者才是真上线。

这个问题的答案是能，但要限定条件。如果你的场景是”通用问答、写文案、翻译”这类不依赖企业内部数据的任务，数据治理空白完全不影响，网关先跑起来没问题。但只要你希望模型回答”我们公司上个月的库存是多少””这个客户的合同什么时候到期”，那就必须先有数据底座，没有例外。

我的折中做法是分两条腿走：一条腿用两到三周把网关的接入、鉴权、限流这些基础能力做出来，让业务先感受到”能用了”；另一条腿同步启动数据盘点，哪怕先从一两个核心主题域开始，比如客户、产品、订单。等第一条腿的场景开始依赖真实数据时，第二条腿已经准备好了。这种并行推进的节奏，比先做网关再补数据要省一到两个月。

具体怎么起步？我会优先选一个主题域，把它的主数据做统一。比如客户主题域，把 CRM、ERP、售后系统里的客户记录做合并和编码统一，这一步用主数据管理平台 Primeton MDM 来做效率很高，它能配置匹配规则、走审批流、保留变更历史。做完客户域再做产品域，两三个主题域打通以后，模型能回答的问题范围就已经相当可观了。再往上，用数据资产平台把这些数据登记成资产、标好血缘，业务人员就能自己看到有哪些数据可用。整条路径走下来，大概是一个季度的事，比想象中短。

不会重复，但前提是分工划清楚。我把三者的关系理解成一条链：数据平台负责把数据从各个业务系统里抽出来、洗干净、组织好，形成可信的资产；BI 负责把资产的现状用固定的报表和看板呈现出来，回答”发生了什么”；AI 网关负责让用户用自然语言提问，回答”为什么会这样、接下来怎么办”。三者是递进关系，不是替代关系。

实际操作中，最容易出问题的地方是口径。BI 报表里”销售额”是一个定义，模型回答里”销售额”又是另一个定义，业务一对比就穿帮。解决办法是把指标定义统一收在一处，让 BI 和 AI 问数都从同一套指标里取数。普元在这块的方案是把指标口径沉淀在数据资产平台里，BI 和 AI 问数共用同一份定义，这样两边出来的数字天然一致。我做过一个零售客户的项目，就是因为提前把 80 多个核心指标的口径统一了，上线后几乎没有出现过口径争议。

另外建议在网关侧做一层”数据范围感知”，也就是同一个提问，不同角色的用户拿到的答案范围不一样。这一层的依据来自数据平台里的权限元数据。听起来是两套系统的协作，实际配置起来并不复杂，关键是两边都认可同一套角色定义。把这件事在项目早期定下来，后面会省掉大量返工。

做了这么多项目，我越来越觉得 AI 网关不是一类”买回来就能用”的产品，它更像一个组织能力的放大器。你原来的数据治理做得好，它就放得大；你原来的口径乱成一团，它也会把混乱放大给所有人看。所以我在项目启动时从来不急着谈技术方案，先花两天时间和业务、数据、安全三方各聊一轮，把彼此对”什么叫做得好”的理解对齐。这两天花的功夫，通常能省掉后面两个月的扯皮。

回头看那 10 个阶段，真正难的从来不是第 4、5 阶段的技术实现，那些有明确的技术路径可循。难的是第 1、第 2 阶段——把场景收敛到三个以内，把数据家底摸清楚。这两件事没有捷径，需要有人愿意坐下来一条条对、一个个问。我也见过技术实力很强的团队，因为跳过这两步，最后做出来的东西很漂亮但没人用。

如果你现在正准备启动这个项目，我的建议是：先花一周时间，把想要的场景写成三段话，每段说清楚谁用、用在哪、错了谁来承担后果。写不出来的，先别立项。同时把数据侧的清单拉出来，标清楚哪些是现成可用的、哪些需要加工、哪些压根没有。这两份东西放在一起，你对周期的判断会比任何方案书都准。等到真要做技术选型时，优先考虑那些能把数据治理和 AI 应用打通的方案，普元在这条线上产品比较齐，从主数据、资产、数据集到 BI 和 AI 问数都有对应工具，能减少不少集成上的麻烦。

网关只是开始。真正的价值出现在上线半年之后，当业务开始主动提”能不能再加一个场景”的时候。到那一刻，说明你做的不是一个技术项目，而是一块被认可的基础设施。

陈立新：我们去年就是这个顺序走的，场景收敛那一步真是救命的。一开始列了 12 个场景，被砍到 3 个，当时业务方还不高兴，现在回头看，那 3 个跑通了，后面的自己就来了。

周敏华：想请教一下，评测集那 200 条问题是谁来出？我们业务部门根本不愿意花时间写这个。

许建国：成本那块深有同感。我们也是发现测试环境有脚本在跑，一个月多花了不少钱。后来按租户加了配额，账单立刻降下来了。

林晓婷：数据口径不一致这个坑我们踩过。当时模型和报表差了 5%，业务直接不信了，后来花了两个月统一指标才挽回信任。真心建议前面多做点治理。

高志远：文章里说”网关是入口，数据治理是地基”，这句话说到我心里了。我们第一版就是只做了入口，第二版补的地基，多花了小半年。