信通院近期把「AI 网关」单独列项，做了一套可信云能力评估，划出七大能力板块、二十四个能力子项。这意味着 AI 网关从厂商各自表述的营销词，变成了可以被第三方测试、评审、发证的能力品类。本文不重复条文，只从工程视角聊聊这七大板块背后真正要解决的问题。
一、传统 API 网关为什么接不住 AI 流量
两个具体原因。
第一是 Token 的流式输入输出。传统网关以「请求-响应」为单位做鉴权、限流、计费，边界干净。但大模型的输出是一段段「挤」出来的流，一个请求持续几十秒、切出几十个 chunk。网关按请求数计费，账对不上；按字节流计费，又分不清哪些是推理产出、哪些是协议开销。计费单位必须从「请求」下沉到「token chunk」：
tokens = 0
for chunk in stream_response:
tokens += count_tokens(chunk) # 只对增量计费，不重复计协议开销
if over_budget(tokens):
stream.abort() # 流中途掐断超预算调用
第二是智能体通信协议的冒头。MCP、A2A 这类协议一次工具调用会牵出多个子调用，一个 Agent 任务横跨多个模型、多个服务。传统网关按 URL 路径路由的那套逻辑，在这种拓扑下基本失效。
二、七大板块拆成三组
「接得住」：多模型适配能力 + 模型服务集成能力。 核心是把不同厂商模型抽象成统一调用接口，让上层无感切换，并把私有化模型、知识库、RAG、Agent 系统纳入统一出口，形成一张模型资产图。本质是消除供应商锁定。
「管得住」：流量治理 + 可观测性 + 插件集管理。 流量治理是「谁能调、调多少、往哪调」，在 LLM 场景下需要模型路由和降级。一个只该访问轻量模型的 Key 试图调用大参数模型，应该在网关层就被拦下，而不是月底看账单。可观测性要回答 Token 花在哪、谁花的，落到工程上是一张跨供应商、多维度的用量视图。
「护得住」：安全防护 + 大模型工具信息交互（MCP）支持。 AI 流量的安全风险分两层：敏感词、PII 是「看内容」，越狱、提示词提取、对抗输入是「看意图」，检测范式完全不同。
三、云上落地的几个切面
如果把这类网关部署在云上，几个能力天然能找到落点：函数计算这类无状态弹性计算适合承接网关的数据面横向扩展；云上的托管 API 网关可以承担接入层的身份鉴权和基础限流；模型服务通过网关统一对外暴露，业务侧无需关心底层切换。网关层再做一张模型路由表，把不同任务路由到不同模型：
routes = [
{
"match": "embedding", "model": "text-embedding"},
{
"match": "reasoning", "model": "reasoning-class", "fallback": "general-class"},
{
"match": "toolcall", "model": "tool-call-class"},
]
路由、降级、计费这三件事做对，AI 网关才算真正「接得住、管得住」。
四、标准的价值在选型
过去选 AI 网关靠厂商 PPT，标准模糊。有了七大板块的能力基线，多模型适配覆盖哪些厂商、可观测性拆到哪个维度、安全防护做到哪一层，都能逐项核对。对认真做产品的团队，这是公共坐标系；对混水摸鱼的，是压力。
