Kong AI Gateway

Kong AI Gateway 是构建在 Kong Gateway 之上的 LLM 与智能体流量治理层。Kong Gateway 是由成立于 2017 年的旧金山企业 Kong Inc. 开发并被广泛部署的开源 API 网关。它旨在解决一个随着模型采用而不断加剧的企业级难题：当组织将 OpenAI、Anthropic、Bedrock、Gemini、Mistral 等模型接入内部系统和智能体工作流时，控制权会变得支离破碎，因为每个提供商都有自己的 SDK、凭证、成本计量和速率限制机制。Kong 位于所有这些模型的前端，作为统一的控制平面，负责路由、成本控制、安全和可观测性。它并非一个独立的二进制文件，而是 Kong Gateway 加上一套 AI 插件，支持自托管运行，或通过 Kong 的托管式 Konnect 控制平面运行。

其功能涵盖多提供商路由与负载均衡、基于 Token 的速率限制与配额、跳过重复调用的语义缓存、PII 清洗与提示词注入防护，以及针对每个模型的 Token 支出和延迟仪表板。到 2026 年 4 月，3.14 版本的 Agent Gateway 将这种治理能力扩展到了原始 LLM 调用之外的两种流量类型：Model Context Protocol 工具流量和智能体间通信。Kong 声称这使其成为唯一能通过单一控制平面覆盖这三种流量的网关。Kong Gateway 免费开源了六个核心 AI 插件，而更高级的功能则包含在付费的 Konnect 层级中。Kong 本身资金雄厚，在 2024 年底的 E 轮融资中筹集了 1.75 亿美元，估值达到 20 亿美元。

Kong AI Gateway 在 2026 年 6 月的治理范围

其核心理念是为所有 AI 流量设立一个单一的关卡。服务不再各自持有提供商的密钥，所有调用都流经 Kong，由其在一个地方统一应用路由、身份验证、速率限制、缓存和安全策略，然后输出统一的可观测性数据。这在规模化应用中具有真正的价值：您可以限制每个团队的 Token 支出，在提供商之间进行故障转移，缓存语义相似的提示词以降低成本，并在 PII 到达模型之前将其剥离。

“只需将您当前的 Kong Gateway 升级到 3.6 版本，您就能使用这些完全专注于 AI 和 LLM 场景的新插件。”—— Kong 首席技术官 Marco Palladino，2024 年 2 月。

最新且最具特色的进展出现在 2026 年 4 月 14 日，当时 Kong 在 3.14 版本中发布了 Agent Gateway，在现有的 LLM 和 MCP 支持之上，增加了对基于 Google A2A 协议的智能体间通信的治理。该版本引入了智能体身份与认证、对智能体间数据流进行策略违规和提示词注入的实时检查、单智能体成本分配以及完整的审计日志。Kong 在 2025 年 9 月收购了计量公司 OpenMeter，这表明它也在致力于完善 Token 成本追踪方面的功能。

开源插件与付费版 Konnect 的对比

与大多数工具相比，这里免费与付费的划分更为关键。Kong Gateway 是真正免费且基于 Apache 2.0 协议的，自 2024 年 2 月的 3.6 版本起，它免费提供了六个 AI 插件，涵盖 LLM 代理、提示词防护以及请求和响应转换。开源层级不包含的，恰恰是大多数 AI 团队真正需要的部分：基于 Token 的速率限制（免费层级仅计算 HTTP 请求）、语义缓存、大规模 PII 清洗、管理 GUI、SSO、高级分析以及 MCP 和 A2A 治理。这些功能需要 Konnect，它提供 30 天免费试用，随后是自助式的 Plus 层级（每月包含 100 万次 API 请求，超出部分每百万次 $200，最多支持 5 个 LLM 模型），以及 Enterprise 层级（提供无限模型、SSO、审计日志和自定义 SLA，通常每年花费数万美元起步）。Kong 不按 Token 收费；您仍需直接向提供商支付该费用。

Kong 与 LiteLLM 及 Portkey 的对比

与 LiteLLM 相比，两者的差异在于量级和语言。LiteLLM 作为一个轻量级的 Python 进程运行在带有 PostgreSQL 的小型服务器上，它是 Python 原生的，因此 AI 工程师可以使用他们熟悉的工具对其进行扩展，并且它涵盖了广泛的提供商列表。自托管 Kong 意味着需要运行 Nginx、数据库和数据平面节点，且自定义插件是用 Lua 编写的，这在 AI 圈子里是一种小众语言。Kong 自己的基准测试显示其在原始吞吐量上遥遥领先，但当 LLM 提供商自身数百毫秒的延迟使网关几毫秒的开销显得微不足道时，这种优势在很大程度上就无关紧要了。Kong 的优势在于成熟的企业级治理：RBAC、SSO、审计日志，以及 LiteLLM 所缺乏的 MCP 和 A2A 覆盖。Portkey 是另一个竞争对手，专为 LLM 流量构建，具有 Python 原生插件和按请求定价的模式，而 Kong 是一个适应 AI 的 API 网关，采用按服务定价的模式。客观的总结是，当您希望将 AI 治理与您已经在运行的更广泛的 API 和微服务治理统一起来时，Kong 是赢家；而像 OpenRouter 这样的多 LLM 路由器或像 Together AI 这样的后端则只能满足这一需求的较小部分。

Kong 的模式让 AI 团队感到沮丧的地方

由于每个模型或提供商都被视为一个独立的网关服务，而智能体工作流会在每次用户操作时扇出许多内部调用，因此成本可能会快速攀升。

“单个智能体工作流可能会触发包含 20 多个内部 API 调用的链条。这种乘数效应使得 Kong 在智能体 AI 应用中缺乏经济效益。”—— TrueFoundry 技术分析，2026 年。

一项分析估计，在 20 个微服务中集成 5 个 LLM，仅服务费每月就大约需要 $2,625。自定义插件需要使用 Lua，这对以 Python 为主的 AI 团队来说是一个真正的入门障碍；对于仅需要 AI 网关的团队来说，在生产规模下进行自托管会带来不成比例的运营开销；AI 专属功能的文档落后于成熟的核心网关；而且团队在发布时期望的一些功能（如模型负载均衡和 MCP 代理）几个月后才姗姗来迟。到 2026 年，在 AI 专属功能上落后于 AI 原生工具的现象已有所改善，但依然存在。

Kong AI Gateway 适合谁，又对谁来说过于笨重

Kong 非常适合那些已经在使用 Kong Gateway 进行非 AI API 管理的团队，对他们来说，添加 AI 插件的边际成本很低，而统一的可观测性则是实实在在的收益。它适合需要 MCP 和智能体间治理的企业，需要对 LLM 流量进行 PII 清洗、审计日志和 RBAC 的受监管行业，以及具备编写 Lua 插件和运行基础设施的平台专业知识的大型工程团队。

对于大多数尚未采用 Kong 的小型 AI 产品团队和初创公司来说，它显得过于笨重，因为运营开销和按服务定价的模式更倾向于整合方案，而非从零开始构建 AI 基础设施，像 LiteLLM 这样更简单的工具会更合适。希望使用 LangChain 风格逻辑扩展网关的 Python 原生团队、真正的瓶颈在于提供商延迟而非网关开销的团队、期望网关按 Token 定价的任何人，以及需要付费版 Konnect 才能使用高级功能的独立开发者，都应该寻找其他替代方案。对于将流量路由到 Fireworks AI 等托管模型且没有企业级治理需求的团队来说，Kong 显得大材小用。