AI 网关能解决什么、不能解决什么：一个 Agent 平台工程师的架构思考

做过一个简单的 LLM 网关之后，我才真正想清楚这一层能扩展到哪里

从一个统一入口说起

最开始，我只是想做一个统一入口。

去年为内部 Agent 平台搭 AI 网关的时候，初衷很简单：为了隔离不同的业务方接入，需要统一入口。多租户鉴权、模型路由、限流、SSE 流式转发——功能不复杂，但完全够用。

后来从架构师思维角度考虑接入的模型变多、业务线增加，一些问题应该会暴露出来：某个模型限流了没有告警、不同业务线的用量不透明、新接的供应商 API 格式又不一样得单独适配……

我开始意识到，这搭的不只是一个转发代理，而是整个 Agent 平台治理层的雏形。只是做得不完整。然后就对比 Higress、LiteLLM、One-API/New-API、Portkey 等主流方案。从简单版本出发，参考主流的技术方案，重新思考这个产品应该如何更好的理解和设计。

先画清楚这一层在哪里

在 Agent/大模型应用的技术栈里，AI 网关的位置是这样的：

统一API契约业务层（Agent/工作流）Dify·Coze·LangGraph·自研AgentAI网关（AIGateway）鉴权·路由·限流·降级·计量·监控·缓存OpenAI私有模型国产模型/ASR/向量库

关键点是独立。它不是 Agent 框架里的一个 try-catch，也不是某个工作流节点的配置项，而是一个有自己进程、自己配置、自己监控面板的独立服务。

最容易踩的坑，就是把本该网关做的事散落在业务代码里。

从"够用"到"完整"：中间差了什么

我当时做的版本，核心定位是转发代理——请求进来，鉴权通过，发给对应模型，结果返回。

这个思路在需求简单时没问题。但当业务开始扩展，就会发现这一层越来越接近治理平台——请求进来，先判断该不该放行、该发给谁、发失败了怎么办、这次调用花了多少钱、整体健康状态如何。

两种思路做出来的系统，复杂度差了一个数量级。

几个具体的差距：

• 监控是零：只有基础日志，没有 Prometheus 指标，没有 TTFT（首 Token 延迟）追踪，没有模型级成功率大盘
• 故障处理很原始：模型返回错误就直接透传，没有自动切换备用模型
• 成本不透明：知道"今天总共花了多少"，不知道"哪个业务线的哪个 Agent 花了多少"
• 路由是静态的：配置写死，没有按成本、灰度、能力的动态路由

这个设计其实是架构演进还没走到哪一步，但想清楚这个差距，是设计更完整方案的前提。

这六类能力，为什么最终都会沉淀到 AI 网关

AI网关承载安全合规可观测性成本计量流量治理路由协议适配

AI Gateway 的演进，走的都是同一条路：把横向治理能力从 Agent 和业务代码里抽出来，沉淀到一个独立的层。以下六层能力，每一层都在解决同一个问题：这件事放在业务代码里会怎样，放在网关里又能解决什么。

1. 协议适配：屏蔽供应商差异

协议适配真正抽象掉的，不是接口格式，而是业务代码对供应商的感知。

不同模型厂商的 API 格式不同——参数命名不一样，流式协议不一样，Token 计数方式不一样，错误码含义不一样。

做 SSE 流式转发的时候感受最深：有的厂商用标准 SSE，有的用自定义分隔符，有的在流式传输中断后能重连，有的直接断掉。如果不在网关层统一抹平这些差异，每个 Agent 的业务代码里都要写一套厂商适配逻辑——写完之后你会发现，十个 Agent 里有八套差不多但又不完全一样的适配代码，维护成本极高。

网关在这一层的职责：对上暴露统一 API 契约，对下做协议转换和格式归一化。Agent 只需要按一种格式调用，网关负责转换参数。

2. 路由：请求该发给谁

路由真正解决的，不是请求发给谁，而是把模型选择权从业务代码收回到平台层。

最基础的路由是静态映射——配置文件里写死"GPT-4 发 OpenAI，Qwen 发阿里"。简单需求下够用，但生产环境中可能会遇到更复杂的动态路由，比如：

• 成本路由：简单对话用便宜模型，复杂推理用贵模型
• 灰度路由：10% 流量切到新模型，观察效果后再决定全量切换
• 能力路由：请求带了图片就只能路由到支持多模态的模型
• 地域路由：国内用户走国内模型（合规需求）

从 New-API 的设计来看，多 Key 轮询和加权随机分配对可用性的提升很显著——这种设计在需求简单阶段容易被跳过，但一旦供应商稳定性出问题，会立刻感受到它的缺失。

3. 流量治理：限流、熔断、降级

流量治理保护的不是某个模型，而是整个平台的稳定性。

这一层跟传统微服务治理逻辑类似，但 AI 场景有几个特殊之处：

限流维度更复杂。 不只是 QPS，还要按 Token 数限流（供应商的限制就是按 Token 来的）、按租户限流（不同业务线配额不同）。租户级限流容易做，Token 级限流才是 AI 场景下最关键的限流维度。

故障判定更模糊。 传统 API 挂了就是返回 5xx。但 LLM 调用可能返回 200 状态码，内容却是空的、乱码的、或者输出明显异常——这种"软失败"（HTTP 层面成功但语义层面异常）需要更精细的健康检测逻辑，不能只靠状态码判断。

降级不只是主备切换。 可以有多个层次：模型降级（贵模型不可用切便宜模型）、能力降级（实时推理不可用返回缓存）、体验降级（流式不可用降级为非流式）、兜底响应（所有模型都挂了返回预设提示）。

4. 成本计量

计量不是为了统计，而是为了治理——知道钱花在哪里，才能管控它。

这是 AI 网关跟传统 API 网关差异最大的一层。

传统 API 的成本是基础设施成本，按部门分摊就行。AI 能力的成本是按调用量实时产生的，不同供应商的计费口径还不统一——OpenAI 按 Token 分 input/output 计价，语音服务按时长，搜索按查询次数。

网关需要在每次调用链路上打好标签（tenant_id、business_line、agent_id），把各家供应商的计费口径统一到可比较的单位，然后输出多维度成本报表。

"知道今天花了多少钱"和"知道哪个业务线的哪个 Agent 花了多少"是两件事——前者靠汇总日志就能做，后者需要在调用链路上系统地打标签。这个差距看起来小，但对于需要做预算管控、对账报表和成本分摊的团队来说是刚需。

5. 可观测性

可观测性不是为了画 Grafana 大盘，而是为了让模型服务变成可以运营的基础设施。

AI 场景的可观测性有几个独特指标，跟传统 API 监控不完全一样：

• 首 Token 延迟（TTFT）：流式场景下用户体感的核心指标，比总延迟更重要
• Token 消耗速率：不只是 QPS，直接关联成本
• 模型级成功率：不同模型、不同供应商各自的可用性，需要分开统计
• 配额水位：各供应商的 API 配额剩余情况，接近上限前需要告警

完整的可观测性需要 Prometheus 指标采集 + Grafana 大盘 + 分级告警的完整链路。这一层在简单需求阶段最容易被跳过，但也是系统规模扩大后最先暴露问题的地方。

6. 安全合规

Prompt 注入检测、敏感信息脱敏（PII 过滤）、审计日志、多租户数据隔离。这一层在 to B 场景和出海场景尤其重要，通常是合规要求的硬性约束，也是网关作为统一入口天然适合承载的能力——业务代码里做分散，集中在网关做可审计。

MCP 工具网关：Agent 场景正在出现的第七层

MCP（Model Context Protocol）的普及，给 AI 网关引入了一个新问题：工具的发现、鉴权和执行，该由谁来管？

Agent 调用外部工具（搜索、数据库、代码执行）的过程，本质上是另一种 API 调用。如果工具调用分散在各个 Agent 的业务代码里，你会遇到和 LLM 调用同样的问题——鉴权分散、没有审计、用量不可见。

MCP Gateway 的核心职责：

• 工具发现的统一入口：Agent 通过网关发现可用工具，网关管理工具注册和版本
• 工具调用的鉴权与 RBAC：哪个 Agent、哪个租户可以调用哪些工具，在网关层集中管控（Kong、Portkey、Bifrost 已实现 per-key 工具白名单）
• 工具执行的审计日志：工具调用记录统一沉淀，而非分散在各 Agent 日志里

目前各方案支持情况（截至 2026 年 7 月）： Kong AI Gateway、LiteLLM、Portkey Gateway 2.0、Bifrost 已原生支持；Envoy AI Gateway 在 Roadmap 中；BricksLLM、Helicone、One-API 尚未支持。

如果你正在建设的是面向 Agent 的平台基础设施，MCP 支持应作为选型的一票否决项——缺少这一能力意味着工具治理只能下沉到业务代码，和 LLM 调用在网关层统一管理的初衷背道而驰。

这三类能力，不应该放进 AI 网关

以上是"网关范围内"的事。但在实际的 AI 平台建设中，还有几类重要需求——不是网关做不到，而是不应该做。把它们塞进网关，会模糊职责边界，最终让网关变成难以维护的大泥球。

所有通用 AI 网关方案都没有覆盖这几类能力——不是遗漏，而是有意为之，因为它们属于不同的工程领域。

效果评估

网关关心的是"请求转发成功了没有"，不关心"这个模型的输出质量好不好"。

但在实际业务中，你需要知道：这家 ASR 供应商的字错误率（Character Error Rate）是多少？这个搜索模型的排序质量（NDCG）达标吗？换了一家声纹供应商之后等错误率（Equal Error Rate）是升了还是降了？

这些评测需要独立的评估工程体系——离线评测集、在线 A/B 测试流水线、供应商横向对比报告。这跟网关的技术领域完全不同，不应该也不可能塞进网关里做。

成本归因到业务线

网关能做到"按租户统计 Token 消耗"，但做不到"打通供应商账单数据，跟公司内部的财务系统和业务线组织架构对齐，输出可用于预算审批的成本分摊报表"。

后者是强业务定制需求：每家公司的业务线划分不同、财务流程不同、预算审批链路不同。通用网关产品不会做这么深，也做不到——因为它不知道你公司的组织架构长什么样。

网关提供的是原始计量数据（谁在什么时间调用了什么模型、消耗了多少 Token），成本归因系统消费这些数据，结合业务上下文做聚合和分摊。两者是上下游关系，不是同一个系统。

运营自动化

"监控发现供应商 A 最近延迟上升 → 自动调整路由权重降低 A 的流量占比 → 生成周报通知相关负责人 → 如果连续三天不恢复自动触发供应商切换流程"——这种端到端的运营自动化，涉及的是工作流编排（n8n / Airflow / Argo Workflows），不是网关的职责。

网关是这个链条里的数据源和执行终端——它产出监控数据，也接受路由策略变更的指令——但"根据什么条件触发什么动作"这个决策逻辑，应该在编排层。

选型

理清了"网关该做什么、不该做什么"之后，选型就相对清晰了。

性能数据说明： 表中 RPS 数据来源于 Kong AI Gateway Benchmark Report（2026），测试条件为 12 核 CPU、400 并发。Bifrost 数据来源于其官方文档，测试条件不同，不直接可比。实际业务场景中，网关吞吐通常不是瓶颈（模型响应延迟是主导），这些数据主要反映架构层面的量级差异。

什么时候需要自研？ 通常是因为以下情况之一：深度业务集成需求（成本归因打通内部财务系统）、现有基础设施跟可选方案技术栈不兼容、或数据安全合规约束（金融、政务场景对数据流转路径有严格要求）。

自研不意味着从零开始。更合理的做法是基于轻型开源方案二次开发，复用已有的协议适配和基础路由能力，重点投入在自己业务真正需要定制的部分。

AI 网关与 Agent 框架的边界

Agent 框架（LangGraph / Dify / Coze）管的是**"做什么"**——用什么工具、按什么顺序、如何决策。

AI 网关管的是**"怎么安全、高效、可控地调用底层能力"**——请求发给谁、发失败了怎么办、花了多少钱、系统是否健康。

一句话：Agent 框架管业务执行，AI 网关管能力治理。

两者是分层协作关系。就像微服务架构里，业务服务不应该自己管限流熔断，而是交给 API 网关或 Service Mesh 来做。Agent 场景下的逻辑完全一致——只是治理的对象从传统 API 变成了 LLM 调用，治理的维度多了 Token 计量和模型级可观测性。

写在最后

做一个"够用"的网关不难，难的是在需求还简单的时候就想清楚这一层能扩展到哪里、哪些事情本来就不属于这一层。

这篇文章也算是一次反思——以架构师的视角重新审视这件事，下次需求复杂起来的时候，知道该往哪个方向补。

扩展阅读

AI 网关设计与选型

Higress AI 网关文档[https://higress.cn/docs/latest/user/ai-proxy/] — 功能最完整的开源方案，插件架构和路由策略设计值得参考，即使不用 Higress 也建议读一下它的设计思路

Envoy AI Gateway[https://github.com/envoyproxy/ai-gateway] — Envoy 官方的 AI 网关项目，Kubernetes Gateway API 原生，适合已在用 Envoy 生态的团队 LiteLLM 官方文档[https://docs.litellm.ai/] — Python 生态里供应商覆盖最广的统一接入层，Proxy 模式的配置示例很直接

New-API GitHub[https://github.com/Calcium-Ion/new-api] — One-API 的社区分支，Go 实现，多渠道管理和计费模型可以直接参考

为什么 AI Agent 需要新的网关（Solo.io）[https://www.solo.io/blog/why-do-we-need-a-new-gateway-for-ai-agents]— 从 Agent 视角讲网关演进，对比了传统 API 网关在 AI 场景的不足

Why AI Gateways Are Becoming a Critical Layer in Enterprise AI Platforms（Forbes）[https://www.forbes.com/councils/forbestechcouncil/2026/05/12/why-ai-gateways-are-becoming-a-critical-layer-in-enterprise-ai-platforms/]— 企业级视角，侧重治理和合规

Kong AI Gateway Benchmark Report（Kong，2026）[https://konghq.com/blog/engineering/ai-gateway-benchmark-kong-ai-gateway-portkey-litellm]— Kong、Portkey、LiteLLM 的吞吐量与延迟对比，本文性能数据来源

Bifrost AI Gateway（GitHub）[https://github.com/maximhq/bifrost]— 2025 年新兴 Go 实现，MCP 为核心功能，性能数据参见官方文档

可观测性

OpenTelemetry Semantic Conventions for LLM[https://opentelemetry.io/docs/specs/semconv/gen-ai/] — OTel 官方的 GenAI 语义约定，定义了 LLM 调用该采集哪些标准指标，是构建 AI 可观测性的基础参考

Prometheus + Grafana 监控 LLM 应用实践[https://www.cnblogs.com/alisystemsoftware/p/19016738] — 阿里云团队的实践文章，指标设计和大盘建设部分可以直接参考

流量治理与成本管理

Token-Based Rate Limiting for LLMs[https://docs.litellm.ai/docs/proxy/rate_limit] — LiteLLM 文档里对 Token 级限流的配置说明，比 QPS 限流更贴近 AI 场景的实际需求

Portkey AI Gateway 架构概览[https://portkey.ai/docs/product/ai-gateway] — 托管方案里文档最完整的，成本追踪和请求日志的设计思路对自建方案也有参考价值