01是什么 / 为什么#gw-what-why
M 个应用 × N 家模型 = M×N 条私接线——格式、鉴权、参数、限流各不同，改模型要动几十处代码。AI 网关坐在应用与各家模型之间：对上给统一接口，对下接所有供应商，接入、路由、成本、安全、观测在这一层集中治理。不止一个模型，就该有一个网关。
区别于普通 API 网关的「LLM 专属六件套」：统一接入/协议转换、按 token 限流、成本归集、语义缓存、护栏/内容安全、AI 可观测。客户说「我有 Kong/APISIX 了」——正确回答不是取代，是在它上面加 LLM 能力，很多产品本就是同一网关的「AI 模式」。多一跳会不会慢？网关转发是毫秒级，而语义缓存命中、就近路由、失败快速兜底整体反而常常更快——大头延迟在模型推理，不在网关。
边界辨析：一张表分清四个概念
| 概念 | 管的是什么 | 和 AI 网关的关系 |
|---|---|---|
| 普通 API 网关 | 通用 HTTP 流量：鉴权、限流、路由 | AI 网关是其「LLM 增强版」 |
| MCP / A2A（协议层） | Agent↔工具、Agent↔Agent 的互操作标准 | 网关是「落地协议 + 统一治理」的位置（第 7 节） |
| 推理服务（vLLM 等） | 单个模型怎么又快又省地跑 | 网关在其之上，管多模型统一治理 |
| 编排 / Agent 框架 | 一次任务里怎么串工具与步骤 | 网关提供统一模型入口与观测，不替代编排 |
记忆锚点:MCP/A2A 是协议、推理服务是引擎、AI 网关是运营管控层——互补不互斥。
02统一接入#gw-unify
网关对外暴露一套 OpenAI 风格接口，对内翻译成各家原生格式——应用只学一种调用姿势，换模型只改 model 一个字段。像万能转接头：带一个欧标插头走遍全球。
各家在 function calling、JSON 模式、多模态、上下文长度上并不一致，网关做三件事：参数映射、能力探测、优雅降级（不支持的特性降级或报清晰错误，个别厂商独有参数支持透传）。要点澄清：网关解决的是「接入」成本，不是「效果对齐」成本——不同模型脾气不同，提示词和输出解析可能要微调，后者靠评估。
虚拟密钥：一把逻辑钥匙管多把真钥匙
真 key 锁在网关的保险箱里，发给应用的是「房卡」：每把虚拟密钥可单独设预算、限速、可用模型范围、有效期，出事一键注销。原厂 key 一旦泄露，账单和数据全裸奔且难吊销——虚拟密钥是企业级管控的地基，也是「最小权限/爆炸半径」在网关的具体落地。
深潜：十步请求链与五层策略栈
把网关拆开看两件事：一条请求进来顺序走哪十步，以及每一步拿身份的哪一层做决策。先看请求链，再看策略栈。
一条请求在网关里走十步
身份侧五层策略栈
| ① 调用身份 | 谁在调 |
| ② 租户映射 | 算哪个租户的 |
| ③ 准入策略 | 允不允许 |
| ④ 资源配额 | 还有没有额度 |
| ⑤ 上游身份 | 用什么身份去调模型 |
像公司报销链，每层各有记录，审计能一层层对上。日志记身份映射与策略版本，绝不记录原始凭据。
03路由与容灾#gw-route
路由就是给请求分诊：医院不会让所有病人都找主任医师。简单问答用便宜模型、复杂推理用强模型，再叠加「哪家现在更快/没限流」——别用杀鸡的牛刀烧钱。
| 策略 | 怎么选 | 典型场景 |
|---|---|---|
| 成本优先 | 按每千 token 价选最便宜的达标模型 | 预算敏感、批量任务 |
| 延迟/负载 | 选当前最快、未限流的后端 | 高并发、实时交互 |
| 质量优先 | 关键请求固定走旗舰模型 | 对错误零容忍的场景 |
| 复杂度路由 | 对请求打分（长度/代码/推理特征）选档位 | 通用降本，零 embedding 依赖 |
| 语义路由 | 按意图用向量相似度选专用后端 | 多专家模型、领域分流 |
实战常叠加：先按语义/复杂度选档位，再在档内按延迟均衡，最后配容灾兜底。降本有论文背书： RouteLLM（LMSYS/Berkeley）训练路由器判断走强还是弱模型，在接近旗舰质量下把大量请求分给便宜模型；FrugalGPT（Stanford）用级联——先问便宜模型、不够好再逐级升级。路由是可控降级：关键场景质量优先，只对可容忍流量降档，用评估持续盯降档流量的质量。
路由省钱计算器
把「路由 + 缓存为什么省钱」算成账。价格是你自己填的口径（默认值只是量级示意，当天价格以官网为准）；节省比例取决于流量结构，先做成本画像再承诺。
容灾：把爆炸半径关进笼子
容灾三件套：
fallback
主挂了自动改走备用模型/供应商，对调用方无感。
指数退避重试
上限 1~2 次封顶——fallback 是保命不是无限重试，别把一个坏请求在多家模型上重复烧钱。
熔断
连续失败的后端隔离一段时间，某路短路空开只跳那一路。
多区域部署再叠一层地域容灾；数据合规用「数据驻留」路由约束强制——某类数据只允许走特定区域的后端，网关是执行这条策略的最佳位置。
容灾还有最后一问：网关自己挂了怎么办
上面三件套保的是「某家模型挂了」，客户接着必问下一句——网关是全流量必经，它挂了是不是全公司的 AI 一起停。分两段答。其一，网关自身无状态、易水平扩展，生产标配是多副本 + 健康检查 + 就近多区域部署，掉一个副本流量自动落到别的副本；不想自己扛可用性，就用云厂商托管网关，把可用性交给云 SLA（Service Level Agreement，服务等级协议）。其二是降级姿态：整条十步请求链要有一个端到端 deadline，并给每一步分配时间与降级策略——否则「没挂但特别慢」比挂了更难交代。
RouteLLM / FrugalGPT 见本模块书单（arXiv 官方链接）；路由与选型的市场侧（三层路由 1:8:1、五约束）见 Model-Landscape 网页版——双向互指：那页定「选哪些模型进路由池」，本页是工程落地件。不可外推边界：两篇论文是各自数据集与模型对上的结论，说明的是「路由降本这条路走得通」，不能外推成某个客户能省多少——省多少只有拿他自己的流量画像测才算数。
04成本治理#gw-cost
LLM 的成本和负载由 token 数决定：一条几万字的长请求抵几百条短请求——按「请求数」限流管不住成本。按用电量收费，不是按开关次数：TPM（token/分）+ RPM（请求/分）双维度限。
花费归集像公司给每个部门发预算卡：每把虚拟密钥挂 TPM/RPM 上限、日/月预算、可用模型范围，网关按 key 记账聚合到团队/项目——月底能出「谁花了多少、花在哪个模型」的账。接进 FinOps 看板后，哪个应用突然涨了、哪个模型性价比低一目了然，再回头调路由策略——成本治理和路由是一对搭档。预算撞线时是「拒绝」还是「降级到便宜模型」，是要和业务约定清楚的产品策略：接近上限先告警、再降级、最后才拒绝。
语义缓存：把相同的问题只回答一次
精确缓存一字不差才命中，换个说法就落空；语义缓存把请求算成向量、按相似度命中——「怎么退货」和「退货流程是啥」是同一个问题，命中即毫秒级返回、零模型计费。阈值是关键旋钮：太松会把「北京天气」和「上海天气」当一个问题答错，太紧几乎不命中。落地清单四条：①按场景分级设阈值；②个性化/实时请求绕过缓存；③缓存键带上租户/权限，避免跨用户串答（既是成本设计也是安全设计）；④监控命中率与疑似错答持续调参。
云上口径核实 2026-09-05：Azure APIM 原生内置「按 token 限流 + LLM 专属策略」（网关侧预估 prompt token 提前拦截 + llm-semantic-cache），来源 learn.microsoft.com；「唯一原生」的说法已被 Apigee 官方页推翻——它同样原生自带 LLM token 策略（PromptTokenLimit / LLMTokenQuota）与语义缓存。缓存输入约 1 折、省约 90% 为三大厂 2026-09 口径（登记于 Prompt-Engineering 模块事实表）。
05安全与护栏#gw-guardrail
所有对模型的请求都经过网关，所以鉴权、脱敏、审计、护栏在这一层配一次就对全公司生效——一处挂、处处生效，不必指望每个开发者都记得做安全。网关是 LLM 流量的安检口。
护栏挂成 pre/post 钩子：请求前（进模型前搜身）做 PII 脱敏、注入检测、敏感话题、越权工具拦截；响应后（出模型后过检）做有害内容过滤、机密信息回收、格式与合规校验——命中就拦截、改写或告警。审计是网关的天然职能：「谁、什么时候、拿什么 prompt、调了哪个模型、花了多少、命中什么护栏」只有网关能一处收全——这是 EU AI Act、NIST RMF 要的「可追溯、可问责」证据链。
诚实的边界要主动讲：护栏不能 100% 挡住提示注入——业界共识是注入无法在模型内根治，网关护栏是纵深防御的一道闸（拦掉大部分已知手法），要配合最小权限、人审关键动作一起用。脱敏会有误报，规则要可配置、可审计、能回溯调优。网关自身也要按高价值资产防护：最小暴露面、密钥库加密、定期红队——安检口本身也要有安保。与 Security 模块的分工：那边出「威胁与对策清单」，网关做「能集中执行的那部分」；红队结论回来调网关护栏阈值。
06可观测#gw-observe
流量必经之路，就是最好的仪表盘：一处埋点就能看见「调了谁、多少 token、多少钱、多快、命中缓存/护栏没有、走了主还是备」——不必在每个应用里各埋一套。
| 支柱 | 通用含义 | AI 网关特有维度 |
|---|---|---|
| 日志 Logs | 每次请求的明细 | prompt/响应（可脱敏）、命中的护栏、路由决策 |
| 指标 Metrics | 聚合的量化趋势 | TPM/RPM、成本、缓存命中率、各模型延迟与错误率 |
| 追踪 Traces | 一次请求的全链路时序 | 网关→路由→模型→（工具/MCP）的端到端 span |
排查实例：「某应用今天变慢又变贵」
看网关面板发现语义缓存命中率掉了、fallback 频繁触发（某家在限流）——几分钟定位，不用翻十个服务的日志。
标准正在收敛：OpenTelemetry GenAI 语义约定 / OpenInference 统一了模型名、token 数、成本等字段——网关按标准吐数据就能接任意 APM（Grafana / Datadog / Langfuse），不锁定。
留存日志三条
脱敏、分级、限权——能看见 ≠ 明文全留。
观测与评估的分工
可观测答「快不快贵不贵」，评估答「好不好」——网关把质量信号纳入观测，就把两者连起来了。
消费与行动层在 AI-Ops，trace id 两层贯通。
07MCP 网关#gw-mcp
Agent 时代流量结构变了：一次任务里除了调模型，还要调大量工具（MCP Server）、甚至委派给别的 Agent——这些流量同样需要统一接入、鉴权、限流、审计。Higress、Agent Router（原 Envoy AI Gateway）、APISIX、 Azure APIM 都在把两者做进同一产品：「AI 网关 + MCP 网关」二合一是 2026 的分水岭。
MCP 网关＝把对「模型」的那套治理平移到「工具」上：统一代理、发现与注册（MCP 市场）、鉴权与授权（最小权限）、限流与配额（防 Agent 失控狂调）、审计与观测（串进同一条 trace）、安全护栏（工具描述投毒检测、危险动作拦截）。存量改造有捷径：openapi-to-mcp 读 OpenAPI 描述批量把现成 REST API 暴露成 MCP 工具——像给旧电器配智能插座，企业几百个 API 几乎零改造就能被 Agent 安全调用，汇成自建 MCP Marketplace。
MCP 授权：窄票替代万能钥匙
难点在「代理身份」：Agent 替用户调工具时，工具那头要知道真正的用户是谁。规范口径（2025-11-25 修订版，OAuth 2.1 底座）：MCP Server 就是一台 OAuth 2.1 资源服务器， audience 校验（RFC 8707）与资源元数据（RFC 9728）是 MUST，PKCE 强制，token 透传明令禁止。网关做 RFC 8693 token 交换：把用户的宽 token 现场换成「audience 限定、最小权限、短时效」的窄票——像演唱会实名制门票，检票口只认本场本人。
| 授权反模式 | 症状 | 网关怎么破 |
|---|---|---|
| Token 透传 | 把用户的宽权限 token 原样转发给上游 | 一律走 RFC 8693 换窄票，上游永远见不到原始 token |
| 混淆代理 | 工具只认网关/Agent 的高权服务身份，谁来调都同一个账号 | 请求级身份传递 + act 委派链，权限判定以最终用户为准 |
| 万能钥匙 | 给 Agent 发长期、全 scope 的静态凭证 | 短时效 + 最小权限 + 虚拟密钥可吊销，爆炸半径钉死在「单工具、几分钟」 |
三合一终态：网关从「模型的统一入口」长成模型 + 工具（MCP）+ Agent（A2A）的中枢控制面。协议机制在 MCP 网页版，Agent 侧的多模型/ 多工具调用在 Agent 网页版——本页讲的是把这些流量统一治理的运营层。
授权规范核实 2026-07-10（来源 modelcontextprotocol.io spec / Red Hat Developer）；现行规范 2026-07-28 已发布：授权侧加了签发方校验、应用类型声明、凭据绑签发方，另新增 Mcp-Method / Mcp-Name 请求头，网关不解 JSON 体就能路由。 Agent Router（原 Envoy AI Gateway）的 MCP 授权、后端安全策略、OIDC token 交换已在正式版发布——是当前最受关注的能力，也是售前要盯的演进点。不可外推边界：路线图上的能力不等于当期可用能力，方案里不能按路线图做承诺。
08选型与问答#gw-cheatsheet
自托管还是托管
| 什么时候选 | 代表 | |
|---|---|---|
| 自托管 | 要多云 / 信创；数据敏感要留在自己边界内；想深度定制；有平台团队扛可用性 | LiteLLM、Higress、Agent Router（原 Envoy AI Gateway）、APISIX、Kong |
| 托管 | 想零运维快速起步；已重度用某朵云；可用性交给云 SLA | Azure APIM、Bedrock、Apigee、Cloudflare AI Gateway |
常见路径：托管起步验证价值 → 规模 / 合规上来后按需转自托管或混合。
选型三条筛
模型与形态
支持你要的模型与部署形态吗。
治理是不是原生的
原生做 token 治理与护栏吗。
跟不跟标准
跟上 MCP 与 OTel 标准吗。
顺带答一个反问：上了网关，会不会反过来被网关锁定
分三层看，答案不一样。接口层不锁——应用只认一个 base_url 和一个 model 名，换网关时业务代码不动，这本就是统一接入的卖点。观测层不锁——按 OpenTelemetry GenAI 语义约定吐数据，接任意兼容后端。真正会锁的是策略层：路由规则、护栏、缓存、配额这些配置各家写法不同，换一家要重配一遍——所以上面三条筛的第三条「跟不跟标准」问的就是它。还要加一层商务锁定：开源 ≠ 免费全功能，哪些能力要企业订阅，选型时就得摊开。
| 产品 | 一句话定位 | 亮点 / 注意（2026-07 口径） |
|---|---|---|
| LiteLLM | 最广泛采用的开源 LLM 代理 | 100+ provider、虚拟密钥、7 维复杂度路由；Python 是性能天花板 |
| Portkey | 开源+托管，主打护栏与缓存 | 开源版带护栏，语义缓存与提示词管理限托管/企业版；「企业版并入开源」的 Gateway 2.0 仍是预发布，2026-05-29 已被 Palo Alto Networks 收购并作为 Prisma AIRS 的 AI 网关（src-portkey） |
| Kong AI GW | 老牌 API 网关的 LLM 插件 | 已用 Kong 的团队天然加装；AI 高级插件需企业订阅 |
| Agent Router（原 Envoy AI Gateway） | Envoy 血统，2026-09 起转入 Agentic AI Foundation，标准派 | v1.0（2026-06-23）；OTel 观测强；provider 覆盖仍在补 |
| Higress | 阿里 AI-Native 网关 | 国内生态全、MCP 能力最激进、含注入检测 |
| APISIX | 云原生 API+AI 网关 | 3.19.0（2026-09-28）支持 MCP 与 Agent 流量治理 |
三云对照一句话：Azure APIM 目前 LLM 网关能力最完整（原生 token 限流 + 语义缓存 + Unified Model API）；AWS 强在 Bedrock 生态（Multi-Provider GW 仅官方 Guidance，自部署）；多云/边缘看 Cloudflare。国内/云原生看 Higress，标准派看 Agent Router（原 Envoy AI Gateway），最快上手 LiteLLM。「开源 ≠ 免费全功能」——Kong 企业订阅这类报价点提前讲。
上线验收：策略有效、失败可控、证据可回放
选完还有一关——怎么算「上得好」。网关最容易被验成「接口通了就算过」，可它卖的是治理，治理没被验证过就等于没有。拆成四条能逐项签字的清单：
| 验的是 | 怎么算过 | |
|---|---|---|
| 权 | 边界与身份 | 责任矩阵、租户隔离、上游凭据轮换——跨租户要真跑一遍，不是画图（第 2 / 5 节） |
| 稳 | 协议与弹性 | 工具调用、结构化输出、流式中断都有回归；重试 / fallback / 缓存不失控——故障注入测过放大倍数（第 3 节） |
| 证 | 策略与观测 | 配额、护栏、路由都有版本与决策日志（影子模式 + 拒绝样例）；trace 能关联到任务结果（第 4 / 6 节） |
| 账 | 运营与升级 | 容量、高可用、回滚、许可证与 TCO（Total Cost of Ownership，总拥有成本）都清楚（第 8 节） |
终极判断只有一句：随手抽一次调用，能不能回答「谁调的、为何允许、路由到哪、花了多少、质量怎样」——这和合规评审要的是同一条证据链，一次采集、两处交差。
现场高频追问
只收会改变某个决定的问题——会改变技术方案、风险判断、验收方法、对客沟通或下一步行动。
每题标出它加入本题库的日期：2026-07-09 来自讲义首版对练页， 2026-07-10 来自 MCP 网关展开章，2026-07-12 来自选型口径复核，2026-07-23 是按客户交锋场景补的三题（网关自己挂了 / 上线验收 / 会不会被网关锁定）。
我已经有 API 网关了，为什么还要 AI 网关？2026-07-09
不是取代，是增强：多了按 token 限流与计费、多模型语义路由、语义缓存、注入/PII 护栏——普通网关没有的 LLM 六件套。很多产品（Kong、APISIX、Higress）就是同一网关的「AI 模式」，平滑升级即可。
这题答成「换掉重建」就把客户推走了——正确姿势是在存量投资上加层，迁移成本近零。
下一步 查客户现有网关是否有 AI 插件/模式，有就按升级路径报，没有再谈新建。
依据 是什么 / 为什么
上网关到底能省多少钱？2026-07-09
自动路由到便宜模型，质量掉了怎么办？2026-07-09
路由是可控降级：关键场景设质量优先固定走旗舰，只对可容忍流量降档；再用评估持续监控降档流量的质量，掉了就调阈值。省钱和质量之间有旋钮，不是赌博。
「降档流量谁来盯质量」是网关方案最常被挑战的点——答案是接评估：网关采样、判官打分、超阈值告警。
下一步 给降档流量配 1~10% 采样评估（方法在 Evaluation 网页版），把质量线写进验收。
依据 可控降级 · Evaluation 网页版
语义缓存会不会给不同用户串答、泄露数据？2026-07-09
会，如果缓存键没带身份。正确做法：缓存键里带上租户/权限维度，个性化和带用户数据的请求绕过缓存。这条既是成本设计也是安全设计。
阈值同理是双刃剑：太松答错（北京天气≈上海天气）、太紧白配——「宁可少命中，别答错」。
下一步 按落地清单四条过一遍缓存配置：分级阈值、绕过规则、键带身份、命中率监控。
依据 语义缓存
护栏能 100% 挡住提示注入吗？2026-07-09
不能，也没有产品能这么承诺——业界共识是注入无法在模型内彻底根治。网关护栏是纵深防御的关键一层，要配合最小权限、人审关键动作、模型外确定性策略一起用。
诚实讲边界反而更专业——「100% 防注入」的承诺本身就是方案不可信的信号。
下一步 把「网关拦已知手法 + 权限控爆炸半径 + 人审兜底」画成纵深防御图，逐层标注证据。
依据 安全与护栏
合规审计具体能提供什么证据？2026-07-09
我们有几百个内部 API，要让 Agent 用，是不是要一个个改造？2026-07-10
不用。openapi-to-mcp 读 OpenAPI 描述批量把存量 API 转成 MCP 工具，再由网关统一托管鉴权限流——存量资产几乎零改造就能被 Agent 安全调用。
「存量资产瞬间对 Agent 可用」是 MCP 网关最实的卖点：不是重写业务，是给旧电器配智能插座。
下一步 挑一个内部 API 做 openapi-to-mcp 试点，挂上鉴权限流，跑通「Agent 经网关安全调用」的完整链路。
依据 MCP 网关
Agent 替用户调工具，权限会不会被放大、被滥用？2026-07-10
这正是 MCP 授权要解决的：网关做 token 交换（RFC 8693），把用户真实身份换成「audience 限定、最小权限、短时效」的窄票——Agent 手里永远没有万能钥匙。
三大反模式（透传/混淆代理/万能钥匙）都有规范级红线：token 透传是 MUST NOT——网关做身份传递有合规依据，不是自选动作。
下一步 对照反模式表审一遍现有 Agent 集成；规范 2026-07-28 已发布， 条款按新版核对。
依据 MCP 授权 · src-mcp-auth
我们该自建还是买托管？2026-07-12
小团队/快验证先用云托管零运维起步；多云、信创、数据敏感或要深度定制，上自托管（LiteLLM/Higress/Agent Router）。绝大多数客户是「托管起步 → 按需转自托管/混合」，不用一步到位。
自托管网关本身会成为单点：要多副本、健康检查、多区域——没有平台团队就别扛，这是路线选择的硬约束。
下一步 按三条筛（模型覆盖/token 治理/标准跟进）列两条路线的对照表，标注客户现状的匹配项。
依据 选型
一句话，AI 网关到底给我带来什么？2026-07-09
网关是所有流量的必经之路，它自己挂了，全公司的 AI 不就一起停？2026-07-23
先把两种「挂」分开，客户常混着问。上游模型挂——这本来就是网关在替你兜：fallback 自动改走备用供应商、熔断隔离连续失败的后端、重试 1~2 次封顶，对调用方无感。网关自己挂——网关是无状态的、易水平扩展，生产标配是多副本 + 健康检查 + 就近多区域部署；不想自己扛可用性，就用云厂商托管网关，交给云 SLA。还有第三件常被漏掉的：整条请求链要有端到端 deadline 和每一步的降级策略，「没挂但特别慢」比挂了更难交代。
这题答不好，前面讲的省钱与治理全白讲——客户脑子里已经把网关画成了新的单点。把「它是不是单点」翻译成「它是不是无状态、能不能多副本」，问题就从架构风险降级成一个部署选项；而选自托管还是托管，本质就是这份可用性由谁扛。
下一步 压测时当着客户的面手动「拔掉」主模型，让他看流量无感切到备用；再把网关自身的副本数、健康检查、多区域方案画进架构图，别只留一个方框。
网关上线，怎么算「上得好」？验收看什么？2026-07-23
和 POC 一个道理：标准事前定死，别上线后再争。一句话是「策略有效、失败可控、证据可回放」，拆成四条逐项签字：权——责任矩阵、租户隔离、上游凭据轮换，跨租户测试要真跑不是画图；稳——工具调用、结构化输出、流式中断都有回归，重试 / fallback / 缓存不失控，故障注入测过放大倍数；证——配额、护栏、路由都有版本与决策日志，trace 能关联到任务结果；账——容量、高可用、回滚、许可证与 TCO 清楚。
网关最常见的验收误区是「接口通了就算过」——可它卖的不是接口，是治理，没被验证过的治理等于没有。四条里最常被跳过的是「稳」：不做故障注入，fallback 与重试的放大倍数要等线上真出事那天才知道，那时候账单和事故一起来。
下一步 POC 启动会上把这四条摆出来逐条认领，并把「故障注入」「跨租户测试」写成要跑的动作、不是要交的文档。
把所有 AI 流量都收到这一层，以后想换掉网关是不是特别难？2026-07-23
分三层看，别笼统答「不会」。接口层不锁：应用只认一个 base_url 和一个 model 名，换网关时业务代码不动。观测层不锁：按 OTel GenAI 语义约定吐数据，接任意兼容后端。真正会锁的是策略层：路由规则、护栏、缓存、配额这些配置各家写法不同，换一家要重配一遍——这正是选型三条筛里「跟不跟标准」要问的东西。再加一层商务锁定：开源 ≠ 免费全功能，哪些能力要企业订阅得先摊开。
「上了你这层会不会被你绑架」是平台类方案的通用异议，网关尤其躲不掉——它自己卖的就是解锁定。诚实分层比一句「不会锁定」可信得多，而且承认策略层要重配，正好把话题引到「选跟标准的产品」这个对你有利的判据上。
下一步 做一次反向演练：把 base_url 指到另一家网关，看应用要改几行；再把「策略配置有多少、换家时要重写哪些」列进选型问卷——这才是换网关的真实工作量。
09上云怎么落地#cloud
前八节讲的是网关这层要管哪些事。这一节换个视角：每件事在云上对应哪个服务、这句话对客户意味着什么、该顺着追问他什么、以及哪些事云替你做不了。顺序按现场画架构图的走法排——先定这层自己放在哪，再往下压成本、挂安全与观测，最后接工具流量。 同一格给多厂商代表选项，不绑死单一供应商；只列讲义点到名的产品，没有就不硬凑。「唯一原生」这类说法已被 2026-09 复核推翻（Apigee 同样原生自带 LLM token 策略），各云能力月级演进，出方案当天按各家当期文档再核一遍。
同一环节给多厂商代表选项，不绑死单一供应商；只列有真实云关联的环节，没有就不硬凑。服务能力以各云 2026 年现状为准，报方案前按当期文档复核。
先定网关自己放在哪，再谈接什么
| 技术环节 | 代表性云服务（多厂商，非绑定） | 给客户一句话 |
|---|---|---|
| 托管网关 | Azure API Management、Bedrock、Apigee、Cloudflare AI Gateway、OpenRouter | 想零运维快速起步、已重度用某朵云，可用性交给云 SLA（Service Level Agreement，服务等级协议） |
| 自托管网关 | LiteLLM、Higress、Agent Router（原 Envoy AI Gateway）、APISIX、Kong | 要多云或信创、数据要留在自己边界内、想深度定制路由与护栏，且有平台团队扛可用性 |
| 统一多模型接口 | Azure Unified Model API（含 Bedrock 后端）；AWS 以 Bedrock 为主，Multi-Provider GW 仅官方 Guidance（自部署）；GCP 侧 Apigee 有部分能力；自托管的 LiteLLM、Higress 同样提供统一入口 | 应用只学一种调用姿势，换模型改一行配置 |
| 路由与容灾 | 各网关内置（路由策略 + fallback + 熔断）；降本方法参考 RouteLLM、FrugalGPT | 这一格没有云独占能力，选型看策略怎么写，不看谁家有 |
顺着追问什么：他现在有没有 API 网关（Kong、APISIX 这类）——有的话很多产品本就是同一网关的「AI 模式」，是加层不是重建，报价完全不同。要接几家模型，跨不跨云、有没有信创要求？数据允许走出自己的边界吗？有没有平台团队能扛网关自身的多副本、健康检查、多区域部署？
云替你做不了什么：托管能把可用性接过去，接不走策略层的账：路由规则、护栏、缓存、配额各家写法不同，换一家要重配一遍——接口层和观测层不锁，会锁的是这一层。云 SLA 保的也只是「网关在不在」，保不了「没挂但特别慢」：整条十步请求链要自己定端到端 deadline，再给每步分配时间与降级策略，否则每层各自耗尽超时，叠出用户侧的分钟级等待。还有一条要在报价前摊开：开源不等于免费全功能，Kong 的 AI 高级插件需要企业订阅。
成本治理：把 token 变成能管的账
| 技术环节 | 代表性云服务（多厂商，非绑定） | 给客户一句话 |
|---|---|---|
| 按 token 限流 | Azure APIM 原生 token limit 策略（网关侧先估 prompt token）；Cloudflare 接 20+ 家 provider + Guardrails/DLP（Beta）；LiteLLM、Higress 内置 TPM/RPM | 超额请求在网关就被拦掉，不必等打到模型才发现爆预算 |
| 语义缓存 | Azure APIM llm-semantic-cache 策略 + Managed Redis；Portkey 托管版、Higress 内置语义缓存；自建可用 Redis + 向量检索 | 意思相近的问题只答一次，命中即毫秒级返回、零模型计费 |
| 花费归集 | Azure APIM 按订阅键与维度统计；LiteLLM 虚拟密钥按 key／团队记账；各云计费导出 | 月底能说清谁花了多少、花在哪个模型上 |
顺着追问什么：他现在的账单能不能拆到应用和团队头上——拆不开就先做一次成本画像，别急着承诺省多少。高频重复问题占多大比例，决定语义缓存值不值得开。预算撞线那一刻，业务能接受降级到便宜模型，还是必须拒绝？额度按团队发还是按项目发？
云替你做不了什么：限流和缓存管住的是花销，管不住质量：切到便宜档的那部分流量得配采样评估盯着，掉了就调阈值。语义缓存的阈值和缓存键这两个旋钮云不会替你拧——太松会把「北京天气」和「上海天气」当同一个问题答错，缓存键不带租户和权限还会跨用户串答，个性化与实时请求要绕过。「Azure APIM 是目前唯一原生内置按 token 限流加 LLM 专属策略的云厂商网关」是一个已过时的时点口径——Apigee 同样原生自带这套策略，各云能力在月级演进，别当成长期结论写进方案。
上线之后：安检口与仪表盘
| 技术环节 | 代表性云服务（多厂商，非绑定） | 给客户一句话 |
|---|---|---|
| 内容安全 · Azure | Azure AI Content Safety（Prompt Shields）+ APIM 策略 | 注入防护加内容分级，直接挂进网关策略里 |
| 内容安全 · AWS | Amazon Bedrock Guardrails | 话题、敏感词、PII 过滤，随 Bedrock 一起用 |
| 内容安全 · GCP | Model Armor + DLP（Data Loss Prevention，数据防泄漏） | 注入与越狱检测加数据防泄漏 |
| 内容安全 · 自托管 | LiteLLM 护栏、Higress 内容安全、NeMo Guardrails | 一处挂载全局生效，多云与信创场景靠它跨云 |
| 观测数据出口 | 按 OpenTelemetry GenAI 语义约定导出到 Grafana、Datadog、Langfuse | 网关按标准吐数据就能接任意 APM（Application Performance Monitoring，应用性能监控），不锁定 |
顺着追问什么：客户是单云还是多云、有没有信创要求——这一句直接决定推托管护栏还是自托管护栏。日志留多久、谁有权看原文（prompt 里往往就带着敏感数据）？合规评审要的那几项证据，能不能从一条 trace 里全取到：谁调的、为何允许、路由到哪、花了多少、命中了什么护栏？
云替你做不了什么：护栏挡不住全部提示注入，也没有哪家产品能这么承诺——它是纵深防御的一道闸，拦掉大部分已知手法，剩下的要靠最小权限和关键动作人审兜住。托管护栏省事但绑生态，换云得重挂一遍；自托管护栏灵活可跨云，代价是自己维护规则，而脱敏规则会误报，要能配置、能审计、能回溯调优。观测这头，云给的是管道和面板，答得了「快不快、贵不贵」，答不了「好不好」——质量那条线得接评估。
MCP：工具流量也收进这一层
| 技术环节 | 代表性云服务（多厂商，非绑定） | 给客户一句话 |
|---|---|---|
| Higress（阿里） | 托管 MCP Server、openapi-to-mcp、自建 MCP Marketplace、工具级鉴权与限流 | 国内与云原生客户目前能力最全的一档 |
| Agent Router（原 Envoy AI Gateway） | MCP 授权、后端安全策略、OIDC token 交换（已在正式版发布） | 标准派首选 |
| Apache APISIX | 支持 MCP 协议、管理 AI Agent 流量 | 已经在用 APISIX 的团队顺路加装 |
| Azure API Management | Build 2026 起提供 MCP 内容安全，把 MCP 纳入统一治理 | 重 Azure 生态的客户不必再买第二套网关 |
顺着追问什么：他有多少存量内部 API 想让 Agent 用——openapi-to-mcp 能批量转、几乎零改造，这句话往往当场就把话题变成一个试点。工具调用要不要带上最终用户身份（决定网关要不要做 token 交换）？一个工具能被哪些 Agent 调、谁批？Agent 失控狂调工具时，限流的额度挂在谁头上？
云替你做不了什么：路线图上的能力不等于当期可用能力，方案里不能按路线图做承诺。网关能把工具流量统一代理、鉴权、限流、串进同一条 trace，替不了工具本身的权限设计：token 透传是规范明令禁止的，混淆代理和万能钥匙这两个反模式也得在每个集成里逐个改掉，网关只负责把宽 token 换成 audience 限定、最小权限、短时效的窄票。
本节服务清单与「给客户一句话」与讲义各章的「上云怎么落地」页同源，未引入新事实；「顺着追问什么」与「云替你做不了什么」两格是网页版补的售前视角。不可外推边界：这是「哪个环节有云服务可用」的地图，不是选型结论——具体产品的地域可用性、配额、计价单位与生命周期状态会月级变动，出方案前按当期官方文档逐项复核。
11来源与核实#sources
本页时效性数字均经联网核实后写入，完整登记（事实 × 核实日期 × 信源）见本模块 MANIFEST。核实窗口 2026-07-09 至 2026-10-20（MCP 授权口径 2026-07-30、Portkey 归属 2026-08-01 补核）。引用任何数字前先核日期。
| 来源 ID | 信源 | 支持什么 | 不能支持什么 |
|---|---|---|---|
src-azure | learn.microsoft.com genai-gateway-capabilities | Azure APIM 的 token 限流与语义缓存能力 | 「唯一原生」说法已被 Apigee 官方页推翻（2026-09），各云月级演进 |
src-litellm | docs.litellm.ai / GitHub | LiteLLM 规模数字（100+ provider、7 维路由） | 版本迭代极快，配置细节看当日文档 |
src-envoy | Tetrate v1.0 博客 / theagentrouter.ai（原 aigateway.envoyproxy.io） | Envoy AI Gateway v1.0 时间线与能力（2026-09 更名 Agent Router） | QuotaPolicy 仍 v1alpha1，不能与核心一并称稳定 |
src-higress | github.com/higress-group / higress.ai | Higress 的 MCP 能力与护栏 | 能力清单随版本演进 |
src-mcp-auth | modelcontextprotocol.io spec 2025-11-25 / Red Hat Developer | MCP 授权规范条款（OAuth 2.1/RFC 8707/8693） | 已按 2026-07-28 规范更新 |
src-portkey | paloaltonetworks.com 新闻室（2026-04-30 宣布 / 2026-05-29 交割） | Portkey 的归属变化与并入 Prisma AIRS 的定位 | 不代表开源版停更或改协议——收购未公布对开源仓的处置 |
src-route | RouteLLM / FrugalGPT（arXiv，见本模块书单） | 路由降本的方法与论文证据 | 具体节省比例依赖流量结构，不能当承诺 |
src-otel | opentelemetry.io semconv/gen-ai | GenAI 观测语义约定收敛趋势 | 约定仍在演进，字段以当日规范为准 |