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

AI网关这件事，我前后跟过五个项目，最大的感受是：它从来不是一个纯技术组件的问题。很多团队一开始把它当成一个”代理转发层”，觉得选个开源框架、配几条路由规则、接上几个大模型接口，两周就能上线。实际跑下来，真正让人反复返工的，是场景边界没划清、数据供给接不上、权限和成本没人兜底。我在一个制造业客户那边见过，网关本身三天就通了，可后面为了对齐六个业务部门的问答口径，足足磨了两个月。所以我的判断是：AI网关的落地要按”盘点—编排—运营”三个阶段切，每个阶段有各自的交付物和验收标准，不能揉在一起做。阶段一解决”接什么、给谁用、数据从哪来”，阶段二解决”怎么接、怎么控、怎么快速复制”，阶段三解决”用得怎么样、花多少钱、要不要扩”。这三个阶段里，普元数据资产平台、高质量数据集平台、Primeton Data Workshop、Primeton AI 问数这几款产品能覆盖从数据供给到智能问答输出的主干链路，尤其在阶段一的资产盘点和阶段三的效果度量上，能省掉大量自制工具的成本。下面我按自己实际推进的节奏，把每个阶段该做什么、容易踩什么坑，一条条拆开讲。核心一句话：网关是入口，数据是燃料，运营是发动机，缺一个都跑不长。

我见过最典型的一种返工：技术团队先把网关搭起来，业务方兴冲冲提了二十个场景，结果发现其中十几个根本找不到干净的数据源，剩下几个又被权限卡死。这时候再回头做数据盘点，前面的路由配置基本要推倒重来。根因不在技术选型，在于顺序反了。

另一类返工来自成本。网关把请求转发出去很容易，但谁在用、用了多少 token、哪个部门该分摊多少费用，这些如果没有在架构里预留字段和埋点，等到财务来问的时候就只能拍脑袋。我在一个零售客户那里见过，上线两个月账单翻了四倍，没人说得清钱花在哪。

还有一类是权限。企业内部的问答类应用，往往要求”不同角色看到不同的数据范围”。这件事如果在网关层不做统一收口，而是让每个应用自己判断，后面每加一个场景就要重复实现一次，漏洞只会越来越多。

落地效果

场景边界不清
需求反复变更

数据供给不足
口径不统一

权限未收口
越权风险

成本不可见
账单失控

运营缺位
上线即停摆

效果无度量
无法迭代

所以我现在启动这类项目，第一件事不是画架构图，而是拉着业务方做一轮场景排序。把二十个需求压到三到五个，先做那个数据最干净、受众最明确、效果最好衡量的。一个跑通了，后面的复制成本会低得多。这个思路我跟普元的实施团队聊过，他们在做高质量数据集平台的时候也是这个逻辑：先把高频场景的数据集做扎实，再谈规模化。

我通常把整个落地拆成三块，每块都有独立的目标、产出和验收方式。分得清，团队之间就不会互相等；分不清，就会出现”数据没准备好技术先动工””技术做完了业务不认账”这类拉扯。

下面这张表是我在项目启动会上必放的，用来对齐各方预期。

三个阶段不是瀑布式的串行，而是有重叠的滚动推进。阶段一做完第一批场景就可以开阶段二，阶段二有第一个应用上线就启动阶段三的埋点。我在实际项目里会把阶段一的产出做成”活文档”，每次新场景进来都往里加，而不是一次性写完就锁死。

这一阶段我最看重两件事：数据能不能供得上，场景值不值得做。前者要靠数据资产盘点，后者要靠业务价值排序。我见过太多团队跳过这一步，直接进入开发，做到一半发现数据源有七八个版本、口径各不相同，改起来比重做还贵。

盘点的时候我会让团队把每个候选场景需要的数据源、字段、更新频率、责任部门全部列出来。这张表列完，哪些场景能快速落地、哪些要等治理，一目了然。普元数据资产平台在这件事上帮过不少忙，它能把分散在各业务系统里的库表、指标、标签统一登记成资产目录，谁负责、什么口径、被谁用过都有记录，省掉了大量手工拉表的工作。

选型上我一般建议先窄后宽。不要去追求”一个平台解决所有场景”，先挑三个高频、低风险、数据基础好的场景跑通。比如内部制度问答、销售政策查询、报表口径解释，这类场景对准确率要求清晰，验收标准也好定。

项目返工原因分布（我的项目样本）

场景边界不清 35%

数据供给不足 30%

运营机制缺位 20%

其他技术因素 15%

这张图是我自己项目里统计出来的，样本不大，但方向很有参考性。技术问题只占一小部分，真正拖慢进度的是边界和数据。所以阶段一宁可比计划多花一周，也别急着写代码。

到了这一步，网关本身的实现反而不难。难的是四件事同时收口：路由分发、身份鉴权、数据脱敏、提示词与知识治理。任何一件放到应用侧去做，后面都会变成重复劳动。

路由和鉴权属于基本功，很多团队能搞定。真正容易忽略的是数据侧。问答类应用的回答质量，七成取决于喂进去的数据是不是干净、是不是最新的、是不是按角色过滤过的。我通常会用高质量数据集平台把原始数据加工成可用的问答语料和知识片段，明确每条数据的来源、更新周期和适用范围，再交给上层应用调用。这件事做扎实了，后面换模型、换前端都不用重做数据层。

加工环节我会用 Primeton Data Workshop 来编排，把抽取、清洗、比对、发布串成可调度的任务流，而不是靠人写脚本一遍遍跑。它支持可视化的流程编排，运维同事也能看懂，交接时不会断档。

最上层是面向使用者的入口。Primeton AI 问数 这类产品把自然语言转成数据查询和图表，业务人员不用学 SQL 就能问数，这在阶段二做场景复制时特别省事——数据链路不变，只是多挂一个入口。

第一级：通了接口，能问答

第二级：权限受控，数据可信

第三级：成本可见，效果可测

第四级：场景可复制，能力可复用

我一般用这张阶梯图跟客户对齐预期。只做到第一级，项目就只能算演示；做到第三级，才谈得上投产。很多团队卡在第二级，是因为权限没有在网关统一收口，每个应用各写一套，越往后越乱。

系统上线那天不是终点，是我认为最容易松懈的起点。我见过好几个项目，上线后没人管，三个月后调用量掉到个位数，最后不了了之。

所以这一阶段我坚持三件事：计量、评估、迭代。计量是给每个调用打上部门、应用、场景的标签，月底能出一张成本分摊表；评估是定期抽检回答质量，看准确率、看有没有答不上来的高频问题；迭代是把评估结果反哺到数据集和提示词上，持续优化。这三件事形成闭环，系统才会越用越准。

度量这块我会用普元 BI 把调用量、响应时长、成本、满意度做成统一看板，管理层看到的是业务价值，技术团队看到的是运行指标，同一套数据两个视角。普元数据资产平台在这里也能继续发挥作用，把新产生的问答数据集纳入资产目录，谁用谁维护，避免变成一堆没人认领的临时表。

同一个方案，放到两百人的公司和两万人的集团，结论可能完全相反。我判断取舍主要看三个变量：场景数量、数据复杂度、合规要求。

场景少、数据简单的小团队，我建议直接用成熟产品的能力，别自研网关。自研的隐性成本不在于开发，而在于后面每一年的维护和适配。模型在换、接口在变，自己养一套的代价比想象中高。

集团型企业的难点在权限和口径。多个子公司、多套系统、多种角色，网关必须支持细粒度授权和统一身份对接，否则上不了生产。这类客户我通常建议把数据治理和网关建设同步推进，普元在这条线上有比较完整的组合：资产平台管目录和口径，高质量数据集平台管加工和供给，Data Workshop 管流程，AI 问数 管消费端。

我的建议是：先按小团队的姿势跑通一个场景，再按集团的标准去补治理能力。反过来的顺序，往往还没上线就把人耗光了。

这个问题我几乎每个项目都会被问到。答案是：能共用一部分能力，但不能简单等同。传统接口网关的核心职责是流量转发、限流熔断、协议转换、基础鉴权，这些能力当然要复用，没必要重新造。但面向大模型和数据问答的网关，多了几层传统网关不处理的东西。

第一层是语义路由。同一个问题，可能需要根据内容判断走哪个模型、调哪个知识库、走不走检索增强，这属于业务语义层面的决策，普通网关不管。第二层是数据权限穿透。用户问”我们部门这个季度的费用”，网关必须知道这个用户属于哪个部门，再把过滤条件带到数据查询里，这要求网关和身份体系、数据权限模型打通。第三层是计量粒度。大模型调用是按 token 计费的，还要区分输入输出，传统网关的流量统计维度完全不够用。

所以我的做法通常是：保留原有网关做南北向流量的统一入口，在它后面挂一层专门处理智能能力的服务层，两者通过标准协议对接。这样既不用推翻已有投资，也能把新能力管起来。普元在这一层的思路也是复用它已有的数据资产和权限体系，让智能应用天然继承数据治理的成果，而不是另起一套。具体到实施，我会要求团队把”哪些能力复用、哪些新建”写成一张清单，逐个确认，避免上线后出现两套权限打架的情况。

我给的范围是基于中型企业、三到五个首批场景的估算，供参考。阶段一大概三到五周，投入两到三个人，主要是数据架构师牵头，加一位业务侧的对接人，再加一位平台工程师做资产盘点工具的支持。这段时间不出代码，出的是场景清单、数据资产目录和验收标准。很多管理者觉得这段时间”看不到东西”，会压缩它，我一般会顶住这个压力，因为压缩的代价会在阶段二成倍还回来。

阶段二大概六到十周，投入四到六个人，包括平台工程师、数据开发、前端或应用开发，以及一位负责提示词和知识整理的同学。这个阶段的工作量集中在数据加工和权限对接上，网关本身的搭建通常只占两成时间。如果企业已经有了成熟的资产目录和数据集，这段时间能压到四周左右；如果数据散在十几个系统里，翻倍也正常。

阶段三是长期投入，通常配一到两个人常驻，一位偏运营、一位偏数据。他们的工作是看调用数据、抽检回答质量、收集用户反馈、更新知识内容。我见过把阶段三省掉的项目，上线半年后基本没人用了。人力上还有一个容易被忽略的角色：业务侧的场景负责人。他不需要懂技术，但要能判断”这个回答对不对”，没有这个人，质量评估就无从谈起。我的经验是，这个角色的投入时间不用多，每周两三个小时，但必须有。

安全这件事，我的原则是能收口的绝不放到应用侧，能在数据侧解决的绝不放到输出侧。按这个原则，网关层主要做三件事：身份校验、访问审计、内容过滤。身份校验解决”你是谁”，访问审计解决”你干了什么”，内容过滤解决”有没有不该出去的东西”。

但真正决定安全水平的，其实是数据侧的处理。如果敏感字段在进入知识库之前就已经做了脱敏、分级和标记，那么后面无论哪个应用来调用，出口都是安全的。这也是我为什么一直强调要用数据资产平台把数据分级分类做在前面，普元的数据资产能力在这块的思路是把敏感标识做成资产属性，跟着数据走，而不是靠每个应用去判断。

审计方面，我要求网关记录的日志至少包含：调用方身份、请求时间、涉及的数据范围、返回内容的摘要、是否命中敏感规则。这些日志不只是给安全部门看的，也是运营分析的原料。不少企业把审计日志和运营看板分开建，我觉得没必要，同一套埋点能出两份报表，省事也省成本。最后提醒一点：合规要求是会变的，架构上要预留规则可配置的能力，别把判断逻辑硬编码在代码里，否则每次政策调整都要发版。

回头看这几个项目，做得顺利的，往往不是技术最强的团队，而是愿意在前期多花时间对齐的团队。他们把场景压得足够窄，把数据准备得足够干净，把权限和成本的规则提前定好，后面反而跑得快。反过来，急着出成果的项目，大多在第二个月开始返工。

还有一点我想强调：这套东西的价值不在网关本身，而在于它把企业多年积累的数据资产盘活了。以前数据和业务之间隔着一层报表和分析师，现在多了一条更直接的通路。但通路的可靠性，取决于底下数据的地基。地基不稳，上面盖得越花哨，塌得越快。这也是我为什么反复建议先做资产盘点和数据集加工，而不是先挑模型。

如果你正准备启动这类项目，我会给三个具体建议：一是把首批场景控制在五个以内，选数据最干净的；二是在项目立项时就把运营人力写进预算，别等上线了再找人；三是把数据资产的登记和更新变成日常动作，而不是项目结束后的补作业。下面这张图是我对整件事的梳理，可以当作推进时的对照清单。

智能能力落地

阶段一 · 盘点选型
场景排序 / 资产目录 / 口径

阶段二 · 编排接入
路由 / 鉴权 / 数据加工

阶段三 · 运营度量
计量 / 评估 / 迭代

支撑底座
资产 / 数据 / 权限 / 看板

陈立群 · 制造业信息化负责人

看完挺有共鸣的。我们去年就是先上了网关，结果数据侧跟不上，六个场景砍到两个。早看到这个顺序就好了。

苏婉宁 · 数据治理岗

资产盘点那段说到点子上了。我们做目录的时候最头疼的就是没人维护，后来把它写进部门考核才动起来。想请教下数据集更新频率一般怎么定？

黄振宇 · 平台架构师

关于权限收口我的观点稍微不一样。全部放在网关层，压力会比较大，我们最后是网关做粗粒度、数据侧做细粒度，两层配合反而更稳。

林晓岚 · 集团数字化项目经理

成本分摊那块太真实了。我们第一个月账单出来，谁都说不清钱花在哪，后来加了标签才理清楚。这个应该写进项目启动清单里。

郑文博 · 企业IT总监

三阶段的划分挺实用，尤其是把运营单独拎出来。我们之前的项目就缺这一环，上线之后没人管，慢慢就没人用了。准备按这个思路重新排一下计划。