如果智能体可以绕过 LLM 网关，它是否实际上充当了控制平面？

许多团队现在在架构中集成了一个 LLM 网关。它路由模型调用、集中管理凭证、添加日志记录、应用速率限制，并可能处理开销跟踪。但存在一个相当基本的架构问题：当智能体根本不使用网关时会发生什么？例如： ┌──→ LLM 网关 ──→ 模型 智能体 ──────────┤ ├──→ 直接提供商 API ├──→ 直接 MCP/工具端点 └──→ 其他外部出口 此时，网关仍在执行其功能，只是不再治理智能体。这一区别很重要，因为流量控制和路径控制是不同的问题。我认为，网关应被视为智能体治理的一个组成部分，而非治理边界本身。像 LiteLLM、Portkey 和 OpenRouter 这样的工具在网关/代理层很有用。但代理无法执行从未到达代理的流量。更有趣的架构是： 智能体 ↓ 智能体网关 ↓ LLM 网关 / 治理工具 ↓ 模型 + API + 网络/出站执行 + 身份 + 影子发现 在 Lyzr Open Controller 中，我发现了一个有趣的领域：网关与出站执行和影子发现相结合，专门用于检测和关闭绕过路径，而不是假设通过网关路由流量就意味着智能体被治理。我认为，随着智能体实例在 Kubernetes、云智能体运行时、MCP 服务器和内部托管服务中变得更加分散，这将成为一个更大的问题。想知道人们在实际生产环境中是如何解决这个问题的：如果智能体拥有凭证和网络访问权限，可以直接调用模型或工具，那么什么实际上阻止了绕过？有兴趣听到实际有效的方法，而不是架构图上理论上应该有效的方法。