北京
多数平台团队一开始没想搞什么“AI基础设施”。他们早就在GKE上跑着Kong，挡在几百个REST服务前面，处理认证、限流、可观测性，干的就是API网关该干的活儿。后来产品团队开始上线大模型功能，接着是RAG流水线，再然后是能自己调用工具的自主Agent——突然间，那层原本在CRUD流量面前运转良好的网关层，开始出问题了。
一个聊天请求的成本可以是另一个的50倍，取决于模型和提示词长度。一个“用户请求”现在可能被Agent发散成一打工具调用，中间没人盯着。这些情况没法简单映射到按请求数算的限流或静态路由规则上。
这正是Kong的AI网关能力要解决的问题，而GCP是运行它的天然场所：用GKE跑网关本体，Cloud Load Balancing挂边缘，Vertex AI和Model Garden作为第一梯队的模型后端，跟OpenAI、Anthropic等并列，再用Memorystore的Redis支撑分布式限流状态。
下面是一份实操指南，讲怎么把一套现有的Kong部署，在GCP上改造成真正的AI网关——覆盖token感知的流量管理、模型上下文协议支持，以及更棘手的难题：治理那些行为不像普通API调用的Agent流量。
传统网关的建造逻辑基于几个假设，在生成式AI工作负载面前都站不住脚。首先是成本跟请求数不成正比。给一个小模型发一条短提示，可能只花零点几美分；把一条长上下文请求发给前沿模型，能烧掉几美元。按每分钟请求数做限流，根本护不住预算。其次，后端不可互换。把请求路由到GPT、Gemini还是Claude，不只是负载均衡的决策——它会改变成本、延迟，甚至输出质量。再者，“客户端”越来越是机器而不是人。Agent会链式调用，会自动重试，会陷入人类点UI根本点不出来的循环。最后，协议本身也在演进。MCP已经让模型发现和调用工具的方式标准化了，网关需要原生支持它，而不是把它当作不透明的HTTP载荷。
Kong AI网关本质上是同一个Kong Gateway核心，配上了一组AI专用插件——ai-proxy、ai-proxy-advanced、ai-rate-limiting-advanced、ai-semantic-cache、ai-prompt-compressor、ai-mcp-proxy等等——让网关不再只认得请求头和路径，而是能处理token、提示词和工具调用。
如果你已经在GKE上跑着Kong Gateway（开源版或企业版），不需要换新平台，你需要的是AI网关插件集。这套插件随Kong Gateway 3.6以上版本提供，从3.12版开始功能更全，加入了原生MCP支持。
一个典型的GCP原生部署布局如下：GKE承载Kong数据面节点。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
