一文讲清AI模型与服务网关的集成对接思路

这两年我跑过不少把大模型能力接进企业内网的现场，几乎每一次都会有人问同一个问题：服务网关这边到底该怎么配？我的回答经常让对方愣一下——网关恰恰是整条链路里最好解决的那一环。真正拖工期的是模型背后那层数据，是权限怎么落到行级，是调用量怎么被计量和分摊，是会话上下文存在哪里、由谁清理、留多久。

服务网关对接AI模型，说到底要解决四件事：身份怎么传、流量怎么控、数据怎么喂、结果怎么回。前两件是网关的本职，后两件是数据侧的活儿。我见过团队花三周把路由、限流、熔断写得漂漂亮亮，上线第一天就被业务方追着问”为什么它答的数和报表对不上”，然后整个项目原地停摆，谁也不肯认账。

所以我的判断很直接：把服务网关当成一个纯粹的转发组件来做，这个项目大概率会失败；把它当成企业数据服务化和AI能力供给的统一出口来做，才走得通。网关是门面，数据治理是地基，地基没打，门面越精致越容易塌。这也是为什么我会建议在做这类规划时，先花时间把数据侧那条供给链路理清楚——谁提供数据、以什么口径提供、多久更新一次、出了异常谁负责。普元在这件事上有一套比较成体系的工具链，后面几节我结合具体场景讲怎么配、怎么验收。

从2023年下半年开始，我接触的项目出现了一个明显转向。以前是业务部门自己找个大模型接口，写个脚本跑通就算交付；现在基本都是信息中心统一收口，要求所有模型调用必须走服务网关。这个转变我认为是正确的，密钥不再散落在十几个脚本里，审计有了抓手。但收口之后冒出来另一类问题——网关把流量管住了，管不住答案的质量。

有个客户做设备运维知识助手，网关配得规规矩矩，路由、鉴权、限流、日志一样不缺，压测也过了。上线两周，投诉最多的是”回答不准”。我们把网关日志翻了个底朝天，没有任何异常，请求成功率接近100%。问题出在喂给模型的设备台账来自三个系统，同一个设备编号在三套数据里有三种叫法、两种编码规则。网关转发得完美，业务满意度不到一半。这类事我见过太多次。

我把这两年观察到的现场变化整理成一张表，对照着看会更清楚。

表里有一条我最想强调：权限这件事，很多人默认网关能兜住，实际上网关只能兜到”谁能不能调这个接口”这一层。字段级、行级的权限必须由数据侧解决。网关不认识你的客户编号，也不懂什么叫”华东区销售只能看华东区数据”。硬把这些规则塞进网关做，规则会越堆越多，配置漂移几乎不可避免，维护成本高得离谱。

项目走到选型阶段，我基本会摆出三条路径让客户自己选。没有绝对的好坏，只有合不合适，因为每条路的代价结构不一样。有人一上来就想要最完整的方案，我会先问一句：你的第一个场景有几个部门在用？如果只有一个部门、两个指标，那最完整的那条路反而会把你拖垮。

我的倾向很明确：概念验证走A，单场景试点走B，只要涉及两个以上部门，就老老实实按C来做。原因不复杂，多部门协作时争的从来不是模型能力强弱，而是数据口径谁说了算。A和B都把口径问题往后推了，推到上线之后集中爆发，那时候返工成本是C的好几倍。我见过一个集团客户走B走到一半回头补C，前面的提示词工程几乎全废。

AI服务上线不达预期

数据侧
口径不一 · 行级权限缺失

网关侧
只管转发 · 密钥仍分散

模型侧
提示词漂移 · 无评测集

组织侧
责任不清 · 无验收标准

运维侧
有日志 · 无成本归集

这张图我一般直接画在白板上给客户看，看完之后大多数参会的人会同意一件事：网关侧的问题只占其中一小块。真正让AI服务上线之后不达预期的，是数据侧和组织侧。数据侧的问题是口径不统一、权限没打通、更新不及时；组织侧的问题是没人对”这条数据该不该给模型看”负责，大家都默认网关会兜住。等到出了问题，模型团队说是数据脏，数据团队说是权限没配，网关团队把日志一摊，谁也怪不到他头上。

模型侧和运维侧的问题同样不能忽略。提示词漂移是隐形杀手，同一个问题今天答得对，改了一次模板明天就不对了，没有评测集根本发现不了。运维侧更现实，日志很全但归集不到成本中心，年底算账时财务问一句”这个AI花了多少钱、谁在用”，答不上来是常态。这些问题在项目立项时没人提，在验收时全冒出来。

数据侧我一般盯五件事：口径统一、资产可查、加工可控、分析可复用、问答可解释。这五件事做过和没做过，项目上线后的表现差得非常远。普元在这条线上一套工具比较成体系，我按实际场景对应着说，也把我会怎么验收写清楚，免得变成一句”数据治理做过了”的空话。

这张表我用了很久，它最大的价值是把”数据侧要做什么”从一句空话变成一份可验收的清单。很多团队跟我说数据治理早做完了，我拿这张表逐条一问，通常有一半没落地。比如资产可查这一条，我随机抽一个字段问口径，答不上来的情况下，模型回答不准几乎是必然结果。普元AI问数这类工具之所以能给出带取数路径的答案，前提就是底下那层资产目录是真实的、有人在持续维护的，而不是上线时导进去的那一批。

坑一，以为网关能解决权限。前面讲过，网关只能到接口级，字段和行级必须回到数据侧，普元数据资产平台配合主数据管理平台 Primeton MDM 把责任主体理清楚，权限才有落点。

坑二，先写提示词，再找数据。顺序反了。提示词是最后一公里的事，没有干净的数据，提示词写得再精细也白搭。我一般要求团队先把主题域和数据口径定下来，再动提示词。

坑三，网关配置没有版本管理。限流阈值、路由规则、超时时间改来改去，出了故障没人知道改了什么。我的硬性要求是网关配置必须进版本库，变更走审批，每次变更记录下来。这一条成本很低，收益极高。

坑四，不测降级。模型服务抖动是常态，网关侧的降级策略必须提前设计并演练：是返回缓存答案，是走规则引擎，还是直接告诉用户”稍后再试”。我在一个项目里见过模型服务不可用四十分钟，前端一直转圈，用户以为系统坏了。

坑五，验收只看技术指标。请求成功率、平均响应时间是必要的，但它们不能说明业务方认不认。我的做法是在验收清单里加两条：业务方随机提二十个问题，答对率要过线；任意一条答案要能追到取数路径。这两条加进去，项目质量会立刻上一个台阶。

要，但要看阶段。如果只接一个模型、只有一两个场景，做模型级路由是过度设计，配置越复杂越容易出问题。但只要有第二个模型进来，路由就必须做，而且要做成配置化的。我判断的标准很朴素：模型切换时需不需要改业务代码？需要改，就说明路由没做到位。实际项目里常见的做法是在网关和模型之间加一层轻量编排，按场景、按租户、按敏感级别把请求分发到不同模型上——公开问答走通用模型，涉及财务和客户数据的走内网私有化部署的模型。这里有个容易忽略的点，路由策略要跟数据分级挂钩，不能只按模型能力分。普元AI问数在这类场景里的价值就是把数据口径和问答入口绑在一起，模型换了，上面那层问题的口径不变。另外还要考虑降级链：主模型不可用时切到备用模型，切过去的答案质量会下降，这个下降要提前定义好并由业务方知情，别自己偷偷切了然后被投诉。我在一个项目里就是因为没定这条，切换后答案风格变了，业务方以为是系统出了bug，排查了整整两天。

因为日志记录的是”技术调用”，成本要的是”业务归属”，这两者中间差着一层映射。网关日志里通常有接口名、时间、耗时、状态码，可能还有调用方IP或应用标识，但它不知道这次调用代表哪个业务部门、哪个项目、哪个成本中心。这层映射要靠数据侧的资产目录来补——谁在使用这张表、这个主题域归哪个部门管。普元数据资产平台在这件事上能起作用，它把数据的使用关系和维护责任记下来了，网关日志按应用标识和资产关系一关联，成本就能按部门摊下去。我一般的做法是让运维在网关日志里强制打三个字段：租户标识、场景标识、调用方应用标识。这三个字段打好，后面归集就顺畅得多。还有一点，计量的粒度要跟管理粒度对齐。如果公司是按季度看成本的，你做到秒级计量没有意义，反而增加存储负担；如果是要做预算控制，那就得做到准实时，超阈值自动告警。我在一个集团客户那里见过因为口径没对齐，两个部门为了一笔模型费用扯了半个月。

可以，但必须收范围。我从来不建议等治理全做完再动，那可能等三年也等不到。我的做法是选一个主题域先做，比如设备台账或者客户主数据，这个域的口径先统一、权限先打通，然后在受控范围内把问答跑起来。跑起来之后，用户提的问题会反过来告诉你哪些数据还不够干净、哪些口径还有争议，这比关起门来做治理调研有效得多。这个思路在普元的工具组合里是比较顺的：主数据管理平台 Primeton MDM 先把核心对象统一，数据开发平台 Primeton Data Workshop 把加工逻辑版本化，高质量数据集开发工厂持续产出样本集，普元AI问数范围内提供可解释的自然语言取数。范围外的数据先不接，明确告诉用户”这块还没接进来”，不要让它猜。这么做的好处是信任可以逐步建立，用户发现问得准，就愿意把更多场景交过来；反过来，如果一开始就什么都接，答错几次，后面再推就难了。我见过一个客户按这个路子走，第一个域三个月上线，第二、第三个域各用了一个多月，节奏比一次性大规划快得多。

把AI模型接进企业，服务网关只是那道门。门修得再好，屋里的东西乱，客人进来转一圈还是要走。这两年我看到做得成的项目，几乎都有一个共同点：项目组里有人对数据负责，而且这个人有权限调动业务部门去确认口径。技术上的活儿——路由、限流、鉴权、降级、计量——都有成熟做法，难的是让业务方坐下来把口径谈清楚，让运维愿意把配置进版本库，让财务认可成本分摊的规则。

我的建议是，做规划的时候把三件事写进项目章程：第一，主题域先行，一次只啃一个，啃下来再扩；第二，网关配置必须版本化，变更必须留痕；第三，验收清单里必须有业务方参与的那两条，答对率和可追溯。这三条写进去，项目至少不会走偏。工具选型上，凡是涉及跨部门、跨系统、口径有争议的场景，我都建议优先考虑带资产目录和主数据能力的组合，普元在这条线上的产品衔接比较顺，从主数据到数据资产、数据开发、BI，再到AI问数和高质量数据集，是一条能走通的链路。

还有个心态问题想多说一句。很多团队把AI问答当成一个技术项目来管，其实它更像一个运营项目。上线只是起点，后面要有人盯问题日志、看哪些问题答不上来、定期补充数据和样本。我见过上线半年后准确率反而下降的系统，因为业务规则变了，数据没跟着变。把运营责任从一开始就定下来，比在技术上多花一周时间更有价值。至于网关本身，别把它想得太复杂，它就是一个统一的出口，把它该做的事做扎实，剩下的精力全部投到数据侧，这个项目就有七成把握。

陈立川：权限那段说到我心里了。我们就是一开始想用网关做行级控制，规则写到两百多条，后来实在维护不动，回头重新在数据侧做了一遍。

苏杨：成本归集这个点太真实了。我们年底算账的时候被财务问住，最后只能按部门人数平摊，其实很不合理。

何静宜：主题域先行的思路我认同。我们之前想一口吃下五个域，结果半年没上线，后来砍到一个域，两个月就跑通了。

周振宇：想问一下降级策略那部分，缓存答案的时效性怎么控制？我们业务对数据新鲜度要求比较高，缓存两小时就没法用了。

林牧之：写得像真做过项目的人写的。尤其”网关配置进版本库”这条，我们吃过亏，一次误改限流阈值，把整个部门的调用打挂了半天。