# 业界模型网关演进调研报告
> 调研目的：梳理业界模型网关（AI Gateway / LLM Gateway / Model Gateway）的演进脉络，覆盖国内外头部云厂商与主流开源项目，明确其细分类型、能力边界与核心功能，为企业内部建设模型网关提供借鉴。
> 初次调研时间：2026-08-14 ｜ **版本：v5.5（再审议最终定稿，第 3 轮终审通过、终稿差异经 Codex 最终复核）** ｜ **更新日期：2026-10-17**
> 本文正文（〇–八章）与附录仅陈述**终态结论**；版本演变与历次审查的过程记录统一收录于**第十一章**。外部产品与协议事实的核验时点以 9.1 各条标注为准，本版复核截至 **2026-10-17**。
---
## 〇、术语与范围界定（工作定义）
本报告所称"模型网关"（AI Gateway / LLM Gateway）采用如下**工作定义**：位于**应用/客户端与多个模型提供方之间**的统一中间层——提供方既可以是**外部模型 API 供应商**，也可以是**企业内部的模型服务与算力池**（与〇.1 的形态 A/B 对齐），以**策略、可观测、成本治理为一等公民**，将散落在业务代码、零散配置、人工流程中的 AI 调用治理能力收敛到标准化入口。
**以下属相关生态，不在本报告"模型网关"范围内**（列出是为避免概念滑移，不含贬义）：
- **模型训练/微调**与 **Agent 业务编排逻辑**（属上层编排框架，如 LangChain/LlamaIndex）；
- **纯客户端 SDK 抽象**（无代理跳转，如 OpenAI SDK / Vercel AI SDK）；
- **单纯聚合计费平台**（如 OpenRouter 的纯计费功能）；
- **云厂商模型推理平台本体**（如 Bedrock 的模型托管本身，仅其网关治理层属本报告范围）。
上述形态与本报告"模型网关"存在交集但**不等同**；网关与路由器、网关与编排层的边界仍在演进（见 4.2），本报告的"必建"建议仅针对上述精确定义。
### 〇.1 两类部署形态的区分
企业实践中存在两类部署形态，二者的能力重心差异显著，混用会导致选型与设计错配。**阅读本报告时须先确定自身属于哪一类**；两者是分析轴而非互斥分类，企业同时使用自有算力池与外部 API 时，应按下游分别适用对应一列：
| | **形态 A：多供应商 API 网关** | **形态 B：私有化多算力池网关** |
|---|---|---|
| 下游 | 外部供应商 API（OpenAI/Anthropic/国内云等） | **企业自有推理集群**（vLLM/SGLang/自研引擎 + 多个 GPU 算力池） |
| 成本本质 | 按 token 计费的**外部账单**（可变成本） | **短期内已有容量为既定投入**（该视角仅适用于短期已有容量的使用决策），token 是容量占用的度量；**电力等可变成本在短期同样存在，租赁、维护、折旧与扩容决策属长期成本** |
| 稀缺性来源 | 预算金额、供应商限速 | **物理算力**：显存/KV 缓存/队列深度——**共享池接近容量时会出现饱和**（是否成为常态取决于容量规划与负载，不作普适断言） |
| 路由目标 | 选"哪个供应商/哪个模型"最划算 | **先选模型/算力池，再选副本**——副本层需 **负载感知与 KV/前缀缓存亲和**（新增一层，不替代模型选择） |
| 故障域 | 供应商宕机 → 跨供应商故障转移 | 节点/副本故障、显存 OOM、排队雪崩 → 副本转移 + **降级到小模型** |
| 数据合规 | 数据出域是核心风险 | **不是"天然满足"而是"需被验证"**：须在外联、日志、备份、运维通道、插件与工具出口均受控的前提下验证数据驻留；重心转为内部数据分级、越权访问与审计（适用法规判断见 8.2 决策点 6） |
| 额度的作用 | 控制真实支出 | **分配稀缺算力 + 引导用量结构**（价值导向） |
**适用性声明**：第一至七章的演进脉络、分类体系与能力清单对两类形态**共同适用**；第八章 8.1–8.4 的建议以形态 A 为默认语境，其在形态 B 下的完整适用性修订见 **8.5.1**（覆盖契约、成本、故障转移、缓存、合规、限流准入与韧性七项）；5.9 的计量/定价/额度三层模型对两类形态均适用，但**定价层的单位须重新选择并明确口径**——可以是货币成本、原始 token 或运营积分；私有化并不禁止货币计价，只是外部单价不再自动等于内部成本（可选方案见 8.5.4，等效算力单位为可选项而非唯一答案）。
---
## 一、摘要
### 执行摘要（一页纸）
**五条结论**（详版七条见下；简版按主题重组，不与详版逐条对应：① 对应详版总述与第 3 条，② 对应第 5 条，③ 对应第 3、5 条，④ 对应第 6 条，⑤ 对应第 7 条；详版第 1、2、4 条的协议、边界与开源格局不在简版单列）：① 模型网关已从"直连"演进为"AI 原生网关 + MCP/Agent 治理"的独立基础设施层；② 建设应以"统一契约入口 + 确定性路由 + 计量采集"为一期底座，content-aware 智能路由与 MCP 工具治理按需二期接入；③ 安全是前提——语义缓存需租户隔离、网关自身是集中化高价值目标、MCP 存在设计级风险；④ 计量·定价·额度是三层而非一件事，业界已有成熟范式与开源实现可直接借鉴，难点在并发一致性而非计费算式（见 5.9）；⑤ **私有化多算力池场景（形态 B）与多供应商 API 场景（形态 A）的能力重心显著不同**——稀缺的主要是物理算力而非预算，路由在选模型/选池之外**新增**"选副本"一层（非替代），共享池接近容量时须启用准入与优先级队列（见〇.1、8.5–8.7）。
**四项必做**：统一契约入口（一期以 OpenAI 兼容为过渡基线并预留中立契约抽象，终态为多协议双向适配，见 8.2 决策点 2；不焊死单一厂商形状）；计量采集 + 预算/配额前置；网关自身韧性（高可用/密钥外部化/降级预案）；额度扣减的原子性与预扣—结算机制（否则预算只是纸面数字）。
**四项风险**：语义缓存跨租户泄露；集中化单点放大；OpenAI 契约漂移；MCP 工具滥用。
> **报告状态与证据边界**
>
> 本报告定位为**行业调研与受控 POC 的研究输入**（本版为再审议最终定稿：第 3 轮终审已按原有通过门槛判为通过，此后仅收口其少数意见并经终稿差异复核，结论不变）。产品能力与许可信息**受所列版本与核验时点限制**；文中工程机制为**设计建议与实施条件**，非已验证的实现方案。**截至本次修订，未取得 8.8 中 T01–T16 的任何执行证据**，因此**额度一致性、调度公平性、缓存收益与计价回算四类结论目前没有运行验证支撑**。实施须在版本、责任角色、阈值与故障语义确定后推进；生产上线以相应验证证据为准，**不得以本报告作为能力已验证的证明**。
（以下为详版结论）
模型网关已经历了从"应用代码直连单一模型 API"到"统一代理层"再到"AI 原生网关 + MCP/Agent 治理层"的三阶段演进。2025 年起，部分主流云厂商与网关厂商的产品从单一的模型代理，扩展为同时治理 **模型（LLM）、工具（MCP）、智能体（Agent）** 的 AI 应用入口（具体产品与能力状态见 6.1、6.3，各产品进度不一）。
关键结论：
1. **协议归一化是地基，但地基在漂移**（详见 2.2、5.1、8.2 决策点 2）：OpenAI 的 Chat Completions 是**当前最广泛实现**的交互形状（2023.03 GPT-3.5-turbo 起，几乎被所有厂商和开源网关作为统一出口），但它是 de facto（事实）而非 de jure（法理）标准——无标准组织、无 RFC；且 OpenAI 已于 2025.03 发布 Responses API 作为面向 Agent 场景的新一代交互形状，并将新能力优先落地于此。Chat Completions 未设弃用时间表，当前官方迁移指南的表述为“**仍受支持，新项目推荐使用 Responses**”；但能力已开始分化——官方指南写明自 GPT-5.4 起，Chat Completions 在 `reasoning_effort` 取 `none` 以外的值时不支持工具调用。**Assistants API 已于 2026-08-26 正式下线**。统一出口仍应建立在"中立契约抽象层"之上，而非焊死在单一厂商形状上。
2. **能力边界在收窄并分层**（详见 3.2、4.4）：AI 网关（管"如何安全合规地调"）与模型路由器（管"调哪个模型最好"）正在解耦；网关与上层编排（Agent 框架）的治理边界仍需企业内部自行厘清。
3. **新一代方向是 MCP/Agent 网关**（详见 7.1、7.2、7.5）：2025 年起，MCP 网关逐渐成为独立品类（AWS Bedrock AgentCore Gateway、Kong、agentgateway、LiteLLM 等）。企业级"网关 + 注册表"已有公开案例（如 Uber 于 2026-10-01 披露其 MCP Gateway 采用 Registry 控制面 + Proxy Gateway 数据面），但这是趋势性判断，不是已确立的标准。MCP 的安全风险须以分层防护为前提：OX Security 将 STDIO 配置信任边界定性为设计级风险；据 OX 转述，Anthropic 认为该执行模型属预期行为、不认同这一定性（见 7.4）。管理面也已出现 MCP 入口，风险随之扩大（见 7.5）。
4. **开源项目百花齐放**（详见 6.3、6.4）：LiteLLM（提供商覆盖面广，且已具语义缓存与 MCP 网关）、Portkey（预算/RBAC/审计等治理功能较完整，开源 core 与企业版的能力划分按拟用版本核对，见 8.3）、Higress（阿里开源，CNCF Sandbox）、One API / New API（国内社区使用较多）、Kong/APISIX（传统网关 AI 化）、Agent Router（原 Envoy AI Gateway，2026-09 更名并成为 AAIF 独立项目）各有定位；**计费/额度平面另有独立品类**（OpenMeter——Kong 于 2025-09 宣布收购、Lago），不必由网关自研，但实时硬限额能力须按版本另行验证（见 6.4）。
5. **对企业自建的核心借鉴**（详见第 8 章）：以"统一契约入口 + 多模型路由 + 虚拟密钥/成本治理 + 可观测 + 安全护栏 + 网关自身韧性"为必建底座；二期补齐语义缓存（含租户隔离）、MCP 注册表与工具级授权；三期再做完整 Agent 生命周期治理。
6. **计量·定价·额度是三层而非一件事**（详见 5.9、6.4、8.2 决策点 9）：业界已收敛出三条实现路线——网关内置"倍率+余额"（One API/New API 系；New API 当前版本另提供带周期重置的订阅套餐）、网关内置"成本预算+周期重置"（LiteLLM/Portkey/Bifrost）、网关只执行限额而额度外置（Higress/Kong/Agent Router + OpenMeter/Lago）。真正的工程难点不在计费算式，而在**并发一致性**：预扣—结算、原子扣减与幂等是必需品，业界已有 TOCTOU 透支与预算误杀的公开缺陷记录可鉴。
7. **私有化多算力池场景需另立一套打法**（详见〇.1、8.5–8.7）：下游是自有推理集群时，**已有容量在短期是既定投入**（电力等可变成本仍然存在，租赁、维护、折旧与扩容属长期成本），因此额度的作用从省钱转为**分配稀缺算力与引导用量结构**，计价口径须另行定义；路由在"选模型/选池"之外**新增一层"选副本"**（按 KV/前缀缓存亲和与队列压力；GIE `InferencePool`+EPP、llm-d、Dynamo 是该层**可评估的规范与实现**，非既成互换标准，且 GIE 自带 EPP 仅为一致性测试参考实现）；在共享算力池且负载接近容量时，**准入与优先级队列**（GIE Flow Control、llm-d 准入/调度分离）是必要能力；治理网关与推理网关应做逻辑职责分层，并以**锁定版本的治理上下文契约**解耦（契约覆盖请求头与请求体扩展字段，由可信层统一重建）；配额计价单位须重新定义（等效算力单位为可选方案之一，须定期标定，且不能替代瞬时容量准入）。配额运营上，**策略定义在 Portal、策略执行在网关**；**治理控制面 Portal 不进入逐请求同步路径**，专用的额度/鉴权/策略服务可按需同步依赖，但须独立设计其 SLA 与降级语义。
---
## 二、模型网关的定义与演进历程
### 2.1 什么是模型网关
模型网关是位于**应用/客户端与多个模型提供方之间**（外部模型 API 供应商或企业内部模型服务与算力池，见〇章工作定义）的统一中间层（智能反向代理），将散落在业务代码、零散配置、人工流程中的 AI 调用治理能力收敛到一个标准化入口。它解决的典型问题包括：多供应商协议差异大、API Key 分散难管理、调用成本不可控、权限边界模糊、日志审计缺失、单点故障引发业务雪崩等。
### 2.2 演进时间线
> 注：下表"意义"栏为报告基于公开信息的归纳判断（非厂商官方定性），带引号的表述为厂商营销话术，仅作语境引用。
| 时间 | 里程碑 | 意义 |
|------|--------|------|
| 2020.06.11 | OpenAI 发布 API（首批开放 GPT-3 系列模型） | 企业开始用自定义代理层包装模型调用，管理成本与策略 |
| 2023 | LiteLLM 开源、Portkey 成立 | "LLM Gateway"成为独立品类，提供统一代理 + 计量 |
| 2023-2024.02 | Kong 推出 AI Gateway（2024.02.15 开源 AI 插件，Kong Gateway 3.6） | 传统 API 网关较早将 AI 能力作为一等公民 |
| 2024.05 | Cloudflare AI Gateway 正式发布（5 月 22 日） | 边缘 AI 网关，定位为"AI 操作的控制平面" |
| 2024.05 | 阿里 Higress v1.4.0 发布，开源 AI 原生插件 | 国内较早体系化开源 AI 网关（AI 代理、内容审核、Token 统计限流插件） |
| 2024.11 | F5 推出 AI 网关抢先体验版 | 集成 NGINX/BIG-IP 安全与交付能力 |
| 2025.09 | Kong 宣布收购 OpenMeter（9 月 3 日） | API 网关厂商把计量计费纳入产品组合 |
| 2025.10 | AWS Bedrock AgentCore GA（10 月 13 日，首批组件见 6.1） | 云厂商网关与 Agent 运行平台组合供给 |
| 2025.10 | Zenlayer AI 网关发布（10 月 28 日） | 网络服务商切入 AI 网关 |
| 2025.12 | Linux 基金会成立 Agentic AI Foundation（MCP、goose、AGENTS.md）；LiteLLM v1.80.8 推出 A2A Agent Gateway | MCP 协议走向中立开放治理；开源网关开始纳管 Agent 调用 |
| 2026.03 | Higress 进入 CNCF Sandbox（CNCF 官方博客 3 月 25 日宣布） | 阿里系 AI 网关社区化 |
| 2026.04 | Databricks 发布 Unity AI Gateway；Kong v3.14 支持 A2A | 数据治理平台与 API 网关同时切入 MCP 治理 |
| 2026.07 | MCP 2026-07-28 规范版本发布（无状态核心、MRTR、移除 SSE 流恢复等，见 7.1） | 协议破坏性升级，网关须处理新旧版本共存 |
| 2026.08 | Azure API Management 推出独立 AI Gateway tier（公开预览）；OpenAI Assistants API 于 8 月 26 日下线 | 控制平面从"围绕 API"转向"围绕模型/MCP/工具"；契约漂移成为既成事实 |
| 2026.09 | Envoy AI Gateway 更名 Agent Router 并于 9 月 10 日成为 AAIF 独立项目；Kong AI Gateway 2.1（9 月 24 日，支持 MCP 2026-07-28）与 2.2（9 月 30 日） | 网关产品开始跟进新版 MCP；Agent 网关项目向中立基金会集中 |
| 2026.09–10 | LiteLLM 发布 LiteAdmin MCP（9 月 23 日）并披露两项管理面安全公告（9 月 30 日、10 月 1 日）；Uber 公开其 MCP Gateway 设计（10 月 1 日） | MCP 延伸到网关管理面；集中化网关的风险不限于供应链（见 7.5） |
### 2.3 演进三阶段
> 说明：三阶段是本报告的**解释框架**，用于归纳演进方向，不代表行业统一历程；各阶段所列能力缺口指当时的常见情形，不对每个产品逐一断言。
**第一阶段（2023 为主）— 直接集成**：应用代码直接集成 OpenAI SDK，API Key 硬编码或简单环境变量管理。单模型、单提供商、零治理。注：2023 下半年 LiteLLM、Portkey 已出现统一代理雏形（第二阶段萌芽），但当年主流实践仍是直接集成，两阶段在 2023 年存在重叠。
**第二阶段（2024）— 统一代理**：LiteLLM、One API 等提供 OpenAI 兼容的统一代理层，屏蔽多提供商差异，解决"多模型接入"。常见短板是治理能力弱（如 YAML 配置难大规模管理、管理界面与组织级策略不完善），具体产品差异较大。
**第三阶段（2025-2026）— AI 原生网关成熟**：Kong AI Gateway、Bifrost、Portkey、Higress 等将 API 网关的成熟治理体系与 AI 特定能力（Token 感知、语义缓存、Prompt 安全、模型路由、MCP 托管）深度融合，形成独立的基础设施层。
---
## 三、细分类型（分类体系）
业界对模型网关存在多套分类视角，综合如下：
### 3.1 网关及相关生态：按部署形态与出身划分
> **口径说明**：3.1–3.3 是**可以交叉的分类维度**，不是互斥类别，更**不构成成熟度排名**。同一产品可同时落入多个格子（例如既是自托管开源网关，也提供托管 SaaS）；3.3 的分组沿用社区习惯说法，仅表示常见归类，不代表优劣次序或成熟度。
| 类型 | 定位 | 代表 |
|------|------|------|
| **自托管/开源网关** | 部署在 VPC/本地，部署边界由企业控制（实际数据控制仍取决于日志、外联与插件配置） | LiteLLM、Portkey(开源版)、Bifrost、Helicone、Higress、APISIX、agentgateway、Agent Router |
| **托管 SaaS 网关** | 云托管端点，底层基础设施由厂商运维（策略、密钥与事件响应仍需企业自理），数据流经第三方 | OpenRouter、Cloudflare AI Gateway |
| **传统 API 管理平台的 AI 扩展** | 在既有 API 治理体系上叠加 AI 能力 | Kong AI Gateway、Apigee、Azure API Management AI Gateway tier、Solo.io Gloo AI、F5 AI Gateway、Tyk |
| **云厂商推理平台**（相关生态，不属本报告网关范围；其网关治理层属范围内，见 6.1） | 单云统一模型访问，原生集成 IAM/模型目录 | AWS Bedrock、Microsoft Foundry（原 Azure AI Foundry）、GCP Vertex AI |
| **推理调度层**（形态 B 的 L2，见 8.5.2） | 在推理集群前按负载与 KV/前缀缓存选副本、做容量准入 | GIE 兼容实现（如 GKE Inference Gateway）、llm-d、NVIDIA Dynamo |
| **客户端 SDK 抽象**（相关生态，不属本报告网关范围） | 无代理跳转，库级别多模型切换 | OpenAI SDK、Vercel AI SDK（LangChain 等含编排能力的框架归入〇章所述编排层） |
### 3.2 按功能角色划分（网关 / 路由器 / 聚合器）
- **聚合器（Aggregator）**：一套 API + 统一计费接入海量模型，如 OpenRouter、Eden AI。
- **代理网关（Proxy Gateway）**：OpenAI 兼容代理 + 治理，如 LiteLLM、Portkey、Cloudflare AI Gateway。
- **智能路由器（Smart Router）**：按质量/成本/延迟自动选择模型，如 Martian、Not Diamond、Unify。
- **API 网关（API Gateway）**：传统网关 AI 化，如 Kong、APISIX；基于 Envoy 的 Agent Router（原 Envoy AI Gateway，2026-09 更名并成为 AAIF 独立项目，见 6.3）同属基础设施网关一类。
> 关键认知：**网关与路由器解耦**是成熟企业的常见组合——底层用基础设施网关统一策略与可观测，上层叠智能路由层做按质量/成本/延迟的模型选择。网关管"如何安全合规地调"，路由器管"调哪个模型最好"。
### 3.3 国内社区常见的分组
- **第一组（纯网关，OpenAI 兼容）**：One API、New API、Portkey、LiteLLM。
- **第二组（应用开发平台，相关生态，不属本报告网关范围）**：Dify、FastGPT、LobeChat 等，常被社区与网关并列讨论，但属〇章排除的编排/应用层。
- **第三组（商业产品中的网关治理层）**：Cloudflare AI Gateway、Apigee（Google）、Azure API Management AI Gateway tier、AWS Bedrock AgentCore Gateway。
---
## 四、能力边界
### 4.1 AI 网关 vs 传统 API 网关
传统 API 网关管理的是"固定端点 + 预定义请求模式"的 Web 流量；AI 网关面向模型与智能体服务，额外提供：语义缓存、Token 级成本归因、Prompt 生命周期管理、护栏（guardrails）、多供应商故障转移。核心差异还体现在：
- **计量单位从"请求次数"转为"Token"**：成本与资源消耗取决于输入/输出 Token 数，而非请求数。
- **数据流从"请求-响应"转为"流式（SSE）"**：需实时转发增量响应，对并发与传输效率要求更高。
- **性能与稳定性**：推理计算密集、响应时间长，需智能流量控制与异常检测。
- **安全合规增强**：细粒度访问控制、数据加密、敏感信息过滤、多认证与审计机制。
### 4.2 网关 vs 编排层（争议边界）
行业报道在讨论 Azure AI Gateway tier 时提出过一个开放问题（据 InfoQ 2026-08 报道，此处的归纳属作者判断）：**"治理 AI 流量"与"治理完整生命周期"是两回事**。当一个 Agent 运行未干净收尾时，其产出是否保留以供审计、是否由网关兜底重试，这涉及"Agent 输出所能改变之物的授权边界"应放在网关还是上层编排层——业界尚无定论。一个可操作的初步划分：**以流量治理（鉴权/限流/计量/审计）为主 → 网关；以 Agent 生命周期（状态/重试/编排/收尾）为主 → 编排层；重叠区按"谁先触发、谁兜底"划分**，企业内部据此明确而非笼统"自行厘清"。
### 4.3 网关候选能力清单
> 本表是**候选能力全集**，不是"公认应有"的共识清单；哪些属一期基线、哪些按需建设，以 8.1 的分期为准，具体产品能力随版本而定。
| 维度 | 能力 |
|------|------|
| 接入 | 多模型统一接入、协议归一化（OpenAI 兼容）、协议双向转换（OpenAI⇄Claude⇄Gemini） |
| 路由 | 模型名路由、负载均衡、故障转移（Fallback）、A/B/金丝雀、按成本/延迟/质量路由 |
| 安全 | 中心化密钥管理、虚拟密钥（Virtual Key）、多租户 RBAC、PII 脱敏、注入检测、内容审核 |
| 成本 | Token 级计量、预算/配额、多级费用归属（客户→团队→虚拟Key→供应商）、**额度引擎（套餐发放/优先级消耗/结转/周期重置）**（见 5.9） |
| 限流 | 基于 QPS 与基于 Token 的双重限流 |
| 缓存 | 精确匹配缓存 + 语义缓存（向量相似度，需按租户隔离） |
| 可观测 | 日志、指标、分布式追踪，OpenTelemetry GenAI 语义约定 |
| 工具/Agent | MCP 服务器托管、工具路由、MCP 新旧协议版本协商、A2A（Agent-to-Agent）、OpenAPI→MCP 自动转换 |
### 4.4 动态路由与计量的层位归属（路由 / 计量 / 网关的边界）
**结论（存在两种范式，非统一共识）**：业界对"路由与计量应否内聚网关"存在两派——**内聚派**（LiteLLM、Portkey、Bifrost 等网关厂商，路由 + 计量皆做在网关内）与**外置派**（Not Diamond、Martian 等路由厂商，主张智能路由独立于网关、架在网关前）。两派立场与其商业定位相关，企业应结合自身取舍，而非视为"已收敛的统一范式"。
**判断准则**——区分「决策 vs 记录」、区分「确定性决策 vs 学习型决策」：
| 能力 | 本质 | 主流做法 | 备注 |
|------|------|----------|------|
| 计量（用量、倍率、plan） | 记录 | 数据采集在网关（choke point），计费规则/对账可在独立计费平面 | 采集与结算可分离 |
| 按组织/用户/标签、繁忙度、规则式复杂度路由 | 确定性决策 | 多数网关内置（virtual key/team、usage-based-routing-v2、complexity_router） | 治理上下文也可由外部 IAM/策略系统提供 |
| content-aware 学习型选路 | ML 决策 | 独立路由层外置（Not Diamond、Martian、RouteLLM） | 系路由厂商立场，非中立共识 |
**为什么计量采集通常在网关**：网关是请求必经的 choke point，是采集 token 用量与归属（谁）最自然的点位；业界主流（New API 三层倍率 `配额消耗 = (输入 token + 输出 token × 补全倍率) × 模型倍率 × 分组倍率`、LiteLLM 的 `input/output_cost_per_token` + `max_budget` + virtual key/team）确在网关内实现。但这**不等于**计量只能内聚——"网关采集 + 独立计费数据湖结算"（chargeback 系统、BI、Stripe Billing）是同样合法且常见的范式，尤其适用于复杂对账/多级结算。关键是区分「采集（ingest）」与「结算（settle）」两层。
**为什么路由分两档**：
- **确定性路由**（按组织/用户/标签、繁忙度、规则式复杂度、fallback）多在网关内实现：按组织/用户/标签 → virtual key/team 的 model allowlist；按繁忙度 → LiteLLM `usage-based-routing-v2`（路由到 least-utilized 副本）；按任务复杂度（规则式）→ LiteLLM `auto_router/complexity_router`（SIMPLE/MEDIUM/COMPLEX/REASONING 分档；官方博客称 v1.94.x 起的 Auto Router v2 把复杂度、语义与自适应路由合并到同一入口，并可选 LLM 分类器——启用后即属学习型决策，应按下一档评估）。其**优势**在于治理上下文与路由决策同处一条请求路径（延迟低、一致性强），但这并非逻辑必然——若治理上下文由外部 IAM/策略系统（如 OPA、自建权限中心）提供，确定性路由同样可外置；内聚是工程权衡而非定义使然。
- **content-aware 智能路由**（Not Diamond、Martian、RouteLLM）外置为独立决策层：这是 ML + 数据问题（模型格局每月变化、需持续重训、有 per-request 决策开销需专门评估），与网关的治理/可观测职责不同质。注意：Not Diamond 主张"路由应独立、架在网关前"是其**作为路由厂商的自我定位**，含商业立场，采信时需独立评估。
**对企业自建的借鉴**（详见第 8 章）：一期网关内聚「计量采集 + 确定性路由 + 虚拟密钥」、计费结算可按需外置；content-aware 智能路由按需二期外置接入。取舍原则：计量采集留网关、结算可外置；学习型路由不焊进网关。
> 本节为层位归属的**判断框架**，其工程实现形态（倍率如何定义、套餐与重置如何落地、采集与结算如何切分）见 **5.9**；该节亦提供了"采集在网关、结算在独立计费平面"这一范式的具体开源证据（含 Kong 于 2025-09 宣布收购开源计量计费平台 OpenMeter，见 6.4；该事实只证明产品组合关系，不证明二者的集成架构）。
### 4.5 安全威胁模型（收敛）
网关建设的安全风险在正文各处有散点论述，此处收敛为一张威胁清单，便于系统性评估：
| 威胁 | 场景 | 缓解（对应章节） |
|------|------|------------------|
| 跨租户数据泄露 | 语义缓存相似命中、RAG 检索越权 | 缓存键含租户标识与授权域 + 物理分区（5.5）；RAG 越权须在检索数据源执行文档/对象级授权，缓存隔离不能替代 |
| 缓存投毒 | 对抗样本污染共享缓存 | 缓存准入策略 + 租户分区（5.5） |
| 网关沦陷（集中化放大） | 供应链投毒、内部恶意管理员 | 供应链门槛、密钥外部化、降级预案（8.2 决策点 8） |
| Prompt 注入（含经工具返回值的间接注入） | 恶意提示或工具输出绕过策略 | 护栏外置、硬约束而非提示词（5.6）；策略引擎只能强制**已定义、可判定**的权限与动作约束，不构成注入的充分防护 |
| MCP 工具滥用 | 不可信 MCP 服务器、工具描述投毒、STDIO 启动命令执行 | 注册表 + 工具级授权、默认拒绝；STDIO 启动命令白名单、进程隔离与出口约束（7.4、8.1 二期） |
| 令牌透传与混淆代理 | 网关/MCP 服务器把收到的客户端令牌转发给上游 | 校验令牌受众绑定，上游使用独立令牌——MCP 授权规范（2025-06-18）明确禁止透传；工具 allowlist 之外由业务系统执行资源级授权（7.4） |
| 管理面越权 | 管理 API、管理用 MCP 工具被低权限主体或受注入的模型调用 | 管理面与数据面分权、只读默认、高危操作审批；按目标版本对照安全公告（7.5） |
| 调度控制参数伪造（形态 B） | 调用方自带优先级、公平域、缓存域等字段（请求头或请求体扩展） | 可信层剥离并重建全部治理上下文（8.6.2 第 12 项） |
| 额度耗尽攻击（denial-of-wallet） | 盗用密钥或重试风暴耗尽预算/算力 | 主体级限额、异常调用检测、应急份额不可重复领取（5.9.5 ⑤、8.6.4） |
| 供应商故障 | 单供应商宕机 | 故障转移/降级（5.2） |
| 凭证泄露 | 虚拟密钥/供应商主密钥泄露 | 虚拟密钥 + 短期凭证 + 异常检测（5.3） |
| 协议漂移 | OpenAI 能力向 Responses API 倾斜（Chat Completions 仍受支持但新能力已分化，Assistants API 已于 2026-08-26 下线）；MCP 2026-07-28 破坏性升级 | 中立契约抽象层（摘要结论 1、8.2 决策点 2） |
> 已知反面教训：LiteLLM 2026.03 PyPI 供应链攻击；OX Security 2026.04 对 MCP STDIO 配置信任边界的风险披露（定性存在分歧，见 7.4）；LiteLLM 2026-09-30、2026-10-01 两项管理面安全公告（低权限用户提权至代理管理员、凭证字段别名导致本地文件读取，见 7.5）。这些都是集中化网关/协议生态的典型风险事件，选型与建设时须纳入上述威胁模型。
---
## 五、核心功能详解
> 本章 5.1–5.8 为核心功能逐项说明，5.9 为计量·定价·额度治理专题；私有化场景的能力差异见 8.5–8.8。
#### 5.1 统一接入与协议归一化
以 OpenAI Chat Completions 为当前主流交互形状（非稳定法理标准，见摘要结论 1），将 Anthropic（messages 接口）、Gemini（generateContent）、各国内厂商的差异在网关内部转换。典型差异点：system 消息位置、工具调用（tool_use vs tool_calls）、多模态（parts.inline_data）、流式事件增量结构。需正视**能力取舍**：Anthropic 扩展思考、Gemini 原生多模态、o 系列推理 token 等无法映射进 OpenAI 形状的能力，应提供"**原生协议透传 + 强制治理**"——保留原生负载形状，但仍经过强制鉴权、限额与审计；网关无法解析的字段须显式限制或拒绝，而非默认放行。
#### 5.2 智能路由与高可用
按模型名直达、按成本/延迟/质量动态选路、供应商故障自动降级与重试、负载均衡。**跨供应商故障转移不是纯可用性动作**：切换前须重新校验目标模型对该主体的授权、数据驻留与敏感数据外发条件，不满足时按契约拒绝或降级，不得为保可用而越过数据边界。
#### 5.3 虚拟密钥与访问控制
中心化管理供应商密钥，向不同团队/应用分发独立虚拟密钥，实现精准策略控制，缩小**供应商主密钥**泄露爆炸半径。注意其边界：虚拟密钥本身泄露仍授予攻击者以该租户配额/策略下的模型访问，其安全性依赖网关自身的认证授权与密钥存储；须配套短期凭证、调用方身份绑定与异常调用检测，而非把虚拟密钥当作认证终点。
#### 5.4 Token 级成本治理
每请求记录 Token 用量，按团队/应用/用例打标签，支持内部结算（chargeback）与超支告警。
#### 5.5 缓存（三类须分别设计）
**须区分三类缓存**：① **精确响应缓存**（哈希匹配，复用完整答案）；② **语义响应缓存**（向量相似度匹配，复用"相近问题"的答案）；③ **前缀 KV 缓存**（推理引擎层复用 prefill 中间状态，如 vLLM APC）。三者的正确性条件、隔离要求、失效规则与收益计算**完全不同**，不可合并设计或合并计算收益：响应缓存的键除租户外还须绑定**授权域、模型与版本、提示模板版本、检索知识/工具数据版本、影响输出的生成参数**，否则会出现同租户内跨权限命中与陈旧知识命中；前缀 KV 缓存**不直接复用历史答案，但不能据此推出其安全**：仍须按信任域设计缓存隔离、缓存身份组成与哈希安全，并评估时序侧信道——vLLM 官方为此提供 `cache_salt`（使缓存共享限定在显式约定同一 salt 的信任组内，并"防止攻击者通过观察延迟差异推断缓存内容"的时序攻击），同时提示使用非密码学安全哈希会增加碰撞风险、在多租户环境下"甚至可能泄露隐私信息"。若采用盐隔离，**信任域映射必须由可信网关/调度层决定，不得允许调用方通过伪造共享标识加入他人缓存域**（见 8.8 T09）。其收益仅作用于 prefill。以下讨论的是①②（网关层）：精确哈希匹配 + 向量相似度匹配（LiteLLM、Bifrost 等均提供语义缓存，见 6.3），命中时可省去一次完整的上游调用，收益取决于实际命中率——个性化流量高的场景命中率可能很低；本报告不引用未经同条件实测的加速倍数或默认阈值。**安全约束（必备前置）**：缓存键必须包含租户/用户标识并按租户物理分区，默认不跨租户共享；建立缓存准入策略（不缓存含 PII/凭据/个性化字段的响应）；设定 freshness 窗口与失效触发并监控误命中率——否则"语义相似即复用答案"构成跨租户泄露通道（该通道的存在属机制推论，本报告不引用任何未溯源的量化比例）与缓存投毒风险（学术界已给出量化证据：CacheAttack 黑盒碰撞攻击在 LLM 响应劫持上达到 **86% 命中率**，见 9.1 #39）。**可参照的开源实现**：LiteLLM 的语义缓存原生提供 `semantic_cache_scope` 隔离维度（默认 `key`，可选 `end_user`），即"缓存键含租户标识"在主流网关中已是可直接复用的能力，而非只能自研（见 5.9）。
#### 5.6 安全护栏
PII/DLP 脱敏、Prompt 注入检测、内容分类与审核、schema 校验。策略应优先在模型推理回路之外强制执行（AWS 用 Cedar、开源用 OPA/WASM），使约束成为硬限制而非提示词建议；但需区分"硬约束（策略引擎强制）"与"软提示（heuristic 插件，如内容审核/提示词装饰）"两级——开源网关的硬约束需额外工程投入，并非开箱即用。
#### 5.7 全链路可观测
聚合所有供应商的日志、Token 计量、延迟、错误率，支持审计留痕与合规。
#### 5.8 MCP/工具治理（新）
MCP 服务器托管、OpenAPI→MCP 自动转换、按工具粒度的授权与审计、凭证代管（网关持有上游凭证，模型/用户不直接接触明文）。
### 5.9 计量、定价与额度治理：Token 套餐 / 模型倍率 / 重置规则
> 本节是 4.4「计量的层位归属」判断框架的实现层下沉。核心结论：这三件事在业界**不是一个功能，而是三层**，各家差异主要在于"三层分别放在哪"。
#### 5.9.1 概念模型：先把三层拆开
| 层 | 回答的问题 | 典型形态 |
|---|---|---|
| **计量 Metering** | 这次调用用了多少 token、算在谁头上 | 网关 choke point 采集 usage + 归属标签 |
| **定价 Pricing** | 这些 token 值多少钱/多少额度 | 倍率制 或 价目表制 |
| **额度 Entitlement** | 该主体还能不能用、什么时候回血 | 预付余额 / 周期预算 / Grant + 结转 |
```mermaid
flowchart LR
subgraph GW["网关（请求必经点）"]
M["计量 Metering
input/output/cache token
+ 归属(who)"]
E["执行 Enforcement
准入检查 / 拒绝
预扣 + 结算"]
end
subgraph PR["定价 Pricing"]
P1["倍率制
模型×补全×分组"]
P2["价目表制
per-token 单价"]
end
subgraph EN["额度 Entitlement"]
Q1["预付余额/钱包"]
Q2["周期预算+重置"]
Q3["Grant+优先级+结转"]
end
M --> PR --> EN --> E
```
**关键认知**：**治理入口负责主体级策略执行**（身份、权限、额度准入），**计量可由网关与推理引擎协同采集**，**容量准入由 L2/推理层负责**；但**定价与额度既可内聚网关、也可外置**——这正是下述三条路线的分岔点，也印证了 4.4「采集（ingest）与结算（settle）应分层」的判断。
#### 5.9.2 三条主流实现路线
**路线 A：网关内置"倍率 + 余额"（国内社区常见做法）**
代表实现 One API（Go/MIT，维护状态待核）→ New API（Go，**AGPL-3.0**），三层倍率齐备，有较多二次开发 fork 沿用（**须区分"独立实现同类设计"与"复用其代码、文档等受保护内容"两种情形；后者按目标版本与实际使用、部署、分发方式逐案审查，本报告不提供许可结论**）：
| 倍率 | 作用 | 官方示例 |
|---|---|---|
| 模型倍率 ModelRatio | 不同模型的基础计费乘数 | GPT-4o=1.25、GPT-3.5-turbo=0.25、o1=7.5 |
| 补全倍率 CompletionRatio | 抹平输入/输出价差 | GPT-4o=4、GPT-3.5-turbo=1.33 |
| 分组倍率 GroupRatio | 用户等级差异化定价（套餐分层的实际载体） | VIP=0.5、标准=1.0、试用=2.0 |
官方计费公式：`配额消耗 = (输入Token + 输出Token × 补全倍率) × 模型倍率 × 分组倍率`；固定价格模型为 `模型固定价格 × 分组倍率 × 配额单位(500,000)`。额度单位为内部"配额点"，锚定 **1 USD = 500,000 配额点**；倍率优先级为"用户个人倍率 > 分组倍率 > 系统默认 1.0"。
One API 的"套餐"并非一等对象，而由三个原语组合而成：**余额（配额点）+ 兑换码（等价于售卖套餐包）+ 分组（等价于套餐等级）**，本质是预付余额制，**不带周期性重置**，"包月 N token、每月 1 号重置"需自行加定时任务。**New API 当前版本已补上这一缺口**：官方《钱包与订阅》文档列出订阅套餐，重置周期可配置为不重置、每日、每周、每月或自定义，到达重置时间后清零已用额度并开始新周期，到期前不再设置越过订阅结束时间的重置。**仍须按目标版本核对**重置的执行方式、与余额的扣减顺序及并发语义——文档与源码存在不等于运行正确（见 5.9.5）。
**路线 B：网关内置"成本预算 + 周期重置"（国际主流）**
| 实现 | 额度单位 | 重置语义 | 层级 |
|---|---|---|---|
| **LiteLLM** | USD（`max_budget`）+ `soft_budget` 预警 | `budget_duration` 支持 `30s/30m/30h/30d/1mo`（`1mo` 为日历月、每月 1 日重置）；**不设则永不重置**；《Budget Reset Times and Timezones》称预算在配置时区的午夜重置，多窗口 `budget_limits` 则按 UTC 日历对齐（`24h` 每日、`7d` 每周一、`30d` 每月 1 日）——**重置时点与时区按作用域和版本而定，须按目标版本逐项核对** | key / 内部用户 / team / team member(`max_budget_in_team`) / organization / tag / `model_max_budget`（覆盖的作用域层级较多） |
| **Portkey** | **USD 或 token 数量二选一**（少见地原生支持按 token 售卖额度） | 不重置 / 每周日 00:00 UTC / 每月 1 日 00:00 UTC；带 Alert Threshold 告警不阻断 | API key / workspace / virtual key |
| **Bifrost** | USD（`max_limit`）+ 并行的 token/请求限额 | `reset_duration`（如 `1d/1M/1Y`）默认滚动，另有 `calendar_aligned` 日历对齐（d/w/M/Q/Y）；支持 `override_amount` 临时提额 | Customer → Team → Virtual Key → Provider Config，**逐层检查、任一层不过即拒** |
> LiteLLM 有两条易踩的规则（官方《Budgets, Rate Limits》，2026-10-17 核对）：① **key 归属 team 时只强制 team 与 team-member 预算，key 所有者的个人预算不生效**；文档记载 v1.94.0 曾短暂对 team key 同时强制个人预算，v1.95.0 已撤回。② **未配置数据库时，全局 `max_budget` 检查 fail-open**（仅启动时告警、请求不被拦截），key/team/user 预算则完全无法执行。
**路线 C：网关只执行限额，定价与额度外置**
| 实现 | 机制与关键配置 | 缺口 |
|---|---|---|
| **Higress `ai-quota`** | Redis 计数（key = `chat_quota:` + consumer），配合 `ai-statistics` 取 token 数；管理接口 `/quota`（查）、`/quota/refresh`（置为定值）、`/quota/delta`（增减，支持负数） | **官方文档未提供周期性自动重置**，需外部定时任务调 `/quota/refresh` |
| **Kong `ai-rate-limiting-advanced`** | `tokens_count_strategy` 支持 `total_tokens`/`prompt_tokens`/`completion_tokens`/**`cost`**；`window_type` 支持 sliding/fixed；可按 provider 分别配额；超限 429 + `X-AI-RateLimit-Retry-After` | advanced 系列属企业版能力（与 6.3"开源版高级 AI 功能受限"一致） |
| **Agent Router**（原 Envoy AI Gateway） | Envoy Global Rate Limit + dynamic metadata；token 类型支持 `InputToken`/`OutputToken`/`TotalToken`/**`CEL` 自定义表达式** | 纯限流语义，无额度账本 |
> **一个值得注意的等价关系**：Agent Router 的 CEL 表达式（如 `input_tokens * 0.5 + output_tokens * 1.5`）与 New API 的"补全倍率"在数学上等价——一个写在限流配置里，一个存在倍率表里。这说明"倍率"并非国内特有发明，而是 token 异质计价的通用解法。
#### 5.9.3 模型倍率：两种定价范式
| 范式 | 代表 | 优点 | 缺点 |
|---|---|---|---|
| **倍率制**（相对基准） | New API 三层倍率、Agent Router CEL 权重 | 新增模型只配一个数；做分组折扣/内部加价天然方便 | 与供应商真实价格脱钩，上游调价需维护倍率表；对账需反推 |
| **价目表制**（绝对单价） | LiteLLM `input/output_cost_per_token`、Kong `cost` 策略、Bifrost | 与供应商账单直接可对账，财务口径清晰 | 模型多时维护量大；折扣/加价需额外一层 |
**建议**：企业自建取**两者叠加**——底层存真实单价（用于成本对账与 FinOps），上层加一层倍率/折扣系数（用于内部分摊与套餐分层）。只做倍率会丧失与供应商账单对账的能力；只做单价则难以表达"研发团队 8 折、试用团队 2 倍"这类内部治理诉求。**缓存 token（cache read/write）须作为独立计价项**，不可并入 input——主流供应商已单独定价。
#### 5.9.4 重置规则：四种语义不可混用
| 语义 | 定义 | 代表实现 | 适用 |
|---|---|---|---|
| **滚动周期** rolling | 从上次重置起算 N 时长 | Bifrost 默认 `reset_duration`（LiteLLM 时长型 `budget_duration` 的对齐方式按版本核对，见 5.9.2） | 按 key 生命周期计费 |
| **日历对齐** calendar-aligned | 固定落在自然日/周/月边界 | Bifrost `calendar_aligned`、Portkey 周日/1 号 00:00 UTC、LiteLLM `1mo` 与 `budget_limits`、New API 订阅的日/周/月周期 | 与财务月对齐、内部结算 |
| **订阅锚点** anchor | 以订阅开始日为锚点周期性补发 | OpenMeter `recurrence.anchor`、Lago recurring top-up | 对外售卖套餐 |
| **滑动窗口** sliding | 任意连续 N 时长内的用量上限 | Kong `window_type=sliding` | 防突发，**属限流不属套餐** |
**三个必须在开工前定义清楚的边界条件**（多数自建项目在此翻车）：
1. **时区**：UTC 还是本地？LiteLLM 预算按配置时区午夜重置、多窗口 `budget_limits` 按 UTC 对齐（按作用域与版本核对，见 5.9.2），Portkey 硬编码 UTC——跨国团队不显式约定，"月底"会差 8 小时。
2. **结转**：清零、全结转还是封顶结转？建议直接采用 OpenMeter 的统一公式表达，而非 if-else 堆叠：`重置后余额 = MIN(maxRollover, MAX(重置前余额, minRollover))`。
3. **多份额度并存时的消耗顺序**：赠送额度、月度套餐、加油包同时存在时先扣谁？**必须显式定义优先级**（OpenMeter：`priority` 取 0–255，**数值越小优先级越高、越先扣**，同级近过期先扣；Stripe credit grants 同样以 priority 排序，实现时须核对其数值方向）。此规则一旦上线极难变更。
#### 5.9.5 工程难点：难在并发与一致性，不在算式
**① 承诺逐请求硬额度的方案，预扣—结算是必需品而非优化项**：token 数只有响应结束才知道，因此 New API 采用"请求前按预估值预扣 → 响应后按实际 token 结算 → 差额多退少补"三步。若要承诺硬额度而不做预扣，高并发下额度就是纸面数字；只做事后计费与 showback 的方案不受此约束。
```mermaid
sequenceDiagram
autonumber
participant C as 客户端
participant G as 网关
participant R as 权威账本/额度服务
participant P as 上游（供应商或引擎）
Note over C,P: 本图仅示意「非流式正常路径」；流式与异常见 8.6.4 图与 T05
C->>G: 请求
G->>R: 预留（按最大可计费消耗，非乐观估算）
alt 预留不足
G-->>C: 拒绝（或按契约进入降级分支）
else 预留成功
G->>P: 转发（强制对应输出上限）
P-->>G: 响应（含 usage）
G->>R: 提交结算（权威账本；差额释放）
G-->>C: 响应
end
Note over G,R: usage 缺失时记为 unknown，保留预留待核对，不得直接释放
```
**② TOCTOU 竞态可致额度"无限透支"**：one-api / new-api 均有公开 issue 记录——`PreConsumeTokenQuota` 的"读快照→检查→扣减"三步无互斥，并发请求可同时通过检查；启用 Redis 时实扣被放入后台 goroutine 异步执行、主流程立即返回，进一步放大竞态窗口；批量更新模式下进程崩溃还会永久丢失扣费记录。社区给出的修复方向为：Redis Lua 原子脚本、SQL 下界约束（`quota >= 0`）、数据库事务、退出前 flush 队列。**但须明确其能力边界——见下方 ⑤，这些手段解决的是"单点竞态"，不构成系统级一致性保证**。
**③ 特定版本中预算强制可能读到陈旧计数而误杀（目标版本待核）**：LiteLLM 有公开 issue 记录预算检查读取 Redis 预留计数器与 DB 实际 spend 背离，出现"实花 $30.45 / 上限 $35 却报 330 次 BudgetExceededError"，后续版本提供 `disable_budget_reservation` 缓解；另有"重置后 Redis 计数未失效导致继续超限""`1mo` 在 user 与 team member 上行为不一致"等记录。**启示**：硬上限与软告警必须分开设计，硬上限路径走原子计数器、不走缓存快照。
**④ 流式与 usage 缺失**：new-api 有公开 issue 记录流式 `/v1/responses` 在 `response.incomplete` 时丢弃 usage，导致该请求**计费为 0**。自建须覆盖三种异常：客户端中断、上游超时、供应商不返回 usage（应以本地 tokenizer 估算兜底，并标记为"估算、待对账"，不可默认 0，也不可冒充真实消耗，见下方 ⑤ 第 7 条）。
**⑤ 原子操作解决什么、不解决什么（本节最关键的一段）**
"Lua 原子脚本 + SQL 约束 + 事务 + 退出 flush"常被并列为额度正确性的解决方案，**但它们不构成系统级一致性保证**。逐条界定：
| 手段 | 确实解决 | **不解决** |
|---|---|---|
| Redis Lua 原子脚本 | 单实例内"读—判—写"的竞态 | ①跨 Redis 与 DB 两个存储的原子性（预扣成功但账本写失败）；②主从切换丢失已确认写入——Redis 官方明确即使使用 `WAIT` 也不构成强一致的 CP 系统；③估算不足导致的透支 |
| SQL `quota >= 0` 下界约束 | 余额被写成负数 | **已经发生的推理消耗**。约束只阻止记账写入，不阻止算力已被消耗——此时应记录欠账而非丢弃成本 |
| 数据库事务 | 单库内多表的一致提交 | 跨服务提交（网关 / 额度服务 / 推理引擎）、应答丢失后的重试去重 |
| 退出前 flush 队列 | **优雅退出**时的队列残留 | SIGKILL、节点失联、磁盘故障。**因此"至少一次投递"不能由 flush 证明**，需写前日志/持久事件或事务 outbox，并定义提交点、确认与去重 |
**必须一并承认的逻辑缺口（非实测，属协议层反例）**：设余额 100、10 个并发请求各预扣 10 全部通过，若实际各消耗 30，则最终需结算 300——**原子预扣全程正确，仍产生 200 缺口**。**须注意：仅限制单请求输出上限并不足够**——10 个请求各预留 10、即使每个被限制最多消耗 30，总消耗仍可达 300；输出有上限只提供了可计算的边界，并不自动把该边界绑定到账户已提交的预留。因此硬上限的成立条件应表述为：
> **硬上限要求：所有获准执行请求的最大可计费消耗，都被已提交的预留所覆盖，并由引擎或可信执行路径强制约束。** 可采用「按最大输入及输出等费用预留 + 强制对应上限」，或「在新增消耗发生前完成分段追加预留，并界定不可取消的在途消耗」。**不能被覆盖的部分必须纳入显式、有界的透支，并不再声称零超支**；计量覆盖不到的请求类型不提供精确硬上限保证。
**由此产生的设计要求清单**（研究报告只列条件，具体方案由实施阶段选定并经 8.8 验收）：
1. **指定权威账本与提交点**：Redis 是准入加速层还是记账权威？二者不一致时以谁为准、如何重建？
2. **区分预留（reserve）/提交（commit）/释放（release）/未知（unknown）四种状态**，并定义预留超时的处置——**预留超时不等于"推理未执行"**，需与推理侧执行记录对账后才能释放。
3. **事件与标识分层，且事件 ID 唯一不足以保证幂等**：业务调用 ID、执行 attempt ID、reservation ID、事件 ID/事件类型须分开；仅用"请求 ID 作幂等键"无法表达同一请求上的预扣、结算、退款三类事件，也无法表达重试导致的多次真实推理。**须特别注意**：若超时重试时重新生成 event ID，同一笔提交仍会入账两次——因此要求为：**同一业务操作的重试复用稳定幂等键**；除 event ID 去重外，**权威账本必须约束 reservation 的合法状态迁移**（同一 reservation 不得重复提交，也不得同时提交与释放；多次合法调整须使用独立的调整操作 ID）。
- **`unknown` 的含义须写死**：它表示"执行结果/结算情况待核对"，**不是可以释放余额的另一种终态**；unknown 请求应保留其关联的有效预留，待恢复后由权威核对流程决定提交或释放（见 8.8 T02）。
4. **跨周期归属**：跨月的结算与退款必须归属**原额度周期**，不可直接加回当前余额，否则等于凭空增发新周期额度。
5. **计价可重算**：历史重算需固定价目表版本、倍率版本、标定版本与舍入规则，仅有"生效时间"不足。
6. **fail-open 的诚实表述**：对核心业务在额度服务不可用时放行，等价于**允许有界应急透支**，必须定义每主体/每实例的应急额度、有效期、并发上限与全局敞口，以及恢复后的补扣与补扣失败处理；**不能同时宣称"超支归零"**。**全局敞口要真正有界，应急份额必须预先分配、不可重复领取**：若每个实例启动时都可领取一份应急额度，扩容与反复重启会让总敞口随实例数和重启次数无界增长。因此须记录份额的发放与归还，恢复后先对账，并对已失联的旧实例做 fencing——旧实例失去新增执行与修改权威状态的权限；其迟到上报的用量不直接入账，也不被丢弃，而是作为待核证据交由当前权威对账流程核对后入账；未确认的在途敞口不得回收再发。具体方案与阈值留待 POC（8.8 T14）。
7. **流式与取消闭环**：SSE 场景下"完整响应→结算"的时序图是简化表示。需补：流开始、首字节、终帧 usage、客户端断连后的取消传播与取消确认；客户端断连不等于上游停止计算；网关侧 tokenizer 估算**看不到**未送达输出与部分推理 token，**估算值必须标记为待对账而不能冒充真实消耗**；私有化场景应优先从推理引擎补取真实 usage。
> 上述 ②③④ 均引自项目**公开 issue**，反映的是特定版本下的已知缺陷，用于提示自建设计要点，**不代表这些项目当前仍存在该问题**；若作为选型依据须按目标版本复核修复状态（见 9.1 #33–#36）。⑤ 中的 Redis 一致性边界引自 Redis 官方复制文档（9.1 #61）；其余为协议层推演与设计要求，非实测结论。
---
## 六、国内外头部厂商与开源项目对比
### 6.1 国际云厂商
| 厂商 | 产品 | 定位与特色 |
|------|------|-----------|
| **AWS** | Bedrock + **AgentCore**（平台 2025-10-13 GA） | 可组合平台，各组件**发布状态不同**（据官方 Release Notes，2026-10-17 核对）：Runtime（Firecracker 微 VM 会话隔离）、Gateway（API/Lambda/MCP 转工具，2026 年起增加可配置限流、推理目标与 HTTP 透传目标）、Memory、Identity、Observability、Browser、Code Interpreter 随平台 GA；**Policy**（自然语言或策略即代码，编译为 Cedar 在网关层强制，2026 年起可接 Bedrock Guardrails）与 **Evaluations** 于 2025-12 预览、2026-03 GA；**Harness** 2026-04 预览、2026-07 GA；**Registry** 2026-04 预览、2026-08 GA；Web Search 工具 2026-07 GA；**Payments 自 2026-05 起为预览**。框架与模型无关。局限：复杂度与成本高、会话隔离有额外开销、地域可用受限、部分组件与 Bedrock 生态绑定。 |
| **Microsoft** | Microsoft Foundry（原 Azure AI Foundry）+ **APIM AI Gateway tier**（2026.08 公开预览） | 独立门户与专用层级，控制平面围绕"模型/MCP 服务器/工具"组织；可接入 Foundry、Azure OpenAI、AWS Bedrock、Google Vertex、OpenAI、Anthropic 等模型，以及由现有 MCP 服务器、OpenAPI 定义或连接器生成的工具；同一端点提供 Chat Completions 与 Responses，Anthropic 模型走 Messages API 透传。遥测以 OpenTelemetry token 用量指标导出到客户后端，**当前仅提供 token 用量一项指标**，日志与追踪尚未提供。**截至 2026-10-17 仍为公开预览，仅 East US 2 / Sweden Central 两区域，无 SLA**（官方 Quickstart，页面更新于 2026-08-11）。 |
| **Google** | **Vertex AI**（Model Garden + Agent Builder + Model Armor）+ **Apigee**（网关治理层）+ GKE Inference Gateway（推理调度层，见 8.5.2） | ADK（开源；Alphabet 2026 Q2 财报电话会称累计下载"接近 7000 万"，为累计口径、属厂商自述）、Agent Engine 运行时、Session/Memory Bank；企业连接器经 Apigee；VPC Service Controls、CMEK；模型无关（Gemini + 第三方 + 开源）。产品命名以官方当前页面为准。 |
| **Databricks** | **Unity AI Gateway**（2026.04；当前官方文档称 **Unity Gateway**，2026-08-04 宣布 GA；据同日 Release Notes，service policies、agent services 等能力仍为 Beta，2026-10-12 推出的 Skills API 亦为 Beta——**平台 GA 不代表全部子能力 GA**，子能力状态须逐项核对） | 据厂商博客：将 Unity Catalog 的治理模型（权限、审计、策略）扩展到模型/Agent/MCP/skills 运行时，提供花费上限、智能路由、内容护栏，并称可治理 Claude Code、Codex 等外部编码 Agent（均为产品自述，硬上限语义与适用范围须按版本核验）。 |
| **Cloudflare** | Cloudflare AI Gateway（2024.05 GA） | 边缘部署的 AI 网关，提供边缘观测与数据驻留相关控制（PoP 数量与延迟开销均为厂商口径，未入来源表，待核；不用于选型比较）。2026-09-30 另以封闭测试推出 **Monetization Gateway**，通过 x402 协议在 HTTP 请求流中处理代理访问 API、MCP 工具等资源的支付授权——属相邻生态，不等于 AI Gateway 已具备该能力（见 7.5）。 |
| **IBM / MuleSoft** | 企业 API 管理与集成平台 AI 扩展（具体产品名与能力未在本报告核验，待核） | 对接大型企业既有 IT 架构，帮助传统企业平滑导入 AI 流量治理。 |
### 6.2 国内云厂商
> **证据边界**：本表以二手资料为主（9.1 #20），最后核验时点为 2026-08，本版未逐项复核。除阿里云外，各行描述的是**模型/应用平台自带的治理能力**，属相关生态；"定位与特色"列只描述厂商宣称的能力入口，不构成认证范围或合规效果的证明。
| 厂商 | 产品 | 定位与特色 |
|------|------|-----------|
| **阿里云** | 百炼（DashScope）+ 云原生 API 网关 + **Higress** | 双轨：百炼提供模型调用/应用编排/API Gateway，Higress 作为开源 AI 原生网关（MCP 托管、OpenAPI→MCP、语义缓存、内容安全）。企业级提供 WAF/KMS/IDAAS 集成（厂商宣称）。 |
| **百度智能云** | 千帆（ERNIE + AppBuilder） | 平台侧自带模型调用治理能力，多租户、多模型路由、审计；可私有化、信创适配（厂商宣称）。 |
| **腾讯云** | 混元 + 大模型知识引擎 | 以企业知识问答切入，混元调用 + 向量检索，与微信生态/多模态集成。 |
| **华为云** | ModelArts Studio + 盘古 | 深度适配昇腾硬件与盘古大模型，服务政企客户。 |
| **火山引擎** | 火山方舟（豆包）+ Coze 企业版 | "应用+模型+数据"一体，鉴权/配额/审计，与抖音生态集成。 |
| **天翼云** | 息壤（大模型应用服务模块） | 内置模型服务网关，支持多厂商大模型接入，面向政务金融等敏感场景；"数据不出域"与等保/密评认证为厂商宣称，**认证对象、范围与日期待核**，不能据此推断客户部署满足相应控制要求。 |
> 国内现状（**社区观察，无抽样调查支撑，不代表市场份额**）：国内较常见的一种组合是"平台 API + One API/New API 私有化"，把多家云合在一张内部 OpenAI 协议入口之后，再加一层内部治理（成本、审批、数据分级）。需注意：这一组合本身只覆盖接入与计费，**一期必建的安全基线**（身份与权限、数据分级、最小留存、访问审计，见 8.1）以及二期的 MCP 工具治理与语义层检测，须按目标版本逐项核对；New API 的 README 未声明 MCP 与 Guardrails（未声明不等于不存在），One API 的维护状态待核。这些缺口是自建/选型要补齐的，而非已达标的终态。
### 6.3 开源项目对比
| 项目 | 语言 | 协议/许可 | 定位 | 特色 | 局限 |
|------|------|----------|------|------|------|
| **LiteLLM** | Python | MIT（仓库中企业功能目录另有许可，按拟用版本核对） | 提供商覆盖面广的 LLM 代理 | 100+ 提供商、统一 OpenAI 格式、虚拟密钥+团队管理、按延迟/成本/用量路由；**多层预算与周期重置**（`max_budget`/`budget_duration`，见 5.9）；**语义缓存**（`redis-semantic`/`qdrant-semantic`/`valkey-semantic`，且原生带 `semantic_cache_scope` 租户隔离）；**MCP 网关**（统一端点 + 按 Key/Team/User 的工具级权限，开源版可用）；**A2A Agent Gateway**（v1.80.8，2025-12-06 起）；LiteAdmin MCP（2026-09-23，经管理 API 管理密钥、模型与预算） | **性能：未做同条件对比，待 8.8 T12**（不以语言运行时特性推断吞吐）；预算强制依赖 DB/缓存，**特定版本有误杀与重置失效的 issue 报告，目标版本待核**（见 5.9）；**2026-09-30、10-01 两项管理面安全公告**（CVSS 9.9 提权、8.1 本地文件读取），选型须对照受影响版本（见 7.5） |
| **Portkey** | TypeScript | MIT（开源 gateway 仓库；企业版另含治理增强，**本表所列能力须按拟采用版本核对**） | 治理功能较完整的网关 | 1600+ 模型、RBAC、审计日志、缓存/护栏/可观测一体化 | 社区较 LiteLLM 小 |
| **One API** | Go | MIT | 国内最早的开源 LLM 网关 | 多用户/分组、计费系统、兑换码、国内供应商覆盖广 | 维护状态待核（应以最近发版、提交与安全响应日期判定）；无周期重置 |
| **New API**（One API 的演进分支） | Go | **AGPL-3.0**（经核验主分支 LICENSE；**历史版本许可须回查对应 commit**） | One API 的活跃演进分支 | 三层倍率与额度账本、兑换码、**订阅套餐与周期重置**（当前官方文档）、OpenAI⇄Claude⇄Gemini 双向转换、缓存命中成本核算 | README 未声明 MCP、Token 压缩、Guardrails；**AGPL 义务须按实际修改与分发方式评估**（见本表下方许可口径说明） |
| **Higress** | Go(Envoy/Istio) | Apache 2.0 | 阿里 AI 原生网关 | Wasm 插件热更新、MCP Server 托管、OpenAPI→MCP、语义缓存、Token 限流、内容安全；CNCF Sandbox | 基于 Istio/Envoy 偏重，Wasm 调试不如原生 Go |
| **Kong AI Gateway** | Lua（OpenResty） | Apache 2.0（开源版；社区报告 3.10 起未见开源构件，官方开源发版政策待核） | 企业 API 管理 + AI | AI Proxy/AI Transformer、Prompt 工程插件、语义缓存/路由/防护（语义缓存等属企业版插件）；AI Gateway 2.1（2026-09-24）支持 MCP 2026-07-28，2.2（2026-09-30）称新增按模态计价与 MCP 服务器聚合（厂商自述） | 开源版高级 AI 功能受限；拟用版本的许可与可得性须先确认 |
| **Apache APISIX** | Lua | Apache 2.0 | 云原生网关 AI 化 | ai-proxy/ai-rate-limiting/ai-prompt-decorator/ai-prompt-guard/ai-rag 插件，ASF 治理 | 无语义缓存、无虚拟密钥预算；**MCP 支持薄弱**——`mcp-bridge` 仅做 stdio↔SSE 协议桥接且已被官方标记 deprecated、不建议新部署，`openapi-to-mcp` 尚在演进；AI 能力常需自写 Lua 插件 |
| **Agent Router**（原 **Envoy AI Gateway**） | Go/C++ | Apache 2.0 | 基于 Envoy 的基础设施网关；原为 CNCF 下的 Envoy 子项目，**2026-09-10 起成为 AAIF（Agentic AI Foundation）独立项目**；当前 1.x（1.0 于 2026-06 作出 1.x 兼容承诺，1.1 于 2026-08 发布） | 提供 OpenAI 兼容 API 与 MCP 端点；token 限流基于 Envoy Global Rate Limit + dynamic metadata，支持 Input/Output/Total 及 **CEL 自定义权重**（等价于"倍率"，见 5.9） | 提供商覆盖面须按 1.x 版本核对（原版"5+"已过时，不再采用）；仅限流语义，无额度账本 |
| **Bifrost** | Go | Apache 2.0 | 性能优先网关 | 官方自测 11µs 开销@5000 RPS（t3.xlarge）、语义缓存(Weaviate)、四层预算、MCP 支持、1000+ 模型 | 提供商集成较 LiteLLM 少、社区小；性能数字为厂商自测基准 |
| **Helicone** | - | 开源 | 可观测优先代理 | Drop-in 日志/缓存/路由，轻量 | 治理能力较浅 |
| **agentgateway** | **Rust** | Apache 2.0（项目章程规定新贡献采用 Apache-2.0） | **统一数据平面**（LF Projects 托管；是否属于 AAIF 未见一手来源） | 官方定位覆盖 HTTP/gRPC、**LLM**、MCP、A2A：15+ LLM 提供商接入、限流/超时/重试/负载均衡、JWT 与 API Key 鉴权、外部授权、**cost controls（预算与支出追踪）**、内置指标/追踪/访问日志 | 具体能力缺口须按**目标版本**核验（如额度账本粒度、Portal 集成、私有化部署适配），本报告未实测 |
| **OpenRouter** | - | 闭源 SaaS | 聚合器 | 400+ 模型、60+ 供应商、统一计费 | 5.5% 平台费、非开源 |
> 开源安全备注（2026 年）：LiteLLM 曾发生 PyPI 供应链攻击（2026.03），其官方安全公告所述事后处置（签名、第三方审计与公开复盘）公开透明度相对较高；但"善后做得好"不等于前置安全性高——2026-09/10 又有两项管理面安全公告（见 7.5），选型仍应独立核验其供应链与管理面防护。Bifrost/Portkey/Helicone 的签名与 SBOM 发布情况本报告未检索核实，选型时按目标版本自行查证，不以本报告作为其"有或无"的依据。
> **许可评估口径**：AGPL-3.0 的义务取决于**是否修改、如何部署、是否对外分发或以网络服务形式提供**三项事实；其第 13 条以"修改版本"与"通过网络与用户远程交互"为触发条件，因此"内部使用"不是当然豁免——内部员工经网络使用修改版本时同样需要评估。企业内部私有化部署与对外 SaaS 的义务差异很大，须由法务按实际形态判定，不能仅凭许可名称排除或接纳。本报告涉及的 AGPL 项目包括 New API 与 Lago。此外，**开源版与商业版能力须分列**：本表中 Kong/APISIX/Portkey 等行混合了开源版与企业版能力，用企业版能力为开源方案打分会高估其可用性，选型时须按拟采用的版本重新核对。
### 6.4 计量计费与额度平面（外置结算的开源/商业实现）
若采用 5.9 路线 C（网关只做计量采集与限额执行、套餐与结算外置），下列项目是业界现成可复用的"结算平面"。其额度语义的完整度显著高于各网关自带的预算功能，自建时**其概念模型可供借鉴**（不等于可直接照搬实现）：
| 项目 | 许可/形态 | 额度语义关键能力 | 对网关建设的价值 |
|---|---|---|---|
| **OpenMeter**（Kong 于 2025-09-03 宣布收购，官网署名 **OpenMeter by Kong**） | 开源（许可按仓库核对） | Entitlement/Grant 模型：`amount`、`priority`（0–255，0 最高，高优先级先扣、同级近过期先扣）、`expiration`+`effectiveAt`、`recurrence{interval, anchor}` 周期补发、`issueAfterReset`、**作用于单个 grant 余额**的结转 `minRolloverAmount`/`maxRolloverAmount` | 额度语义在同类中较完整；其结转公式可表达清零/全结转/封顶结转/保底补足四种策略。**两点须注意**：① 该公式作用于**单个 grant 的余额**而非账户总余额，"月初总可用额度"还需叠加旧 grant 结转、到期清理、新 grant 发放与在途预留；② 官方说明其 entitlement 引擎按**分钟粒度**预聚合历史用量，发放/重置/过期等时间点**不支持亚分钟精度**。**证据边界**：时间戳精度与并发预留原子性是两个不同维度，**该证据不足以证明整个产品缺乏逐请求控制能力**，正确表述是"**已核验文档尚不足以证明其满足本报告要求的并发 reserve/commit/release 保证**"——因此在未对目标版本的接口与一致性做验证前，不得将其作为硬限额服务；验证不通过时另设实时额度组件 |
| **Lago** | 开源，**AGPL-3.0**（另有 Premium 商业层） | 预付费钱包：`rate_amount`（credit↔货币换算）、`paid_credits` vs `granted_credits`、recurring top-up 周期自动充值、`expiration_at` 到期作废；区分 `balance`（已开票）与 `ongoing balance`（含当前用量估算，分钟级刷新） | 适合"预付余额 + 加油包"的对外售卖形态 |
| **Stripe Billing credit grants** | 商业（参考） | `amount` + `applicability_config.scope`（限定适用的计量价格）+ `priority` + 过期日，与 `meter` 配合完成预付额度抵扣按量账单 | 对外收费场景的事实参考实现 |
> **一条与 4.4 相关的产品组合信号（弱证据）**：Kong 既有 AI 网关（`ai-rate-limiting-advanced` 做 token 限额执行），又于 2025-09-03 宣布收购开源计量计费平台 OpenMeter，公告称将为 Kong Konnect 带来按量计费能力。这只证明同一厂商同时拥有两条产品线，**不能证明部署时二者分层**——厂商同样可能把计量并入网关控制面；公告中的集成计划也不是完成证明。因此它只作为 4.4「采集与结算可分离」判断的佐证之一，不单独作为论据。
---
## 七、演进趋势：MCP/Agent 网关（2025-2026）
### 7.1 MCP 采用规模快速扩大
- MCP 采用规模快速扩大：Anthropic 官方（2025-12-09，捐赠 MCP 至 LF 的公告）称公开 MCP 服务器超 1 万个、月度 SDK 下载量 9700 万+（97M+，Python + TypeScript 合计）。这是 **2025-12 的厂商口径快照**，本版未取得更新的官方数字（详见附录来源分级）。
- **2026-07-28 规范版本的重大变更**（依官方 Key Changes 逐条列出；该版本的候选版于 2026-05-21 冻结，正式版于 2026-07-28 发布）：
- **无状态化**：移除协议级会话与 `Mcp-Session-Id` 头；移除 `initialize`/`initialized` 握手，协议版本与客户端能力改由每请求的 `_meta` 携带；新增 **`server/discover`**（服务端 MUST 实现）用于版本与能力协商。
- **Tasks 从核心移出、进入官方扩展** `io.modelcontextprotocol/tasks`：以 `tasks/get` 轮询替代阻塞式 `tasks/result`，新增 `tasks/update`，移除 `tasks/list`。
- **MRTR（Multi Round-Trip Requests）** 取代服务端发起请求（`roots/list`、`sampling/createMessage`、`elicitation/create`）：服务端返回 `resultType: "input_required"` 与 `inputRequests`，客户端**以重试原请求**并携带 `inputResponses` 的方式作答；所有结果新增**必需字段 `resultType`**。
- **移除 SSE 流可恢复性与消息重发**（`Last-Event-ID` 与 SSE event ID）：**响应流中断即丢失在途请求，客户端 MUST 以新的 request ID 重新发起**。
- 其他：以 `subscriptions/listen` 取代 HTTP GET 端点与 `resources/subscribe`；移除 `ping`/`logging/setLevel`；`tools/list` 等结果新增 `ttlMs` 与 `cacheScope`（`public`/`private`）缓存语义；Streamable HTTP 的 POST 请求须携带 `Mcp-Method`/`Mcp-Name` 标准头；**Roots、Sampling、Logging 三项特性进入弃用窗口**，动态客户端注册（RFC 7591）弃用、改推 Client ID Metadata Documents；新增特性生命周期与弃用政策（最短 12 个月窗口）。
- **授权加固**：客户端 MUST 校验授权响应中的 `iss`（RFC 9207），客户端凭证与签发它的授权服务器绑定，不得跨授权服务器复用。
- **对网关的直接影响（不止是"扩展性收益"）**：① 无状态核心确实降低了 MCP 托管的水平扩展成本；② 但**会话级上下文的归属需分类处理**——鉴权上下文属网关、服务端任务状态属服务端句柄、工具业务状态属业务系统，不可一概说"由网关自行维护"；③ **流中断不再可恢复 + MRTR 以"重试原请求"作答**，意味着**同一有副作用的业务操作存在被重复执行的风险**，网关与工具侧必须各自具备业务级幂等（请求 ID 变化不能作为幂等依据）；④ `cacheScope` 的 `public`/`private` 语义须被网关侧缓存严格遵守，否则构成跨主体泄露通道；⑤ **新旧版本将长期共存**：`server/discover` 可作为向后兼容探测，网关须分别对客户端侧与上游侧做版本协商，不能因规范发布就推定现有产品已采用新语义——已有产品开始跟进（如 Kong AI Gateway 2.1 于 2026-09-24 声明支持该版本并处理 `ttlMs`/`cacheScope` 缓存提示），但支持范围限于其声明的版本。
> 需注意：采用规模 ≠ 协议安全性或最优性——MCP 仍存在设计级安全风险（见 7.4），选型应独立评估，不因采用规模而默认其安全。
### 7.2 网关从"代理"到"Agent 控制平面"
当 MCP 工具数量与调用团队规模增长到一定程度（业界有"三个服务器即触发网关需求"的说法，属非实证经验阈值），MCP 网关需解决四个 CISO 核心问题：谁能调哪个工具、每次调用记录在哪、如何限流、如何避免在推理时把用户级凭证交给模型。**"网关 + 注册表"是已有公开案例的趋势方向**，尚不能称为企业级主流架构：网关执行认证、授权、策略、审计，注册表管理元数据与服务发现。代表案例为 Uber（2026-10-01 工程博客）：MCP Registry 作控制面、Proxy Gateway 作数据面，把 MCP 调用转换为对内部服务的 HTTP/gRPC 等调用；新注册的服务器与工具默认禁用，经所属团队审核后启用；Uber 自述托管 800+ 个 MCP 服务器、5000+ 个工具。单一案例的规模与做法不能外推为行业普遍情况。
### 7.3 三阶段路线图（2024-2027+）
> 说明：本路线图为一种**可能的演进猜想**（综合多家厂商/网关产品的路线图投射），非确定性行业共识；各阶段时间点为趋势性估计，供规划参考而非立项依据。
1. **Sidecar 模式（2024-2025）**：保留现有 API 网关，独立 AI 网关并行部署，安全隔离但存在逻辑重复与策略漂移。
2. **智能 API 网关（2025-2026）**：OpenAPI→MCP 自动转换、语义缓存、上下文感知限流、Agent 统一身份认证，趋于收敛。
3. **Agentic Mesh（2027+）**：网关成为"能力市场"，管理能力注册表、意图匹配、跨团队发现、组合编排，引入信任与声誉体系。
### 7.4 风险提示
- **安全**：2026-04-15 OX Security 发布研究，认为 STDIO 传输的配置信任边界存在设计级风险，被污染的配置可导致执行任意命令。这是**研究方的风险定性**：据 OX 转述，Anthropic 认为 STDIO 执行模型属预期行为、输入净化是开发者责任，双方对责任归属有分歧。OX 原文给出三个口径不同的数字，均未公开统计方法：① **150M+ 下载**——受影响供应链的下载量，统计窗口与包范围未说明，**不能与 7.1 的 97M 月下载量比较或换算**；② **7000+ 台公网可访问服务器**；③ **最多 20 万个潜在受影响实例**（上限估计）。三者都不是已确认的受害数。企业必须构建分层防护，不能默认 MCP 服务器可信：工具级授权之外，还须有启动命令白名单、进程隔离与出口约束，并遵守 MCP 授权规范的令牌受众绑定与禁止透传要求。
- **A2A 兴起**：开源网关 LiteLLM 自 v1.80.8（2025-12）起提供 A2A Agent Gateway，Kong v3.14（2026.04）也已支持 Agent-to-Agent 协议。跨 Agent 协作的治理正在成为下一竞争点；A2A 协议本身的治理归属与版本本报告未展开核验。
### 7.5 2026 年 9 月以来的新进展（截至 2026-10-17）
> 以下仅收录主持人已核到一手来源的事项（来源见 9.1 #70–#95）；"趋势判断"一列为本报告归纳，不是厂商结论。计划中、封闭测试或厂商自述的事项已单独注明。
| 日期 | 事项 | 状态 | 趋势判断与对建设的影响 |
|---|---|---|---|
| 2026-09-09/10 | Envoy AI Gateway 更名 **Agent Router**，9 月 10 日起成为 AAIF 独立项目（当前 1.x） | 已发生 | Agent/模型网关项目向中立基金会集中；选型须按 1.x 重新核对能力，0.1 版文档不再适用 |
| 2026-09-23 | LiteLLM 发布 **LiteAdmin MCP**：AI 代理可通过管理 API 创建虚拟密钥、添加模型部署、管理团队与预算，支持限定工具与只读模式 | 已发布 | **MCP 从业务工具入口延伸到网关管理入口**：受注入的模型可能把恶意指令转化为策略或额度变更。应把管理类工具分为只读、有限写入、高危需审批三档，不把管理员凭证交给全部工具 |
| 2026-09-24、09-30 | **Kong AI Gateway 2.1** 支持 MCP 2026-07-28（含 `ttlMs`/`cacheScope` 缓存提示）；**2.2** 称新增按文本/音频/图像/视频分别计价、缓存读写分别计价、MCP 服务器聚合与身份感知策略 | 已发布（2.2 能力为厂商自述） | 商业网关开始跟进 MCP 破坏性升级；多模态与缓存的分项计价与 5.9.3"缓存 token 独立计价"的要求方向一致（厂商自述，未独立验证） |
| 2026-09-30 | LiteLLM 安全公告 GHSA-7hp6-4w63-5g45：同一密钥既用于加密密文又用于签发会话令牌，`internal_user` 可提权至代理管理员并在主机执行命令（CVSS 9.9；修复版本 1.100.4/1.101.3/1.102.2/1.103.1/1.104.0rc2，按分支对照） | 已披露、已修复 | **集中化网关的风险不限于供应链**：密钥用途分离、管理 API 授权与令牌边界同样关键（见 4.5、8.2 决策点 8） |
| 2026-10-01 | LiteLLM 安全公告 GHSA-g5ff-637f-6q2m：请求体黑名单漏掉凭证字段别名，`internal_user_viewer` 可读取代理进程可访问的任意本地文件，可能泄露主密钥与供应商密钥（CVSS 8.1；1.95.0 修复） | 已披露、已修复 | 字段级黑名单不可靠；网关对请求体中的凭证类字段应采用白名单。选型须逐项对照目标版本 |
| 2026-09-30 | Cloudflare **Monetization Gateway** 封闭测试：通过 x402 协议在 HTTP 请求流中处理代理访问 API、MCP 工具、站点与数据集的支付授权 | 封闭测试 | 网关开始连接工具访问与支付；**支付成功不等于业务授权成功**，支付上限、重试与重复收费须单独处理。属相邻生态，不写成现有 AI 网关的通用能力 |
| 2026-10-01 | **Uber** 公开 MCP Gateway 设计（Registry 控制面 + Proxy Gateway 数据面，工具默认禁用、审核后启用） | 已公开 | "网关 + 注册表"有了大型企业的一手案例（见 7.2） |
| 2026-04-17（早于本节时间窗） | （因 v5.3 补核正式版文档、且关联 8.6.2 第 12 项而收录）NVIDIA Dynamo 在**请求体** `nvext.agent_hints` 中携带 `priority`、`strict_priority`、预计输出长度 `osl`、`speculative_prefill`，用于路由排队与预热前缀缓存；当前正式版 v1.5.1 文档已列出这些字段，并按后端区分支持情况（如按优先级逐出缓存在 vLLM、TensorRT-LLM 上仍为计划）；开发版文档称 v1 API 仍在与社区共同设计 | 2026-04-17 技术博客已公开介绍；当前正式版 v1.5.1 文档已列；后端支持与配置条件按目标版本核验 | Agent 状态开始进入推理路由、排队与缓存决策；**调度控制信息不再只在请求头**，治理上下文契约须覆盖请求体扩展字段（8.6.2 第 12 项） |
| 计划 2026-10-19 | **llm-d 1.0** 发布跟踪（2026-09-29 创建）：多租户 QoS 与限流卸载、路由高可用与滚动升级、配置 API 升至 v1、Agent 感知的会话路由 | **截至 2026-10-17 仅为计划**，不得写成已发布 | 推理调度层的关注点从单项性能转向多租户、升级与恢复等运维成熟度 |
> 未纳入本节的候选（检索或核验不足）：OTel GenAI 语义约定稳定化（截至本版仍未见官方标记 stable）、Azure AI Gateway tier 的区域扩展与 GA（截至 2026-10-17 未发生）、国内云厂商 2026 年 9 月以来的网关层发布（本版未检索到可核验的一手材料）。
---
## 八、对企业内部建设模型网关的借鉴建议
### 8.1 建设定位：分阶段落地
**建与不建的门槛（报告作者基于本次调研公开案例归纳的经验判断，非统计意义上的行业阈值）**：若企业满足以下多数情形，自建网关收益明显——接入模型 ≥3 个、调用团队 ≥3 个、月 Token 消耗达规模量级、有成本归因/合规审计诉求。反之（单一模型、单一团队、用量小、无治理诉求），直接使用云厂商托管网关或纯 SDK 即可，自建网关属过度工程。
| 阶段 | 目标 | 核心能力 | 触发条件（信号） |
|------|------|----------|------------------|
| **一期（必建）** | 统一接入与成本治理 | 统一契约入口、多模型路由/故障转移、虚拟密钥、Token 计量与预算配额、限流、基础日志观测；额度账本与预扣—结算机制（见 5.9.5）；**安全基线前置：身份与权限、数据分级、最小留存、访问审计须与采集能力同期落地** | 模型/供应商 ≥3，或出现成本失控、密钥分散 |
| **二期（增强）** | 安全与降本（**一期的预算即需固定周期语义**；重置时区、结转与多份额度优先级三项语义须在一期设计时定下，二期只是上线完整的额度引擎，见 8.2 决策点 9） | 语义缓存（含租户隔离）、**语义层检测增强**（注入检测模型、内容分类器调优；**基础脱敏与保护控制属一期、不可后置**）、按团队/应用的精细计费归因、OpenTelemetry GenAI 观测、MCP 注册表 + 工具级授权（不可信服务器默认拒绝，呼应 OX 披露的风险）；**套餐/额度引擎（周期重置、结转、多份额度优先级，见 5.9.4）** | 出现安全/合规诉求、成本优化压力、MCP 工具数量上升、**出现按套餐分档或对外计费诉求** |
| **三期（前瞻）** | 完整 Agent 治理 | MCP 服务器托管规模化与工具路由、OpenAPI→MCP 自动转换、Agent 身份（A2A 预留）、Agent 生命周期治理与编排层衔接 | 多智能体/A2A 协作进入生产 |
> 投入量级（定性）：一期中、二期较高、三期高；人力与工期因团队规模差异大，此处仅给相对量级，不设具体人月。
> **安全分期的一条硬约束**：把日志/Prompt 采集放在一期、而把脱敏与内容安全放在二期，会形成"**先采集、后保护**"的危险窗口。正确口径为：**一期必须先落身份认证、权限边界、数据分级、最小必要留存与访问审计**；**默认只记录经字段白名单控制的元数据**；摘要与全文按数据级别与用途逐项启用（**注意语义摘要仍可能包含敏感原文，摘要不等于脱敏**）。**凡需采集或外发敏感内容，相应的脱敏或保护控制必须与采集能力同期就绪，不得后置**。可后置的是**语义层检测增强**（注入检测模型、内容分类器调优），不是安全基础本身。相应地，5.1 的"**原生协议透传 + 强制治理**"指的是**保留原生负载形状**，不等于绕开强制鉴权、限额与审计；网关无法解析的字段应显式限制或拒绝，而非默认放行。日志回放默认只用于隔离评测环境，**禁止默认重放带副作用的真实工具调用**。
> **待填假设表**（用于把"投入量级"变成可估算项）：以下参数缺一不可，全部标注为预算假设而非承诺——模型与引擎组合及版本 / 硬件型号与卡数 / 上下文与输出长度分布 / 峰值并发与日均请求 / 分级 SLO 目标 / 日志与账本留存量及周期 / 可复用的既有基础设施（IAM、配置中心、数仓、告警）/ 版本升级频率。填表后再分别估算研发、推理运维、安全、计量运营四类投入。
>
> **责任归属**：至少为**权限、额度账本、调度与容量、计价、业务质量**五项各指定一名 accountable 角色，并写明交付物与验收责任；8.4 风险登记册中"平台/架构"这类模糊归属须在立项时落到具体角色。
### 8.2 关键决策点
> 优先级标注：P0 = 必须现在定（影响架构地基）；P1 = 尽快定；P2 = 可后定。
决策点 1 的选型逻辑（自研/开源 vs 托管 vs 商业）：
```mermaid
flowchart TD
Q0{已确定的隔离/驻留/审计控制要求} --> Q1
Q1{需深度定制或数据须留在自有边界?} -->|是| R1[自托管/开源二次开发
候选：LiteLLM / Portkey / Higress
目标版本待核]
Q1 -->|否| Q2{已确定必须离线或强隔离部署?}
Q2 -->|是| R2[自托管 + 离线/气隙架构
候选须满足已确定的控制要求]
Q2 -->|否| Q3{团队小 需快速落地?}
Q3 -->|是| R3[托管 SaaS / 云厂商网关
数据经第三方，须先判断是否可接受]
Q3 -->|否| R1
```
1.【P0】**自研 vs 开源 vs 商业**：**先按 8.2 决策点 6 确定隔离、数据驻留与审计等控制要求，再选能满足这些要求的部署方式**——行业标签（如"金融/医疗"）与产品品牌都不是部署结论的充分条件。有较强工程能力且需深度定制、数据须留在自有边界 → 基于 LiteLLM/Portkey/Higress 二次开发（目标版本待核）；需快速落地且团队小 → 托管 SaaS 或云厂商网关（须先判断数据经第三方是否可接受）；**已确定必须离线/强隔离部署**时 → 自托管 + 离线架构，候选方案须逐项核验是否满足已确定的控制要求。
2.【P0】**统一协议出口（契约抽象层而非单一厂商形状）**：以 OpenAI Chat Completions 兼容作为**过渡基线**（当前生态最广、迁移成本最低），以**中立契约抽象层为终态目标**（因其 de facto、无治理，且 OpenAI 的新能力正优先落地 Responses API；Chat Completions 仍受支持，但官方已推荐新项目使用 Responses，且 GPT-5.4 起的部分推理模式下 Chat Completions 不支持工具调用，见摘要结论 1）。网关内部以中立语义模型表示请求，双向适配 Chat Completions / Responses / Anthropic / Gemini，将原生协议转换能力从"可选"提升为**必建**（参考 New API 的双向转换）。当上游 Responses API 采用度显著上升、所需模型能力只能经 Responses 获得，或自身多协议需求明确时，由过渡基线迁至终态。**分级口径**：一期 MVP 只要求"OpenAI 兼容入口 + 中立契约抽象的预留"，四协议双向适配是终态目标，二者不矛盾。需正视能力取舍：Anthropic 扩展思考、Gemini 原生多模态、o 系列推理 token 等差异化能力应提供"**原生协议透传 + 强制治理**"（保留原生负载形状但不绕开鉴权、限额与审计，见 5.1），避免归一化即丢失能力。
3.【P0】**成本治理前置**：不要等发生超支事故后再补限流与花费追踪，应把预算/配额/花费上限作为网关的一等能力，提供"一个控制平面"而非"每个应用各自打补丁"。
4.【P1】**安全策略外置**：鉴权、策略、脱敏、审计应在模型推理回路之外强制执行（参考 AWS Cedar、Kong 声明式插件、OPA），使约束成为硬限制而非提示词建议。
5.【P1】**厘清网关与编排边界**：明确"AI 流量治理"（网关职责）与"Agent 完整生命周期治理"（编排层职责）的边界，避免重复建设与责任真空。
6.【P0】**国产合规（适用范围须先行判断）**：不能笼统地说"生产环境模型调用需符合《生成式人工智能服务管理暂行办法》"。该办法**第二条**明确：适用对象是"利用生成式人工智能技术**向中华人民共和国境内公众**提供生成文本、图片、音频、视频等内容的服务"；并明确"**行业组织、企业、教育和科研机构、公共文化机构、有关专业机构等研发、应用生成式人工智能技术，未向境内公众提供生成式人工智能服务的，不适用本办法的规定**"。因此**纯企业内部使用、不向境内公众提供服务的私有化部署（形态 B 的典型情形），通常不落入该办法的适用范围**。
- **但"不适用某一部规章"绝不等于没有法律义务**：网络安全法、数据安全法、个人信息保护法、等级保护与行业监管要求（金融、医疗、政务等）以及劳动者个人信息处理规则**仍须分别判断并履行各自适用的义务**（不得由某一部规章的例外反推其余规则一概适用或一概免除）；一旦服务面向企业外部公众（含对外产品嵌入生成式能力、对外开放试用），适用性判断即发生变化。
- **正确的判断顺序**：① 是否**向境内公众提供服务**（而非仅内部使用）→ ② 处理何种**数据类型**（是否含个人信息、敏感个人信息、重要数据）→ ③ 实际**服务提供主体**是谁（自研自用 / 转售 / 嵌入对外产品）→ ④ **部署与外联路径**（是否有出境、是否经第三方）。四项逐一判定后再确定义务清单，**不得以部署地点或供应商资质替代适用性分析**。
- 在仍需对外提供服务的场景下，以下判断仍成立（配置 + 路径 + 备案的组合，而非"走有资质云厂商即自动合规"）：(a) 数据驻留由部署区域与转发策略保证、需可验证，厂商资质本身不自动等于数据不出域；(b) **自托管、气隙与云网关都只是部署选项，不是"合规路径"**：应先按服务对象、数据类型、服务主体与外联路径确定适用义务，再核验相应技术控制及必要手续；部署方式与供应商资质均不能替代该判断，安全评估、算法备案与行政许可分别按各自适用条件判断；(c) 企业内部网关调用第三方 API 可能触发服务提供者义务与算法备案要求，须独立评估，不由网关路由自动免除。**注**：法规以施行文本为准——修改后的《网络安全法》自 2026-01-01 起施行，新增人工智能安全与发展条款；《人工智能生成合成内容标识办法》自 2025-09-01 起施行，对向公众提供生成内容的服务设定标识义务，内部使用场景按第一步判断其适用性。本报告合规部分仅覆盖境内场景；若业务涉及出海或欧洲用户，需另行评估 GDPR、EU AI Act（如高风险 AI 系统的自动化决策留痕、数据主体访问权）对网关层的要求。
7.【P1】**可观测统一**：采用 OpenTelemetry GenAI 语义约定，避免各供应商观测数据割裂。**但需注意其成熟度**——该约定已迁移至独立的 GenAI 语义约定仓库维护、官方口径为"处于积极开发阶段"，本报告复核未能确认其已达 stable；因此应"锁定版本 + 自有扩展字段集中定义"，并把升级迁移纳入计划，而非假定字段永久稳定（见 8.7 口径提醒）。
8.【P0】**网关自身韧性（威胁模型）**：集中化网关是新的单点故障与高价值攻击目标，须补齐：网关高可用（多可用区、无状态化）、密钥外部化（HSM/KMS，网关不落地明文；**注意外部化不等于网关运行时被控后无法滥用凭证**——运行时仍可调用解密或代签，须配合最小权限、短期凭证、按用途分离密钥与调用审计）、审计日志防篡改（WORM）、以及"网关被控"降级预案（按租户熔断、本地策略缓存）。当团队数/网关流量规模超阈值时，应评估"联邦式网关"（每团队/每域轻量网关 + 中央策略/计量聚合）作为集中式之外的替代，避免单一集中点放大风险。
9.【P1】**计量分层与额度语义前置定义**（详见 5.9）：① 架构上区分「计量采集（网关）/ 额度执行（网关）/ 定价与结算（可外置）」三段，不把财务逻辑焊进数据面；② 定价采用"真实单价 + 倍率系数"双层，缓存 token 独立计价；③ **三项额度语义必须在开工前写进设计文档**——重置时区、结转规则、多份额度的消耗优先级，这三项上线后极难变更；④ 额度正确性按 **5.9.5 ⑤ 的权威账本与硬上限条件**设计（预留覆盖最大可计费消耗、稳定幂等键、状态迁移约束），硬上限与软告警分开设计；**不把某一种技术组合（如 Redis Lua + DB 约束）写成统一必选方案**——它解决单点竞态，不构成跨存储一致性或硬上限证明。
10.【P0·仅形态 B】**网关分层与饱和治理**（详见 8.5、8.6）：① **治理与调度应做逻辑职责分离**——治理侧（身份/额度/策略/审计）与调度侧（负载与 KV 缓存感知选点、容量准入）职责分开，通过**锁定版本的治理上下文契约**（优先级、公平域、缓存域等，载体可能是请求头，也可能是请求体扩展字段，见 8.6.2 第 12 项）解耦；**二者可以由同一产品模块实现，也可以拆成物理上的 L1/L2，是否双跳取决于既有组件、性能与故障域**，本报告不主张单一架构；调度侧优先评估复用 GIE / llm-d 等既有实现而非自研；② **共享池接近容量时须启用准入与排队**（并发、速率与容量约束可以并存，准入不替代限速），并公示"保 TPOT 牺牲 TTFT"的取舍口径；③ **额度计价单位须重新定义**（等效算力单位为可选方案，须定期回归标定，且长期配额不能替代瞬时容量准入，见 8.5.4）；④ **降级优先于拒绝**，任何拒绝都要给出自助解决路径，否则业务将绕过网关（影子 AI），失去的是全部治理能力；⑤ 区分成熟度：GIE 的 `InferencePool` 自 v1.0.0 起为 v1/GA，`InferenceObjective` 仍为 alpha（v1alpha2）、官方明示可能破坏性变更，**后者不宜过早深度绑定**。
### 8.3 推荐参考组合
- **基础设施底座**：LiteLLM（提供商覆盖面广、扩展点多）或 Higress（MCP 能力强、国内生态集成度高）或 Kong/APISIX（已有网关体系可复用；**注意 Kong 的 advanced 系列属企业版，APISIX 与其能力不应合并评价**）。
- **可选智能路由层**：Not Diamond / Martian 等，做按质量/成本/延迟的模型优选。
- **治理增强**：Portkey 企业版等商业治理产品（强监管场景；须按目标版本核验）。
- **供应链安全门槛（选型硬约束）**：仅选用提供 SBOM、镜像签名（Cosign/Sigstore）、依赖扫描的构件，并**校验签名者身份、构建来源（provenance）与部署制品摘要**——合法流水线也可能签出恶意制品，仅"有签名"不够。LiteLLM 2026.03 供应链攻击表明网关是"高价值集中目标"；按最坏情形推演，依赖链被控可能连带泄露网关持有的供应商密钥、虚拟密钥、PII 与审计日志（这是推演，不是该事件的实际影响范围）。
> 选型利益声明：上述推荐基于公开资料的能力匹配，不代表任何厂商赞助或背书。其中 LiteLLM、Higress、Not Diamond 因本报告引用其官方说法较多，特说明其对外结论对自身产品有推广立场，采纳时请独立核验。亦可关注同属可选的方案（APISIX ai-* 插件、Agent Router（原 Envoy AI Gateway）、agentgateway、Bifrost、自研轻量网关）以对冲确认偏误，其中前四者已列入下方选型决策表。
**场景 → 推荐映射**：
- Python 技术栈、需快速扩展生态 → LiteLLM
- 需国内生态集成与 MCP 能力、CNCF 治理 → Higress 列为候选（能力与版本仍须核验；**不以产品名替代 8.2 决策点 6 的适用性判断**）
- 已有 Kong 网关体系 → Kong AI 插件（**注意 `*-advanced` 系列属企业版**）；已有 APISIX 体系 → APISIX ai-* 插件（开源，但无语义缓存与虚拟密钥预算）
- 已确定需强隔离与企业级治理审计 → Portkey 企业版等商业治理产品列为候选（须核验其满足已确定的控制要求）
- 纯托管、团队小、可接受数据经第三方 → OpenRouter / Cloudflare AI Gateway（底层运维由厂商承担，策略与密钥仍需自理）
- 需"倍率 + 套餐 + 兑换码"式内部分发计费 → New API 的倍率、账本与订阅套餐模型（当前版本已提供周期重置；重置执行与并发语义须按目标版本验证，见 5.9.2；注意 AGPL-3.0 义务评估）
- 需对外售卖 token 套餐（含结转、加油包、消耗优先级）→ 套餐生命周期与结转语义可借鉴/复用 OpenMeter / Lago；**逐请求实时硬限额须按目标版本单独验证其并发 reserve/commit/release 保证**，未通过验证前另设实时额度组件（见 6.4）
**MVP（最小可行清单）**：最小集必须覆盖网关高可用、身份与数据分级、恢复期对账，以及形态 B 的准入与取消传播——**任何少于下表的清单都不足以支撑一期上线**。按两类形态分列：
| | **形态 A（多供应商 API）最小集** | **形态 B（私有化算力池）最小集** |
|---|---|---|
| 入口与契约 | 统一 OpenAI 兼容入口 + 中立契约抽象的预留 | 同左，并明确引擎版本差异的屏蔽范围 |
| 身份与权限 | 虚拟密钥 + 主体解析 + **模型 allowlist** | 同左，**并须剥离/重建调度与治理控制字段（请求头与请求体扩展）**（8.6.2 第 12 项） |
| 额度 | Token 计量 + 预算 + 预扣/结算，并**书面明确硬上限口径与 fail-open 敞口**（5.9.5 ⑤） | 同左 |
| 稳定性 | 故障转移 + 网关自身高可用 | **同左（网关自身高可用与故障恢复是共同前提）**，另加准入与优先级队列、取消传播、以及契约化的降级路径 |
| 可观测与留存 | 基础日志 + **访问审计 + 数据分级下的最小留存** | 同左，另加队列与容量指标 |
| 运维闭环 | 账本与供应商账单对账 | 账本与**推理侧执行记录**对账 |
**上线前置条件（非可选项）**：以上每格都需有明确的失败语义与责任人；未完成 8.8 中对应用例者，只能进入受控 POC，不进入生产承载。
**若自建额度体系，建议的最小数据模型（五类核心实体的示意表，详见 5.9）**：
| 表 | 关键字段 | 设计要点 |
|---|---|---|
| `price_book` 价目表 | model、provider、input/output/cache_read/cache_write 单价、生效时间 | **保留版本**，历史账单按当时价格重算 |
| `ratio` 倍率表 | 作用域（模型/分组/用户）、倍率值、优先级 | 与价目表解耦，折扣与成本互不污染 |
| `grant` 额度发放 | 主体、amount、priority、effective_at、expire_at、recurrence、结转上下限、**所属额度周期** | 可借鉴 OpenMeter 的语义模型（注意其结转公式作用于**单个 grant 余额**而非账户总额，见 6.4） |
| `reservation` 预留 | reservation ID、业务调用 ID、执行 attempt ID、预留额、**状态（reserved / committed / released / unknown）**、预留超时、关联 grant 分配明细 | 预扣与结算是两类事件，必须独立建模；**预留超时 ≠ 推理未执行**，释放前需与推理侧执行记录对账 |
| `ledger` 事件账本 | **事件 ID（唯一）+ 事件类型（预扣/提交/释放/退款/补扣/调整）**、reservation ID、业务调用 ID、attempt ID、主体、**额度周期**、原始 token 明细、所选计价单位金额（WTU 仅在启用时记录）、**不可变计价版本**（价目表版本 + 倍率版本 + 标定版本 + 舍入规则）、实际模型与副本、估算/实测标记 | **只追加不更新**；余额由账本派生并与权威余额定期对账；跨周期退款按**原周期**归属，不得直接加回当前余额 |
**成本结构维度（定性，不设具体金额）**：自建成本 = 人力（开发/运维/安全）+ 基础设施（计算/存储/数据库/缓存）+ 许可（商业版）+ 持续维护（协议适配、模型接入迭代）；托管 SaaS 成本 = 平台费/流量费，无自建运维但数据流经第三方。
**选型决策表（定性能力矩阵，强/中/弱）**：
| 方案（须标明拟评估版本） | 提供方覆盖面 | 治理能力 | 性能 | MCP/A2A | 部署与数据控制条件 |
|------|----------|----------|------|---------|----------|
| LiteLLM（开源版） | 广 | 预算/虚拟密钥/RBAC 具备；**须对照 2026-09/10 安全公告的受影响版本** | **未做同条件对比，待 T12** | 具 MCP 网关与工具级权限；具 A2A Agent Gateway（v1.80.8 起），协议兼容与授权深度按目标版本核对 | 可自托管，数据留在自有边界 |
| Portkey（**目标版本待核**：开源 core 与企业版能力不同） | 中 | 开源 core 具基础治理；审计/RBAC 深度按版本而定 | **未做同条件对比，待 T12** | 目标版本待核 | 开源 core 可自托管；企业版另含治理增强（部署形态按合同核对）；托管形态数据经第三方 |
| Higress（开源版） | 中 | 内容安全、Token 限流、配额插件（无内置额度账本） | **未做同条件对比，待 T12** | MCP 托管与 OpenAPI→MCP 具备 | 可自托管，国内生态集成度高 |
| Kong（**开源版 / 企业版能力差异显著**） | 中 | 开源版基础治理；`ai-rate-limiting-advanced` 等属企业版 | **未做同条件对比，待 T12** | 目标版本待核 | 可自托管 |
| Apache APISIX（开源版） | 中 | ai-* 插件；**无语义缓存、无虚拟密钥预算** | **未做同条件对比，待 T12** | `mcp-bridge` 已弃用，MCP 支持薄弱 | 可自托管 |
| Bifrost（开源版） | 中 | 四层预算、虚拟密钥 | **未做同条件对比，待 T12**（厂商自测数字不并入） | 具 MCP 支持，A2A 目标版本待核 | 可自托管 |
| Agent Router（1.x） | 目标版本待核 | token 限流（含 CEL 权重）、凭证与配额管理；无额度账本 | **未做同条件对比，待 T12** | 具 MCP 端点，A2A 目标版本待核 | 可自托管（Envoy/Kubernetes） |
| agentgateway | 目标版本待核 | 鉴权、外部授权、cost controls（粒度待核） | **未做同条件对比，待 T12** | 官方定位覆盖 MCP 与 A2A | 可自托管 |
| OpenRouter（SaaS） | 广 | 聚合计费为主，治理浅 | **未做同条件对比，待 T12** | 未见 | **数据经第三方**，不满足数据不出域 |
> 使用说明：本表为**功能与条件对照**，非量化评分。**性能一律标为未实测**，任何性能取舍须由 8.8 T12 的同硬件、同负载、同治理功能、同流式条件对比给出；厂商自测数字见第六章及其来源与测试条件限制，不并入本表。**未能定位到具体版本的能力标注为"目标版本待核"，不得用企业版能力为开源方案打分**。"部署与数据控制条件"仅描述可核验的部署事实，**不构成合规结论**——适用义务须按 8.2 决策点 6 的四步判断。
### 8.4 成功度量与风险登记
**成功度量 KPI（示例，需按企业目标定制）**：
- 成本：单请求平均成本较直连下降；**未经授权的额度突破为零**，应急透支不超过约定敞口并**单列统计**（不与"零超支"混同）；
- 可用性：供应商切换 RTO 分钟级、网关自身可用性 ≥ 99.9%；
- 治理：100% 调用可计量归属、密钥泄露爆炸半径缩小；**账本与供应商账单月度对账差异率 ≤ 0.5%**（口径需自定，此处为示例量级）；
- 安全：注入/越权拦截率（须同时定义攻击样本集与误报率，否则不构成安全保证）、审计日志完整率。
> **KPI 口径要求（没有口径的 KPI 会被优化成假象）**：① **状态须拆成三个正交维度，不可混为同一组分母**（否则会重复统计或错误相加）——**请求生命周期**：已拒绝 / 已接纳在途 / 已完成 / 已失败 / 已取消 / 结果未知；**计量质量**：引擎实测 / 网关估算 / 缺失；**结算状态**：未结算 / 已结算 / 待调整。三维**各自定义分母、窗口与数据来源，三者之间不得直接相加**（例如"已完成"与"估算"完全可能同时成立）。具体枚举值在实施设计阶段冻结即可。只看"成功请求的延迟"可以靠拒绝长请求把指标做好看，因此**延迟必须与接纳率同屏报告**。② **延迟口径**：TTFT 须声明起点（客户端到达 / 网关接纳 / 转发上游）以及**是否包含网关排队时间**；TPOT 须区分服务端生成 token 与网络流块。③ **分位数聚合**：多实例须先聚合直方图再算分位数，**不可对各实例 P99 取平均**。④ **不可同单位相加**：token、计价单位（WTU）、GPU 利用率分别统计，"对账差异率"只在**同一口径的两份记录之间**计算（如网关账本 vs 推理侧执行记录），不可用不同量纲的数据相除。⑤ **高基数控制**：用户/请求 ID 留在日志与分析存储，不要作为时序指标标签无限展开。⑥ **质量不能只看成本**：单纯"低成本模型调用占比上升"可能掩盖业务质量下降，须与采纳率/返工率等业务指标同屏对照。
**建设风险登记册（示例）**：
| 风险 | 影响 | 缓解 | 责任 |
|------|------|------|------|
| 语义缓存跨租户泄露 | 高 | 租户分区 + 准入策略 | 平台/安全 |
| 网关集中化单点 | 高 | 高可用 + 密钥外部化 + 降级预案 | 平台 |
| OpenAI 契约漂移 | 中 | 中立契约抽象层 | 架构 |
| 供应链投毒 | 高 | SBOM + 签名 + 依赖扫描 | 安全 |
| MCP 工具滥用 | 高 | 注册表 + 工具级授权 | 安全 |
| 成本失控 | 中 | 预算/配额前置 | 财务/平台 |
| **额度扣减并发透支（TOCTOU）** | 高 | 按 5.9.5 ⑤ 的**预留覆盖最大可计费消耗、稳定幂等键、reservation 状态迁移约束与权威恢复**设计（具体实现待决）；由 8.8 T01–T04 验收 | 平台 |
| **计费数据缺失（流式中断/上游不返回 usage）** | 中 | 异常路径以本地 tokenizer 估算兜底并打标记，禁止默认计 0（5.9.5） | 平台 |
| **算力池饱和引发排队雪崩**（形态 B） | 高 | 网关侧准入与优先级队列 + 饱和检测 + 降级路由（8.5.3） | 平台 |
| **额度单位与算力占用错配**（形态 B） | 中 | 明确定义计价单位与标定方法并定期回归（等效算力单位为可选方案之一，见 8.5.4）；由 T11 验收 | 平台/架构 |
---
### 8.5 私有化多算力池场景：能力差异与架构分层
> 适用语境：网关下游为**企业自有推理集群**（多模型 + 多 GPU 算力池），不涉及公有云模型服务（形态 B，见〇.1）。本节只讲相对 8.1–8.4 默认语境的**差异**，未提及处沿用前文结论。
#### 8.5.1 前八章结论在本场景下的适用性修订
| 原结论/建议 | 形态 A（外部 API）语境 | **形态 B（私有化算力池）下如何改写** |
|---|---|---|
| 统一契约入口（8.2 决策点 2） | 屏蔽多供应商协议差异 | **仍成立且更易达成**（下游多为 vLLM/SGLang 等 OpenAI 兼容实现），重点转为屏蔽**引擎版本差异**与自研模型的非标接口 |
| 成本治理（8.2 决策点 3） | 控制外部账单美元支出 | **改写**：在短期资源决策视角下 GPU 容量已沉没，额度的目的从"省钱"转为**分配稀缺算力 + 引导用量结构**；但**电力等可变成本在短期同样存在**，租赁、维护、折旧分摊与扩容决策属长期成本，不可据此认为成本不重要。计价单位须重新定义（8.5.4） |
| 故障转移（5.2） | 跨供应商 fallback | **改写**：无"换一家供应商"这条退路，可选处置为**副本/池切换、排队等待、契约内降级（小模型或低精度变体）或明确拒绝**——按调用方契约选择，降级不是唯一兜底（8.6.5） |
| 缓存（5.5） | 语义/精确响应缓存，省外部调用费 | **须拆成三类分别设计**：精确响应缓存、语义响应缓存、**前缀 KV 缓存**。前两者属网关层、复用"答案"，收益是省一次完整调用但有跨主体与陈旧知识风险；后者属推理引擎层、复用 prefill 中间状态，**收益上界受限**（官方文档明确其只减少 prefill、不减少生成阶段耗时；无共享前缀或长输出场景收益很小） |
| 合规（8.2 决策点 6） | 数据出域是核心风险 | **适用范围变化而非义务消失**：纯内部、不向境内公众提供服务的场景通常不适用《生成式人工智能服务管理暂行办法》（该办法第二条），但个保法/数安法/网安法/等保与行业监管仍适用；"数据不出域"须经外联、日志、备份、运维与工具出口的逐项验证，不能假定 |
| 限流（4.3） | 防止超预算、适配供应商配额 | **改写**：在限速之外**增加准入控制**——共享池接近容量时启用优先级队列与排队策略；并发、速率与容量三类约束并存（8.5.3） |
| 网关自身韧性（8.2 决策点 8） | 集中化单点 | **仍成立**，但增加一条：网关不可用时算力池仍应可被受控直连（保留应急旁路，避免全域停摆）。**旁路必须自带独立控制**：独立鉴权、模型与数据域限制、限额、审计、短期授权与自动退出，否则会变成长期存在、绕过全部治理的后门（8.8 T13） |
#### 8.5.2 差异一：路由从"选供应商"下沉为"选副本"——算力感知路由
业界正在形成**治理与调度的职责分层**：上层治理网关（本报告主体）+ 下层**推理调度层**（inference gateway / router）。需要强调的是，这一层目前是**可评估的生态规范与若干实现**，而非一组可互换的既成标准。评估时建议按**四层分别锁定版本**：`Gateway API / GIE 资源规范` → `代理实现` → `生产级 EPP / 调度器` → `推理引擎`，并记录 CRD 版本、特性开关与兼容组合。
- **Gateway API Inference Extension（GIE，Kubernetes SIG 项目）——注意它首先是"规范"而非"生产实现"**：官方自述目标是"定义规范以构建兼容的生态"。核心 API 为 `InferencePool`（**自 v1.0.0 起为 v1/GA**；一组模型服务端点，用 `selector` 匹配 Pod、`targetPorts` 指定端口、`endpointPickerRef` 引用 EPP——官方文档记载该字段在 v1.5.0 之前为必填、现为可选；`failureMode: FailOpen` 时 EPP 故障则回落由网关自行选点）。**关键澄清**：项目自带的 Endpoint Picker 被官方明确描述为"**用于一致性测试的轻量参考实现**"，并明示"生产部署应实现自有 EPP 或采用既有实现（如 llm-d-router，组件现行名称以 llm-d 官方仓库为准）"——因此**不可把它当作开箱即用的生产调度器**。EPP 这一角色本身负责"根据模型服务上报的指标与能力做出最优端点决策"，支持按模型名路由、LoRA 适配器路由、前缀缓存状态等因素，并提供 serving priority（在线推理优先于容错批量任务）。`InferenceObjective`（**alpha**，通过 `x-gateway-inference-objective` 请求头关联）承载 Priority，官方明示未来将扩展 SLO attainment 等字段且**可能有破坏性变更**——须按锁定版本描述与集成，不宜过早深度绑定。
- **llm-d**（截至 2026-10-17 尚未发布 1.0，1.0 计划于 2026-10-19 发布，见 7.5；评估须锁定具体版本）：Router = **Proxy**（符合 GIE 标准的 L7 代理，经 `ext-proc` 咨询 EPP）+ **EPP**（按实时指标、KV 缓存亲和与策略为 Pod 打分）。提供前缀缓存感知路由、事件驱动的 KV 缓存索引、KV 分层卸载（CPU/SSD）、**P/D 分离**（prefill 与 decode 交由不同 worker，Router 编排 KV 传输）、**Workload Variant Autoscaler**（跨 variant/池放置副本，在满足延迟目标下最小化成本）。
- **NVIDIA Dynamo**（当前正式版 v1.5.1，评估须锁定版本）：前端 tokenize 后基于 worker 上报的 **KV 缓存事件**评分选点（`--router-mode kv`），亦可以 GIE EPP 形态接入；另在请求体 `nvext.agent_hints` 中接收优先级等 Agent 提示（v1.5.1 文档已列，后端支持不一，见 7.5），由此带来的信任边界问题见 8.6.2 第 12 项。
**结论**：形态 B 下"智能路由"（5.2）**增加了一层新含义**——在"选模型/选池"之外，还需"**按 KV/前缀缓存亲和 + 队列压力选副本**"；但**选副本不替代选模型**，二者是串联而非替代关系。关于收益幅度须避免无条件断言：前缀缓存命中免去的是 **prefill** 计算，vLLM 官方明确其"只减少处理查询（prefill）阶段的时间，不减少生成新 token 的时间"，因此**在长输出、低前缀共享率的负载上收益可能很小**。是否构成主要杠杆，取决于实际负载的前缀共享率与输入/输出长度比，**须以自有流量实测判定**（见 8.8 T09/T12），本报告不作普适性结论。
```mermaid
flowchart TB
APP["业务应用 / Agent"]
subgraph L1["L1 治理网关（本报告主体·控制治理面）"]
A1["身份与主体解析
虚拟密钥→用户/项目/任务"]
A2["模型准入校验
allowlist / 上下文上限"]
A3["配额预扣 + 优先级判定"]
A4["协议归一化 / 护栏 / 审计"]
end
subgraph L2["L2 推理网关（GIE / llm-d / Dynamo·算力面）"]
B1["Flow Control
准入与优先级队列"]
B2["EPP 选点
负载 + KV/前缀缓存亲和"]
B3["P/D 分离编排 / LoRA 路由"]
end
subgraph POOL["算力池（多模型 × 多副本）"]
C1["池 A：70B 主力"]
C2["池 B：7B 降级/批处理"]
C3["池 C：多模态 / 长上下文"]
end
OPS["计量 + 观测 + 管理 Portal"]
APP --> L1
L1 -->|"注入 priority 与 fairness-id"| L2
L2 --> POOL
L1 -.->|"用量账本 / 观测信号"| OPS
L2 -.->|"vLLM 指标：队列深度 / KV 水位"| OPS
```
**边界纪律（逻辑职责，而非强制的物理部署）**：治理侧负责主体级策略（身份、权限、额度、审计），调度侧负责容量准入与副本选点；二者通过**锁定版本的治理上下文契约**解耦（GIE 的 `x-gateway-inference-*` 请求头是其中一种载体，跨实现互通须按所选版本确认）——治理侧把"这是谁、什么优先级、属于哪个公平域"写进请求（并**剥离调用方自带的同类字段，无论在请求头还是请求体**，见 8.6.2 第 12 项），调度侧据此排队与选点并校验来源可信。是否拆成两个物理网关，取决于既有组件复用、性能预算与故障域划分；单体实现同样可以满足该职责分离。
#### 8.5.3 差异二：共享池接近容量时，准入控制与优先级队列成为必要能力
外部 API 场景下限流主要为了"别超支"；私有化场景下物理算力有限，**共享池接近容量时会出现饱和**，此时需要在限速之外**增加准入（admission）**——两类约束并存而非互相替代。GIE 的 Flow Control 指南给出了一套可借鉴的机制模型（**实际可用性取决于所选 EPP/调度器实现与锁定版本**）：
- **要解决的三个问题**：嘈杂邻居（单用户长提示独占队列与 KV 缓存）、调度遗憾（请求过早锁定到次优端点无法改派）、优先级反转（模型服务器按序列长度/到达时间批处理，不理解业务优先级）。
- **核心取舍**：饱和时"**保护 TPOT 而牺牲 TTFT**"——让请求在网关队列中等，换取已接纳请求稳定的生成速度。这条取舍值得在企业内部作为明确的 SLO 约定写进服务协议。
- **关键机制**：FlowKey = **Fairness ID**（`x-gateway-inference-fairness-id`，可取租户/用户等级）+ **Priority**（整数，负值表示后台/低优先级）；**严格优先级**（高优先级队列服务完才轮到低优先级）；同一优先级内**工作保守型公平**（有闲置容量就不人为节流，仅争用时激活公平分配）；容量与生命周期由 `maxBytes`（待处理请求聚合体积上限）、按优先级的独立容量上限与 `defaultRequestTTL`（超时丢弃）控制；**饱和检测器**综合 KV 缓存利用率与本地队列深度评估池健康度。
- > **适用性限定（就近说明）**：本节描述的是 **GIE 定义的能力模型**；**实际可用性取决于所选 EPP/调度器实现与锁定版本**（GIE 自带 EPP 仅为一致性测试参考实现，见 8.5.2 的四层版本组合要求），不可假定"照文档即可复用"。
**llm-d 的工程补充**：**准入与调度分离**（"admission 决定何时可推进，scheduling 决定去哪跑"）；同一优先级带内**按租户轮询**，避免单租户突发独占调度机会。**须澄清一处常见误读**：同级轮询只保证**该优先级内部**的公平，**并不能推出"低优先级不会饿死"**——在严格优先级下，只要高优先级持续占满容量，低优先级就可能长期得不到调度；且**请求数轮询也不等于 token 或 GPU 时间公平**（长请求占用远大于短请求）。因此企业必须在两条路线中**显式选择并写入服务承诺**：(a) 接受低优先级可饿死，但以 TTL 超时 + 明确的失败语义兜底；(b) 设保底份额、老化提升（等待越久优先级越高）或限制高优先级总负载。同时须定义队列取消、TTL 到期后的额度释放、多实例容量聚合口径，以及调度元数据陈旧时的行为；分级 SLO 实践（高优先级维持亚秒级 TTFT，批处理档吸收排队延迟）；并强调 `dispatcher ceiling`、队列上限等参数**必须针对具体模型、vLLM 配置、GPU 容量与流量组合实测校准**，无通用默认值。
**与批处理调度的分工**（易混淆，须写清）：
| 层次 | 组件 | 管什么 |
|---|---|---|
| 在线推理请求级 | 网关 Flow Control（GIE/llm-d） | 单次请求的准入、排队、优先级、公平性（秒级） |
| 离线/批量作业级 | **Kueue**（ClusterQueue） | 作业级配额与排队：`nominalQuota`、`borrowingLimit`/`lendingLimit`、cohort 内借用、`reclaimWithinCohort` 抢占、Fair Sharing（分钟至小时级） |
两者作用于同一组 GPU 但处在不同调度层次，**不可互相替代**：只有 Kueue 无法解决在线请求的队头阻塞，只有网关 flow control 无法防止训练/批量作业把卡占满。
#### 8.5.4 差异三：额度单位必须与算力占用挂钩
**问题**：相同数量的 token，其实际资源占用**受上下文长度、模型、引擎实现与当时负载影响而不同**（具体差异须本地实测，本报告不给量级结论）；若照搬公有云"美元/千 token"做内部额度，可能系统性地**鼓励错误行为**（例如放任超长上下文、惩罚善用缓存的用户）。
**建议的分层**——先把三件事分开，再决定是否引入加权单位：
| 层 | 内容 | 性质 |
|---|---|---|
| **原始计量** | prefill/decode token、缓存命中与未命中输入、上下文档位、多模态用量、实际模型与副本 | **客观事实**，必须原样留存，任何计价变更都能据此重算 |
| **资源成本模型** | 各计量项对应的实际资源占用（需实测） | **工程估计**，随引擎版本与硬件变化 |
| **运营计价** | 面向用户展示与扣减的单位（可以是原始 token、token × 模型系数，或下述 WTU） | **运营选择**，含价格导向，不等于物理成本 |
在此基础上，**可选**采用等效算力单位（WTU, Weighted Token Unit）作为运营计价单位。**须先承认它的性质**：WTU 同时混合了资源权重与优先级价格，因此它是一个**运营积分**，**不能宣称精确等于物理算力**。初期更稳妥的做法是先用"原始 token + 模型系数"试点，待计量与对账闭环后再考虑加权：
```
WTU = (prefill_tokens × w_p + decode_tokens × w_d) × 模型系数 × 优先级系数 − 缓存命中折减
```
| 因子 | 含义 | 标定方式 |
|---|---|---|
| `w_p` / `w_d` | prefill 与 decode 的单位算力占用差异 | 在目标模型与引擎配置上**实测标定**，不可沿用他人经验值 |
| 模型系数 | 模型规模与并发占用（70B vs 7B、多模态） | 以单卡可承载并发或显存占用为基准 |
| 优先级系数 | 高优先级贵、批处理便宜 | 由运营策略定，是"削峰"的主要经济杠杆 |
| 缓存命中折减 | 前缀缓存命中部分按折扣计费 | 把"复用系统提示、稳定前缀"变成用户**可感知的收益** |
**五条纪律**：
1. 权重需**定期回归标定**——引擎升级、量化方式变更、P/D 分离开关都会改变实际算力占用；
2. 账本须**同时记录原始 token 与计价单位**（5.9 的 `ledger` 表），否则日后无法换算口径、也无法向用户解释扣费；
3. **警惕重复计价**：若 `w_p`/`w_d` 已在目标模型上标定，再乘"模型系数"可能对同一差异计价两次；计价式中的各项**必须互不重叠**，并逐项标明**哪些可直接采集、哪些为估算、哪些当前不支持**（如多模态内部用量常不可见）；
4. 上式为**线性示意**，**并未表达"长上下文加价"**——若要体现长上下文的非线性成本，需显式增加上下文档位项，而非依赖读者脑补；缓存命中折减还须定义**计量单位、折减下界与所属计价版本**；
5. **计价单位不能替代运行时准入**：WTU 余额是**长期配额**约束，而 GPU 显存、KV 缓存水位、队列深度是**瞬时容量**约束，二者不同类。余额充足不代表此刻有容量，余额耗尽也不该成为绕开容量判断的理由——运行准入必须继续以并发、KV 水位、队列与容量反馈为准（8.5.3）。
若启用加权计价，5.9 数据模型的映射关系为：模型系数与优先级系数落在 `ratio` 表，标定版本与价目版本落在 `price_book`，且须随每条账本事件固化（见 8.3 `ledger` 的"不可变计价版本"字段）。
---
### 8.6 Token 配额运营：网关与管理 Portal 的能力划分与交互
> 需求语境：按用户、任务等差异分配不同能力的模型，管理 token 套餐额度，驱动合理使用、体现价值导向。
#### 8.6.1 设计目标：约束、引导、度量
价值导向的配额体系不止于"别超用"，而是让**"用对模型、写好 prompt、错峰跑批"成为对用户最有利的选择**。三个目标依次是：**约束**（谁能用什么、用多少）、**引导**（差异化定价让正确行为更划算）、**度量**（让每一份算力消耗可归因到业务价值）。缺任一环，配额就退化为单纯的行政限制，最终被业务绕过。
#### 8.6.2 网关侧（数据面）能力清单
| # | 能力 | 说明 | 优先级 |
|---|---|---|---|
| 1 | **主体与上下文解析** | 虚拟密钥/令牌 → 用户、组织、项目、**任务类型**（在线问答/批量处理/编码助手…）的映射；任务类型建议由调用方显式声明并由网关校验 | P0 |
| 2 | **模型准入校验** | 该主体可调用哪些模型、上下文长度上限、并发上限、是否允许多模态——即"能力分级"的实际执行点 | P0 |
| 3 | **配额检查与原子预扣** | 按**所选计价单位**预扣、响应后结算（5.9.5）；余额不足时按契约进入降级或拒绝分支（8.6.5），不得静默降级 | P0 |
| 4 | **优先级与公平标识注入** | 依据主体等级与任务类型判定 priority，写入下发给推理网关的治理上下文契约（请求头与请求体扩展字段，按目标引擎协议覆盖实际载体，由 L1 统一重建，见第 12 项与 8.5.2/8.5.3） | P0（形态 B） |
| 5 | **降级与兜底路由** | 额度不足/池饱和/超时 → 降级到小模型、缩短上下文、转入批处理队列；**降级必须可观测、可解释** | P0（形态 B） |
| 6 | **限流** | RPM/TPM/并发三维，主体级与全局级双层 | P0 |
| 7 | **结算与账本写入** | 同时记录原始 token、**所选计价单位金额**（WTU 仅在启用时记录）、缓存命中、降级标记、任务类型 | P0 |
| 8 | **审计埋点与内容留存** | **默认只记录字段白名单内的元数据**；摘要与全文按数据级别和用途逐项启用（摘要仍可能含敏感原文，不等于脱敏）；**凡启用敏感内容采集/外发，对应脱敏或保护控制必须同期就绪** | P0 |
| 9 | **护栏与内容安全** | **基础 PII/敏感数据处理保护属一期前置**；可后置的是语义层检测增强（注入检测模型、输出审核策略调优） | P0（基础）/ P1（检测增强） |
| 10 | **观测信号上报** | 见 8.7；含排队时长、降级率、配额拒绝率等**运营指标**，不止技术指标 | P0 |
| 11 | **策略本地缓存与降级** | 控制面不可用时以本地快照继续执行，并按预设 fail-open/fail-close 策略工作；**但须按配置类型分级新鲜度**（见 8.6.4 链路①） | P0 |
| 12 | **治理上下文信任边界**（安全关键） | L1 **必须剥离调用方自带的全部调度与治理控制信息**，并仅依据可信身份重新生成。范围不止请求头（`priority` / `fairness-id` / `objective`），还包括请求体扩展字段（如 Dynamo 的 `nvext.agent_hints.priority`）、模型别名与缓存域标识（如 `cache_salt`）。L2 须校验请求确实来自 L1（mTLS 或签名），否则用户可自行提权、绕过公平域或加入他人缓存域。**这是 8.5.2 双层架构引入的新攻击面** | P0 |
> **一条架构纪律**：**网关只执行策略，不定义策略，也不持有策略的唯一真相**。所有策略的权威来源在 Portal/配置中心；网关持有的是带版本号的副本。违反这条纪律的直接后果是：策略无法审计、无法回滚、多实例间行为漂移。
#### 8.6.3 管理 Portal 侧（控制面）能力清单
| 域 | 能力 | 说明 |
|---|---|---|
| **主体与组织** | 用户/团队/项目管理、与企业 IAM/LDAP 对接、角色与审批人配置 | 主体模型应与企业组织架构对齐，否则成本归因无法落到部门 |
| **模型目录与准入** | 模型上/下架、能力标签（推理、多模态、长上下文）、**能力分级（如 T1 通用小模型 / T2 主力 / T3 旗舰或专用；此处用 T 前缀以免与 8.5.2 的 L1/L2 网关分层混淆）**、可见范围、模型卡与合规信息、下线公告 | 这是"按用户与任务差异分配不同能力模型"的定义处 |
| **套餐与配额** | 套餐模板（模型分级 × 额度 × 周期 × 优先级）、发放/回收、加油包、结转与优先级消耗规则、冻结与解冻 | 语义直接对应 5.9.4 与 6.4 的 grant 模型 |
| **申请与审批** | 开通申请、提额申请、临时特批（**必须带有效期**）、审批链与全程留痕 | 审批通道畅通是防止"绕过网关"的关键 |
| **密钥自助** | 申请、轮转、吊销、绑定项目与用途、泄露应急一键失效 | 减少平台团队工单负担 |
| **用量与成本运营** | 实时余额、消耗趋势、TOP 消耗主体、按项目/任务归因、**showback 报表**、预算执行率 | 私有化下建议先 showback（透明）再考虑 chargeback（真扣） |
| **效能与价值** | 缓存命中率、降级率、排队时长分布、**单位业务产出对应的原始用量与运营计价额（分别展示，不合并）** | 价值导向的核心度量，需与业务方共同定义"业务产出" |
| **策略编排** | 路由与降级策略、限流阈值、优先级映射、模型分级映射的可视化配置、**灰度发布与一键回滚** | 策略变更必须可灰度、可回滚、可审计 |
| **告警与订阅** | 余额预警（阈值/预测性）、异常调用、SLO 违约、配额拒绝激增 | 预警应发给"能采取行动的人"，而非只发平台团队 |
| **审计与合规** | 调用检索（脱敏视图）、导出、留存策略配置、访问审计的审计 | 需区分平台管理员与业务方可见范围 |
| **评测与灰度** | 模型评测集管理、A/B 实验、灰度放量与效果对比 | 支撑模型上下架决策，避免"凭感觉换模型" |
#### 8.6.4 交互机制：控制面与数据面的四条链路
```mermaid
flowchart LR
subgraph CP["控制面 · 管理 Portal"]
P1["策略/套餐/模型目录"]
P2["审批流"]
P3["报表与看板"]
end
subgraph STORE["共享存储层"]
D1["配置中心
（策略 + 版本号）"]
D2["权威额度服务/账本
（实现待决，见 5.9.5 ⑤）"]
D3["分析/观测存储
数仓·BI（非权威账本）"]
end
subgraph DP["数据面 · 模型网关"]
G1["策略本地缓存"]
G2["原子预扣/结算"]
G3["观测/分析事件发布"]
end
P1 -->|"①策略下发
版本化·灰度·回滚"| D1
D1 -->|"监听/轮询 + 本地快照"| G1
G2 <-->|"②reserve / commit / release
幂等与状态迁移约束"| D2
P2 -->|"额度发放（写）"| D2
G3 -->|"③用量回流（分析用途）
异步批量 + 事件 ID 去重"| D3
D2 -.->|"权威结算结果（对账基准）"| D3
D3 --> P3
P1 -.->|"④控制指令：熔断/限速/强制降级
低频高危·二次确认·可撤销"| G1
```
**四条链路的工程契约**：
| 链路 | 方向与频率 | 一致性要求 | 失败策略 |
|---|---|---|---|
| ① 策略下发 | Portal → 网关，低频 | **按配置类型分级，不可一刀切**：路由与限流等普通策略最终一致即可；**凭证撤销、权限回收、模型紧急下架属高风险类，必须有最大生效时限**（超时未确认即进入受限模式），否则"快照过期仍继续服务"会让已吊销的密钥继续可用 | 配置中心不可用 → 普通策略沿用本地快照并告警；高风险类超过最大时限后按预设降级（**约束后续每次调用**；在途调用的处理按事先约定的契约，见链路④）。须记录**发布版本、实例应用确认、覆盖率**，未确认实例应被隔离出流量 |
| ② 额度校验与扣减 | 网关 ↔ 额度服务，**每请求** | 目标是**在权威账本上线性化**；原子脚本只覆盖单点竞态，跨存储一致性、故障切换丢写与估算透支须另行设计（见 5.9.5 ⑤） | 额度服务不可用 → 按主体等级差异化：核心业务 **fail-open**（= **允许有界应急透支**，须定义应急额度、有效期、并发与全局敞口及补扣失败处理；应急份额预先分配、不可重复领取，失联旧实例须 fencing，见 5.9.5 ⑤ 第 6 条），长尾业务 **fail-close**；该策略必须事先书面约定并对外说明其后果 |
| ③ 用量回流 | 网关 → 计量 → Portal，异步批量 | 目标为**至少一次 + 事件 ID 去重**；该目标须由**写前日志/持久事件或事务 outbox** 支撑并定义提交点与确认，**不能由"退出前 flush"证明**（SIGKILL/节点损毁会绕过它） | 失败进持久队列重试；按 8.4 的**请求生命周期 / 计量质量 / 结算状态三维口径**分类并设积压告警；与推理侧执行记录定期对账 |
| ④ 控制指令 | Portal → 网关，极低频高危 | **沿用链路①的高风险类保证**：最大生效时限 + 实例应用确认 + 未确认实例受限或隔离（**不可仅写"即时生效"**——推送或短轮询本身并不保证隔离实例即时生效） | 必须二次确认 + 操作审计 + 可撤销；建议设自动过期，避免"临时熔断"变成永久遗留。**撤销类指令适用于其后的每一次调用**，不能只做到"拒绝新会话"；既有连接与在途调用的取消边界须在实施前明确约定（见 8.8 T08） |
**一条常见的设计错误**：把 Portal 做成请求路径上的同步依赖（例如每次调用都去 Portal 查配额）。正确做法是**治理控制面 Portal 不成为逐请求同步依赖**；确有需要时，请求路径可同步访问**专用的额度、鉴权或策略服务**，但这些服务须独立设计其 SLA、容量与降级语义——这不等于禁止请求路径上的一切同步依赖，而是禁止把面向人使用的管理控制台放进请求链路。
```mermaid
sequenceDiagram
autonumber
participant U as 用户/应用
participant G as 治理网关(L1)
participant Q as 额度服务(权威账本)
participant I as 推理调度层(L2)
participant M as 算力池
participant A as 分析/观测存储
U->>G: 请求（携带密钥/任务类型/降级契约）
G->>G: 主体解析 + 模型准入 + 剥离并重建治理控制字段（请求头与请求体）
G->>Q: 预留（所选计价单位；WTU 仅为其中一种取值）
alt 预留不足
Q-->>G: 拒绝
G->>G: 判断调用方契约是否允许降级
alt 契约不允许降级
G-->>U: 拒绝并终止本次请求（附自助解决路径）
else 允许降级
G->>G: 重新授权（目标模型/上下文变换）
alt 重新授权不通过
G-->>U: 拒绝并终止本次请求
else 重新授权通过
G->>Q: 按降级目标重新预留
alt 重新预留失败
G-->>U: 拒绝并终止本次请求（附自助解决路径）
else 重新预留成功
Note over G,Q: 持有有效预留，进入执行段
end
end
end
end
opt 授权通过且持有有效预留（原请求或契约内降级）
G->>I: 转发（注入可信治理上下文：priority / fairness-id 等，头与请求体扩展字段）
I->>I: 饱和检测 → 按已选定的优先级/公平策略准入排队
I->>M: 选点（负载 + KV 前缀缓存亲和）
M-->>I: 响应增量
I-->>G: 响应增量
G-->>U: 持续转发增量（流式）
G->>Q: 终止后提交结算；usage 缺失则记 unknown 保留预留待核对
G->>A: 发布观测/分析事件（分析副本，非权威账本）
end
Note over G,A: 任何拒绝或未持有有效预留的路径均不进入转发；故障与异常分支见 8.8 T02 / T05 / T06
```
#### 8.6.5 "驱动合理使用"的机制设计
| 目标 | 机制 | 需要防范的副作用 |
|---|---|---|
| 用**对**模型 | 模型分级 + 所选计价单位的差异化系数（启用 WTU 时即 WTU 系数）；默认路由到"够用"的模型；高阶模型需申请并说明用途 | 分级过粗会逼用户全部申请高阶；需定期看降级后的效果反馈 |
| 写**好** prompt | 前缀缓存命中折减、超长上下文加价、重复前缀提示优化建议 | 折减规则需可解释，否则用户无法理解账单波动 |
| **错峰**运行 | 低优先级/批处理档折扣 | **承诺完成窗口必须有保留容量或接单限制做支撑**；若该档位按 8.5.3 被定义为"允许饥饿"，则**不得同时承诺无条件完成**，只能给出尽力而为语义 |
| 不**浪费** | 识别重试风暴、无效轮询、超长无意义上下文并计入消耗；失败请求的计费规则事先公示 | 计费规则不透明会引发信任问题，须在 Portal 可查 |
| **透明**与公平 | showback 看板、部门排行榜、配额与消耗公开 | 排行榜可能诱发"刷用量"，指标应与业务产出挂钩而非绝对消耗量 |
> **反模式警示（最重要的一条）**：一刀切的硬限额会把业务逼向"绕过网关"——自建直连、共用私人密钥、影子部署，最终**失去的是全部治理能力而不只是那点额度**。因此三条底线建议写入设计原则：**降级优先于拒绝**；**申请通道永远畅通且有 SLA**；**任何拒绝都必须返回可自助解决的路径**（如何申请、降级到哪个模型、何时恢复）。
> **但"降级优先于拒绝"必须受契约约束**：自动换小模型、缩短上下文、转异步批处理**都改变了调用契约**，不能由网关单方面静默执行。要求：① 由**调用方显式声明**可接受的替代模型集合、质量下限、允许的上下文变换、以及是否接受同步转异步；② 降级后须**重新走权限校验与额度预留**再执行并结算（8.6.4 时序图的降级分支即按此规则绘制：重新授权或重新预留任一失败即终止本次请求，不进入转发）；③ **流已开始输出后不得透明拼接另一模型的续写**；④ 余额为零时降级到小模型**仍然消耗算力**，因此必须另设应急额度，不能用"降级"绕开额度或权限拒绝；⑤ 涉及有副作用的工具调用时，降级与重试都需业务级幂等保障（与 7.1 中 MCP 移除流恢复后的重发风险同源）。
---
### 8.7 运维监控与运营管理能力清单（超出标准观测与按需内容留存）
> 说明：OTel 标准观测信号上报与**按需启用的内容留存**（默认仅字段白名单内的元数据，见 8.6.2 第 8 项）只是基线，不是全部。以下按八个域给出需要额外开立的能力，标注"必备/增强"。形态 B 特有项已单独标注。
| 域 | 必备能力 | 增强能力 |
|---|---|---|
| **1. 服务可用性与 SLO** | 分级 SLO 定义与达成率（TTFT / TPOT / 端到端，按优先级档分别定义）；错误预算消耗看板；上游探活与熔断半开策略；**饱和时的取舍口径公示**（保 TPOT 牺牲 TTFT，见 8.5.3） | 影子流量与合成拨测；SLO 违约的自动降级联动 |
| **2. 算力与容量运维**（形态 B） | 队列深度、排队时长分布、KV 缓存水位、抢占次数、饱和度信号；容量水位预警与扩缩容联动（以 vLLM 指标驱动 HPA/KEDA）；副本健康与模型加载状态 | 容量预测与采购建议；P/D 分离与 variant 配比调优；碎片化显存治理 |
| **3. 质量与效果运营** | **标准观测与按需内容留存**（内容类留存按数据分级启用）；回归评测集与上线前基线比对；输出质量抽检流程；失败样本归档与复盘；**降级命中率与降级后效果反馈** | 模型 A/B 与灰度放量；用户满意度/采纳率回收；坏样本自动聚类 |
| **4. 成本与计量运营** | 原始计量与所选计价单位的多维归因（用户/项目/任务/模型）；预算执行率；**账本与算力用量的对账差异率**；浪费识别（重试风暴、无效轮询、超长上下文） | chargeback 结算与内部转账；闲置副本与低效模型识别；单位业务产出成本趋势 |
| **5. 安全与合规运维** | 审计日志防篡改（WORM）；**数据分级驱动的留存策略与字段白名单（属一期基础，非增强项）**；PII/敏感词命中统计；越权与异常调用检测（用量陡增、非工作时间、密钥爆破）；密钥轮转与泄露应急 | 红队演练与注入攻击回归；影子 AI 发现（旁路流量识别） |
| **6. 变更与配置运维** | 策略与路由配置版本化、灰度发布、一键回滚、变更审计；**配置漂移检测**（多网关实例间策略版本一致性） | 变更影响面预演（基于历史流量回放）；配置即代码与审批流打通 |
| **7. 服务台与自助运维** | 配额与余额自助查询；错误码自助诊断（尤其"为什么我被降级/被拒"）；**调用回放（脱敏，且仅限隔离评测环境；禁止默认重放带副作用的真实工具调用）**；工单系统联动 | 自助限额模拟器（申请前预估）；常见问题的诊断机器人 |
| **8. 报表与治理** | 月度运营报告（用量、成本、SLO、异常 TOP）；模型准入与下线评审记录；配额审批统计 | 治理委员会看板；跨部门效能横向对比；年度容量与预算规划输入 |
**关键指标清单（建议最小集）**
| 来源 | 指标 | 用途 |
|---|---|---|
| 网关（L1） | QPS、TTFT、TPOT、端到端延迟、错误率（按错误类分）、**配额拒绝率、降级率、排队时长**、缓存命中率与节约量、活跃主体数 | 运营与 SLO |
| 推理网关（L2） | 准入排队长度与等待时长（按优先级档）、丢弃/超时计数、公平性指标（各租户获得的调度机会） | 饱和治理 |
| 算力池（vLLM 等） | `vllm:num_requests_running`、`vllm:num_requests_waiting`、`vllm:kv_cache_usage_perc`（KV 缓存块占用比例）、`vllm:prefix_cache_queries` / `vllm:prefix_cache_hits`（命中率由两计数器推导）、`vllm:num_preemptions_total`、`vllm:time_to_first_token_seconds`、`vllm:request_time_per_output_token_seconds`（请求级 TPOT）与 `vllm:inter_token_latency_seconds`（流式输出间隔）、`vllm:e2e_request_latency_seconds`、`vllm:prompt_tokens_total` / `vllm:generation_tokens_total` | 容量与扩缩容 |
> **两点口径提醒**：① 上表 vLLM 指标名按其 latest 版《Metrics 设计》文档（V1 引擎口径，2026-10-17 核对）列出；旧版的 `gpu_cache_usage_perc`、`gpu_prefix_cache_hit_rate` 等名称已改名或弃用。**指标名随版本演进**，落地时须锁定一个 vLLM 版本，以实际部署版本的 `/metrics` 为准；② **OpenTelemetry GenAI 语义约定仍在演进**——该约定已迁移至独立的 GenAI 语义约定仓库维护，官方表述为"正在被使用且处于积极开发阶段"，截至本报告核验时点（2026-10-17）**未见官方将其标记为 stable**，多份二手资料称其属性仍为 Development 状态。因此建议：以 OTel GenAI 约定为主干字段，企业自有维度（任务类型、优先级档、WTU、降级标记）作为扩展字段并集中定义，同时**锁定所采用的约定版本**、在升级时统一迁移，避免各系统字段语义漂移。
---
### 8.8 POC 验收矩阵与实施前待决项
> 性质声明：以下全部为**待执行用例**，不是已完成的测试记录。执行前须先锁定版本、配置、负载画像与判定阈值，执行后归档原始证据。**本报告的任何结论都不能替代这些用例的实测结果**；未通过对应用例的能力，只能进入受控 POC，不得进入生产承载。
| 编号 | 用例场景 | 必须观测到的结果 | 关联章节 |
|---|---|---|---|
| T01 | 并发接近额度耗尽、实际用量超出估算、组织与个人额度同时受限 | 原子约束的作用范围被明确；硬上限成立**或**约定透支边界成立；实际消耗被完整记录而非丢弃。**另须判定两点**：① 强制的输出上限与已提交预留金额**是否匹配**；② 分段追加预留失败后**是否仍发生未被覆盖的消耗** | 5.9.5 ⑤ |
| T02 | 预扣提交后应答丢失、结算重复/乱序到达、Redis 主从切换、DB 故障 | 不重复扣退；未知状态请求可核对；余额重建结果与权威账本一致。**另须判定**：重试复用稳定幂等键而非新生成 event ID；同一 reservation **不可重复提交或同时提交与释放**；`unknown` 期间其预留**保持有效不被自动释放** | 5.9.5 ⑤、8.6.4 |
| T03 | 预扣后跨月、grant 到期、并发重置、退款晚到 | 归属周期明确；旧周期退款不会错误增发新周期权益 | 8.3 `ledger` |
| T04 | SIGKILL、节点损毁、事件存储阻塞 | 实测持久性与 RPO；丢失可被发现；**不以正常退出 flush 代替持久性保证** | 5.9.5 ⑤ |
| T05 | SSE 首帧前/后断连、上游无 usage、上游仍在计算、取消失败 | 各状态可区分；不透明拼接不同模型输出；估算值与最终结算可追踪 | 5.9.5 ⑤、8.6.5 |
| T06 | 额度不足触发降级、上下文变换、同步转异步 | 存在调用方契约；降级后重新授权与重新预留；零余额处置与任务身份明确 | 8.6.5 |
| T07 | 高优先级持续饱和、长短请求混合、低优先级长期排队 | **是否允许饿死被显式定义**；保底份额或 TTL 生效；接纳率与分级 SLO 被记录 | 8.5.3 |
| T08 | 伪造 `priority`/`fairness-id` 头或请求体中的同类调度字段、越权调用模型、密钥吊销遇网络分区 | 外部伪造调度上下文不被接受；撤销最大生效时限与失联策略可验证。**另须判定**：撤销对**其后每一次调用**均生效（不止"拒绝新会话"）；既有连接与在途调用的取消边界符合事先约定 | 8.6.2 第 12 项、8.6.4 链路①④ |
| T09 | 缓存跨租户与同租户跨权限、知识库更新、模型版本升级 | 隔离与失效规则成立；**响应缓存与前缀 KV 缓存分别核验**。**另须判定**：前缀 KV 缓存的信任域由可信网关/调度层决定，**调用方无法通过伪造共享标识（如自带 salt）加入他人缓存域**；并评估时序侧信道与哈希碰撞风险 | 5.5、8.5.1 |
| T10 | 多副本下 KV 事件延迟、EPP 故障、容量变化、在线与离线争用 | 不突破资源与授权边界；降级选点、恢复与队列清理符合契约 | 8.5.2、8.5.3 |
| T11 | 不同模型/上下文/缓存/并发负载下的计价单位回算 | 原始计量可解释；重复计价被排除；误差范围与计价版本明确 | 8.5.4 |
| T12 | 同负载下直连与经网关对照、模型升级、质量回归 | 同时给出延迟、吞吐、拒绝率、资源消耗、业务质量与完整配置 | 8.7、8.4 KPI |
| T13 | 网关不可用时启用应急旁路、旁路到期 | 旁路有独立鉴权、模型与数据域限制、限额与审计；到期自动退出，不残留长期通道 | 8.5.1 |
| T14 | 额度服务不可用期间实例扩容、反复重启、旧实例失联后恢复 | 应急份额不可重复领取，全局敞口有界；恢复后完成对账；旧实例被 fencing，失去新增执行与修改权威状态的权限，其迟到用量经权威对账流程核对后入账，未确认的在途敞口不被回收再发 | 5.9.5 ⑤ 第 6 条、8.6.4 链路② |
| T15 | 排队 TTL 到期与请求已派发执行并发发生；跨供应商 fallback 目标缺少授权或不满足数据驻留 | 未经执行侧确认不释放预留；fallback 前重新校验权限、驻留与外发条件，不满足即按契约拒绝或降级 | 5.2、8.5.3、8.6.4 |
| T16 | 低权限主体或受注入的模型调用管理 API/管理用 MCP 工具；请求体中夹带凭证类字段及其别名、调度控制字段 | 管理操作按只读/有限写入/高危审批分档执行；凭证类与调度类字段按白名单处理，别名不能绕过 | 4.5、7.5、8.6.2 第 12 项 |
**实施前待决项登记表**：以下事项**不需要在研究定稿前解决**，但必须在实施启动前逐项定下来并留痕；阈值可先写"POC 开始前确定"，责任角色沿用 8.1 的五类 accountable 角色，**不在本报告中虚构姓名或数字**。
| 待决项 | 内容 | 责任角色 | 决策时点 | 交付物 | 对应用例 |
|---|---|---|---|---|---|
| 权威账本与恢复 | 权威存储、提交点、缓存重建规则、恢复期准入方式 | 额度账本 | POC 开始前 | 额度一致性设计说明 | T01–T04 |
| 硬上限与应急敞口 | 预留口径、输出上限强制方式、透支敞口与补扣规则、应急份额的发放与 fencing | 额度账本 + 计价 | POC 开始前 | 额度协议（含 fail-open 条款） | T01、T02、T06、T14 |
| 调度与容量 | 优先级档、公平策略、是否允许低优先级饥饿、TTL 与取消边界 | 调度与容量 | POC 开始前 | 调度策略与 SLO 约定 | T07、T10 |
| 协议与引擎版本 | GIE/EPP/引擎/MCP 各层锁定版本与兼容组合（含 MCP 新旧版本共存策略） | 调度与容量 | POC 开始前 | 版本矩阵 | T10 |
| 旁路与管理面 | 应急旁路的授权与退出条件、管理 API/管理 MCP 的分级授权 | 权限 | POC 开始前 | 旁路与管理面授权规范 | T13、T16 |
| 留存与撤销 | 数据分级、字段白名单、撤销最大生效时限与失联策略 | 权限 | POC 开始前 | 数据留存与撤销规范 | T08、T09 |
| 计价与质量阈值 | 计价单位、标定方法、回算规则、业务质量判定阈值 | 计价 + 业务质量 | POC 开始前 | 计价规范与质量基线 | T11、T12 |
---
## 九、附录：关键事实来源与证据分级
本报告关键事实按"优先一手、二手复核"原则逐项追溯，**但不构成"全部已核验"的总括保证**；表中仍存在待核条目。**A/B/C 仅表示来源类型，不表示核验状态或证明力度**——三者分列如下。**厂商能力断言与运行保证不得仅由产品自述、用户报告或作者推论支撑**；逻辑反例可以支持"机制存在局限"这类判断，但不能替代运行实测结论。分级标准如下：
**一、来源类型（A/B/C）——只描述来源身份，不含核验状态判断**：
- **A 级（一手/官方）**：厂商或标准组织的官方文档、官方博客、官方新闻稿、官方 GitHub Release/仓库文件、法规发布机关原文。
- **B 级（二手，有交叉印证）**：权威行业媒体，或多个来源相互印证的二手信息。
- **C 级（二手，单一来源）**：单一二手来源（技术博客、内容平台转载等）。
- **issue（项目公开 issue）**：由用户在项目仓库提交的缺陷报告或讨论，位于官方仓库但**不代表项目官方结论**，单列一类。
**二、核验状态**：逐条记录在表内"核验结果"列（✅ 确认 / ⚠️ 有限定 / 待核）。**来源等级高不等于已核验，也不等于证明力强**——例如 A 级的产品自述只能证明"厂商如此声明"。
**三、证据性质**：表内"证据性质"列按下列取值标注——**规范事实**（标准、法规、官方 API 定义）、**产品自述**（厂商文档、博客与公告，含推广立场；能证明"厂商如何描述其能力"，不能单独证明运行保证）、**用户报告**（公开 issue，仅证明"有人在某版本报告过"）、**安全公告**（项目方发布的漏洞通告，证明受影响与修复版本的官方认定）、**安全研究**（安全厂商或研究机构的研究报告，非同行评审，含研究方立场）、**学术研究**（论文）、**二手报道**（媒体或二手资料转述）、**作者推论**（本报告的设计判断与逻辑反例）、**待核**。
**四、核验时点**：v5.2 新增或复核的条目在"核验结果"列注明核验日期；未注明日期的 ✅ 为历史版本（v1.x–v5.1，2026-08 至 2026-09-18）的核验记录，本版未逐条重访，**不等于截至本版仍然成立**。
### 9.1 关键事实来源分级表
> 编号为历史沿用，其中三项（原 #18、#22、#40）因未能追溯到一手来源已从本表与正文一并移除；#66 自 v5.2 起并入 #48，#70–#95 为 v5.2 新增。处置过程见第十一章。
| # | 关键事实 | 核验结果 | 来源 | 来源类型 | 证据性质 |
|---|---------|---------|------|------|------|
| 1 | AWS Bedrock AgentCore 2025.10.13 GA | ✅ 确认 | AWS 官方博客 | A | 产品自述 |
| 2 | Azure APIM AI Gateway tier 2026.08 公开预览 | ✅ 确认 | Microsoft 官方（learn/updates/techcommunity） | A | 产品自述 |
| 3 | Databricks Unity AI Gateway 2026.04.15；当前官方文档名称为 Unity Gateway，Release Notes 记载 2026-08-04 GA | ✅ 确认（名称与 GA 于 2026-10-17 对照 Release Notes 补核；service policies、agent services 与 Skills API 为 Beta，同日补核） | Databricks 官方博客 + Unity Gateway Release Notes | A | 产品自述 |
| 4 | Cloudflare AI Gateway 2024.05.22 GA | ✅ 确认 | Cloudflare 官方博客 | A | 产品自述 |
| 5 | Linux 基金会 AAIF 2025.12.09 成立 | ✅ 确认 | Linux 基金会官方新闻稿 | A | 规范事实 |
| 6 | Higress 加入 CNCF Sandbox 2026.03.25 | ✅ 确认（以官方博客发布时间戳为准） | CNCF 官方博客 | A | 规范事实 |
| 7 | Higress v1.4.0 2024.05.29 发布 | ✅ 确认 | GitHub Release | A | 产品自述 |
| 8 | F5 AI Gateway 2024.11 抢先体验 | ✅ 确认 | F5 官方新闻稿 | A | 产品自述 |
| 9 | Kong 开源 AI 插件 2024.02.15（Gateway 3.6） | ✅ 确认 | Kong 官方新闻稿 | A | 产品自述 |
| 10 | LiteLLM PyPI 供应链攻击 2026.03.24 | ✅ 确认 | LiteLLM 官方安全公告 + Snyk | A | 产品自述 |
| 11 | OX Security MCP STDIO 风险 2026.04.15 披露 | ✅ 确认 | 一手：OX Security 官方博客（A）；二手：CSA 研究笔记（B） | A/B 分列 | 安全研究 |
| 12 | 公开 MCP 服务器 1 万+（2025.12） | ✅ 确认（2025-12 快照） | Linux 基金会官方新闻稿 | A | 产品自述 |
| 13 | MCP 9700 万/月 SDK 下载（97M+，2025.12） | ✅ 追到 Anthropic 官方一手 | Anthropic 官方新闻稿（捐赠 MCP 公告） | A | 产品自述 |
| 14 | OpenAI API 2020-06-11 发布 | ✅ 定位到官方页面《OpenAI API》（日期 2020-06-11，2026-10-17 经检索核对；直接访问受限） | OpenAI 官方博客 | A | 产品自述 |
| 15 | LiteLLM 2023 开源、Portkey 2023 成立 | 可 GitHub 交叉验证 | 多个二手来源一致 | B | 二手报道 |
| 16 | Zenlayer AI 网关 2025.10.28 发布 | ✅ 追到官方新闻稿 | Zenlayer 官方新闻稿 | A | 产品自述 |
| 17 | Kong AI Gateway 3.14 支持 A2A（2026.04） | ✅ 追到官方博客 | Kong 官方博客 | A | 产品自述 |
| 19 | 开源项目 Star/Provider 数（LiteLLM 100+、Portkey 1600+、OpenRouter 400+ 等） | 动态数据（快照 2026-08） | 多二手来源 + GitHub 官方仓库可交叉 | B | 二手报道 |
| 20 | 国内云厂商能力描述（百炼/千帆/混元/方舟/息壤等） | 二手为主 | it168、kejihangye 等行业媒体 | B/C | 二手报道 |
| 21 | Bifrost 11µs 开销@5000 RPS | ✅ 追到官方 README（厂商自测基准，t3.xlarge，非独立第三方） | Bifrost 官方 GitHub README | A | 产品自述 |
| 23 | Google ADK 累计下载接近 7000 万（2026 Q2） | ✅ 读取 Alphabet IR 发布的实录 PDF 原文："Agent Development Kit … reached nearly 70 million total downloads"（累计口径；2026-10-17 核对） | Alphabet 2026 Q2 财报电话会议实录（2026-07-22） | A | 产品自述 |
| 24 | 百度千帆 Agent 数量 | 正文已不再引用（与网关能力无关） | 中新网/经济参考报/网易等 | B | 二手报道 |
| 25 | OpenRouter 5.5% 平台费 | ✅ OpenRouter 官方博客（对充值额收取，非 token 加价） | OpenRouter 官方博客 | A | 产品自述 |
| 26 | New API 三层倍率体系（模型倍率 × 补全倍率 × 分组倍率） | ✅ 官方文档 | New API 官方文档（doc.newapi.pro 倍率设置） | A | 产品自述 |
| 27 | LiteLLM 内置确定性路由（usage-based-routing-v2、complexity_router） | ✅ 官方 config 示例 | LiteLLM 官方配置文档 | A | 产品自述 |
| 28 | Not Diamond "not a gateway，架在网关前" 的定位 | ✅ 官方博客 | Not Diamond《Model Routing vs Gateways》 | A | 产品自述 |
| 29 | New API 1 USD = 500,000 配额点、倍率优先级（个人>分组>默认） | ✅ 官方文档 | New API 官方文档《倍率设置》 | A | 产品自述 |
| 30 | LiteLLM `max_budget`/`budget_duration`(30s–1mo)/多层级预算/"默认所有预算在配置时区午夜重置"（多窗口 `budget_limits` 按 UTC 日历对齐，见 #81） | ✅ 官方文档 | LiteLLM《Budgets, Rate Limits》《Budget Reset Times and Timezones》 | A | 产品自述 |
| 31 | LiteLLM 语义缓存后端（`redis-semantic`/`qdrant-semantic`/`valkey-semantic`）、`similarity_threshold`、`semantic_cache_scope`（默认 key，可选 end_user） | ✅ 官方文档 | LiteLLM《Semantic Caching》 | A | 产品自述 |
| 32 | LiteLLM MCP 网关：统一端点、三种传输、按 Key/Team/User 工具级权限，开源版可用 | ✅ 官方文档 | LiteLLM《MCP Overview》《MCP Permission Management》 | A | 产品自述 |
| 33 | LiteLLM 预算陈旧计数误杀、重置后 Redis 计数未失效、`1mo` 行为不一致 | ✅ 项目公开 issue（#27735 / #29576 / #25432） | BerriAI/litellm issues | issue（修复状态需按版本复核） | 用户报告 |
| 34 | one-api / new-api 配额扣减 TOCTOU 竞态与异步非原子写入可致透支 | ✅ 项目公开 issue（new-api #5690 / one-api #2440） | GitHub issues | issue（同上） | 用户报告 |
| 35 | new-api 流式 `/v1/responses` 在 `response.incomplete` 丢失 usage 致计费为 0 | ✅ 项目公开 issue（#7241） | GitHub issue | issue（同上） | 用户报告 |
| 36 | New API "预扣—结算—差额调整"三步流程 | 二手技术解读，与 one-api/new-api 源码中 `PreConsumeTokenQuota`/`postConsumeQuota` 命名可交叉印证 | 奇连 AI 技术解读 + GitHub 源码 | B | 二手报道 |
| 37 | Portkey 预算按 USD 或 token、周日/每月 1 日 00:00 UTC 重置、Alert Threshold | ✅ 官方文档 | Portkey《Enforce Budget and Rate Limit》 | A | 产品自述 |
| 38 | Bifrost 层级预算（Customer→Team→VK→Provider Config）、`reset_duration`/`calendar_aligned`/`override_amount`、token 与请求双限额 | ✅ 官方文档 | Bifrost《Budget and Limits》 | A | 产品自述 |
| 39 | CacheAttack 黑盒碰撞攻击在 LLM 响应劫持达 86% 命中率 | ✅ 追到一手论文摘要原文 "achieves a hit rate of 86% in LLM response hijacking" | arXiv 2601.23088《From Similarity to Vulnerability: Key Collision Attack on LLM Semantic Caching》 | A | 学术研究 |
| 41 | Higress `ai-quota` 的 Redis key 规则与 `/quota`、`/quota/refresh`、`/quota/delta` 接口；文档未提供周期性自动重置 | ✅ 官方插件文档 | Higress 官方文档 | A | 产品自述 |
| 42 | Kong `ai-rate-limiting-advanced` 的 `tokens_count_strategy`（total/prompt/completion/cost）、窗口类型、429 + Retry-After | ✅ 官方插件文档 | Kong 官方文档 | A | 产品自述 |
| 43 | Envoy AI Gateway 更名 Agent Router 并成为 AAIF 项目；token 限流支持 Input/Output/Total/CEL | ✅ 官方公告 + AAIF 项目页（原域名 302 跳转实测，2026-09-18）；加入日期与版本见 #76 | Agent Router 官方博客/文档、AAIF 项目页 | A | 规范事实 |
| 44 | OpenMeter grant 的 `priority`（0–255，0 最高）/`expiration`/`recurrence{interval,anchor}`/`issueAfterReset`/结转公式；官网署名 "OpenMeter by Kong" | ✅ 官方文档与官网（priority 方向 2026-10-17 复核）；收购事实见 #75 | OpenMeter 官方文档 | A | 产品自述 |
| 45 | Lago wallet 的 `rate_amount`、paid/granted credits、recurring top-up、`expiration_at`、ongoing balance | ✅ 官方文档 | Lago 官方文档 | A | 产品自述 |
| 46 | Stripe credit grants 的 `applicability_config`、priority、过期与 meter 配合 | ✅ 官方实现指南 | Stripe 官方文档 | A | 产品自述 |
| 47 | APISIX `mcp-bridge` 仅做 stdio↔SSE 桥接且已官方标记 deprecated、不建议新部署 | ✅ 官方插件文档原文 "is deprecated and will be removed in a future release" | APISIX 官方文档 | A | 产品自述 |
| 48 | MCP 2026-07-28 规范版本 Key Changes（移除会话与 initialize 握手、新增 `server/discover`、Tasks 移入官方扩展、MRTR 与必需 `resultType`、移除 SSE 流恢复与消息重发、`ttlMs`/`cacheScope`、`iss` 校验、Roots/Sampling/Logging 与动态客户端注册弃用、Extensions 框架）；**"MCP Apps" 未见于正式版 changelog，正文不采用** | ✅ 官方规范变更日志逐条核对（2026-10-17 复核）；候选版博客（2026-05-21 冻结）列有 MCP Apps 扩展，正式版 changelog 未列，以 changelog 为准 | modelcontextprotocol.io 官方 | A | 规范事实 |
| 49 | OX Security 原文给出三个口径：150M+ 下载（统计窗口与包范围未说明）、7000+ 台公网可访问服务器、最多 20 万个潜在受影响实例（上限估计）；据 OX 转述，Anthropic 认为属预期行为 | ✅ 读取 OX 原文（2026-10-17）；三个数字均未公开方法，正文 7.4 分列 | 一手：OX Security 官方博客（A）；二手：媒体报道（B，Infosecurity 原文链接本版未能定位，仅作辅助，不支撑结论） | A/B 分列 | 安全研究 |
| 50 | GIE `InferencePool` 字段（`selector`/`targetPorts`/`endpointPickerRef`/`failureMode: FailOpen`）、EPP 定位与模型感知/LoRA/前缀缓存路由、serving priority | ✅ Kubernetes SIG 官方文档 | gateway-api-inference-extension.sigs.k8s.io | A | 规范事实 |
| 51 | GIE `InferenceObjective` 为 **alpha**、经 `x-gateway-inference-objective` 头关联、官方明示可能破坏性变更并将扩展 SLO attainment | ✅ 官方文档原文 | 同上 | A | 产品自述 |
| 52 | GIE Flow Control：三类问题（嘈杂邻居/调度遗憾/优先级反转）、"保 TPOT 牺牲 TTFT"、FlowKey（`x-gateway-inference-fairness-id` + priority，负值为低优先级）、严格优先级、工作保守公平、`maxBytes`/`defaultRequestTTL`、饱和检测（KV 水位 + 队列深度） | ✅ 官方 Flow Control 指南 | 同上 | A | 产品自述 |
| 53 | llm-d 架构：Proxy（GIE 标准、ext-proc 咨询 EPP）+ EPP 打分、前缀缓存感知路由、KV 索引与分层卸载、P/D 分离、Workload Variant Autoscaler | ✅ 项目官方文档 | llm-d.ai/docs/architecture | A | 产品自述 |
| 54 | llm-d flow control：准入与调度分离、同优先级带内租户轮询防饿死、分级 SLO 实践、`dispatcher ceiling` 等参数须实测校准 | ✅ Red Hat 开发者博客（项目主要贡献方，**含项目推广立场**，采信时宜独立评估） | developers.redhat.com | A | 产品自述 |
| 55 | NVIDIA Dynamo KV-aware 路由：基于 worker 上报的 KV 缓存事件评分、`--router-mode kv`、可经 GIE EPP 接入、Planner 组件 | ✅ NVIDIA 官方文档 | docs.nvidia.com/dynamo | A | 产品自述 |
| 56 | vLLM 生产指标名（`num_requests_running`/`num_requests_waiting`/`gpu_cache_usage_perc`/`gpu_prefix_cache_hit_rate`/`num_preemptions_total`/TTFT/TPOT/e2e/token 计数等） | ✅ vLLM 官方文档（**v0.6.x 历史口径，部分已改名或弃用；当前口径见 #88**） | docs.vllm.ai | A（版本相关） | 产品自述 |
| 57 | Kueue ClusterQueue：`nominalQuota`、`borrowingLimit`、`lendingLimit`、cohort 借用、`reclaimWithinCohort`/`withinClusterQueue` 抢占、Fair Sharing | ✅ Kubernetes SIG 官方文档 | kueue.sigs.k8s.io | A | 规范事实 |
| 58 | OTel GenAI 语义约定已迁移至独立 GenAI 语义约定仓库；官方博客表述为"正在被使用且处于积极开发阶段" | ✅ 迁移声明与官方博客表述属实；⚠️ **"是否已达 stable"未能证实**，正文与 8.2 决策点 7 按"仍在演进"处理 | opentelemetry.io | A（迁移事实）/ **待复核**（稳定性状态） | 待核 |
| 59 | 云厂商侧同类实现佐证：GKE Inference Gateway 的 KV-cache-aware 路由、Azure Application Gateway for Containers 的 inference gateway | 仅作"该形态已被多方采纳"的佐证，未逐项核验能力细节 | Microsoft Learn（A）；Spheron 博客（C） | A/C 分列 | 产品自述 / 二手报道 |
| 60 | 私有化/共享 AI 平台的 showback 与 chargeback 实践 | 行业媒体与实践文章，作为**方法参考**而非规范依据；本报告对"先 showback 后 chargeback"的建议属作者判断 | CloudZero、vdf.ai 等 | B/C | 二手报道 + 作者推论 |
| 61 | Redis 复制/故障切换不构成强一致 CP 系统（即使使用 `WAIT`），切换仍可能丢失已确认写入 | ✅ Redis 官方复制文档 | redis.io | A | 规范事实 |
| 62 | **New API 主分支 LICENSE 为 AGPL-3.0** | ✅ 直接读取仓库 LICENSE 文件首部："GNU AFFERO GENERAL PUBLIC LICENSE Version 3"；**历史版本许可须回查对应 commit** | github.com/QuantumNous/new-api | A | 规范事实 |
| 63 | **agentgateway 以 Rust 实现**，覆盖 HTTP/gRPC、LLM、MCP、A2A，含 15+ LLM 提供商、cost controls 等 | ✅ 官方文档 Introduction | agentgateway.dev | A | 产品自述 |
| 64 | GIE 官方自述为"定义规范以构建兼容生态"；自带 EPP 为"用于一致性测试的参考实现"，**生产应自建 EPP 或采用既有实现（如 llm-d-router）** | ✅ 官方主页原文 | gateway-api-inference-extension.sigs.k8s.io | A | 规范事实 |
| 65 | 《生成式人工智能服务管理暂行办法》**第二条**：适用于向境内公众提供服务的情形；"行业组织、企业…研发、应用生成式人工智能技术，未向境内公众提供生成式人工智能服务的，**不适用本办法的规定**" | ✅ 国家网信办官网原文 | cac.gov.cn | A | 规范事实 |
| 66 | （v5.2 起并入 #48，编号保留不再使用） | — | — | — | — |
| 67 | vLLM APC "只减少处理查询（prefill）阶段的时间，不减少生成新 token 的时间"；无共享前缀或长输出场景收益很小 | ✅ 官方 APC 文档 Introduction 与 Limits | docs.vllm.ai | A | 产品自述 |
| 68 | OpenMeter 结转公式作用于**单个 grant 余额**；entitlement 引擎按**分钟粒度**预聚合，发放/重置/过期**不支持亚分钟精度** | ✅ 官方 Grant 文档（含 Caveats）。**证据边界**：该页仅证明时间精度限制，**不能据此推断其并发预留原子性或整体逐请求控制能力**（见 6.4） | openmeter.io | A（规范事实，但适用范围有限） | 规范事实 |
| 69 | vLLM 提供 `cache_salt` 将前缀缓存共享限定在约定同一 salt 的信任组内，并"防止攻击者通过观察延迟差异推断缓存内容"；非密码学安全哈希的碰撞在多租户环境下"甚至可能泄露隐私信息" | ✅ vLLM 官方前缀缓存设计文档 | github.com/vllm-project/vllm | A | 产品自述 |
| 70 | Assistants API 已于 2026-08-26 下线；Chat Completions "仍受支持，新项目推荐 Responses"；GPT-5.4 起 Chat Completions 在 `reasoning_effort` 非 `none` 时不支持工具调用 | ✅ 官方迁移指南原文（2026-10-17） | OpenAI《Assistants migration guide》《Migrate to the Responses API》 | A | 产品自述 |
| 71 | LiteLLM v1.80.8（2025-12-06）推出 A2A Agent Gateway | ✅ 官方发布记录（2026-10-17） | LiteLLM 文档仓库 release notes | A | 产品自述 |
| 72 | LiteLLM GHSA-7hp6-4w63-5g45（2026-09-30）：密钥跨用途复用致 `internal_user` 提权至代理管理员并可执行命令，CVSS 9.9；修复版本按分支 1.100.4/1.101.3/1.102.2/1.103.1/1.104.0rc2 | ✅ 官方安全公告（2026-10-17） | GitHub Security Advisory（BerriAI/litellm） | A | 安全公告 |
| 73 | LiteLLM GHSA-g5ff-637f-6q2m（2026-10-01）：`vertex_ai_credentials` 别名绕过黑名单致任意本地文件读取，CVSS 8.1；1.95.0 修复 | ✅ 官方安全公告（2026-10-17） | GitHub Security Advisory（BerriAI/litellm） | A | 安全公告 |
| 74 | LiteAdmin MCP（2026-09-23）：经管理 API 管理虚拟密钥、模型部署、团队与预算，可限定工具或只读 | ✅ 官方博客（2026-10-17） | LiteLLM 官方博客 | A | 产品自述 |
| 75 | Kong 于 2025-09-03 宣布收购 OpenMeter，称将为 Kong Konnect 带来按量计费能力 | ✅ 官方新闻稿（2026-10-17） | Kong 官方新闻稿 | A | 产品自述 |
| 76 | Agent Router（原 Envoy AI Gateway）2026-09-10 起成为 AAIF 独立项目，原为 CNCF 下 Envoy 子项目；1.0（2026-06）作出 1.x 兼容承诺，1.1（2026-08）；Apache 2.0 | ✅ AAIF 公告（2026-09-09）与项目公告（2026-10-17） | AAIF 官方博客、Agent Router 官方博客 | A | 产品自述 |
| 77 | agentgateway 为 LF Projects 下项目，新贡献须采用 Apache-2.0；章程未提 AAIF | ✅ 项目章程原文（2026-10-17） | agentgateway CHARTER.md | A | 规范事实 |
| 78 | Azure AI Gateway tier：公开预览，仅 East US 2 / Sweden Central，无 SLA；可接多家模型与 MCP/OpenAPI/连接器工具；当前仅导出 token 用量指标 | ✅ 官方 Quickstart（页面更新 2026-08-11；2026-10-17 访问） | Microsoft Learn | A | 产品自述 |
| 79 | AgentCore 各组件发布状态：Policy、Evaluations 2025-12 预览、2026-03 GA；Harness 2026-04 预览、2026-07 GA；Registry 2026-04 预览、2026-08 GA；Web Search 2026-07 GA；Payments 2026-05 预览 | ✅ 官方 Release Notes（2026-10-17）；首批 GA 组件沿用 #1 | AWS 官方文档 | A | 产品自述 |
| 80 | New API 订阅套餐：重置周期可设不重置/每日/每周/每月/自定义，到点清零已用额度 | ✅ 官方《钱包与订阅》文档（2026-10-17）；运行语义未验证 | New API 官方文档 | A | 产品自述 |
| 81 | LiteLLM：team key 只强制 team 与 team-member 预算；v1.94.0 曾短暂强制个人预算、v1.95.0 撤回；无数据库时全局 `max_budget` fail-open；`budget_limits` 按 UTC 日历对齐 | ✅ 官方《Budgets, Rate Limits》（2026-10-17） | LiteLLM 官方文档 | A | 产品自述 |
| 82 | LiteLLM `auto_router/complexity_router`（SIMPLE/MEDIUM/COMPLEX/REASONING）；Auto Router v2（v1.94.x）合并复杂度/语义/自适应路由 | ✅ 官方文档与博客检索核对（2026-10-17） | LiteLLM《Auto Router》、《Autorouter v2》 | A | 产品自述 |
| 83 | Kong AI Gateway 2.1.0（2026-09-24）支持 MCP 2026-07-28 与 `ttlMs`/`cacheScope`；2.2.0（2026-09-30）称新增分模态计价、MCP Server Bundling、身份感知策略 | ✅ 官方 changelog 与新闻稿（2026-10-17） | Kong 官方文档、新闻稿 | A | 产品自述 |
| 84 | Cloudflare Monetization Gateway 2026-09-30 封闭测试，以 x402 在 HTTP 请求流中处理支付授权 | ✅ 官方 changelog（2026-10-17） | Cloudflare 开发者文档 | A | 产品自述 |
| 85 | Uber MCP Gateway（2026-10-01）：Registry 控制面 + Proxy Gateway 数据面；工具默认禁用；自述 800+ 服务器、5000+ 工具 | ✅ 官方工程博客（2026-10-17） | Uber 工程博客 | A | 产品自述 |
| 86 | NVIDIA Dynamo 请求体 `nvext.agent_hints`（`priority`、`strict_priority`、`osl`、`speculative_prefill`）：v1.5.1 版文档已列字段并按后端区分支持；NVIDIA 技术博客 2026-04-17 已公开介绍其中 `priority`、`osl`、`speculative_prefill` 三项（未提及 `strict_priority`）；开发版文档称 v1 API 仍在共同设计 | ✅ v1.5.1 官方文档、NVIDIA 技术博客、开发版文档（2026-10-17 访问；博客所列字段于同日复核） | NVIDIA Dynamo 文档、NVIDIA 开发者博客 | A | 产品自述 |
| 87 | llm-d 1.0 发布跟踪（2026-09-29 创建，目标 2026-10-19），范围含多租户 QoS、路由高可用、配置 API v1、Agent 感知路由 | ✅ 项目 issue（2026-10-17，状态 open）；**属计划** | llm-d GitHub issue #2619 | issue | 产品自述（计划） |
| 88 | vLLM 当前指标：`kv_cache_usage_perc`、`prefix_cache_queries`/`prefix_cache_hits`、`inter_token_latency_seconds`、`request_time_per_output_token_seconds` | ✅ 官方 latest《Metrics 设计》（2026-10-17） | docs.vllm.ai | A（版本相关） | 产品自述 |
| 89 | GIE `InferencePool` 自 v1.0.0 起为 v1/GA；`endpointPickerRef` 在 v1.5.0 前必填、现为可选；`InferenceObjective` 仍为 v1alpha2 | ✅ 官方 API 文档与 GKE 迁移指南（2026-10-17 检索） | Kubernetes SIG 官方、Google Cloud 文档 | A | 规范事实 |
| 90 | MCP 授权规范（2025-06-18）：服务器 MUST 校验令牌受众，MUST NOT 透传收到的令牌给上游；混淆代理问题 | ✅ 官方规范原文（2026-10-17） | modelcontextprotocol.io | A | 规范事实 |
| 91 | Lago 采用 AGPL-3.0（另有 Premium）；Portkey 开源 gateway 仓库采用 MIT | ✅ 官方仓库/文档（2026-10-17） | getlago/lago、Portkey-AI/gateway | A | 规范事实 |
| 92 | 修改后的《网络安全法》2025-10-28 通过、2026-01-01 施行，新增人工智能条款；《人工智能生成合成内容标识办法》2025-09-01 施行 | ✅ 多家官方媒体一致（2026-10-17 检索）；条文以全国人大常委会与网信办公布文本为准 | 新华网、国家网信办等 | B | 二手报道 |
| 93 | Kong Gateway 3.10 起未见开源构件 | 待核：仅见社区讨论与第三方版本列表，未见官方政策原文 | Kong GitHub Discussions、endoflife.date | C | 待核 |
| 94 | OTel GenAI 语义约定截至 2026 年中仍为 Development 状态 | 待核：多份二手资料一致，未取得官方注册表截图式原文 | Dash0、ClickHouse、GreptimeDB 等 | B | 二手报道 |
| 95 | AGPL-3.0 第 13 条：修改版本经网络与用户远程交互时须提供对应源码 | ✅ 许可原文 | GNU AGPLv3 | A | 规范事实 |
### 9.2 少数意见与未采纳意见
> 本节保留第 1–3 轮各席中有依据但未纳入正文、或经核实不成立的意见，供后续修订参考。处置依据见第十一章 11.2.9（第 1 轮）、11.2.10（第 2 轮）与 11.2.11（第 3 轮）。
| 来源席位 | 意见 | 处置 | 理由 |
|---|---|---|---|
| 顾问席 | 原报告把第二代独立网关定为"唯一标准解"、建议统一用 tiktoken、断言"P99 代理延迟增量均在 5ms 以内"、"未来 3 年 100% 独立形态"等，并要求逐条纠正 | **不成立，未采纳** | 经逐条对照原文，原报告不含这些表述；该席所引行号（如 report.md:1298、:1322、:1345）均落在第十一章修订历史内，与所述内容不符。按本项目记录，顾问席意见须经主持人核实后才能使用 |
| 顾问席 | 补充若干通用工程实践：P2C + EWMA 负载均衡、本地租约配额与批量核销、SSE 关闭代理缓冲与背压、Guardrails 分级（同步规则 + 旁路流式监测）、离线 Batch 与在线混部、边缘网关端云协同 | **保留为少数意见** | 方向合理，但未附可核来源，且不对应原报告的具体结论；本报告定位为调研与 POC 输入，不展开为实现细则。其中"本地租约配额"与 5.9.5 ⑤ 的一致性要求相关，实施阶段可作为候选方案在 T01–T04 中验证 |
| 顾问席 | "OTel GenAI 语义约定已正式 GA"、"vLLM 与 SGLang 联合推进网关—引擎标准协议" | **不采纳** | 未能找到一手来源；OTel 现有资料指向仍为 Development（9.1 #94） |
| 主主持 | 3.2 补入推理侧语义路由器（如 vLLM Semantic Router、NVIDIA LLM Router），8.5.2 点名代理实现层产品（kgateway、Envoy Gateway、Istio 等）并声明对 AIBrix、KServe、SGLang router 等实现未覆盖 | **保留为少数意见** | 本版未对这些项目完成一手核验；正文只保留已核项目，并在 8.5.2 要求按四层锁定版本评估，未覆盖的实现不作否定判断 |
| 主主持 | 4.5 增加"工具描述投毒/rug-pull"的独立条目 | **部分采纳** | 已并入"MCP 工具滥用"行；rug-pull 的独立量化证据未核到 |
| 核验席、主主持 | 时间线补 2025 年上半年 A2A 发布与移交 LF、llm-d 发布、MCP 2025-06-18 与 2025-11-25 版本 | **部分采纳** | 本版仅补入已核到一手来源的里程碑；上述项目来自席位知识，主持人未逐条核到发布日期，暂不写入时间线；定稿后按一手来源补证，未补证前不写入 |
| 质疑席 | Agent Router 加入 AAIF 的日期写作"9 月 10 日" | **采纳并注明双日期** | AAIF 公告发布于 2026-09-09，项目公告称 9 月 10 日正式加入；正文以加入日为准 |
| 核验席 | LiteLLM 仓库 `enterprise/` 目录适用商业许可 | **以待核方式采纳** | 主持人未读取该目录许可文件，正文写作"企业功能目录另有许可，按拟用版本核对" |
| 主主持 | Kong Gateway OSS 自 3.9 后不再发新版，若属实须重述全部"开源版"能力 | **以待核方式采纳** | 仅见社区讨论（9.1 #93），未见官方政策原文；正文在 6.3 标注"拟用版本的许可与可得性须先确认"，未据此改写能力结论 |
| 第二主持（第 2 轮独立意见 REVISE，互评改 APPROVE） | 8.6.4 时序图只写"调度头"，未覆盖请求体中的治理控制字段，主张作为阻塞项 | **采纳修改，不作为阻塞项** | 质疑席、核验席在互评中认定 8.6.2 第 12 项与 T08/T16 已覆盖请求体，属示意表述不完整；v5.3 已统一时序图，8.6.2 第 4 项于 v5.4 完成措辞统一，均为"请求头与请求体"（v5.5 更正：原记录写作 v5.3 已统一两处） |
| 顾问席 | 第 2 轮所引任务书行号与转述内容（如"零拷贝"、A/B 表各 4 项）在材料中不存在 | **不成立，未采纳** | 质疑席与核验席均指出引用失实；其 APPROVE 只计入法定人数，不作为阻塞项闭环依据，两个强席位的 APPROVE 已独立满足法定人数 |
| 核验席 | llm-d 1.0 计划于 2026-10-19 发布，定稿若晚于该日须重核 7.5 与 8.5.2 | **保留为定稿前核对项** | 截至 2026-10-17 仍为计划，正文维持"计划"表述；终审或定稿晚于 2026-10-19 时须重访一手来源 |
| 核验席（质疑席互评反对直接采纳） | 5.9.5 ⑤ 第 6 条与 T14 的"未确认的在途敞口不得回收再发"缺终止条件，旧实例永久失联时敞口会被无限期占用；建议补"租约到期且超过最大执行时长后按权威对账结论处置" | **保留为少数意见，正文不改** | 质疑席指出租约与最大执行时长结束只能限制后续执行，不能证明此前没有未上报消耗；若补终止条件，应以执行侧拒绝旧授权，并经权威对账结清或按最大可能消耗计入已用/损失为前提。现文禁止未确认敞口再发是保守且自洽的，终止条件与阈值随 T14 在 POC 中确定 |
| 顾问席 | 第 3 轮所引任务书行号（:28、:46 等）、11.2.10 A 表内容及 Pingora、WebTransport 等转述在材料中不存在 | **不成立，未采纳** | 核验席、质疑席在互评中逐条核实为引用失实；其 APPROVE 只计入法定人数，不作为闭环依据 |
## 十、参考资料
### 一手/官方来源（A 级）
- [Amazon Bedrock AgentCore is now generally available（AWS 官方博客）](https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-is-now-generally-available/)
- [Amazon Bedrock AgentCore Release Notes（AWS 官方文档）](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html)
- [Azure AI Gateway 层级（预览）概述（Microsoft Learn）](https://learn.microsoft.com/zh-cn/azure/api-management/ai-gateway-overview)
- [Quickstart: Create an AI Gateway tier (preview) instance（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/api-management/quickstart-ai-gateway-create)
- [Expanding agent governance with Unity AI Gateway（Databricks 官方博客）](https://www.databricks.com/blog/ai-gateway-governance-layer-agentic-ai)
- [AI Gateway is generally available（Cloudflare 官方博客）](https://blog.cloudflare.com/ai-gateway-is-generally-available/)
- [Linux Foundation Announces the Formation of the Agentic AI Foundation（LF 官方新闻稿）](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-Agentic-ai-foundation)
- [Higress（CNCF 官方项目页）](https://www.cncf.io/projects/higress/)
- [Higress v1.4.0（GitHub Release）](https://github.com/alibaba/higress/releases/tag/v1.4.0)
- [F5 Introduces AI Gateway（F5 官方新闻稿）](https://f5.com/company/news/press-releases/f5-ai-gateway-manage-secure-traffic-application-demands)
- [Kong Open Sources New AI Gateway（Kong 官方新闻稿）](https://konghq.com/company/press-room/press-release/ai-gateway)
- [Security Update: Suspected Supply Chain Incident（LiteLLM 官方安全公告）](https://docs.litellm.ai/blog/security-update-march-2026)
- [How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM（Snyk）](https://www.snyk.io/articles/poisoned-security-scanner-backdooring-litellm/)
- [MCP STDIO Design Flaw Enables Systemic AI Supply Chain RCE（CSA 官方研究笔记）](https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-rce-design-vulnerability-20260423-csa/)
- [Donating the Model Context Protocol and establishing the Agentic AI Foundation（Anthropic 官方新闻稿）](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation)
- [Zenlayer 发布 AI 网关产品（Zenlayer 官方新闻稿；链接格式沿用原版，可访问）](https://www.zenlayer.cn?p=29991/)
- [Kong Gateway 3.14 发布（Kong 官方博客）](https://www.konghq.com/blog/product-releases/kong-gateway-3-14)
- [New tools for building agents（OpenAI 官方）](https://openai.com/index/new-tools-for-building-agents/)
- [Higress Joins CNCF: Delivering an enterprise-grade AI gateway（CNCF 官方博客，2026-03-25）](https://www.cncf.io/blog/2026/03/25/higress-joins-cncf-delivering-an-enterprise-grade-ai-gateway-and-a-seamless-path-from-nginx-ingress/)
### 计量·定价·额度治理专题一手来源（A 级）
- [倍率设置（New API 官方文档）](https://doc.newapi.pro/en/guide/console/settings/rate-settings/)
- [Budgets, Rate Limits（LiteLLM 官方文档）](https://docs.litellm.ai/docs/proxy/users)
- [Budget Reset Times and Timezones（LiteLLM 官方文档）](https://docs.litellm.ai/docs/proxy/budget_reset_and_tz)
- [Semantic Caching（LiteLLM 官方文档）](https://docs.litellm.ai/docs/proxy/caching_semantic)
- [MCP Overview（LiteLLM 官方文档）](https://docs.litellm.ai/docs/mcp)
- [MCP Permission Management（LiteLLM 官方文档）](https://docs.litellm.ai/docs/mcp_control)
- [Enforce Budget Limits and Rate Limits for Your API Keys（Portkey 官方文档）](https://portkey.ai/docs/product/administration/enforce-budget-and-rate-limit)
- [Budget and Limits（Bifrost 官方文档）](https://docs.getbifrost.ai/features/governance/budget-and-limits)
- [AI Quota Management（Higress 官方插件文档）](https://higress.ai/en/docs/latest/user/plugins/ai/api-consumer/ai-quota/)
- [AI Rate Limiting Advanced（Kong 官方插件文档）](https://developer.konghq.com/plugins/ai-rate-limiting-advanced/)
- [Usage-based Rate Limiting（Agent Router 官方文档）](https://theagentrouter.ai/docs/0.1/capabilities/usage-based-ratelimiting/)
- [Envoy AI Gateway is becoming Agent Router（Agent Router 官方公告）](https://theagentrouter.ai/blog/envoy-ai-gateway-is-now-agent-router/)
- [Agent Router（AAIF 官方项目页）](https://aaif.io/projects/agent-router)
- [Grant（OpenMeter 官方文档）](https://openmeter.io/docs/billing/entitlements/grant)
- [Wallets and prepaid credits（Lago 官方文档）](https://getlago.com/docs/guide/wallet-and-prepaid-credits/overview)
- [Set up billing credits（Stripe 官方实现指南）](https://docs.stripe.com/billing/subscriptions/usage-based/billing-credits/implementation-guide)
- [mcp-bridge（Apache APISIX 官方插件文档，已标记 deprecated）](https://apisix.apache.org/docs/apisix/plugins/mcp-bridge/)
- [MCP Specification 2026-07-28 Key Changes（MCP 官方变更日志）](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
- [From Similarity to Vulnerability: Key Collision Attack on LLM Semantic Caching（arXiv 2601.23088）](https://arxiv.org/abs/2601.23088)
- [new-api #5690 配额扣减 TOCTOU 竞态（项目公开 issue）](https://github.com/QuantumNous/new-api/issues/5690)
- [one-api #2440 Quota consumption TOCTOU race（项目公开 issue）](https://github.com/songquanpeng/one-api/issues/2440)
- [litellm #27735 虚拟密钥预算 stale spend（项目公开 issue）](https://github.com/BerriAI/litellm/issues/27735)
- [litellm #29576（项目公开 issue，见 9.1 #33）](https://github.com/BerriAI/litellm/issues/29576)
- [litellm #25432（项目公开 issue，见 9.1 #33）](https://github.com/BerriAI/litellm/issues/25432)
- [new-api #7241 流式 responses 丢失 usage（项目公开 issue）](https://github.com/QuantumNous/new-api/issues/7241)
### 产品事实与法规核验一手来源（A 级）
- [New API LICENSE（AGPL-3.0，官方仓库）](https://github.com/QuantumNous/new-api/blob/main/LICENSE)
- [agentgateway Introduction（官方文档）](https://agentgateway.dev/docs/standalone/latest/documentation/about/introduction/)
- [《生成式人工智能服务管理暂行办法》（国家网信办官网原文）](https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm)
- [MCP 2026-07-28 Key Changes（官方变更说明）](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
- [Automatic Prefix Caching（vLLM 官方文档，含 Limits）](https://docs.vllm.ai/en/v0.9.1/features/automatic_prefix_caching.html)
- [Redis Replication（官方文档，一致性边界）](https://redis.io/docs/latest/operate/oss_and_stack/management/replication/)
### 私有化算力池与推理调度专题一手来源（A 级）
- [Gateway API Inference Extension 项目主页（Kubernetes SIG 官方）](https://gateway-api-inference-extension.sigs.k8s.io/)
- [InferencePool API（Kubernetes SIG 官方）](https://gateway-api-inference-extension.sigs.k8s.io/api-types/inferencepool/)
- [InferenceObjective API（alpha，Kubernetes SIG 官方）](https://gateway-api-inference-extension.sigs.k8s.io/api-types/inferenceobjective/)
- [Flow Control 指南（Kubernetes SIG 官方）](https://gateway-api-inference-extension.sigs.k8s.io/guides/flow-control/)
- [llm-d Architecture（项目官方文档）](https://llm-d.ai/docs/architecture)
- [llm-d flow control: Priority queuing for shared GPU inference（Red Hat 开发者博客，项目贡献方）](https://developers.redhat.com/articles/2026/08/27/llm-d-flow-control-priority-queuing-for-shared-gpu-inference)
- [Master KV cache aware routing with llm-d（Red Hat 开发者博客）](https://developers.redhat.com/articles/2025/10/07/master-kv-cache-aware-routing-llm-d-efficient-ai-inference)
- [KV Cache Aware Routing / Router Guide（NVIDIA Dynamo 官方文档）](https://docs.nvidia.com/dynamo/user-guides/kv-cache-aware-routing)
- [Disaggregated Serving（NVIDIA Dynamo 官方文档）](https://docs.nvidia.com/dynamo/user-guides/disaggregated-serving)
- [Production Metrics（vLLM 官方文档，v0.6.x 口径）](https://docs.vllm.ai/en/v0.6.1/serving/metrics.html)
- [Metrics 设计（vLLM 官方文档，latest）](https://docs.vllm.ai/en/latest/design/metrics/)
- [Cluster Queue 概念（Kueue 官方文档）](https://kueue.sigs.k8s.io/docs/concepts/cluster_queue/)
- [Inside the LLM Call: GenAI Observability with OpenTelemetry（OTel 官方博客）](https://opentelemetry.io/blog/2026/genai-observability/)
- [OpenTelemetry GenAI 语义约定仓库（迁移后维护地）](https://github.com/open-telemetry/semantic-conventions-genai)
### v5.2 新增与复核的一手来源（A 级，2026-10-17 访问）
- [Assistants migration guide（OpenAI 官方，含 2026-08-26 下线说明）](https://developers.openai.com/api/docs/assistants/migration)
- [Migrate to the Responses API（OpenAI 官方）](https://developers.openai.com/api/docs/guides/migrate-to-responses)
- [OpenAI API（OpenAI 官方博客，2020-06-11）](https://openai.com/index/openai-api/)
- [Alphabet 2026 Q2 Earnings Call Transcript（Alphabet IR，2026-07-22）](https://s206.q4cdn.com/479360582/files/doc_events/2026/Jul/22/2026_Q2_Earnings_Transcript.pdf)
- [v1.80.8-stable - Introducing A2A Agent Gateway（LiteLLM 官方发布记录）](https://github.com/BerriAI/litellm-docs/blob/main/release_notes/v1.80.8-stable/index.md)
- [GHSA-7hp6-4w63-5g45（LiteLLM 官方安全公告，2026-09-30）](https://github.com/BerriAI/litellm/security/advisories/GHSA-7hp6-4w63-5g45)
- [GHSA-g5ff-637f-6q2m（LiteLLM 官方安全公告，2026-10-01）](https://github.com/BerriAI/litellm/security/advisories/GHSA-g5ff-637f-6q2m)
- [Introducing LiteAdmin MCP（LiteLLM 官方博客，2026-09-23）](https://docs.litellm.ai/blog/litellm-admin-mcp)
- [Auto Router（LiteLLM 官方文档）](https://docs.litellm.ai/docs/auto_router/)
- [Kong Acquires OpenMeter（Kong 官方新闻稿，2025-09-03）](https://konghq.com/company/press-room/press-release/kong-acquires-openmeter-to-unlock-ai-and-api-monetization-for-the-agentic-era)
- [Kong AI Gateway Changelog（Kong 官方文档）](https://developer.konghq.com/ai-gateway/changelog/)
- [Kong AI Gateway 2.2 公告（Kong 官方新闻稿，2026-09-30）](https://konghq.com/company/press-room/press-release/kong-ai-gateway-expands-with-new-capabilities-bringing-enterprise-governance-to-the-agentic-ai-era)
- [Agent Router joins AAIF（AAIF 官方博客，2026-09-09）](https://aaif.io/blog/agent-router-joins-aaif)
- [agentgateway CHARTER（项目章程）](https://github.com/agentgateway/agentgateway/blob/main/CHARTER.md)
- [Wallet and Subscriptions（New API 官方文档）](https://docs.newapi.pro/en/docs/guide/feature-guide/user/wallet)
- [MCP 2026-07-28 Release Candidate（MCP 官方博客，2026-05-21）](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/)
- [MCP Authorization，2025-06-18（MCP 官方规范）](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)
- [The Mother of All AI Supply Chains（OX Security 官方博客，2026-04-15）](https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/)
- [Monetization Gateway closed beta（Cloudflare 官方 changelog，2026-09-30）](https://developers.cloudflare.com/changelog/post/2026-09-30-closed-beta/)
- [Designing MCP Gateway（Uber 工程博客，2026-10-01）](https://www.uber.com/blog/designing-mcp-gateway/)
- [Agentic Inference（NVIDIA Dynamo 开发版文档）](https://docs.nvidia.com/dynamo/dev/digest/agentic-inference)
- [Agent Hints（NVIDIA Dynamo v1.5.1 官方文档，v5.3 补核）](https://docs.nvidia.com/dynamo/v1.5.1/agents/agent-hints)
- [Full-Stack Optimizations for Agentic Inference with NVIDIA Dynamo（NVIDIA 技术博客，2026-04-17，v5.3 补核）](https://developer.nvidia.com/blog/full-stack-optimizations-for-agentic-inference-with-nvidia-dynamo)
- [Unity Gateway release notes（Databricks 官方文档，v5.3 补核）](https://docs.databricks.com/aws/en/release-notes/unity-gateway/)
- [llm-d 1.0 Release Tracking #2619（llm-d 官方仓库）](https://github.com/llm-d/llm-d/issues/2619)
- [Metrics 设计（vLLM 官方文档，latest，V1 指标口径）](https://docs.vllm.ai/en/latest/design/metrics/)
- [InferencePool（GIE 官方 API 文档，v1）](https://gateway-api-inference-extension.sigs.k8s.io/api-types/inferencepool/)
- [Migrate GKE Inference Gateway from v1alpha2 to v1（Google Cloud 官方文档）](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/migrate-gke-inference-gateway)
- [Lago（官方仓库，AGPL-3.0）](https://github.com/getlago/lago)
- [Portkey AI Gateway（官方仓库，MIT）](https://github.com/Portkey-AI/gateway)
- [GNU Affero General Public License v3](https://www.gnu.org/licenses/agpl-3.0.html)
### 二手来源（B/C 级，已用于交叉参考）
- [新华鲜报｜引导AI发展！网络安全法完成修改（新华网，2025-10-28）](https://www.news.cn/politics/20251028/b3400522666a4b3f8c844b9fa6c31131/c.html)
- [《人工智能生成合成内容标识办法》发布（新华网，2025-03-14）](https://www.news.cn/tech/20250314/f8b96305ff274e0cb70031c2819092ee/c.html)
- [Kong OSS container/docker image release for 3.10.0（Kong GitHub Discussions，社区讨论，待核）](https://github.com/Kong/kong/discussions/14405)
- [OpenTelemetry GenAI Semantic Conventions Explained（Dash0，2026-09-14 更新）](https://www.dash0.com/knowledge/opentelemetry-genai-semantic-conventions-explained)
- [Azure API Management Adds Dedicated AI Gateway Tier（InfoQ）](https://www.infoq.com/news/2026/08/azure-apim-ai-gateway-tier/)
- [AI Gateway:从API网关到AI应用核心中间件的演进与实践（CSDN）](https://blog.csdn.net/weixin_34195546/article/details/90251691)
- [GenAI网关平台发展驶入快车道（CSDN）](https://tianqi.csdn.net/6a71a54610ee7a33f295ee2f.html)
- [企业级 AI 网关全景图（CSDN）](https://blog.csdn.net/clj198606061111/article/details/162706891)
- [AI 网关（Newton Wiki）](https://www.newton.com.tw/wiki/AI%E7%B6%B2%E9%97%9C/67566534)
- [Best Open Source AI Gateway in 2026（dev.to）](https://dev.to/pranay_batta/best-open-source-ai-gateway-in-2026-2flb)
- [AI Gateways Explained（Zooz Engineering）](https://engineering.zooz.com/ai-that-works/ai-gateways-the-essential-infrastructure-layer-for-scaling-enterprise-ai-3903ff6ba447)
- [The LLM Gateway & Router Index (2026)（DEV Community 内容的第三方镜像域名，非原站）](https://hello.doclang.workers.dev/srijan_paudel_d9837a5d8fd/the-llm-gateway-router-index-2026-16fm)
- [AI网关简单介绍（博客园）](https://www.cnblogs.com/miaocbin/articles/22036178)
- [Best 7 Open Source AI Gateways in 2026（Future AGI）](https://futureagi.com/blog/best-open-source-ai-gateways)
- [大模型基础设施工程：大模型网关（掘金）](https://juejin.cn/post/7634370785185382436)
- [Higress AI 网关（官网）](https://higress.cn/ai-gateway)
- [Scaling MCP: From a Proxy to an Agent Gateway（agentgateway）](https://agentgateway.dev/blog/2026-06-26-scaling-mcp-proxy-to-agent-gateway)
- [MCP Gateway（exploreagentic.ai）](https://exploreagentic.ai/glossary/mcp-gateway)
- [Best Agent Gateways for Tool Calling at Scale（MintMCP）](https://www.mintmcp.com/blog/agent-gateways-tool-calling-scale)
- [MCP vs API Gateways: 3-Phase Roadmap（LinkedIn）](https://www.linkedin.com/pulse/still-confused-mcp-vs-api-gateways-heres-3-phase-roadmap-ashish-s-k-c6zvc)
- [AWS AgentCore + Databricks Integration（ChatForest）](https://chatforest.com/builders-log/aws-agentcore-databricks-dais-2026-enterprise-agent-stack-builder-guide)
- [大模型服务网关架构深度解析（CSDN）](https://blog.csdn.net/a13662080711/article/details/161838782)
- [深入解析 AI Gateway（Jimmy Song）](https://jimmysong.io/zh/blog/ai-gateway-in-depth/)
- [LLM Gateway Architecture（ai-solutions.wiki）](https://ai-solutions.wiki/guides/llm-gateway-architecture)
- [API 网关十五年演进（今日头条）](https://www.toutiao.com/a7502361577144943144/)
- [Amazon Bedrock AgentCore: Production AI Agents Made Simple（AWS Builder Center）](https://builder.aws.com/content/3GSlxjkXwfKHuAkTXpcV0zrjrBu/amazon-bedrock-agentcore-production-ai-agents-made-simple)
---
## 十一、版本与修订历史
> 本章为**过程性记录**，用于说明结论的演变与证据的处置方式，**不构成现行设计要求**；现行要求一律以正文（〇–八章）与附录为准。
### 11.1 版本概要
| 版本 | 日期 | 主要变更 |
|------|------|----------|
| v1.0 | 2026-08-14 | 初版；经第一轮对抗性安全审查（17 项）、第二轮对抗审查（S1–S15）、第三轮专家评审（24 项）迭代 |
| v1.1 | 2026-08-14 | 第四轮外部专家独立复核：修正 OpenAI 弃用口径（P0）、Higress CNCF 日期（P1），落实 6 项增量建议（当时版本的 9.4，现见 11.2.3） |
| **v2.0** | **2026-09-17** | **① 新增 5.9「计量·定价·额度治理」专题（Token 套餐/模型倍率/重置规则的业界实现与开源方案）与 6.4 计费平面对比；② 第五轮全文复核：修正 3 处能力/时效性失准（LiteLLM 语义缓存与 MCP、Envoy AI Gateway 更名为 Agent Router、APISIX MCP 现状）+ 1 处来源缺档，另补 3 项体例与可读性；③ 来源分级表由 28 项扩至 49 项，新增自建数据模型与并发透支风险（当时版本的 9.5，现见 11.2.4）** |
| **v3.0** | **2026-09-18** | **面向"私有化多算力池"场景的增补：① 〇章补两类部署形态的范围界定与前八章结论适用性差异；② 新增 8.5 私有化多算力池场景的三处能力差异（算力感知路由 / 饱和准入与优先级队列 / 配额与算力换算）；③ 新增 8.6 Token 配额运营中网关与管理 Portal 的能力划分与交互契约；④ 新增 8.7 运维监控与运营管理能力清单（八域）；⑤ 8.2 增决策点 10 并修正决策点 7 的 OTel 约定口径；⑥ 来源分级表扩至 60 项（当时版本的 9.6，现见 11.2.5）** |
| **v4.0** | **2026-09-18** | **响应第六轮外部独立审阅（21 项）：① 修正 4 处产品/法规事实错误（New API 许可为 AGPL-3.0、agentgateway 为 Rust 且覆盖 LLM、GIE 自带 EPP 仅为参考实现、MCP 2026-07-28 变更逐条重写）；② **P0 合规修正**——《生成式人工智能服务管理暂行办法》第二条明确不适用于未向境内公众提供服务的企业内部应用；③ 撤回三类过强保证（原子扣减=强一致、退出 flush=至少一次、前缀缓存=最大杠杆），改为"目标 + 实施条件"；④ 拆分响应缓存与前缀 KV 缓存、修正优先级饥饿推论、WTU 降为可选方案；⑤ 撤回"五项即可一期上线"，安全基线前置到一期；⑥ 新增 8.8 POC 验收矩阵 T01–T12；来源扩至 68 项（当时版本的 9.7，现见 11.2.6）** |
| **v5.0（研究定稿）** | **2026-09-18** | **定稿收口（R01–R12）：全文一致性修订，使摘要、表格与图执行与正文同一套规则。① 删除"两条合规路径"旧结论；② 硬上限条件改为"预留覆盖最大可计费消耗并强制执行"，透支与零超支不再并存；③ 补稳定幂等键与 reservation 状态迁移约束，控制指令删除"即时生效"；④ 收回"KV 缓存无跨主体泄露风险"的过强表述（补 `cache_salt`/侧信道/哈希碰撞）；⑤ 两张时序图重绘（降级重新授权与预留、权威结算与分析副本分离、流式增量）；⑥ WTU 全文改为"所选计价单位"，饱和/沉没成本/选副本等假设统一限定；⑦ 选型表与来源表实质改写（删排名、性能改"待 T12"、新增证据性质分类）；⑧ KPI 改三维正交、新增实施前待决项登记表；⑨ 定稿状态声明前移至摘要（当时版本的 9.8，现见 11.2.7）** |
| **v5.1（研究定稿）** | **2026-09-18** | **终态复核收口（7 组）：① 修复 8.6.4 时序图控制流——拒绝/未持有有效预留的路径不再进入转发；② 选型矩阵实质改写（性能列全部标未实测、Kong 与 APISIX 分行、"国内合规"评分列改为可核验的部署与数据控制条件）；③ 选型决策图与决策点 1 不再把行业标签或产品品牌当作部署结论；④ 额度架构图与风险表去除固定技术组合、区分权威账本与分析副本；⑤ 清理场景口径残留（WTU 必选、饱和是日常、Prompt 记录是基线、梯队排名等）；⑥ 证据分级拆为来源类型/核验状态/证据性质三维并逐条标注；⑦ 修复失效章节引用（9.4–9.8 → 11.2.3–11.2.7）。详见 11.2.8** |
| **v5.2（再审议修订稿）** | **2026-10-17** | **管理员发起的再次审议（005 第 1 轮意见收集）：① 更新已过时事实（Assistants API 已下线、Chat Completions 官方口径、Microsoft Foundry 更名、AgentCore 各组件状态、vLLM V1 指标名、GIE `InferencePool` v1）；② 修正选型事实错误（New API 已有订阅与周期重置、LiteLLM 已具 A2A、Portkey/agentgateway/Lago 许可、Kong 收购 OpenMeter）；③ 消除自相矛盾（"必建"与分期、契约抽象分级、OX 三种口径、证据性质定义、GKE Inference Gateway 归类、Portkey 自托管）；④ 补安全恢复条件（受控旁路、应急份额不可重复领取、fallback 重新授权、请求体调度字段、MCP 令牌受众绑定、管理面越权），8.8 增 T13–T16；⑤ 新增 7.5（2026-09-18 以来新进展）与 9.2 少数意见；⑥ 删除无来源数字与名称，来源表扩至 #95。详见 11.2.9** |
| **v5.3（再审议修订稿）** | **2026-10-17** | **005 第 2 轮复审（三个投票席位均 APPROVE，强席位无阻塞项）后的少数意见收口：① 时序图与 8.6.2 第 4 项统一为"请求头与请求体"治理控制字段；② fencing 补明旧实例的权限边界与迟到用量对账；③ 经重访官方文档更正 Dynamo `agent_hints` 状态（v1.5.1 正式版文档已列字段，2026-04-17 首次公开）；④ 7.5 标题改为"2026 年 9 月以来"；⑤ 状态措辞统一为修订稿；⑥ 措辞降级（OX 披露的风险、Kong 2.2 方向一致）与摘要 OX/Portkey 限定；⑦ #11 来源类型分列、#3 补 Release Notes 并补 Databricks 现名 Unity Gateway 与 GA 日期、#49 二手链接说明；⑧ 更正 11.2.9 B5 记录。详见 11.2.10** |
| **v5.4（再审议研究定稿）** | **2026-10-17** | **005 第 3 轮终审（完整研讨，五席两个阶段均 APPROVE，强席位无阻塞项，判为通过）后的少数意见收口，结论不变：① 8.6.2 第 4 项改为"请求头与请求体"，与第 12 项及处置记录一致；② 7.5 Dynamo 行注明早于时间窗的收录理由，"首次公开"改为"已公开介绍"，#86 经复核博客原文写明所介绍的三项字段；③ 6.1 与 #3 补 Databricks 子能力 Beta 状态（经 Release Notes 复核）；④ 5.9.4 与 #30 补 LiteLLM 多窗口 UTC 对齐；⑤ 摘要简版与详版对应关系、9.2 悬空承诺、11.2.3/11.2.9 D/11.2.10 C 的历史补注；⑥ fencing 终止条件保留为少数意见。详见 11.2.11** |
| **v5.5（再审议最终定稿）** | **2026-10-17** | **终稿差异最终复核（Codex 质疑席，复核范围为相对第 3 轮通过对象 v5.3 的全部差异，并对照相对原报告 v5.1 的完整差异）：文首版本与状态声明改为最终定稿，新增 11.2.12 记录复核结论与处置；按复核意见更正两处处置记录（9.2 第 2 轮第二主持行的统一版本、11.2.10 C 的 v5.4 补注）；正文结论与安全要求不变。详见 11.2.12** |
### 11.2 历次审查与复核记录
#### 11.2.1 核实与修订记录（过程汇总）
**来源可信度复核（第 1 轮）**：对所有关键事实按"优先一手、二手复核"逐一追溯，据此修正 4 处原始错误（Cloudflare AI Gateway GA 日期、Higress CNCF Sandbox 日期、Higress v1.4 日期、Kong 时间线），来源分级表扩充至 28 项（#1–#28）。
**C 级清零（第 4 轮）**：原 4 项 C 级全部处置——#13 MCP 9700 万/月下载追到 Anthropic 官方（97M+，2025.12），"2.2 万服务器"无一手已删除；#16 Zenlayer（2025.10.28）、#17 Kong A2A（2026.04）均追到官方一手升级；#18 Gartner 无一手且正文未采用，删除。最终：A 级 20 项、B 级 5 项（另 #20 为 B/C）、删除 2 项（#18、#22）、C 级 0 项。
**第一轮对抗性安全审查（17 项）**：全部采纳（6 项部分采纳）。主要修订：语义缓存租户隔离/投毒防护、网关威胁模型与供应链门槛、术语与范围界定、OpenAI 兼容去绝对化、MCP 安全下沉二期、国内现状对齐、合规重写、未标来源数字入表。详见《模型网关报告_对抗性安全审查.md》与《模型网关报告_审查意见采纳决策与修订记录.md》。
**第二轮对抗审查（15 项 S1–S15）核实结论与修改说明**：
| 编号 | 核实结论 | 修改说明 |
|------|----------|----------|
| S1 | 成立 | 4.4 区分"采集/结算"两层，承认"网关采集 + 独立计费数据湖"为合法替代范式，删除循环前提 |
| S2 | 成立 | 4.4 删"已收敛统一范式"，改"内聚派 vs 外置派两范式并存"，披露路由厂商立场 |
| S3 | 成立 | 4.4 删"天然内聚"，改"工程权衡非定义使然"，补外部 IAM 替代架构 |
| S4 | 成立 | 2.3 第一阶段时间边界改"2023 为主"，补两阶段重叠说明 |
| S5 | 成立 | 7.1 补增幅口径差异说明，明确优先采信 LF 官方 1 万 |
| S6 | 成立 | 7.2 "三个服务器"标注"非实证经验阈值" |
| S7 | 成立 | 8.2 决策点 2 区分"过渡基线/终态目标"，补迁移触发条件 |
| S8 | 成立 | 8.3 增加选型利益声明 + 补充可选方案 |
| S9 | 成立 | 4.2 补"网关 vs 编排"轻量决策框架 |
| S10 | 成立 | 2.2 时间线加注"意义栏为报告归纳，引号内为营销话术" |
| S11 | 成立 | 5.5 收益侧补 best-case/命中率对冲 |
| S12 | 成立 | 6.3 "为同类最强"改"公开透明度相对较高"，补"善后好≠更安全" |
| S13 | 成立 | 7.1 标题改中性"采用规模快速扩大"，补"采用≠安全"注 |
| S14 | 成立 | 8.2 决策点 8 增加"集中 vs 联邦"替代评估 |
| S15 | 成立 | 4.4 删除"没有任何厂商把计量拆出去"绝对化，随 S1 一并修正 |
> 说明：上述修订已直接落实到正文；附录仅保留核实结论与改动摘要，正文不再重复过程性说明，避免重复。
#### 11.2.2 第三轮专家评审意见响应与修改说明
以下为作者对第三轮专家评审（`模型网关报告_第三轮专家评审.md`）的逐条响应：采纳 15 项、部分采纳 5 项、未采纳 4 项。
| # | 意见（维度） | 决策 | 理由 | 修改位置 |
|---|-------------|------|------|----------|
| 1 | 缺"何时不该建网关"边界条件（完整性） | 采纳 | 避免小团队过度工程 | 8.1 增"建与不建门槛" |
| 2 | 缺量化选型矩阵（完整性） | 部分采纳 | 虚构数字评分有"伪精确"风险（前几轮已批），改定性能力矩阵 | 8.3 增"选型决策表"（强/中/弱） |
| 3 | 缺成本/ROI 模型（完整性） | 部分采纳 | 具体金额无来源违背准确性，改成本结构维度清单 | 8.3 增"成本结构维度" |
| 4 | 缺威胁模型专章（完整性） | 采纳 | 收敛散落安全结论 | 新增 4.5 安全威胁模型 |
| 5 | 缺独立第三方基准（完整性） | 未采纳 | 需独立实测，非文档可凭空生成；已标注厂商自测 | 见 #12 |
| 6 | 缺失败案例（完整性） | 部分采纳 | 已有 LiteLLM 攻击/OX 漏洞反面教训，集中收敛 | 4.5 附"已知反面教训" |
| 7 | 多智能体治理未展开（完整性） | 未采纳 | 三期"前瞻"定位即点到为止；2026 无成熟范式，展开会引入无来源推测 | 保留三期"前瞻" |
| 8 | "一期必建"必然性未论证（合理性） | 采纳 | 补量化门槛（标注经验值） | 8.1 增门槛 |
| 9 | 分阶段缺触发条件（合理性） | 采纳 | 补触发信号 | 8.1 表增"触发条件"列 |
| 10 | 推荐组合缺场景规则（合理性） | 采纳 | 补场景→推荐映射 | 8.3 增"场景→推荐映射" |
| 11 | "主流架构"证据偏弱（合理性） | 采纳 | 结论降级为"趋势性判断" | 摘要结论 3、7.2 |
| 12 | 厂商自测数字加标签（准确性） | 采纳 | Bifrost 已标；Cloudflare/Higress 补标 | 6.1、2.2 时间线 |
| 13 | 厂商细节未独立核验（准确性） | 未采纳 | 来源表已逐项标等级，无需正文重复标注 | 9.1 |
| 14 | 动态数据未标时点（准确性） | 采纳 | 补快照日期 | 9.1 #19 |
| 15 | 客户名单二手（准确性） | 采纳 | 加"据公开报道" | 6.2 阿里行 |
| 16 | 摘要结论无章节映射（结构性） | 采纳 | 5 条结论加"详见第X章" | 摘要结论 1–5 |
| 17 | 4.4 与第八章交叉（结构性） | 采纳 | 4.4 末段改交叉引用 | 4.4 |
| 18 | 缺执行摘要（结构性） | 采纳 | 加一页纸执行摘要 | 摘要前 |
| 19 | 缺决策树（可操作性） | 部分采纳 | Markdown 用决策表更清晰（流程图难维护），改"选型决策表" | 8.3 |
| 20 | 缺时间/资源估算（可操作性） | 部分采纳 | 人力/工期因企业差异大、具体数字无来源，改定性投入量级 | 8.1 表后注 |
| 21 | 缺 KPI（可操作性） | 采纳 | 增成功度量 KPI | 8.4 |
| 22 | 缺风险登记册（可操作性） | 采纳 | 增建设风险登记册 | 8.4 |
| 23 | 决策点无优先级（可操作性） | 采纳 | 8 条决策点加 P0/P1 | 8.2 |
| 24 | 缺 MVP（可操作性） | 采纳 | 增 MVP 最小可行清单 | 8.3 |
> 未采纳项说明：#5（独立基准需实测，文档无法凭空产出，已以"厂商自测"标签兜底）；#7（多智能体治理 2026 无成熟范式，展开会引入无来源推测，违背"祛推测"原则）；#13（来源表已逐项标等级，正文重复标注会造成冗余）。
#### 11.2.3 独立复核修正（第四轮，外部专家）
本附录承载历次审查与复核的过程记录，可独立抽取为《审查修订记录》附件。**说明（v4.0 修正）**：正文中仍保留少量"v2.0 修正""v4.0 修正"等标注，用途是让读者知道哪些结论被推翻过、避免沿用旧版转述，属有意保留而非编辑残留；此前"正文不含过程性内容"的表述与此不符，已更正。（v5.2 补注：截至 v5.1，正文中的此类标注已全部清除，本说明仅保留为当时的记录；9.1 #31、#32 中残留的"据此修正"字样亦已在 v5.2 移入本章。）
- **P0（必修）**：修正"OpenAI 计划弃用 Chat Completions（约 2026 年中）"→ 实际为"官方承诺无限期支持 Chat Completions，真正进入弃用轨道（2026 年中退役）的是 Assistants API"。（v5.4 补注：Assistants API 实际已于 2026-08-26 下线，见 11.2.9 A 表第 2 项。）涉及摘要结论 1、8.2 决策点 2、4.5 威胁模型"协议漂移"行。来源：OpenAI 官方《构建智能体的新工具》。
- **P1（必修）**：Higress 加入 CNCF Sandbox 日期改回 **3 月 25 日**（此前误改为 3.15），来源改引 CNCF 官方博客（URL 含 2026/03/25）。涉及 2.2 时间线、9.1 #6。
- **P2（增量，均已落实）**：8.2 决策点 6 补跨境合规（GDPR/EU AI Act）说明；执行摘要"三项风险"改"四项风险"（纳入 MCP 工具滥用）；8.1 门槛补来源标注（作者经验判断非行业阈值）；8.3 选型矩阵补评分依据说明；8.2 决策点 1 补 Mermaid 选型决策图；附录加"可独立抽取"说明。
> 过程教训：本轮独立复核再次印证——事实核验（尤其具体日期、官方产品路线图）应作为与内容/结构审查相独立的最后一道关卡，"多轮审查"不等于"零错误"，此前一次"修正"本身引入了新错误。
#### 11.2.4 第五轮全文复核与专题整合记录（v2.0，2026-09-17）
**A. 专题整合（新增内容）**
| 新增 | 位置 | 说明 |
|---|---|---|
| 计量·定价·额度治理专题 | **新增 5.9**（含 5.9.1–5.9.5） | Token 套餐 / 模型倍率 / 重置规则的三层拆解、三条实现路线、两种定价范式、四种重置语义、预扣—结算时序与并发一致性坑位 |
| 计费平面对比 | **新增 6.4** | OpenMeter（by Kong）/ Lago / Stripe credit grants 的额度语义能力对比 |
| 决策点 9 | 8.2 | 【P1】计量分层与额度语义前置定义（时区/结转/优先级三项须开工前定） |
| 自建最小数据模型 | 8.3 | price_book / ratio / grant / ledger 四表设计要点 |
| 风险两项 | 8.4 | 额度扣减并发透支（TOCTOU）、计费数据缺失（流式中断） |
| 交叉引用 | 4.3、4.4、5.5、8.1、8.3 | 将 5.9 的实现证据回挂到既有判断框架 |
**B. 全文复核修正（本轮发现的失准项）**
| # | 问题 | 性质 | 修正 |
|---|---|---|---|
| 1 | 6.3 称 LiteLLM "无语义缓存、无 MCP" | **事实性错误**（能力描述失准，直接影响选型） | 经官方文档核实：LiteLLM 支持 `redis/qdrant/valkey-semantic` 语义缓存（含 `semantic_cache_scope` 租户隔离），并提供开源版 MCP 网关与按 Key/Team/User 的工具级权限；已改写该行并同步修正 8.3 选型矩阵（MCP/A2A 弱→中） |
| 2 | 6.3 及 3.2、8.3 中的 "Envoy AI Gateway" | **信息过时** | 该项目已更名 **Agent Router** 并成为 AAIF 项目（原域名 302 跳转实测）；3.2 / 6.3 / 8.3 三处主表述已更新，摘要结论 4 与 5.9.2 同步标注 |
| 3 | 6.3 称 APISIX "无 MCP" | **表述不精确** | 精确化为：`mcp-bridge` 仅做 stdio↔SSE 协议桥接且已被官方标记 deprecated、不建议新部署；`openapi-to-mcp` 尚在演进 |
| 4 | 5.5 两处安全量化数字未入来源表 | **来源缺档** | "CacheAttack 86% 响应劫持"已追到一手论文（arXiv 2601.23088，见 9.1 #39）；"0.70 阈值 6% 敏感暴露"**未追到一手来源**，已在正文标注待回查并在 9.1 #40 立"待复核"条目——若最终无法追溯，应降级为定性表述 |
| 5 | 7.1 "2026.07 协议架构大升级"无版本锚点 | 表述可强化 | 精确到 **2026-07-28 规范版本**并补一手来源；补充对网关的直接影响（无状态核心降低 MCP 托管扩展成本，但会话级治理上下文需网关自维护） |
| 6 | 报告缺版本号与更新历史 | 体例缺失 | 头部补 v2.0 版本标识、更新日期与概要更新历史表 |
| 7 | 第五章 1–8 条与正文"见 5.5/5.6"交叉引用的对应关系未显式说明 | 可读性 | 章首补编号对应关系说明 |
**C. 本轮复核的范围声明（诚实边界）**
- 本轮以**能力描述类断言**（各项目支持/不支持某能力）与**时效性**为重点重新核验，已按官方文档逐项复核 LiteLLM、APISIX、Higress、Kong、Bifrost、Portkey、Agent Router、OpenMeter、Lago、Stripe、New API 的相关能力；
- **未重新核验**的部分：6.1/6.2 国内外云厂商的产品细节描述（沿用 v1.x 的 A/B 级标注）、动态数据（Star/Provider 数，快照仍为 2026-08）、第 2 章时间线中 v1.x 已核实条目；
- 截至复核日（2026-09-17）的通用检索**未发现**需新增的重大时间线里程碑，但此为消极证据（未见 ≠ 不存在），不构成"行业无新进展"的断言；
- 9.1 #33–#35、#40 的性质已在表内逐条标注，引用时须注意其证据强度差异。
#### 11.2.5 私有化场景专题增补记录（v3.0，2026-09-18）
**A. 触发本轮增补的三点补充需求**
1. 网关为**私有化部署**，不涉及公有云服务，面向企业内部多模型、多算力池的统一调配与管控；
2. 存在 **token 配额管理**需求：按用户/任务差异分配不同能力的模型、管理套餐额度、驱动合理使用、体现价值导向；需明确网关侧能力、管理 Portal 侧能力及两者交互；
3. 除 OTel 观测信号与 Prompt 记录外，还需开立哪些**运维监控与运营管理**能力。
**B. 本轮新增内容**
| 需求 | 落点 | 核心结论 |
|---|---|---|
| 1 | **〇.1**（两类部署形态与**完整适用性修订表**，覆盖契约、成本、故障转移、缓存、合规、限流准入与韧性七项）、**8.5** | 形态 B 的主要稀缺性来自物理算力；路由新增"选副本"一层；共享池接近容量时需准入队列；额度计价单位须重新选择（WTU 为可选方案） |
| 2 | **8.6**（网关 11 项 / Portal 11 域能力清单、四条交互链路契约、时序图、价值导向机制设计） | 策略定义在 Portal、执行在网关；请求路径只与额度服务交互，**绝不同步依赖 Portal**；降级优先于拒绝 |
| 3 | **8.7**（八域运维运营能力清单 + 最小指标集 + 口径提醒） | OTel 与 Prompt 记录是基线；另需容量运维、质量效果运营、成本对账、变更配置、自助服务台与治理报表五类常被遗漏的能力 |
| 配套 | 8.2 决策点 10（新增）、决策点 7（修正）、8.4 风险登记册（+2 行）、摘要结论 7、9.1（+11 项来源） | — |
**C. 本轮的证据边界（诚实声明）**
- 8.5 的技术机制（GIE / llm-d / Dynamo / vLLM / Kueue）**均以项目官方文档为一手来源**并逐条入表（9.1 #50–#57）；其中 llm-d 相关表述来自项目主要贡献方的官方渠道，**含项目推广立场**，采信时宜独立评估；
- 8.6 的能力清单与交互契约**属工程设计建议**，综合自前述机制的约束与 5.9 的一致性要求，**不宜标注为"业界标准"**——业界在"网关/Portal 如何分工"上并无公开的统一规范，各企业实现差异较大；
- 8.7 的能力清单同属**结构化设计建议**；其中指标名与 OTel 口径部分有一手来源（9.1 #56、#58），其余为归纳；
- WTU（等效算力单位）的**公式形态与因子选择为本报告提出的设计建议**，非既有业界标准术语；其权重必须由企业在自有模型与引擎配置上实测标定，本报告**不提供任何经验权重数值**（提供即是伪精确）；
- "先 showback 后 chargeback"、"降级优先于拒绝"等运营原则为作者判断，证据强度为 B/C（9.1 #60），列出供决策参考而非作为定论。
#### 11.2.6 第六轮独立审阅响应记录（v4.0，2026-09-18）
来源：外部独立审阅意见 v1.0（21 项，含 12 组待执行验收用例）。处置：**21 项均已逐项响应并落实到正文**（v5.0 说明：此前"采纳 19 / 部分采纳 1 / 不成立 1"的总数结算式**已删除**——各项之间并非互斥分类，F03 的实质主张已采纳、其中仅"链接访问结果"一个子项存在分歧，用一个计数无法准确表达）。所有涉及事实的意见均由本方重新回查官方一手来源后再修订，未直接采信转述；**实施类验证事项一律待执行**。
**A. 已采纳并修订（按审阅编号）**
| 编号 | 意见 | 本方核验结论 | 修订位置 |
|---|---|---|---|
| F01 | New API 许可为 AGPL-3.0 而非 MIT | ✅ 直读仓库 LICENSE 确认 | 6.3（拆分 One API / New API 两行）、5.9.2、6.3 新增"许可口径统一说明" |
| F02 | agentgateway 是 Rust、且覆盖 LLM | ✅ 官方 Introduction 确认，并含 15+ LLM 提供商与 cost controls | 6.3 |
| F03 | GIE 是规范、自带 EPP 仅为参考实现 | ✅ **实质成立**（官方明示生产应自建或用 llm-d-router）；**但"链接 404"一项不成立**，见 B 段 | 8.5.2、摘要结论 7 |
| F04 | MCP 变更总结遗漏关键项 | ✅ 逐条核对官方 changelog：Tasks 确为移出核心进入扩展；另发现本报告此前所列"MCP Apps"**未见于该 changelog**，属自身错误 | 7.1 整段重写 |
| F05 | 合规适用范围错误（P0） | ✅ 《暂行办法》第二条明确不适用于未向境内公众提供服务的企业内部研发应用 | 8.2 决策点 6 重写、〇.1、8.5.1 |
| F06 | 证据分级混淆来源身份与证明力 | ✅ 采纳：删除未溯源数字、补充版本相关性标注 | 5.5、9.1 #40 |
| M01–M04 | 原子操作 ≠ 系统一致性；估算预扣不保证硬上限；四表模型不足；flush 不证明至少一次 | ✅ 全部成立，属本报告过强表述 | **5.9.5 新增 ⑤"原子操作解决什么、不解决什么"**、8.3 数据模型扩为五表、8.6.4 链路②③ |
| M05 | 流式/重试/降级未闭环；降级改变调用契约 | ✅ 成立 | 5.9.5 ⑤ 第 7 条、8.6.5 新增降级契约约束 |
| M06 | 过期策略不停服与即时吊销冲突；伪造调度头 | ✅ 成立，且"剥离用户自带调度头"是双层架构引入的新攻击面，此前完全未提 | 8.6.2 新增第 12 项、8.6.4 链路① |
| M07 | 语义响应缓存与前缀 KV 缓存混为一谈 | ✅ 成立；并据 vLLM 官方"只减少 prefill、不减少生成"删除"最大单一杠杆"的无条件结论 | 5.5 拆三类、8.5.1、8.5.2 |
| M08 | 同级轮询 ≠ 低优先级不饿死 | ✅ 成立，此前推论有误 | 8.5.3 |
| M09 | WTU 被写成唯一正确答案 | ✅ 成立 | 8.5.4 改为三层分离 + WTU 降为可选、纪律扩为五条（含重复计价与"不可替代瞬时准入"） |
| M10 | 外部额度引擎不能直接充当逐请求硬限额 | ✅ 官方 Caveats 确认分钟级精度限制；结转公式作用于单个 grant | 6.4、8.3 场景映射 |
| D01 | MVP 与新增要求不一致 | ✅ 成立，**撤回"五项即可一期上线"** | 8.3 改为 A/B 两形态最小集 + 上线前置条件 |
| D02 | 先采集后保护 | ✅ 成立 | 8.1 新增安全分期硬约束 |
| D03 | KPI 缺口径 | ✅ 成立 | 8.4 新增 KPI 口径要求六条 |
| D04 | 缺假设表与责任人 | ✅ 成立 | 8.1 新增待填假设表与五类 accountable 角色 |
| D05 | 编辑残留与强断言 | ✅ 成立 | "四条结论"→五条、第五章统一 5.1–5.8 标题、附录"正文不含过程性内容"更正、多处绝对措辞降级 |
| 验收矩阵 | 建议补入报告 | ✅ 采纳 | **新增 8.8 POC 验收矩阵 T01–T12** |
**B. 一项访问结果分歧（客观记录，不作为定稿阻断项）**
关于 GIE 的 `/guides/flow-control/` 链接：审阅方两轮访问均返回 404；本方于 **2026-09-18** 两次访问该 URL 均正常返回内容（页面标题 Flow Control Layer User Guide，含 The Elevator Pitch、Why Flow Control、Core Concepts、Configuration Guide、Autoscaling、Observability 等章节）。**这是双方访问结果的差异，不构成任何一方结论错误**，双方也一致认为"链接失效不足以断言机制不存在"。处置：保留本方取得的官方依据与 8.5.3 的机制描述，并**标注访问日期**；建议后续实施阶段以**版本化来源**（对应 release tag 或 commit）替代活链接引用，以消除此类分歧。F03 的**实质主张已全部采纳**（GIE 是规范而非生产实现、自带 EPP 仅供一致性测试），相应限定已就近写入 **8.5.3 开头**并与 8.5.2 的四层版本组合要求呼应。
**C. 状态声明**
- 本轮修订**全部为文档层面**：撤回过强保证、补齐实施条件、修正事实。**未执行任何运行测试**，8.8 中 T01–T12 仍全部处于待执行状态。
- 修订后本报告的定位应表述为：**行业调研与受控 POC 的输入**；其中额度一致性、调度公平性、缓存收益、计价回算四类结论，**在 8.8 对应用例完成前不构成选型定案或上线依据**。
#### 11.2.7 定稿收口记录（v5.0，2026-09-18）
> **完成状态更正**：本表中关于"性能列统一""WTU 全文改完""选型表实质改写"等条目，在 v5.0 时**仅部分落地**（新增说明已写入，但摘要、选型矩阵与部分图表仍保留旧规则）。这些条目的**实际完成发生在 v5.1**，处置见 11.2.8。保留本表原文以记录当时的认定与其偏差。
来源：定稿复审意见 v1.0 的收口清单 R01–R12。该轮复审确认 v4.0 的新增说明方向正确，但指出**新增的正确说明没有替换掉摘要、表格与图中的旧规则**——读者通常直接采用摘要与表格，不应由其自行判断哪一处覆盖哪一处。本轮据此做**全文一致性修订**，不扩充调研范围、不新增章节主题。
| 编号 | 收口要求 | 本轮落实 |
|---|---|---|
| R01 | 合规段仍保留被撤回的"两条合规路径" | 8.2 决策点 6(b) 改为"部署选项不是合规路径"，并要求先判断适用义务再核验技术控制；"仍然适用"改为"仍须分别判断并履行适用义务" |
| R02 | 硬上限条件不足；"有界透支"与"超支归零"并存 | 5.9.5 ⑤ 改为**预留须覆盖最大可计费消耗并由引擎/可信执行路径强制**；8.2 决策点 9 不再把某一技术组合写成必选方案；8.4 KPI 改为"未授权突破为零 + 应急透支单列统计" |
| R03 | 事件 ID 唯一不保证幂等；控制指令"即时生效" | 5.9.5 ⑤ 补**稳定幂等键 + reservation 状态迁移约束 + `unknown` 不得释放预留**；链路④ 改为沿用链路①的最大生效时限与实例确认，并明确撤销对后续每次调用生效 |
| R04 | 新增的 KV 缓存安全表述过强 | 5.5 改为"不直接复用历史答案 ≠ 安全"，补 vLLM `cache_salt` 信任域隔离、时序侧信道与哈希碰撞风险（来源 #69），并要求信任域映射由可信层决定 |
| R05 | 两张图仍未表达已采纳规则 | 两张时序图重绘：降级分支加入契约判断→重新授权→重新预留→失败拒绝；金额改"所选计价单位"；权威结算与分析副本分离；第一张图标注"非流式正常路径"，第二张图改为增量持续转发、终止后结算或转 unknown；队列改"已选定的优先级/公平策略" |
| R06 | WTU/成本/饱和假设未全文统一 | 沉没成本限定为短期已有容量视角并承认可变成本；私有化不禁止货币计价；"饱和是常态"改为"共享池接近容量时"；"选副本替代选模型"改为新增一层；WTU 全文改为"所选计价单位，WTU 仅在启用时记录"；降级不再是唯一兜底；折扣档位承诺须有容量保障；删除"差一个量级"的无本地测量量级结论 |
| R07 | 逻辑分层、产品范围与物理双网关混写 | 工作定义纳入"内部模型服务"；"明确不含"改为"相关生态"；3.1–3.3 标注为可交叉维度、非成熟度排名；删除"唯一能拒绝请求"；双网关改为**逻辑职责分离、是否双跳取决于组件/性能/故障域**；形态 B 稳定性补"网关高可用同 A"；Portal 依赖表述收窄为"管理控制台不进请求链路" |
| R08 | 安全分期与留存默认值未在表格同步 | 8.1 二期移除基础脱敏、保留检测增强；8.6.2 第 8/9 项改为白名单元数据默认 + 基础保护前置；8.7 将数据分级留存移入必备列、调用回放限隔离环境；"原生直通 + 治理旁路"全文改为"原生协议透传 + 强制治理" |
| R09 | 产品矩阵与来源分级只承认问题未改表 | 删除"最广/最全/首选/多数企业"等无样本排名；性能列统一改为"未做同条件对比，待 T12"；Portkey 标注版本相关、Kong 与 APISIX 分述；预算缺陷收窄为"特定版本 issue、目标版本待核"；9.1 删除"所有关键事实均已核验"总括并新增**证据性质**分类；许可表述改为区分独立实现与代码复用 |
| R10 | OpenMeter 结论超出分钟精度证据 | 6.4 与 8.3 改为"已核验文档**尚不足以证明**满足所需并发 reserve/commit/release 保证"，须按目标版本验证；来源 #68 补证据边界 |
| R11 | KPI 状态维度不正交；实施条件缺交接表 | 8.4 KPI 改为**请求生命周期 / 计量质量 / 结算状态三维、不得相加**；8.8 新增**实施前待决项登记表**（含责任角色、决策时点、交付物、对应用例）；T01/T02/T08/T09 补判定项；T12 引用改为 8.4 KPI |
| R12 | 修订记录与状态声明收口 | "四张表"改为五类核心实体；〇.1 适用性修订改为完整七项引用；9.7 删除总数结算式改为逐项响应；GIE 链接分歧改为**客观记录双方访问结果**并建议改用版本化来源；8.5.3 就近补适用性限定；**定稿状态声明前移至摘要**；历史版本记录标注"不作为现行设计要求" |
> **本轮不做的事（与复审意见一致）**：不执行 T01–T12，不把研究报告扩写为完整生产设计，不重新审查市场动态。额度事务方案、实际阈值、资源测算与运行证据留待实施阶段，**未完成前不得引用本研究定稿作为能力已验证的证明**。
#### 11.2.8 终态复核收口记录（v5.1，2026-09-18）
来源：v5.0 终态复核意见（7 组）。该轮确认结构重组合理、头部版本信息应保留，但指出**过程标记清零与 Mermaid 语法通过不足以证明全文一致**——旧规则仍残留在图、表与摘要中。本轮为局部收尾，未扩大调研范围、未执行 T01–T12。
| 组 | 收口要求 | 本轮落实 |
|---|---|---|
| 1 | 时序图拒绝分支后仍无条件转发 | 8.6.4 第二张图重绘：降级分支细分为"重新授权不通过 / 重新预留失败"两条终止路径，共同执行段包入 `opt 授权通过且持有有效预留`，并在图注写明"任何拒绝或未持有有效预留的路径均不进入转发"；8.6.5 对应说明同步改为引用图中规则 |
| 2 | 选型矩阵未落实已声明口径 | 8.3 矩阵重写：**所有方案性能统一为"未做同条件对比，待 T12"**；Kong 与 APISIX 分行并标注开源/企业版差异；Portkey 标"目标版本待核"；删除"国内合规"评分列、改为可核验的"部署与数据控制条件"并声明其不构成合规结论；另删除"国内事实标准""层级最全""组件最全""使用最广之一""功能最简"等无样本比较级 |
| 3 | 决策图仍由"强监管"直推气隙 | 决策图改为先识别已确定的隔离/驻留/审计控制要求，再判断"是否必须离线或强隔离部署"；决策点 1 与场景映射改为"列为候选并须核验目标版本"，不以行业标签或产品品牌作为部署结论的充分条件 |
| 4 | 旧架构图与风险表保留旧技术组合 | 架构图节点改为"权威额度服务/账本（实现待决）"与"分析/观测存储（非权威账本）"，接口改 `reserve/commit/release（幂等与状态约束）`，网关侧改"观测/分析事件发布"，并补权威结算结果作为对账基准的连线；TOCTOU 风险行改为引用 5.9.5 ⑤ 的机制要求并挂 T01–T04；撤销范围与状态分类口径与正文统一 |
| 5 | 场景口径残留 | 逐条替换：路由改"先选模型/池再选副本"；2.1 定义纳入内部模型服务；成本口径与〇.1 统一；请求路径依赖改为"Portal 不进同步路径、专用服务可按需依赖"；WTU 在能力清单、账本字段与效能指标中改为"所选计价单位（WTU 仅在启用时）"；8.5.3 开头改为"共享池接近容量时增加准入、与限速并存、实现取决于锁定版本"；8.7 标题与说明改为"标准观测与按需内容留存"；3.1/3.3 标注相关生态并将"梯队"改为"分组" |
| 6 | 证据分级定义矛盾 | 附录说明拆为**来源类型（A/B/C，仅描述来源身份）/ 核验状态（表内列）/ 证据性质**三维；来源表新增**证据性质**列并对全部 66 条逐条标注（规范事实 13、产品自述 37、二手报道 8、用户报告 4、学术研究 2、待核 1、二手报道+作者推论 1）；结论约束收窄为"厂商能力断言与运行保证不得仅由产品自述、用户报告或作者推论支撑"，同时明确逻辑反例可支持机制局限判断 |
| 7 | 引用迁移与完成记录 | 版本概要中的 9.4–9.8 改为"当时版本的 9.x，现见 11.2.x"；11.2.7 补完成状态更正说明；另修正来源表 #48 中残留的 "MCP Apps"（该项未见于 2026-07-28 changelog） |
> 证据边界不变：本轮全部为文档层面修订，**未执行任何运行测试**；T01–T12 及具体版本、阈值与实施协议按 8.8 推进。
#### 11.2.9 再次审议修订记录（v5.2，2026-10-17）
**来源与轮次**：管理员提交的再次审议（议题 005），第 1 轮以 `--goal review` 审议 v5.1 全文，按意见收集采纳——五席均有效作答，投票席位（核验、质疑、顾问）与两个主持席全部投 REVISE，插件停在独立意见阶段，没有互评与综合稿。本版以各席原文为依据，由主持人逐条核对原报告行文，并对外部事实重新检索一手来源（2026-10-17）。**强席位（质疑席、核验席）的异议是本版必须闭环的阻塞项**，处置如下；其余意见的取舍见 9.2。
**A. 核验席第一档（7 项）**
| # | 意见（原报告位置） | 处置 | 修订位置 |
|---|---|---|---|
| 1 | 6.2 称 Token 压缩/MCP 等为"本报告论证为必建"，与 8.1 分期矛盾（report.md:418） | 采纳：删除"Token 压缩"与"必建"定性，改为按 8.1 区分一期安全基线与二期能力 | 6.2 |
| 2 | Assistants API"2026 年中退役/弃用"过时且两处用词不一（:59、:199） | 采纳：经官方迁移指南核实，统一为"2026-08-26 已下线"；Chat Completions 改用官方当前措辞，补 GPT-5.4 工具调用限制 | 摘要结论 1、4.5、8.2 决策点 2、2.2 |
| 3 | OX 口径：来源表称"正文已区分 20 万口径"而正文没有，1.5 亿与 97M 关系未说明（:484、:1002） | 采纳：读取 OX 原文，正文分列三个数字并说明不可比，补 Anthropic 立场 | 7.4、9.1 #49 |
| 4 | 证据性质定义漏掉在用取值，#11、#44 标错（:949） | 采纳：定义补全为九种取值并新增"核验时点"说明；#11 改安全研究、#44 改产品自述、#12 改产品自述；#33–#35 来源类型改为 issue | 9 章说明、9.1 |
| 5 | 5.5 在"不引用未溯源量化"的声明下出现 20 倍、0.8、Traefik 等无来源数字（:227） | 采纳：删除三项数字与示例，改定性表述 | 5.5 |
| 6 | Portkey 自托管描述矛盾（:588 对 :113） | 采纳：矩阵改为"开源 core 可自托管、企业版另含治理增强"；许可补 MIT | 8.3、6.3 |
| 7 | GKE Inference Gateway 范围归类与 8.5.2 矛盾（:116） | 采纳：3.1 新增"推理调度层"一行，GKE Inference Gateway 移入 | 3.1、6.1 |
核验席第二档意见中，以下已采纳：Microsoft Foundry 更名、AgentCore 逐组件标状态、vLLM 指标名更新、许可列修正、OpenMeter 推论降级（并补 Kong 收购公告）、时间线补断档（仅补已核项目）、6.2 二手条目降级、参考资料补链换链、11.2.3 陈旧说明补注、OmniRoute 与"Google AI Gateway"处置。任务书 B1 所引证据边界位置的偏差（实为 report.md:49-51）已记录，不影响修订。
**B. 质疑席必须修改（5 组）**
| 组 | 意见 | 处置 | 修订位置 |
|---|---|---|---|
| 1 | 选型事实：New API 套餐与重置能力、LiteLLM"未见 A2A"（:287、:555、:587） | 采纳：经 New API 官方文档与 LiteLLM v1.80.8 发布记录核实，改写 5.9.2 路线 A、8.3 场景映射、6.3 与选型矩阵 | 5.9.2、6.3、8.3 |
| 2 | 安全恢复：受控旁路、应急份额不可重复领取、fallback 再校验、请求体调度参数（:637、:387、:812、:215、:758） | 采纳：四处补条件；8.6.2 第 12 项扩为"治理上下文信任边界"；决策点 10 与 8.5.2 的"标准请求头"改为"锁定版本的治理上下文契约" | 5.2、5.9.5 ⑤、8.5.1、8.5.2、8.6.2、8.2 |
| 3 | MCP 安全边界：令牌受众绑定、资源级授权、STDIO 启动隔离；OX 风险定性归属研究方（:196、:239、:484） | 采纳：经 MCP 授权规范原文核实，4.5 新增令牌透传、管理面越权等行，7.4 重写 | 4.5、7.4 |
| 4 | 证据与时效：Assistants 退役、当前安全公告、来源表误标、缺失引用（:59、:437、:967、:976、:997、:1031） | 采纳：见 A 表；补入 LiteLLM 2026-09-30、10-01 两项安全公告；Azure 链接换为 Quickstart 原文 | 4.5、6.3、7.5、9.1、第十章 |
| 5 | 验收补充：旁路、实例重启/扩容应急额度、队列派发竞态、请求体控制参数、管理面 MCP 越权 | 采纳：新增 T13–T16；待决项新增 1 项（旁路与管理面）、扩写 2 项（硬上限与应急敞口、协议与引擎版本），不虚构测试结果（v5.3 更正：原记录写作"两项待决项"） | 8.8 |
质疑席一般改进中，以下已采纳：A/B 形态可组合、"数据主权最强/零运维"改写、"首次/普遍/主流"等比较级删除、4.3 改"候选能力清单"、AGPL 第 13 条补充、KPI 补攻击集与误报率、签名身份与来源校验、KMS 外部化的边界。
**C. 主持席意见（不计票）的主要采纳项**：契约抽象三处强度统一为分级口径；一期预算的周期语义前置；IBM 推荐因无产品证据删除；3.3 与 6.2 的范围口径与〇章对齐；4.2 对 Azure 的归因改为"据 InfoQ 报道、作者归纳"；法规补《网络安全法》修改与 AI 标识办法；GIE 成熟度分层；9.1 合并 #48/#66、#68/#69 顺序修正；WTU 可选性在 8.6.5 统一；Agent Router"5+"提供商数删除。
**D. 补充最新进展（B17）的处置**：质疑席提出的 5 条候选与研究综合席提出的 3 条候选，主持人逐条读取一手来源后写入 7.5（Agent Router 加入 AAIF、LiteAdmin MCP、Kong AI Gateway 2.1/2.2、LiteLLM 两项安全公告、Cloudflare Monetization Gateway、Dynamo agent_hints、llm-d 1.0 计划），另补主持人检索到的 Uber MCP Gateway 一手案例。llm-d 1.0 截至 2026-10-17 仅为计划，Dynamo agent_hints 仅见开发版文档，均已在正文注明状态。（v5.4 补注：Dynamo 状态以 11.2.10 A 表第 3 项的更正为准。）
**E. 本版删除的内容**：OmniRoute、LiteLLM Cloud（未定位到来源）；Docker 作为 MCP 网关"采用方"的例子（Docker 是供应商而非采用方）；百度"130 万+ Agent"、阿里云客户名单（与网关能力无关或无具体报道）；5.5 的"20 倍、0.8、Traefik"；Azure 行的"1400+ 连接器""卡片式策略"与 Cloudflare 行的"免费额度充足"（无来源或属主观评价）；Agent Router 的"5+ 提供商"。
**F. 本版的证据边界（诚实声明）**
- 本版**全部为文档层面修订**，未执行任何运行测试；T01–T16 均未执行。
- 6.2 国内云厂商条目仅做降级与范围标注，**未逐项复核**；国内 2026-09 以来的网关层新发布本版未检索到可核验的一手材料，不构成"无新进展"的断言。
- 9.1 中未注明核验日期的 ✅ 条目为历史核验记录，本版未逐条重访。
- 顾问席第 1 轮意见所引的原报告表述经核对均不存在，未采纳（见 9.2）；其通用工程建议保留为少数意见。
- 本版为修订稿，须经复审轮按原有通过门槛（法定人数满足、强席位阻塞项全部闭环）后方可定稿。
#### 11.2.10 第 2 轮复审处置记录（v5.3，2026-10-17）
**来源与轮次**：第 2 轮复审以 v5.2 为材料完成完整研讨（独立意见、互评与综合），法定人数满足。三个投票席位（核验、质疑、顾问）在独立意见与互评两个阶段均投 APPROVE；`strong_objections` 与 `strong_unparsed` 均为空，**没有强席位阻塞项需要闭环**。第二主持（不计票）独立意见投 REVISE，互评改投 APPROVE。本版处理的都是少数意见与编辑建议，不改变任何结论。
**A. 少数意见处置**
| # | 意见（v5.2 位置） | 提出席位 | 处置 | 修订位置 |
|---|---|---|---|---|
| 1 | 8.6.4 时序图与 8.6.2 第 4 项仍写"调度头/请求头"，未覆盖请求体（:788、:866、:888） | 第二主持、质疑席、核验席 | 采纳：三处统一为"治理控制字段（请求头与请求体）"，与第 12 项一致 | 8.6.2 第 4 项、8.6.4 时序图 |
| 2 | fencing 写作"不再接受旧实例提交"，易混淆"拒绝修改权威状态"与"拒收消耗证据"（:401、:962） | 质疑席、第二主持、核验席 | 采纳：补明旧实例失去新增执行与修改权威状态的权限，迟到用量经权威对账流程核对入账，未确认在途敞口不回收再发；链路② 补交叉引用 | 5.9.5 ⑤ 第 6 条、8.6.4 链路②、T14 |
| 3 | Dynamo `agent_hints`"仅见开发版、未进入稳定支持矩阵"失准（:517、:1085、:1510） | 质疑席、第二主持 | **经主持人重访官方页面核实成立**（2026-10-17）：v1.5.1 文档已列 `priority`、`strict_priority`、`osl`、`speculative_prefill`，并按后端区分支持（按优先级逐出缓存在 vLLM、TensorRT-LLM 上为计划）；NVIDIA 技术博客 2026-04-17 首次公开。正文改为"已有正式版文档，后端支持按目标版本核验"；11.2.9 D 中"仅见开发版文档"的表述以本条为准 | 7.5、8.5.2、8.6.2 第 12 项、9.1 #86、第十章 |
| 4 | 7.5 标题"2026-09-18 以来"与首行 9 月 9/10 日事项不符（:504、:510） | 第二主持、核验席 | 采纳：标题改为"2026 年 9 月以来"；11.1 v5.2 行为历史记录，保留原文 | 7.5 |
| 5 | 状态措辞冲突：:51 写"定稿"，:4 与末尾写"待复审" | 核验席、第二主持 | 采纳：统一为"修订稿，经终审按原有通过门槛确认后定稿" | 头部、报告状态与证据边界、本节 |
| 6 | 措辞降级与记录更正："OX 漏洞"、Kong 2.2"印证"、11.2.9 B5"两项待决项" | 主主持、质疑席、核验席 | 采纳：改为"OX 披露的风险""方向一致（厂商自述，未独立验证）"；经对照 v5.1 与 v5.2 的待决项表，B5 实为新增 1 项、扩写 2 项，已在原记录中更正并注明 | 8.1、7.5、11.2.9 B5 |
| 7 | 其他编辑建议：摘要 OX/Anthropic 加"据 OX 转述"；#11 来源类型分列；摘要 Portkey 加版本限定；#3、#49 补链接 | 核验席 | 采纳前三项；#3 补 Unity Gateway Release Notes 链接，补核时发现 Databricks 当前官方文档名称为 Unity Gateway、2026-08-04 宣布 GA，已在 6.1 与 #3 注明；#49 的 Infosecurity 原文链接未能定位，改注"仅作辅助，不支撑结论" | 摘要结论 3、4，6.1，9.1 #3、#11、#49，第十章 |
| 8 | llm-d 1.0 计划 2026-10-19 发布，定稿晚于该日须重核（:518、:682） | 核验席 | 保留为定稿前核对项：截至 2026-10-17 仍为计划，正文不变 | 9.2 |
**B. 席位作答质量记录**：质疑席与核验席均指出，顾问席（agy）第 2 轮所引任务书行号不存在，并把 A 表 7 项、B 表 5 组误述为各 4 项，所述"零拷贝"等内容在报告中不存在。其 APPROVE 只计入插件法定人数，不作为阻塞项闭环依据；不计该票时，两个强席位的 APPROVE 也已满足法定人数。
**C. 本版的证据边界（诚实声明）**
- 本版**全部为文档层面修订**，T01–T16 仍未执行。
- 本版只对 Dynamo（v1.5.1 文档、NVIDIA 技术博客）与 Databricks（Unity Gateway Release Notes）重访了一手来源；7.5 其余条目与 #70–#95 未逐条重访，第 2 轮质疑席与第二主持抽核了 LiteAdmin MCP、Cloudflare、llm-d 的状态。
- 本版为修订稿：第 2 轮已按原有通过门槛判为通过；按默认轮次，终审（第 3 轮）复核相对原报告 v5.1 的完整修订差异，并由第 2 轮少数意见的提出席位（质疑席、核验席、第二主持）定向复核本节 A 表。（v5.4 补注：A 表第 6 项的提出席位还包括主主持；A 表第 3 项与 11.1 v5.3 行的"2026-04-17 首次公开"为当时表述，历史原文保留；现行结论以 7.5 与 9.1 #86 的"已公开介绍"为准，见 11.2.11。v5.5 更正：v5.4 原补注误称两处已改写。）
#### 11.2.11 第 3 轮终审处置记录（v5.4，2026-10-17）
**来源与轮次**：第 3 轮终审以 v5.3 为材料、以相对原报告 v5.1 的完整修订差异为复核范围，完成完整研讨（独立意见、互评与综合），法定人数满足。五席在独立意见与互评两个阶段均投 APPROVE；`passable=true`，`strong_objections` 与 `strong_unparsed` 均为空，**没有强席位阻塞项需要闭环**，本轮按原有通过门槛判为通过。质疑席按差异重建 v5.1 后与 v5.3 一致，并抽核了 NVIDIA Dynamo v1.5.1、Databricks Release Notes 与两项 LiteLLM 安全公告；核验席本轮未访问外部来源，只核对内部一致性。本版处理的都是少数意见与编辑建议，不改变任何结论。
**A. 少数意见处置**
| # | 意见（v5.3 位置） | 提出席位 | 处置 | 修订位置 |
|---|---|---|---|---|
| 1 | 8.6.2 第 4 项仍写"请求头**或**请求体扩展字段"，与 11.2.10 A 表第 1 项、9.2、11.1 v5.3 行"统一为请求头与请求体"的记录不符（:788、:1111、:1275、:1537） | 第二主持提出，核验席补强，质疑席认可 | 采纳：改为"请求头与请求体扩展字段，按目标引擎协议覆盖实际载体"；第 12 项已强制覆盖两类载体，安全要求本未缺失。4.5 威胁模型行描述调用方可能伪造的载体，"或"保留 | 8.6.2 第 4 项 |
| 2 | 7.5 标题限定"2026 年 9 月以来"，却收录 2026-04-17 的 Dynamo 事项；"首次公开"属 v5.2 已删除的比较级；#86 称博客介绍"三项字段"而同行列四项；日期列混入状态文字（:504、:517、:1085、:1539） | 质疑席、核验席、第二主持、主主持 | 采纳：日期列只写"2026-04-17（早于本节时间窗）"，事项列注明因补核正式版文档且关联 8.6.2 第 12 项而收录，状态移入状态列；"首次公开"改为"已公开介绍"。主持人于 2026-10-17 重读 NVIDIA 技术博客原文，确认博客所列为 `priority`、`osl`、`speculative_prefill` 三项，未提及 `strict_priority`，#86 据此写明 | 7.5、9.1 #86 |
| 3 | Databricks 平台 GA 不代表子能力 GA（:417、:1005） | 质疑席 | 采纳：主持人于 2026-10-17 重读 Unity Gateway Release Notes，确认 2026-08-04 GA 条目写明 service policies、agent services 仍为 Beta，2026-10-12 条目将 Skills REST API 标为 Beta；已在 6.1 与 #3 注明 | 6.1、9.1 #3 |
| 4 | 5.9.4 与 #30 仍概括为 LiteLLM 按配置时区午夜重置，未反映 5.9.2 的多窗口 UTC 对齐（:343、:1030） | 核验席、质疑席 | 采纳：两处补多窗口 `budget_limits` 按 UTC 对齐，并引回 5.9.2 与 #81 | 5.9.4、9.1 #30 |
| 5 | fencing"未确认的在途敞口不得回收再发"缺终止条件（:401、:962） | 核验席提出；质疑席互评反对直接采纳 | **保留为少数意见，正文不改**：质疑席的反例成立——租约与最大执行时长结束不能证明此前没有未上报消耗，直接回收可能重复承担敞口。现文保守自洽，终止条件随 T14 在 POC 中确定；两种意见均收入 9.2 | 9.2 |
| 6 | 历史与附录残留：9.2"待复审轮补证"终审后将悬空；11.2.10 C 定向复核席位漏列主主持；11.2.3 仍写"2026 年中退役"；11.2.9 D 仍写 Dynamo"仅见开发版"；摘要"第 1、4 条在此合并"对应关系不清（:1107、:1552、:1346、:1517、:43） | 核验席、主主持 | 采纳：9.2 改为"定稿后按一手来源补证，未补证前不写入"；三处历史记录保留原文并加 v5.4 补注；摘要改为写明简版与详版的对应关系 | 摘要、9.2、11.2.3、11.2.9 D、11.2.10 C |
| 7 | llm-d 1.0 计划 2026-10-19 发布，定稿晚于该日须重访一手来源（:518、:682、:1113） | 核验席、主主持、质疑席 | 保留为定稿前核对项：本版日期 2026-10-17 早于计划发布日，正文维持"计划"表述；站内发布若晚于 2026-10-19，须先重核 7.5 与 8.5.2 | 9.2（既有条目） |
**B. 席位作答质量记录**：核验席、质疑席在互评中逐条核实，顾问席（agy）第 3 轮所引任务书行号（:28、:46、:68 等）不存在（任务书仅 10 行），所述 11.2.10 A 表位置与内容、4.2/5.3/7.2/9.3 等章节内容，以及 Pingora、WebTransport、Radix 等转述在报告中均不存在。这是该席连续第 2 轮出现同类问题。其 APPROVE 只计入插件法定人数，不作为闭环依据；不计该票时，两个强席位的 APPROVE 也已满足法定人数。
**C. 本版的证据边界（诚实声明）**
- 本版**全部为文档层面修订**，T01–T16 仍未执行，本报告不作为能力已验证或生产上线的证明。
- 本版只重访了 NVIDIA 技术博客（核对所列字段）与 Databricks Unity Gateway Release Notes（核对子能力状态）两项一手来源；其余外部事实沿用 9.1 标注的核验时点。
- 本版是第 3 轮终审通过后的定稿收口，改动限于上表所列措辞、限定与记录补注，未改变任何结论或安全要求；相对 v5.3 的差异已另行留存，按规约交提出席位定向复核。
#### 11.2.12 终稿最终复核记录（v5.5，2026-10-17）
**来源与范围**：按项目规约，报告由 Claude 执笔时，终稿的修订差异须交 Codex 做最终复核。复核人为 Codex 质疑席（与讨论组质疑席同一模型与推理强度），材料为：① 相对第 3 轮终审通过对象 v5.3 的全部差异（含 v5.4 的少数意见收口与 v5.5 的定稿改动）；② 相对原报告 v5.1 的完整修订差异。终审口径：只有会导致结论错误、主体自相矛盾或无法落地的问题才列为阻塞项，其余作为少数意见。这是对差异的定向复核，不是新一轮 council。
**A. 复核结论**：**VERDICT: APPROVE，无阻塞项。** 复核人认定：v5.3→v5.5 的差异未改变主体结论或安全要求（请求头与请求体的覆盖与 8.6.2 第 12 项一致；Databricks Beta、LiteLLM UTC 对齐及 Dynamo 字段补充均属限定与澄清；fencing 未放宽；T01–T16 未执行的证据边界保持明确），且与 11.2.11 A 表、11.1 v5.4/v5.5 行一致；v5.1→v5.5 完整差异未见导致结论错误或无法落地的新增矛盾，原标题保留，既有历史以原文加补注延续，版本号递增正确，新增与修改文本不含本机或内部归档路径。复核人报告本地全文读取因沙箱启动失败未能执行，复核依据为提示中附带的两组完整差异，未独立重核外部事实；未改动部分的路径扫描由主持人完成，未发现本机或内部归档路径。
**B. 复核意见处置**
| # | 少数意见（v5.5 草稿位置） | 处置 | 修订位置 |
|---|---|---|---|
| 1 | 11.2.10 C 的 v5.4 补注称 A 表第 3 项与 11.1 v5.3 行的"首次公开"已改为"已公开介绍"，但两处历史原文仍保留"首次公开"（:1556） | 采纳：补注改为"为当时表述，历史原文保留；现行结论以 7.5 与 9.1 #86 为准"，并注明 v5.5 更正 | 11.2.10 C |
| 2 | 9.2 第二主持行称"v5.3 已把时序图与第 4 项统一"，而 11.2.11 A 表第 1 项记载第 4 项到 v5.4 才完成统一（:1111） | 采纳：改为"v5.3 已统一时序图，第 4 项于 v5.4 完成措辞统一"，并注明 v5.5 更正；第 12 项安全要求不受影响 | 9.2 |
两处均为处置记录的版本表述更正，复核后未改动正文，未再次送审。
**C. 定稿判定依据**
- 第 3 轮终审为完整研讨（独立意见与互评），法定人数满足，核验席与质疑席均作答并在两个阶段投 APPROVE，`passable=true`，强席位无阻塞项、无无法解析的表决；第 1 轮强席位阻塞项已在 v5.2 逐条闭环（11.2.9），并经第 2、3 轮由提出席位复核。
- 顾问席（agy）第 2、3 轮均出现引用失实（11.2.10 B、11.2.11 B），其 APPROVE 不作为闭环依据；不计该票时，两个强席位的 APPROVE 仍满足法定人数。
- v5.4、v5.5 相对 v5.3 的改动限于措辞、限定、历史补注与定稿状态，未改变任何结论或安全要求，并已经 Codex 最终复核（见 A）。
**D. 本版的证据边界（诚实声明）**
- 本报告**全部为文档层面的调研结论**，T01–T16 均未执行，不作为能力已验证或生产上线的证明。
- 本版未新增外部事实；外部事实沿用 9.1 标注的核验时点（本轮再审议复核截至 2026-10-17）。
- llm-d 1.0 截至 2026-10-17 仍为计划（计划 2026-10-19 发布）；对外发布若晚于该日，须先重访一手来源并重核 7.5 与 8.5.2。
- 6.2 国内云厂商条目仍未逐项复核（见 11.2.9 F）。