Kong Gateway 3.9：当 API 网关开始认真对待 LLM 与 MCP 流量
API 和 AI 网关。由于其官方 Kubernetes Ingress Controller，Kong 在 Kubernetes 上原生运行。
秒懂
- 它是什么？
- Kong 从 API 网关扩展到 AI 网关，新增通用 LLM 路由与 MCP 流量治理。本文基于仓库与文档，拆解其架构、部署方式、适用场景与边界。
- 适合谁用？
- Kong Gateway 3.9 适合已有微服务架构、需要统一管理传统 API 与 LLM/MCP 流量的团队，尤其是那些已经部署 Kubernetes 并使用 Ingress 的环境。它不适合只处理单一 LLM 提供商、且不愿引入额外运维层的场景。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 9 天前。
- 用什么语言写的？
- 主要是 Lua（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
从 API 网关到 AI 网关：Kong 在解决什么问题
Kong 原本是处理微服务流量的 API 网关，提供代理、路由、负载均衡、健康检查和认证。3.9 版本的定位变成了 API、LLM 与 MCP 三层流量的统一入口。文档中明确提到它支持多 LLM 提供商路由、语义安全、MCP 流量安全与分析。换句话说，Kong 试图把传统 API 网关的治理能力扩展到生成式 AI 的调用链路上。适合的团队是那些已经在微服务架构中使用 Kong，或者正在为多个 LLM 提供商寻找统一接入层的组织。它的目标不是替代模型本身，而是成为模型调用前的守门员。
核心机制：声明式配置与插件体系
Kong 的架构基于 Nginx 和 OpenResty，但用户接触的是 RESTful Admin API 或声明式配置文件。文档强调支持 Declarative Databaseless Deployment，即无数据库模式，配置以 YAML 形式提交，适合 GitOps 工作流。插件是扩展功能的载体，官方插件中心列出了 AWS Lambda、Correlation ID、Response Transformer 等。插件可以用 Lua、Go 或 JavaScript 编写，这意味着团队不必被单一语言绑定。流量处理流程是：请求进入 Kong，经过路由匹配、插件链执行，再转发到上游服务。对于 LLM 流量，Kong 提供 Universal LLM API，统一不同提供商的请求格式，然后路由到 OpenAI、Anthropic 等后端。
部署与启动：从 Docker Compose 到 Kubernetes
README 给出的快速启动方式是克隆 docker-kong 仓库，进入 compose 目录，然后运行 KONG_DATABASE=postgres docker-compose --profile database up。这条命令会启动带 PostgreSQL 的完整栈，网关监听 8000 端口转发流量，8001 端口提供 Admin API，8002 端口运行 Kong Manager 管理界面。如果不想用数据库，文档也提供了 DB-less 模式的 Docker 安装方式。对于 Kubernetes 用户，Kong 有官方的 Ingress Controller，可以在集群内以 Ingress 资源的方式声明路由规则。实际部署时需要注意，DB-less 模式适合配置频繁变动的场景，而传统数据库模式更适合需要动态更新路由和插件的生产环境。
AI 流量治理：LLM 路由与 MCP 安全
Kong 对 AI 流量的支持是 3.9 版本的亮点。Universal LLM API 允许开发者用同一套接口调用多个模型提供商，减少供应商锁定。文档列出的提供商包括 OpenAI、Anthropic、GCP Gemini、AWS Bedrock、Azure AI、Databricks、Mistral、Huggingface 等。MCP（Model Context Protocol）流量治理则包括安全策略和可观测性，甚至可以从 RESTful API 自动生成 MCP 端点。这些功能意味着 Kong 试图覆盖 AI 应用的后端通信层。但要注意，AI 功能的具体实现细节在 README 中并未展开，实际能力需要查阅官方 AI 文档。对于只调用单一模型的团队，这些功能可能显得多余。
真正的局限：复杂性与性能取舍
Kong 的灵活性带来配置复杂度。声明式配置虽然适合自动化，但调试插件链和路由规则需要学习成本。DB-less 模式下，配置更新需要重新加载或通过 API 推送，不像数据库模式那样即时生效。另一个局限是，Kong 本身不处理 LLM 推理，它只是转发和治理流量，这意味着延迟和错误处理仍然依赖上游模型服务。对于高吞吐、低延迟的实时推理场景，Kong 的代理层可能成为瓶颈，虽然 README 声称高性能，但没有给出具体基准数据。此外，MCP 治理功能是否支持所有 MCP 版本，文档没有明确说明，这是采用前需要验证的风险点。
替代方案与差异：Ingress Controller 与自建代理
如果团队只需要 Kubernetes 内的流量管理，可以直接使用 Nginx Ingress Controller，它更轻量，但缺少 Kong 的插件生态和 AI 特性。另一个替代方案是自建基于 Envoy 的代理，比如使用 Istio 或 Contour，它们提供更细粒度的服务网格能力，但配置更复杂，且没有现成的 LLM 路由插件。Kong 的差异化在于插件市场：60 多个 AI 相关特性，如语义缓存和语义路由，这些在通用代理中很难找到。如果只是需要简单的 API 密钥转发，一个几十行的 Nginx 配置就能完成，不必引入 Kong。选择的关键在于是否需要多提供商路由和 MCP 治理这类高级功能。
维护成本与许可证
Kong 采用 Apache-2.0 许可证，允许商用和修改，没有 copyleft 约束。版本遵循 SemVer，最近发布 3.9.3，修复了 3.9.2 和 3.9.1 的问题，发布节奏活跃。维护成本主要来自运行 PostgreSQL（如果使用数据库模式）、监控网关状态以及升级插件兼容性。Kong 的插件 API 在不同版本间可能有变化，升级前需要查看 Changelog。社区支持通过 GitHub Discussions 和 Slack，但企业级支持需要购买 Kong Konnect 或企业版。对于小团队，自托管 Kong 需要投入运维时间，而云托管版本则减少这部分负担，但引入供应商依赖。
编辑结论
Kong Gateway 3.9 适合已有微服务架构、需要统一管理传统 API 与 LLM/MCP 流量的团队，尤其是那些已经部署 Kubernetes 并使用 Ingress 的环境。它不适合只处理单一 LLM 提供商、且不愿引入额外运维层的场景。采用前应先验证三件事：确认你的 LLM 提供商是否在官方支持的列表中，检查 MCP 治理功能是否覆盖你实际使用的 MCP 协议版本，以及评估声明式配置（DB-less 模式）下插件热更新是否符合你的发布节奏。Kong 的核心价值在于把 API 网关的成熟机制（路由、限流、认证）平移到 AI 流量上，而不是提供全新的 AI 基础设施。
社区笔记