Agent Gateway（智能体网关）

据 agentgateway 官方文档的梳理，传统 API 网关、反向代理与 AI 网关（如 Envoy 一类）为 RESTful 微服务架构优化：客户端发来短生命周期的 HTTP 请求，网关选一个后端转发，通常不需要会话上下文与持续的连接状态。MCP 则完全不同——它是基于 JSON-RPC 的有状态协议，客户端与服务端要维持长会话，请求与响应必须绑定在同一会话上下文中；服务端还能向客户端异步回推消息。一次「列出可用工具」的请求，可能需要代理访问多个后端 MCP 服务器、聚合结果再返回一致视图，甚至按客户端权限动态调整工具列表。

这些模式带来的挑战分布在四个方向：跨工具与服务认证授权审计的安全问题、跨自治工作流执行策略（数据驻留、访问控制）的治理问题、对「智能体在做什么」的可见性问题，以及长连接高并发下的低延迟与弹性问题。官方文档的判断是：不做大的重新架构，传统网关无法支撑这些会话化、双向化的智能体负载。

agentgateway 源自 Solo.io。据其官方博客，团队曾考虑以 Envoy 为基础，但意识到支持 A2A 与 MCP 需要对 Envoy 做大规模重构，于是转而全新构建；项目借鉴了团队三年间在 Istio ambient 服务网格与零信任隧道 ztunnel 上的生产经验。2025 年，Solo.io 在 Open Source Summit Europe 上把 agentgateway 捐入 Linux 基金会；据官方文档，2026 年该项目被 Agentic AI Foundation 接纳。项目以 Rust 实现，Apache 2.0 许可，定位是 AI 优先的云原生网关控制面与代理数据面。

架构上它同时是一个通用 HTTP 与 gRPC 数据面（负载均衡、超时重试、TLS、限流、鉴权与流量策略），因此可以把普通 API 与微服务也放在同一个代理后面，运营方不再需要并行维护「常规」与「AI」两套网关。

作为 LLM 网关：提供 OpenAI 兼容端点对接 OpenAI、Anthropic、Azure、Gemini 及自托管模型，支持模型别名与切换不改代码、按请求与按 token 的限流配额、集中密钥管理，以及在提示与响应上内联执行 guardrail 规则。作为 MCP/A2A 网关：把任意 OpenAPI 规格即时暴露为 MCP 工具而无需改代码；对 MCP 服务器动态请求的后端 URL 做校验与沙箱化，阻断 shadow MCP 访问；支持 A2A 协议下的跨边界智能体发现与协作，并为每次工具调用与智能体交互留存完整审计。作为推理网关：面向自托管模型池做负载均衡、按上下文路由与 GPU 利用率优化。

治理侧的核心思路是把控制从各智能体框架中抽出来放到平台层：MCP 服务器来源校验、审批目录工作流、集中策略、基于 OpenTelemetry 的端到端追踪。官方页面公布的性能数据（内存约 30MB 对 9GB、吞吐约 165k QPS 对 4.6k QPS、延迟约 0.09ms 对 11ms、周级发版节奏）来自厂商自报、基于 gateway-api-bench 的对比，引用时应注明口径。

把本站相关条目串起来看：MCP（ENC-PROTOCOL-01）与 A2A（ENC-PROTOCOL-02）定义了智能体与工具、智能体之间的通信语法；路由模式（ENC-ARCH-10）解决框架内任务怎么分发给合适的智能体；托管运行时（ENC-ARCH-16）解决智能体跑在哪里、状态如何持久。网关补的是「跨边界流量的安全与治理」这一层——当智能体开始调用别人的工具服务器、与其他团队的智能体协作时，企业需要一个统一的检查点。

同属这一生态的还有 Solo.io 捐出的 kagent（Kubernetes 原生智能体运行时）与 agentregistry（MCP 服务器、智能体、技能与提示的注册表）。对平台工程团队而言，网关、注册表与运行时正在构成智能体时代的「服务网格三件套」，而协议本身的演进（如 MCP 2.0 与事件订阅规范，见 ENC-PROTOCOL-21）会持续向网关层提出新要求。

智能体网关正在成为智能体时代的流量入口与治理中枢：协议侧会随 MCP 2.0、事件订阅等演进持续扩展，治理侧将与非人类身份（NHI）、审计合规深度融合；Kubernetes Gateway API 集成与多租户能力预计是企业落地的竞争焦点。Linux 基金会与 AAIF 的中立托管有助于其成为生态公共件。