一个网关不够用了
企业接入大模型的最初形态很简单：在应用和模型服务之间放一个网关，统一密钥、做限流、记录用量、在多个供应商之间路由。这类「模型网关」在 2023 到 2024 年迅速普及，解决的问题也很明确——别让每个业务团队各自去对接模型 API。
但当智能体开始真正干活，事情变得复杂了。智能体不仅要调模型，还要通过工具协议去调外部工具和数据；多个智能体之间还要互相调用与委派；与此同时，安全团队关心的是员工和业务把什么数据喂给了 AI、有没有被恶意注入。这几件事分别发生在不同的位置上，一个网关无法同时管住。于是，业界正在把 AI 网关拆成多层，每层只解决一个问题。
需要说明的是，这种分层是行业实践中的归纳，并非某个标准组织发布的分层规范；各层的边界在实践中也在互相渗透。目前官方及行业暂未披露统一的层间接口标准，后续将持续跟进迭代动态。本文只讨论其中已经公开的代表性做法。
一层：模型网关，管「模型怎么接」
最底层是模型网关，位置夹在应用与各家大模型之间。它的职责是统一的模型接入：把不同厂商的接口差异抹平，按成本与延迟做路由，做限流、缓存与用量统计。常见方案包括 Kong、LiteLLM、Portkey 一类，国内主流云厂商也提供统一的模型接入服务。
这一层按部署位置与控制权，通常可以分成三类：托管型、开源自建型与私有化型。选择哪一类，取决于企业对密钥归属、数据出境与故障责任的要求，而不是单纯看功能表。一个常见的误区是把模型网关当成「加了缓存的代理」，但它的核心价值其实在于把「用哪个模型」从一个散落在各处的硬编码决定，变成一个可以集中调整的策略。
二层：MCP 网关，管「Agent 怎么调工具」
模型接进来之后，下一步是让它通过协议去调用外部工具与数据。MCP（模型上下文协议）在 2024 年 11 月开放后迅速成为工具调用的通用接口，但工具一多，新问题就来了：哪个智能体能调哪些工具、用谁的凭据、调用有没有留痕。
MCP 网关的作用是把散落的 MCP 服务器聚合成一个入口，在这一层做鉴权、按角色分配可见的工具、并记录审计。代表项目包括容器厂商的 MCP Gateway 与 IBM 开源的 ContextForge。这一层的价值在权限治理而非协议转换——协议本身已经标准化了「怎么调」，网关解决的是「谁能调、调了记在哪」。
三层：Agent 网关，管「Agent 之间怎么协同」
当多个智能体分工协作、互相调用时，通信同样需要秩序：对方身份是谁、任务走到哪一步、哪里需要人来把关。A2A（智能体对智能体）是这个方向的互操作协议，2025 年 4 月提出，2025 年 6 月移交 Linux 基金会治理，代表实现包括开源的 agentgateway。
这一层与 MCP 层的区别值得强调：MCP 标准化的是「智能体到工具」，A2A 标准化的是「智能体到智能体」。前者解决「我有什么工具可用」，后者解决「我能把任务交给谁」。两者互补，实践中常同时使用。Agent 网关在这一层的职责，是把跨智能体的调用纳入统一的身份、任务状态与人工介入机制，而不是让每个框架各搞一套。
值得注意的是，有金融行业的架构实践提到，把 A2A 协议与 MCP 并排运行并不冲突，因为底层 API 仍是稳定的契约，交互层可以替换。这个观察对正在做架构规划的企业有参考价值：把控制与流程固化成代码化的配置，就不必每次交互方式变化都从头重做。
四层：AI 安全网关，管「AI 用得安不安全」
前三层让 AI 用起来、用得顺；安全团队关心的则是内容侧的问题：员工和业务把什么数据喂给了 AI、有没有被恶意注入、会不会顺着对话泄漏出去。这一层的职责是识别「影子 AI」、拦截提示词注入、对 AI 流量做内容级检测并留下审计记录，主体通常是网络安全厂商。
这一层正在从概念走向产品。据公开报道，有安全厂商在 2026 年 9 月发布了面向 AI 的安全网关产品，把统一模型入口、调用行为研判与审计记录收在同一个控制点上；另有安全厂商在 2026 年半年报中披露，其 AI 安全防护业务收入同比增长超过 130%，方案已在政府、金融、医疗、教育等行业落地。被多方引用的 Gartner 调研数据则显示，17% 的企业已部署 AI 智能体，42% 计划在一年内落地——这组数字常被安全厂商用来论证防护需求的紧迫性，引用时应注意其转引性质。
把这一层单独拆出来的意义在于，它解决的是前三层不覆盖的问题：模型网关不管内容、MCP 网关不管内容、Agent 网关也不管内容。而恰恰是「内容」这一层，是提示注入这类攻击的入口。
五层：网络层 AI 网关，管「加速、治理与数据主权」
最上面一层几乎都在网络侧工作。前四层基本属于应用层，且多为云服务——请求要先交出去，服务才帮你路由、缓存、检测。网络层网关的思路不同：把加速、AI 治理与数据主权放在更靠近企业网络边界的位置，让流量在企业可控的范围内完成处理。
这一层的成熟度低于前四层，公开的技术细节也更少，但它反映了一个现实诉求：当 AI 流量成为企业出网流量的重要组成部分，网络团队希望有与既有网络架构一致的管控点，而不是把所有治理能力都寄托在应用层的第三方服务上。
三类典型失效点
分层之后，需要提醒三类常见的失效方式。
一类是「宣称覆盖几层」。分层是责任划分，不是功能清单。判断一个产品属于哪一层，标准应当是它在哪一层真正落地、承担了什么职责，而不是它宣称自己覆盖几层。一个宣称从模型到安全全包的网关，很可能每一层都只做了薄薄一层。
二类是网关自身成为新的单点。把鉴权、策略与审计都集中到一个入口，意味着这个入口的可用性直接决定业务可用性；同时它也引入了额外的延迟，尤其当内容检测被放在关键路径上时，延迟会随检测深度增长。集中化带来的收益与风险，需要在架构阶段就一起评估。
三类是策略漂移。MCP 网关与 Agent 网关的核心价值是权限治理，而权限治理的有效性取决于策略是否准确、是否随业务变化更新。工具清单会变、角色会变、外部合作伙伴会变，如果策略更新依赖人工比对，网关会很快退化成「记录一切但不拦任何东西」的日志系统。
中立思辨
需要辩证看待几件事。其一，五层划分是实践归纳，不同厂商与团队可能给出四层或六层，层数本身不重要，重要的是别把「有网关」等同于「有治理」。其二，四层应用层网关多为云服务，意味着请求需要离开企业环境才能被处理，这与部分行业的数据主权要求存在张力，网络层的出现正是对这一张力的回应，但其技术成熟度仍需时间验证。其三，各层边界正在互相渗透——模型网关开始做提示词防护，安全网关开始做模型路由，MCP 网关开始承载部分 Agent 编排职责，这种渗透会让选型时的功能对比变得混乱，企业应以「谁承担最终责任」而不是「谁功能多」来做判断。其四，把提示注入防护放在安全网关，存在一层结构性问题：注入的载荷往往藏在智能体自己检索到的内容里，而安全网关看到的是流量而非语义，仅靠流量侧检测难以完整覆盖间接注入。其五，网关层的集中化在安全上是双刃剑：它既收紧了控制点，也放大了故障半径，因此高可用与降级策略必须与功能一起设计，而不能后补。其六，多层网关叠加会显著抬高运维复杂度与延迟，对规模不大的团队，先做模型网关与 MCP 网关、把策略与审计跑通，可能比一次性铺五层更务实。
趋势研判
短期看，模型网关与 MCP 网关会先在企业里成为标配，因为它们直接解决成本与权限两个最痛的问题；中期看，随着多智能体协作进入生产，Agent 网关会从可选变成必要，尤其是当企业开始跨部门、跨组织委派任务时；长期看，真正决定分层走向的可能不是技术，而是责任归属——当一次智能体的错误动作造成损失，究竟由模型供应商、框架提供方、网关厂商还是部署企业承担，这个问题的答案会反过来决定各层网关需要保留哪些证据、执行哪些强制动作。
对正在做架构规划的团队，一个务实的起点是画一张「调用链地图」：从用户请求出发，经过模型、工具、其他智能体，一直到最终动作，把每一跳的凭据来源、可写范围与审计落点标出来。图上那些空白的、或者靠人手工维护的环节，就是当前最需要补的网关层。