返回博客列表

Agent 爆发之后，谁来做流量网关？agentgateway 的答案

2026-05-28T07:42:00+08:00
AgentagentgatewayMCPA2AGatewayRustKubernetesLinux Foundation

Agent 爆发之后，谁来做流量网关？agentgateway 的答案

API Gateway 这个东西，从 Nginx 到 Kong 到 Envoy，已经卷了二十年。但当你开始部署 AI Agent——一个 Agent 要调 LLM、调工具、还要跟别的 Agent 通信——你会发现传统网关根本不够用。

LLM 请求不是普通 HTTP 调用，它有 streaming、有 token 计费、有 prompt 注入风险。MCP 工具调用不是 REST API，它有自己的协议和传输层。Agent-to-Agent 通信更是全新领域，A2A 协议才刚出来。

agentgateway 就是来填这个空白的。Rust 写的，2.8k stars，146 个贡献者，已经是 Linux Foundation 项目。它自称"第一个完整的 Agentic AI 连接方案"。

本文提纲

  1. Agent 时代为什么需要新网关
  2. agentgateway 的三层架构
  3. LLM Gateway：统一模型调用
  4. MCP Gateway：工具联邦
  5. A2A Gateway：Agent 间通信
  6. Inference Routing：智能推理路由
  7. Guardrails：多层防护
  8. Kubernetes 原生部署
  9. 和传统 API Gateway 的本质区别

Agent 时代为什么需要新网关

传统 API Gateway 解决的核心问题是：请求路由、负载均衡、限流、认证。

但在 Agent 系统里，你要面对的新问题：

多协议并存。一个 Agent 同时要跟 LLM（OpenAI/Anthropic API）、工具（MCP 协议）、其他 Agent（A2A 协议）通信。三种不同的协议，传统网关只能处理 HTTP。

流式响应。LLM 的输出是 streaming 的，一个请求可能持续几十秒。传统网关的请求-响应模型不适合。

Token 计费。不是按请求量收费，是按 token 收费。你需要预算控制、花费追踪、跨 provider 的成本优化。

安全边界不同。传统安全关注的是"谁能访问哪个 API"。Agent 安全关注的是"这个 prompt 有没有注入风险"、"这个工具调用是否越权"、"Agent 之间能不能互相信任"。

Agent 发现。在微服务里，服务发现靠 DNS 或 service mesh。在 Agent 系统里，Agent 怎么知道另一个 Agent 能做什么？A2A 协议定义了 capability discovery，但网关要能代理这个发现过程。

agentgateway 的思路：用 AI 原生协议（MCP + A2A）重新设计网关，而不是在传统网关上打补丁。

agentgateway 的三层架构

graph TB
    subgraph Agents
        A1["Agent 1"]
        A2["Agent 2"]
        A3["Agent 3"]
    end

    subgraph AgentGateway
        LLM["LLM Gateway
OpenAI / Anthropic / Gemini / Bedrock"]
        MCP["MCP Gateway
Tool Federation / OAuth"]
        A2A["A2A Gateway
Capability Discovery / Task Collab"]
        IR["Inference Routing
GPU / KV Cache / LoRA"]
        GR["Guardrails
Regex / Moderation / Webhooks"]
        SEC["Security
JWT / OAuth / RBAC / TLS"]
    end

    subgraph Backends
        B1["LLM Providers"]
        B2["MCP Servers"]
        B3["Other Agents"]
        B4["Self-hosted Models"]
    end

    A1 --> LLM
    A2 --> MCP
    A3 --> A2A
    LLM --> B1
    MCP --> B2
    A2A --> B3
    IR --> B4
    GR --> LLM
    SEC --> LLM

六个核心模块，三层连接：Agent → Gateway → Backend。

关键设计决策：所有协议在 Gateway 层统一处理，Agent 不需要知道后端是什么协议。你用 OpenAI SDK 调 Gateway，Gateway 帮你转发到 Anthropic；你用 MCP 协议调工具，Gateway 帮你做 tool federation。

LLM Gateway：统一模型调用

这是最基础的功能，也是最容易理解的。

统一 API：所有 LLM provider 都暴露成 OpenAI 兼容的 API。你的代码只需要改一个 base URL，就能在不同 provider 之间切换。支持 OpenAI、Anthropic、Gemini、AWS Bedrock、Azure AI Foundry 等。

预算和花费控制：这是生产环境最关心的。你可以设 token 预算上限，超了就拒绝请求。可以按用户、按项目、按 Agent 追踪花费。

Prompt 增强：在请求发给 LLM 之前，Gateway 可以自动注入 system prompt、添加 safety instruction、做 prompt 模板替换。

负载均衡和故障转移：同一个请求可以配多个后端 provider，一个挂了自动切到另一个。对于高可用场景，这是刚需。

MCP Gateway：工具联邦

这部分是 agentgateway 最有价值的创新。

工具联邦（Tool Federation）：一个 MCP Server 只暴露有限的工具。但你的 Agent 可能需要调很多工具。Gateway 层可以把多个 MCP Server 聚合起来，暴露一个统一的工具列表给 Agent。

多传输支持：MCP 协议支持 stdio、HTTP、SSE、Streamable HTTP 四种传输方式。Gateway 全部支持，而且可以在不同传输之间做桥接。

OpenAPI 集成：你有现成的 REST API，想让 Agent 调用？Gateway 可以把 OpenAPI spec 自动转成 MCP 工具定义，Agent 不需要知道底层是 REST 还是 MCP。

OAuth 认证：工具调用需要认证？Gateway 内建了 OAuth 支持。最新版本（v1.3.0-alpha.1）还加入了 Okta 作为一等公民的 MCP 认证 provider。

内置 Playground：agentgateway 有一个 Web UI，你可以直接在浏览器里试 MCP 工具调用、看请求响应、调试工具行为。这对开发阶段非常有用。

A2A Gateway：Agent 间通信

这是最前沿的部分。A2A（Agent-to-Agent）协议是 Google 提出的，用于解决 Agent 之间的互操作问题。

能力发现（Capability Discovery）：Agent A 想找能做"数据分析"的 Agent，Gateway 帮它发现 Agent B 有这个能力。

模态协商（Modality Negotiation）：Agent A 只能输出文本，Agent B 能接收文本和图片。Gateway 帮它们协商出一个双方都能理解的通信格式。

任务协作（Task Collaboration）：Agent A 把一个子任务交给 Agent B，Gateway 负责跟踪任务状态、转发结果、处理超时。

在 v1.3.0-alpha.1 版本中，A2A 已经成为一等公民的 backend 类型，说明这个功能正在快速成熟。

Inference Routing：智能推理路由

这个功能面向自托管模型的场景。

如果你在公司内部部署了自己的 LLM（用 vLLM、TensorRT-LLM 等），你需要一个路由层来决定每次推理请求发给哪个模型实例。agentgateway 的 Inference Routing 基于 Kubernetes Gateway API 的扩展实现，路由决策可以考虑：

  • GPU 利用率：哪个实例还有算力？
  • KV Cache：哪个实例已经缓存了相关的 context？
  • LoRA Adapter：哪个实例加载了你需要的微调权重？
  • 队列深度：哪个实例排队最短？

这基本上是把 service mesh 的智能路由搬到了 AI 推理领域。

Guardrails：多层防护

安全不是单一层次的事，agentgateway 用了多层防护：

Regex 过滤：最基础的，用正则匹配 prompt 和 response 中的敏感内容。

OpenAI Moderation：直接调 OpenAI 的 moderation API 做内容审核。

AWS Bedrock Guardrails：如果你用 AWS，可以直接复用 Bedrock 的 Guardrails 配置。

Google Model Armor：Google Cloud 的内容防护。

自定义 Webhook：以上都不满足？写一个 webhook，Gateway 会把每个请求先发给你，你决定放行还是拒绝。

五层防护叠加，基本覆盖了从"简单过滤"到"复杂业务规则"的全场景。

Kubernetes 原生部署

agentgateway 不只是一个 standalone binary，它有完整的 Kubernetes 集成。

内置 Controller：不需要额外装 Istio 或其他 service mesh。agentgateway 自带 Kubernetes controller，可以动态发现和配置后端。

Gateway API 支持：使用 Kubernetes Gateway API 的标准 CRD（Custom Resource Definition）来配置路由。如果你已经熟悉 Gateway API，上手成本几乎为零。

Helm Chart：cr.agentgateway.dev/charts/agentgateway 一行命令装好。

Docker 镜像：cr.agentgateway.dev/agentgateway:v1.2.1 拉下来就能跑。

两种部署模式：

  • Standalone：本地开发或简单部署，一个 binary 搞定
  • Kubernetes：生产环境，用 controller + Gateway API 动态管理

和传统 API Gateway 的本质区别

维度 传统 API Gateway agentgateway
核心协议 HTTP/HTTPS/gRPC MCP + A2A + OpenAI API
路由目标 微服务 / API LLM Provider / MCP Server / Agent
计费模型 按请求 / 按带宽 按 Token
安全模型 API Key / OAuth Prompt 过滤 / RBAC / 工具权限
流式支持 有限 原生 streaming
工具发现 N/A MCP Tool Federation
Agent 发现 N/A A2A Capability Discovery
推理路由 N/A GPU / KV Cache / LoRA
项目背景 各厂商 Linux Foundation

最关键的区别在第一行：传统网关的协议假设是 HTTP，而 agentgateway 的协议假设是 MCP 和 A2A。这不是功能增量的区别，是架构范式的区别。

技术栈：Rust（代理核心）+ Go（Kubernetes controller）。Rust 写的代理性能极高，Go 写的 controller 跟 Kubernetes 生态无缝集成。Rust edition 2024，最低 Rust 1.90，项目非常新。

背景：由 Blacksmith 赞助开发，核心贡献者 howardjohn 是 Istio 的前 maintainer。有 Istio 背景的人来做 AI 网关，service mesh 的经验直接复用。

项目治理：已经进入 Linux Foundation，有正式的 TSC（Technical Steering Committee）、贡献者指南、行为准则。不是个人项目，是社区治理的开源项目。

当前最新稳定版 v1.2.1（2026-05-15），alpha 版 v1.3.0-alpha.1（2026-05-23）。迭代速度很快，两周一个版本。

agentgateway 解决的是一个真实存在的痛点：当你的 Agent 系统从 demo 走向 production，你需要一个"AI 原生的 Nginx"。它不替你选模型、不替你写 prompt，但它把模型调用、工具连接、Agent 通信这三条线统一管起来，加上安全、可观测、治理。

如果你在做 Agent infra，值得花半小时跑一下 quickstart。

作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。

觉得文章不错？分享给更多人！