在本系列文章第一部分中，我们构建了一个基于 Quarkus 的 MCP 工具服务器，并通过可流式 HTTP 将其与 Goose AI 代理连接。工具运行正常，演示过程清晰，一切均在 localhost 上完成。然而，一旦设想 50 名开发者在其笔记本电脑上运行 Goose，同时访问同一组后端 MCP 服务器，该架构便开始出现裂痕。谁认证了该工具调用？哪个角色授权了 getAuditTrail 的调用？什么机制能阻止被投毒的工具名称向您的后端注入负载？本文通过引入 agentgateway——Linux 基金会为代理式 AI 流量设计的开源代理——将其置于 Goose 客户端与我们在第一部分构建的 Quarkus MCP 微服务之间，来解答上述问题。