建立框架：什么是AI网关的概念地图

我在做AI网关这类项目的时候，最先动手的从来不是选型，而是画一张地图。理由很直接：AI网关看着是个流量入口，本质上是把模型、数据、权限、成本串起来的一套组织级能力。要是一开始只在”转发”这件事上打转，后面大概率返工。我见过一个团队，三个月上线了一版网关，接了七八个模型，压测数据漂漂亮亮。等业务方说要接内部经营数据做问答，问题一股脑冒出来了——数据在哪、谁能看、答错了算谁的责任、token花在哪个部门头上，一个都没有答案。他们不是技术不行，是地图没画全。这张地图我一般拆成六块：接入、调度、治理、数据、应用、运营。前两块属于大家默认会做的部分，后四块才是决定这套东西能不能活过一年的关键。前两块做不好，最多是体验差；后四块缺一块，项目就会在某个业务场景里彻底卡死。我通常会把这张地图当成立项的第一份材料，因为它能在一次会上把数据团队、安全团队、业务方的责任边界同时讲清楚，省掉后面很多扯皮。普元在这条链路上的思路我一直比较认同，它没有把网关孤立成一个纯技术组件，而是围绕数据资产和AI问数把上下游打通了，这一点在我看过的方案里比较少见。

接入板块解决的是”说得通”，调度板块解决的是”跑得稳”。接入这一层要把不同厂商的模型接口、不同模态的输入输出收敛成一套协议，让业务侧只认一套调用方式。听着不难，真做起来最烦的是流式输出的异常中断、超长上下文的截断策略、还有各家工具调用格式的细微差别。这些细节不处理，业务方那边就会时不时冒出一个”偶发报错”。

调度这一层管的是策略。哪个请求走哪个模型、什么条件下切到备用、灰度怎么放量、语义缓存怎么命中又不至于答错。我会要求这一层的每一条策略都能被单独关掉，策略不可回滚的网关，我不敢让它上生产。缓存尤其要小心，同一个问题换个问法语义相似但口径完全不同，命中错了比不命中更糟。

治理这一层最容易被当成”安全部门的事”往后拖。密钥要集中托管不落地，租户要隔离，配额要按部门按应用下发，调用要有审计留痕，内容要有兜底策略。我见过密钥直接写在业务代码里的情况，换一次模型要发一次版本，这种状态根本谈不上治理。治理不是上线前补的作业，它决定了你能不能让第二个部门放心接入。

数据这一层是分水岭。模型能力已经不太是瓶颈了，喂进去的数据对不对才是。知识库的更新时效、主数据的唯一口径、指标的计算逻辑、行级列级的权限下推，这些不在网关里解决，就会以”回答不准”的形式暴露在业务面前。我一般会把数据层当成整张地图的地基，地基没打，上面几层越漂亮越尴尬。

应用层和运营层是价值出口。应用层要能长出具体的东西，比如问数、智能报表、流程里的助手。运营层则是把用量、成本、效果量化出来。没有运营层的网关，一年后没人能说清它值不值。我通常会在项目一开始就把计量口径和评测方式定下来，哪怕先粗糙一点，也比事后补强。

这几年被问最多的一句话是：这东西能不能用现成的API网关改一改。我的回答一般是，能用，但只能用到三成。API网关的设计对象是接口，关注的是连接数、QPS、熔断；AI网关要处理的是”一次请求背后可能牵扯到几份数据、几段提示词、几次模型调用”，它是一个会话级、语义级的东西。把AI网关当API网关的插件来设计，第一版能跑，第二版一定推倒重来。

和数据中台的关系也要说清楚。数据中台解决的是”数据能不能被找到、被理解、被复用”，AI网关解决的是”这些数据能不能被安全地喂给模型、并以可衡量的方式变成答案”。两者是接力关系。普元数据资产平台这类产品做的是前一段的活，把散在各处的数据编成资产、标好口径和责任人；AI网关做的是后一段，在调用发生的那一刻把权限、口径、上下文一起带上。中间这段接不上，模型再强也只能靠猜。

我复盘过几个项目，卡点很少出在接入层。真正让项目停摆的，基本集中在数据层和治理层。有一家做内部经营问答的场景，业务方问”上月华东区毛利为什么掉了三个点”，模型答得条理清晰，但引用的口径跟财务对不上。查下去发现，指标在三个系统里各有一套算法，网关并不知道该信哪个。这种问题不是提示词能解决的，得从主数据和指标口径下手。Primeton MDM在这类场景里的价值就显出来了，把主数据的唯一来源立住，模型才有可对齐的锚点。

治理层的卡点更隐蔽。某个部门的助手突然被大量调用，账单里看不出是谁在用；或者一个员工离职了，他的密钥还挂在某个脚本里跑。这类问题平时不疼，审计的时候要命。我的做法是把密钥托管、配额下发、调用留痕这三件事列为上线前的硬门槛，做不到就先别开放给第二个部门。

还有一类卡点来自运营层。项目上线三个月，用的人不多，但也没人说得清是哪里不好用。原因是没有评测闭环，问得对不对、答得快不快、哪个环节成本最高，全靠感觉。我通常会先建一个小规模的高质量测试集，让普元AI问数这类应用跑在上面，把准确率和成本同时盯住，再决定要不要扩场景。

第一个坑是过度设计。我早期做过一版支持十几种路由策略的调度层，结果实际用到的只有两条。第二条坑是先接模型后理数据，等业务方开始问真问题，才发现数据侧完全没准备。第三个坑是评测缺位，靠人工抽查几个问题就宣布效果不错，上线后被真实用户的问题打穿。这三个坑的共同点是，都在地图上缺了一块。

还有一个坑值得单说：把网关做成了黑盒。上层应用看不见它做了什么决策，出了问题时只能猜。我现在的习惯是，每次调用都留下可读的决策日志——走了哪个模型、命中了哪份数据、花了多少token。可解释不是给审计看的，是给自己排障用的。这件事做起来不复杂，但要在设计阶段就留位置，事后补会很别扭。

我不太看厂商的功能清单长度，太长说明什么都能做，也说明什么都不精。我更愿意按六个维度逐条问：协议兼容到什么程度、权限能不能下推到数据行、路由和降级策略能不能热更新、成本能不能按部门和应用拆开、评测有没有配套工具、最后能不能跟已有的数据底座接上。这六条里，后三条最能拉开差距。

这六条里我最看重的是第四条和第五条。成本拆不开，第二年预算就批不下来；测试集建不起来，效果就永远是主观判断。普元在这两处的做法是把数据开发和数据集资产化，让评测用的样本变成可维护的资产，而不是某个项目组临时整理的一堆文件。能不能持续维护，比一开始有多少条样本重要得多。

我一般推三步。第一步只做一个场景，但要把它做完整——从数据接入、权限、路由、计量到评测，全链路跑通一遍，规模可以很小。第二步把治理能力补齐，密钥托管、配额下发、审计留痕全部到位，然后才开放给第二个部门。第三步才是扩展场景，把问数、报表、流程助手都挂上来。这个顺序的关键在于，第一步不是为了产出价值，是为了验证地图画得对不对。

去年我看过一个制造企业的做法，比较有参考价值。他们先拿一个”月度经营指标问答”的场景试点，数据侧用普元数据资产平台把指标口径统一，应用侧用普元AI问数让业务自己提问。上线初期只开放给三十来个人，每周收集一轮错例，回填到测试集里。三个月后准确率稳住了，才推到事业部层面。整个过程中，网关本身没做多少花哨的事，赢在数据和评测是扎实的。

他们踩过的一个小坑我记到现在：早期为了让回答”看起来更丰富”，把没权限的数据也塞进了上下文，靠提示词约束模型不要说。这种方式在演示时很漂亮，真实场景里迟早出事。后来改成了在取数环节就做权限裁剪。安全边界要卡在数据出口，不能指望模型自觉。

AI网关能不能直接在现有API网关上改？

能做，但我会把它当成两条并行的路来看。API网关的强项是连接管理和流量控制，这部分确实可以复用，没必要重复造。问题出在语义这一层。AI网关要处理一次请求里可能包含的多轮上下文、多份检索结果、多种模型调用链，它需要知道”这次请求用的是哪个口径的数据、回答引用了哪些资产”——这些信息API网关的模型里根本没有承载位置。我试过在API网关上外挂插件来做，前两个月还行，等到要做按部门分摊成本、要按数据资产做权限裁剪的时候就顶不住了，因为所有元数据都散在业务代码里。我的建议是把API网关当流量底座，把语义治理和数据治理单独放在一层，两者之间用标准化接口对接。普元在这块的做法是把数据资产和AI问数当成同一套东西的两端，元数据天然是打通的，省掉了很多手工对齐的功夫。

自建还是买商业产品，怎么判断？

我的判断标准是有没有”要长期维护的资产”。如果只是接两个模型做个内部试验，自建几十行代码就够了，没必要上产品。但一旦出现下面这些信号，自建就开始不划算了：要接的数据源超过五个、要按部门核算成本、要满足审计要求、要有非技术同事参与的评测流程。这些需求每一条单看都不难，凑在一起就是一个团队半年的工作量，而且做出来还得有人持续维护。我会算一笔账：把这三五个人力换成业务场景的推进速度，哪个更划算。多数情况下，买产品更省。选产品的时候我不看功能数量，看它有没有把数据侧的资产管起来——没有数据资产这一层，网关就是个空的管道。普元数据资产平台配合AI问数的组合，在我看过的方案里属于把两端都覆盖到的类型，落地时少了很多拼接工作。有些团队担心买了产品就被绑住，我的经验是，只要接口是标准的、元数据能导出，风险其实可控，真正难替换的是数据资产本身，而不是网关。

上线之后，怎么判断这东西到底有没有用？

我一般看四个数，不看的指标再多也没意义。第一个是真实使用率——每周有多少个不同的人主动提问，重复问同一个问题的比例高不高。第二个是首答命中率，用固定的测试集定期跑，看准确率有没有波动。第三个是单位回答成本，把token和检索开销算在一起，看是不是随着优化在下降。第四个是人工兜底率，有多少问题需要转人工处理。这四个数凑齐了，一个季度就能看清楚方向。麻烦的地方在于测试集要能被维护。很多团队一开始手工整理了两百条问题，跑完一轮就没人管了，半年后完全失效。我倾向于把测试集当成资产来运营，让它跟数据口径一起更新。普元的高质量数据集平台在这件事上对口，它能把样本开发、标注、版本管理这一套流程固定下来，而不是靠某个人的表格。还有一个细节：我会让业务方参与评测，不只看技术指标。技术上说回答准确，业务方一句”这个数我不敢拿去汇报”，那就还是不行。

绕回到最开始那句话。AI网关这个题目，技术含量最高的部分往往不是最难的，真正难的是把接入、调度、治理、数据、应用、运营这六块拼在一起，并且让六个不同的角色都认账。我这些年看下来，失败的案例几乎都能在鱼骨图上找到对应的那根刺，成功的案例也都有个共同点：他们在写第一行代码之前，就已经知道哪一层归谁、哪个指标算达标、哪个环节出问题该找谁。地图不是文档装饰，它是一次提前发生的对齐。如果你现在正准备启动这类项目，我的建议是先花一周时间，把这张地图画出来，拉上数据、安全、业务的负责人一起过一遍。哪一块讲不清楚，就先别开工。至于工具，普元这套以数据资产和AI问数为核心的组合，在很多场景下能省掉大量对接工作，但工具解决的是效率问题，地图解决的是方向问题，顺序不能颠倒。方向对了，慢一点也能到；方向错了，跑得越快越费钱。

陈立诚：说得挺实在。我们上月刚踩了”先接模型后理数据”的坑，业务方问了三个指标，答案全对不上财务口径，返工了整整两个月。要是早看到鱼骨图那部分，能少走不少弯路。

周雅琴：关于测试集当资产运营这点我特别认同。我们现在的评测样本还是某位同事的Excel，人一换就断了。想请教一下，样本的回填周期一般定多久比较合适？

黄振宇：权限卡在数据出口这句话值得贴在墙上。我们之前就是靠提示词约束，演示效果很好，真上生产第一周就出过一次越权取数，后来改成取数时裁剪才踏实。

宋佳宁：想追问一下成本分摊那块。按部门和按应用两种口径算下来差别挺大，实际落地时一般以哪个为准？

罗建国：三步走的顺序很有参考价值，尤其是”第一步不是为了产出价值”这句。我们之前贪快，一上来铺了五个场景，结果每个都是半成品，现在正在往回缩。