AI-Gateway系列_kagateway-06Agentgateway

Introduction

Agentgateway是一个开源、高可用、高可扩展、企业级的数据面，可以在任何环境中为AI agents和工具提供AI连接能力。你可以使用kgateway作为控制面，在Kubernetes环境中快速启动并管理agentgateway proxy的生命周期。控制面会将Kubernetes Gateway API和kgateway自定义资源翻译成agentgateway数据面的代理配置。Agentgateway支持多种agent连接场景，包括以下内容：

  • Agent-to-agent（A2A）
  • Model Context Protocol（MCP）
  • 将 REST API 用作 agent 原生工具
  • 面向云端与本地大语言模型（LLM）的 AI 路由
  • 支持 Gateway API Inference Extension 项目

可获得企业级的安全性、可观测性、弹性、可靠性与多租户能力。通过这些能力，agentgateway能弥补传统网关代理或像MCP、A2A等协议的常见不足。借助 agentgateway，你可以快速采用并扩展你的agentic AI环境。

Why agentgateway?

为了理解agentgateway 的优势以及你为何应该使用它，我们需要介绍 agentic AI 环境的工作方式、其面临的挑战，以及为何传统网关无法解决这些挑战。

About MCP and A2A

随着agentic AI 改变组织构建与交付应用的方式，组织面临着快速采用新技术和互操作协议的挑战，以在碎片化环境中连接 agents 和工具。由于AI agents和工具可能基于不同框架构建，并访问不同的 API和数据源，标准化agents与工具之间的通信方式对于加速agent开发至关重要。Model Context Protocol（MCP）和 Agent-to-Agent（A2A）是用于在agents与工具之间实现通信的主要协议。

  • MCP帮助从大型语言模型（LLMs）检索与交换上下文，并将 LLMs 连接到工具。
  • A2A 则用于在多个 agents 之间处理长时任务与状态管理。

MCP和A2A都是JSON-RPC协议，定义了agent 如何描述其意图、如何调用工具，以及如何将任务交给其他 agents。

Challenges with MCP and A2A

虽然MCP和A2A定义了agents与工具之间的RPC通信协议，但它们目前并未解决真实企业级环境的问题。Agents 通常不会孤立运行。它们需要与以下对象交互：

  • 其他 agents（A2A）
  • 内部系统（agent-to-tool）
  • 外部模型或基础模型（agent-to-LLM）

这些交互往往是动态的、多模态的，并跨越组织和数据边界。这种长生命周期的交互带来新的风险与复杂性，包括：

  • 安全性：如何处理跨工具与服务的身份认证、授权与审计？
  • 治理：如何在自主流程中强制执行数据驻留、访问控制等策略？
  • 可观测性：如何洞察 agents 在做什么、何时做以及为何做？
  • 可扩展性与性能：如何保证低延迟，同时安全地处理重试、超时和失败？

Agentgateway 从设计之初就针对这些问题：为所有MCP与A2A的通信提供内置的安全、治理与可观测能力。

Traditional gateways vs. agentgateway

传统API网关、反向代理与AI网关（如 Envoy）是为REST 微服务架构构建的：网关接收短生命周期的HTTP请求 → 选择后端 → 转发请求。这类场景通常不需要会话上下文或持续连接状态。

MCP则相反，它是基于JSON-RPC的有状态协议，需要：

  • 长生命周期会话
  • 持续的请求与响应
  • 请求与响应必须绑定到同一会话上下文
  • MCP 服务器可以异步向客户端发送消息

这使得维护所有状态会话变得困难。一个简单的客户端请求（例如列出所有可用工具）可能需要：

  • 代理访问多个 MCP 后端服务器
  • 聚合结果
  • 返回一个一致的响应

此外，客户端可能无法访问服务器上的所有工具，因此代理必须能够：

  • 基于会话动态调整响应
  • 将每个客户端会话映射到其可访问的后端服务器

传统网关并未设计用于：

  • 处理会话感知
  • 消息感知
  • 状态性双向通信
  • 高资源消耗的 AI 交互

因此在面对 agentic AI 场景时会迅速出现性能下降甚至失败。而 agentgateway 则能够在任何环境中连接 AI agents、MCP 工具服务器和 LLM 提供商，实现：

  • 安全
  • 可扩展
  • 有状态
  • 企业级治理、可观测性与多租户

从而解决传统网关与 MCP/A2A 自身的不足，让你可以快速构建与扩展 agentic AI 环境。

Key features

Agentgateway 提供以下关键特性：

Unified data plane

Agentgateway 是用于管理 agent 连接的统一数据面，支持 MCP、A2A 等 agent 协议，

并可将现有 REST API 集成为 agent 原生工具。

Highly performant

Agentgateway 由 Rust 构建，可处理任意规模，针对以下方面进行了优化：

  • 高吞吐量
  • 低延迟
  • 可靠性
  • 稳定性

尤其适合长生命周期与 fan-out 模式的连接。

Any agent framework

兼容所有支持 MCP 和 A2A 的 agent 框架，包括：

  • LangGraph
  • AutoGen
  • kagent
  • Claude Desktop
  • OpenAI SDK

你还可以使用 agentgateway将REST API 暴露为 agent 原生工具。

Platform-agnostic

可以在任何环境运行：

  • 裸金属
  • 虚拟机
  • 容器
  • Kubernetes

Multiplexing and tool federation

Agentgateway 提供单一端点来联邦多个 MCP 后端服务器，并可以基于客户端虚拟化工具服务器。

Automatic protocol upgrades/fallbacks

Agentgateway 可以协商并优雅地处理协议升级与回退，避免 MCP/A2A 协议演进时客户端或服务器失败。

Authentication and authorization

内置：

  • JWT 认证
  • RBAC 授权

可用于控制对 MCP 服务器、工具和 agents 的访问，并防止工具投毒攻击（tool poisoning）。

Built-in observability

提供内置指标与追踪功能，用于监控 MCP 客户端与后端工具的交互。

Self-service portal

Agentgateway 提供内置的开发者门户，允许 agent 开发者在任何环境（裸金属、VM、容器、Kubernetes）中轻松：

  • 连接
  • 发现
  • 联邦
  • 集成
  • 保护

agents 和工具。

Open source

Agentgateway 是开源的，并采用 Apache 2.0 许可证。

Conformant to the Gateway API project

符合 Kubernetes Gateway API 项目标准，可以与任何 Gateway API 实现一起作为网关使用。

Dynamic configuration updates

Agentgateway 可通过 xDS 接口进行无停机更新。

Policies

Agentgateway 提供策略来管理、转换和保护 MCP 与 A2A 后端的流量。基于其 schema，你可以配置以下策略。每个策略可以单独使用或组合使用。

Traffic management

  • Header manipulation：添加、设置、删除 HTTP 请求与响应头
  • Redirect：重定向到不同的 scheme、authority、path 或状态码
  • Rewrites：在转发前重写 authority 或路径
  • Direct response：直接返回固定响应（body + status），不转发至后端

Security

  • CORS
  • MCP Authorization
  • MCP Authentication（使用外部提供商，如 Auth0、Keycloak）
  • A2A（启用 agent-to-agent 功能）
  • AI（为使用 AI backends 的路由附加 AI 配置）
  • Backend TLS（配置证书、信任根等）
  • Backend Auth（passthrough、key、GCP、AWS 等）
  • Local Rate Limit（本地限流）
  • Remote Rate Limit（分布式限流）
  • JWT Auth
  • External Authorization（extAuthz）

Resiliency

  • Request mirroring（请求镜像）
  • Timeout（请求与后端超时）
  • Retries（重试次数、退避、触发重试的响应码）

Architecture

Agentgateway resource configuration

了解如何在 kgateway 中配置 agentgateway 资源。

Agentgateway 资源描述在 kgateway 中由以下方式配置
Bind将网关监听器（gateway listeners）与特定网络端口关联的一组端口绑定。Bind 拥有一个唯一键，格式为：port/namespace/name，例如：8080/default/my-gateway；其值为端口号，例如 8080。根据 Gateway 以及所有 Gateway listeners 或 ListenerSets 中的唯一端口自动创建。
Port要监听的端口。每个端口有自己的一组 listeners，而每个 listener 又有自己的 routes、policies 和 backends。由 Gateway 或 ListenerSet 中的 ports 定义。
Listener定义 agentgateway 如何接收与处理传入请求的监听器配置。包含：• 监听器的唯一键• 与 Gateway listener section name 对应的名称• 所属 bind 的 bind key• Gateway 名称• 接收流量的 hostname• 协议（HTTP、HTTPS、TCP、TLS）• TLS 配置详情，如证书和终止方式每个 listener 都可以拥有自己的一组 routes、policies 和 backends。由 Gateway 或 ListenerSet 中的 listeners 定义。
Route定义 agentgateway 如何将传入请求路由到正确 backend 的路由规则。包含：• 唯一键：namespace.name.rule.match• 路由名称：namespace/name• 所属 listener 的 listener key• 源路由中的 rule 名称• 来自 Gateway API 路由资源的流量匹配条件（path、headers、method、query params）• 请求与响应的转换过滤器，如 header 修改、重定向、重写、镜像等 policies• 启用负载均衡与健康检查的目标 backend 服务• 提供服务的 hostnames来自 HTTPRoute、GRPCRoute、TCPRoute、TLSRoute 等路由资源。
Backend流量路由到的后端目标。与其他资源不同，backend 是全局资源（非 per-gateway），适用于所有使用 agentgateway 的 Gateways。每个 backend 有唯一名称：namespace/name。backend 类型包括：• AI（模型特定的 LLM 提供商配置）• 静态主机名或 IP 地址• 虚拟 MCP 服务器，包括 A2A 场景由 Services 和 Backends 定义。
Targetbackend 的详细内容，例如 MCP backend 中的工具列表。由 Services 和 Backends 定义。
Policiesagentgateway 如何处理传入请求的策略，包括：• Request Header Modifier：添加、设置、删除请求头• Response Header Modifier：添加、设置、删除响应头• Request Redirect：重定向到不同 scheme、authority、path 或 status code• URL Rewrite：重写 authority 或 path• Request Mirror：镜像部分请求到另一个 backend• CORS：跨域配置（origins、headers、methods、credentials）• A2A：启用 agent-to-agent（A2A）功能• Backend Auth：为 backend 设置身份认证（passthrough、key、GCP、AWS 等）• Timeout：设置请求与 backend 的超时• Retry：重试次数、退避策略、触发重试的响应码

Feature enablement

要使用agentgateway 的功能，你必须在kgateway中启用 agentgateway(–set agentgateway.enabled=true)。此外，如果需要路由到AI 服务，需要同时启用 AI Gateway 功能。

Leave a Reply