北京
一个AI应用直接调用大模型，在实验阶段还行。可一旦做成生产级的智能代理，状况就不一样了——需要对接多家模型供应商、发现并调用MCP工具、跨代理通信，还得管认证、限流、重试、超时、成本追踪和内容安全。如果每个应用都把这些能力自己实现一遍，用不了多久就会变成一锅“连接乱炖”，操作难度陡增。
于是，有人主张：传统API网关应付得来。API网关本来就能做路由、鉴权、TLS终结和速率限制，加上几次小升级，管起LLM请求也绰绰有余。这种看法在技术圈并不少见，毕竟“流量管理”听起来大同小异。
但另一面的声音也不弱。代理类系统引入的全是“不对劲”的流量：模型服务不是标准REST，有流式响应和令牌级的计量；MCP服务器的发现与调用自带独特协议；代理间通信（A2A）又需要另一套寻址和权限模型。更麻烦的是，管理员得在同一套体系里落实安全策略，既要看住密钥存在哪儿、哪些模型能被谁调用，又要防止一个应用烧光全年预算，还得统一观察延迟、令牌消耗和故障。把所有这些逻辑嵌入各个代理内部，不仅产生重复代码，还让策略执行七零八落。
这就是Agentgateway被提出来的背景。它是一个开源、AI优先的数据平面，专为连接应用与代理、MCP工具、LLM供应商、推理服务以及传统后端而设计。在Kubernetes环境中，它还包含一个控制平面，通过观察Gateway API资源和自定义资源，把配置转成运行态并分发给代理网关代理。它既不是单纯把LLM请求转发出去，也不是要取代现有的API网关，而是在一个平面上收敛MCP、A2A、HTTP、gRPC等不同协议，让代理系统有统一的连接入口和策略层。
我的判断是：这两股观点并不是非此即彼。传统API网关在某些路径上依然好用，比如对外暴露标准HTTP接口；而Agentgateway处理的是代理特有的“多协议混合”流量和精细化治理。两者更像是互补，而非竞争。对团队来说，真正要做的，是把认证、访问控制、预算管理、可观测性这些横向关注点，从一个个代理里抽出来，放进一个共享的基础设施层，让架构从“每个代理自扫门前雪”变成有规则、可治理的连接生态。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
