从LLM Gateway到Agent Gateway：大模型网关架构演进的技术分析

引言

大模型网关的技术栈正在经历一次结构性变化。2025年以来，多个独立网关项目相继被收购或归档：TensorZero归档，Pydantic AI Gateway并入Logfire，Helicone被Mintlify收购后进入维护模式，Portkey被Palo Alto Networks纳入旗下。与此同时，LiteLLM继续保持较高的社区活跃度，Envoy AI Gateway发布v1.0成为CNCF背书的生产级选项，一批面向编码Agent的网关项目在GitHub上的星数增长迅速。

这些事件表面上是开源与商业的竞争结果，但更值得关注的是技术重心的转移。网关的核心职能正在从"协议转换和请求转发"转向"策略执行和多目标决策"。本文从成本治理、语义路由和MCP工具调用三个方向，分析这一转移在工程层面的具体表现和落地难点。

据The Business Research Company发布的《2026年全球LLM网关平台市场报告》，该市场规模预计从2025年的33.4亿美元增长到2026年的42.3亿美元，复合年增长率26.7%。市场在增长，但独立网关产品的生存空间反而在收窄，原因在于网关能力正在被云平台、安全平台和可观测平台吸收。这意味着网关的长期价值不在"网关"这个产品形态本身，而在于它承载的控制能力。

一、成本治理：从Token计费到状态一致性

1.1 现有方案的局限

大多数开源网关的成本治理围绕Token用量构建。调用完成后解析响应中的usage字段，按预设单价计算费用，从余额中扣减。这个流程在单租户、低并发场景下工作良好，但在多租户、高并发场景下会暴露两个问题。

第一，扣减时机与回写顺序不一致。如果先扣减后调用，调用失败时需要回滚，回滚失败会导致用户余额被错误扣除；如果先调用后扣减，并发请求可能同时读到相同的余额，导致超扣。第二，不同提供商的计费语义差异很大。Anthropic的prompt cache分为cache_creation_input_tokens和cache_read_input_tokens，单价不同；Google Gemini在超长上下文时可能触发阶梯定价；国内模型的usage结构和计费单位也各不相同。如果费控层只依赖OpenAI格式的usage字段，计费结果会和实际账单产生偏差。

根据Mavvrik《2026年AI成本治理报告》对396家企业的调查，62%的企业表示意外的AI支出在过去一年中实质性地改变了至少一项业务决策，33%的企业启动了紧急支出冻结。FinOps Foundation《State of FinOps 2026》报告显示，98%的受访者正在管理AI支出，这一比例在两年前仅为31%。这些数据说明，成本治理的粒度必须细化到单次调用和单个租户级别，传统月度账单和tag分摊的方式无法满足需求。

1.2 四阶段费控模型

我在开发LLM网关的费控模块时，经历了三次重构。第一版是简单的余额扣减，第二版加入了配额和倍率，第三版才把预扣和对账分开。最终确定的模型是四个阶段：预扣、执行、回写、对账。

text

css 复制代码

请求进入
  ↓
[预扣] 根据预估Token数和模型单价，冻结一部分余额
  ↓
[执行] 调用上游提供商，记录实际usage
  ↓
[回写] 按实际usage计算费用，解冻预扣金额，扣减实际费用
  ↓
[对账] 定期与提供商账单比对，修正偏差

预扣阶段的关键是"冻结"而非"扣减"。冻结金额是一个上界估计，实际费用在回写阶段确定。如果调用失败，直接解冻即可，不需要回滚已扣减的余额。执行阶段需要记录原始usage，包括所有提供商特有的字段。回写阶段按实际usage计算费用，这里需要一个协议无关的计费适配层，把不同提供商的usage结构归一化，同时保留各自的计费特殊性。对账阶段是很多网关忽略的环节，但它是保证长期账目一致的必要步骤。

这个模型不完美。预扣金额的估计如果偏小，会导致余额充足但调用被拒绝；如果偏大，会过度冻结用户余额，降低资金利用率。实际实现时，我采用动态预扣策略：根据历史调用的平均Token数估算，并设置一个安全系数。对于流式响应，usage可能在流结束后才完整，回写需要延迟到流关闭。

1.3 计费适配层的设计

计费适配层的核心是一个归一化结构：

python

ini 复制代码

class NormalizedUsage:
    input_tokens: int
    output_tokens: int
    cache_creation_tokens: int = 0
    cache_read_tokens: int = 0
    reasoning_tokens: int = 0
    # 其他提供商特有字段

每个提供商有一个适配器，负责把原始响应转换为NormalizedUsage，并附加该提供商的计费规则。计费规则不是简单的单价乘法，而是一个可配置的表达式，支持阶梯、倍率、时段等条件。这样，费控层不需要知道具体是哪个提供商，只需要处理归一化后的usage和计费规则。

二、语义路由：规则引擎与embedding的工程权衡

2.1 两种方案的对比

语义路由的目标是根据请求内容选择最合适的模型。摘要任务走便宜模型，代码任务走强模型，向量任务走Embedding模型。实现方式主要有两种：规则引擎和embedding分类。

规则引擎基于关键词、正则或请求元数据做决策。优点是决策可解释、延迟低、无需额外模型调用。缺点是维护成本随模型数量和路由维度指数增长。当你有10个模型、5个任务类型、3个租户等级时，规则组合会迅速变得难以管理。

Embedding方案用一个小模型对请求做语义分类，再映射到目标模型。优点是泛化能力好，能处理规则难以覆盖的边界情况。缺点是分类边界模糊时路由决策不可解释，且每次路由都需要一次额外的模型调用，增加了延迟和成本。

2.2 混合路由方案

我最终选择了一个混合方案：规则做兜底，语义做优化，两者通过权重融合。具体流程是：

text

css 复制代码

请求进入
  ↓
[规则引擎] 检查显式规则（如租户指定、模型白名单、成本上限）
  ↓ 未命中
[语义分类] 用轻量embedding模型计算任务类型概率分布
  ↓
[决策融合] 规则得分 * 0.4 + 语义得分 * 0.6
  ↓
选择目标模型

规则引擎负责硬约束，比如某个租户只能使用特定模型，或者单次调用成本不能超过阈值。语义分类负责软优化，在多个候选模型中选择最匹配的。权重可以根据实际效果调整，初期可以偏向规则，随着语义分类的准确率提升逐步增加其权重。

这个方案不完美，但在可控性和效果之间找到了平衡点。规则兜底保证了系统不会因为语义分类的错误而完全失控，语义优化则避免了规则引擎的维护爆炸。

2.3 多模型协作的方向

vLLM Semantic Router团队正在推动一个更有野心的方向：Mixture-of-Models。不是选择一个模型，而是让多个模型协作完成一次请求。例如，先用小模型做意图识别和路由，再用大模型做推理，最后用另一个模型做格式化和校验。这需要网关具备编排多个模型调用的能力，而不仅仅是转发单个请求。

从工程角度看，MoM对网关的状态管理提出了更高要求。一次用户请求可能对应多次模型调用，每次调用的usage都需要归集到同一个请求ID下，费控和可观测都需要支持这种父子调用的关系。目前大多数网关的usage模型是扁平的，不支持嵌套调用。

三、MCP网关：工具调用带来的架构扩展

3.1 从模型调用到工具调用

当Agent成为企业AI的主要形态时，网关的控制点从"模型调用"扩展到了"工具调用"。一个Agent的完整行为链包括：用户请求、模型推理、工具调用、结果处理、再次推理。如果网关只能看到模型调用这一环，它看到的只是冰山一角。

MCP（Model Context Protocol）解决的是Agent如何发现和调用外部工具的问题。但当Agent需要调用数十个MCP Server时，鉴权、限流、路由和可观测需要统一管理。这正是MCP网关的定位。

Envoy AI Gateway v1.0将MCP Gateway作为核心组件发布，支持对MCP Server的多路复用、路由和授权。Higress在网关层完成了工具搜索、鉴权、限流和可观测，Agent侧无需重复实现。Traefik Hub的Triple Gate架构则将API Gateway、AI Gateway和MCP Gateway三者统一。

3.2 MCP网关的架构位置

MCP网关位于Agent和MCP Server之间，承担以下职责：

text

arduino 复制代码

Agent
  ↓
[MCP Gateway]
  ├── 工具发现：聚合多个MCP Server的工具列表
  ├── 鉴权：验证Agent是否有权限调用该工具
  ├── 限流：控制工具调用的频率和并发
  ├── 路由：将工具调用转发到正确的MCP Server
  └── 可观测：记录工具调用的延迟、成功率、参数
  ↓
MCP Server A / B / C

这个架构的价值在于，Agent不需要知道有多少个MCP Server，也不需要处理鉴权和限流。网关作为统一入口，把工具调用的治理集中化。同时，MCP网关可以和LLM网关共享同一套费控和可观测基础设施，把模型调用和工具调用纳入统一的成本视图。

3.3 技术难点

MCP网关的最大技术难点是工具调用的状态管理。一次Agent请求可能触发多次工具调用，每次调用的结果会影响后续的模型推理。网关需要维护调用链的上下文，以便在费控和审计时还原完整的行为轨迹。这要求网关具备有状态的会话管理能力，而传统API网关通常是无状态的。

另一个难点是工具调用的权限模型。模型调用通常按租户和API Key授权，而工具调用可能需要更细粒度的权限控制，比如某个Agent只能调用查询类工具，不能调用写入类工具。这需要网关支持基于工具名称、参数和调用上下文的动态授权策略。

四、Agent控制平面：多目标优化问题

4.1 统一决策的四个维度

当成本、安全、路由、合规不再是四个独立的功能模块，而是统一决策的四个维度时，网关就从一个代理变成了一个控制平面。每一次模型调用或工具调用，都是一次在成本约束、安全策略、性能要求和合规要求之间的多目标优化。

成本维度关注余额、配额、单价和倍率。安全维度关注提示注入、凭证泄露、数据外泄和工具滥用。路由维度关注模型能力、延迟、可用性和负载。合规维度关注数据驻留、审计日志、内容过滤和许可证限制。

这四个维度不是独立的。一个请求可能因为安全策略而被迫路由到更贵的模型，也可能因为成本约束而牺牲一部分延迟。控制平面的任务是在这些约束下找到可行解，而不是单独优化某个维度。

4.2 架构层面的核心挑战

实现这样的控制平面，架构上需要解决三个问题。

第一是策略的表达和组合。策略不能硬编码在代码里，而需要一套配置模型或DSL，让运维人员可以定义和修改。策略之间可能存在冲突，比如安全策略要求使用某个模型，但成本策略禁止该模型，系统需要检测冲突并提供解释。

第二是决策的延迟。控制平面在请求路径上，每次决策都会增加延迟。如果策略评估需要多次数据库查询或模型调用，延迟会变得不可接受。实际实现时，需要把常用策略缓存在内存中，只对复杂策略做实时评估。

第三是可观测性。控制平面的决策需要被记录和解释，否则运维人员无法理解为什么某个请求被路由到了某个模型，或者为什么被拒绝。这要求网关在记录日志时，不仅记录结果，还记录决策依据。

4.3 结论

大模型网关的未来，不是成为一个更好的代理，而是成为一个更智能的控制平面。在这个控制平面上，成本、安全、路由、合规不再是四个独立的功能模块，而是统一决策的四个维度。对于正在开发网关的团队来说，这意味着一个关键的战略选择：是做一个更好的连接器，还是做一个更深的控制器。连接器的门槛正在降低，控制器的门槛正在升高。

从我的项目实践来看，控制点的设计决定了系统的可扩展性和治理能力。费控的状态一致性、路由的可解释性、工具调用的权限模型，这些问题的解决程度，决定了网关能否从"能用"走向"可运营"。

参考来源

The Business Research Company. 2026年全球LLM网关平台市场报告.
Mavvrik. 2026年AI成本治理报告.
FinOps Foundation. State of FinOps 2026.
Envoy AI Gateway v1.0 文档.
vLLM Semantic Router 项目文档.
RSAC 2026 会议资料.
awesome-ai-gateway 赛道分析.