LLM网关不是控制平面：Agent绕过治理的真相

一个被忽视的架构问题

如今，几乎每个AI团队的技术栈中都能找到一个LLM网关（LLM Gateway）。它负责路由模型调用、集中管理凭证、添加日志、施加速率限制，甚至处理开销追踪。像 LiteLLM、Portkey、OpenRouter 这类工具已经成为许多生产环境的标配。

但一个来自 Reddit 的技术讨论提出了一个相当根本却常被忽视的问题：如果一个 Agent 根本不使用网关，会发生什么？

这个问题看似简单，却触及了 Agent 治理（Agent Governance）的核心。当我们把网关部署在技术栈中时，我们默认它就是"治理边界"。然而现实是，网关只能治理那些经过它的流量——对于绕过它的流量，它无能为力。

reddit source: Is an LLM gateway actually a control plane if agents can bypass it?

流量控制 ≠ 路径控制

原帖作者用一张简洁的架构图揭示了问题的本质：

         ┌──→ LLM Gateway ──→ Models
Agent ───┤
         ├──→ Direct provider API
         ├──→ Direct MCP/tool endpoint
         └──→ Other external egress

在这个结构中，Agent 完全可以选择不走网关这条路。它可以：

直接调用模型提供商的 API
直接访问 MCP/工具端点
通过其他外部出口（egress）发起请求

此时，网关仍然在"尽职工作"——它照常路由、记录、限流。但它不再治理这个 Agent。

作者由此提出了一个关键洞察：流量控制（traffic control）和路径控制（path control）是两个不同的问题。 一个代理（proxy）无法强制约束那些从未到达它的流量。换句话说，如果治理机制依赖于"流量必须经过网关"这个前提，那么只要 Agent 拥有绕过网关的能力，整个治理体系就形同虚设。

网关是组件，不是边界

这里的核心论点是：LLM 网关应该被视为 Agent 治理的一个组件，而非治理边界本身。

这是一个重要的心智模型转变。很多团队在部署网关后会产生一种"安全错觉"——认为只要流量走了网关，Agent 就被管住了。但实际上，网关能提供的治理能力，仅覆盖那些"愿意"或"被迫"经过它的流量。真正的治理边界，需要在网络层、身份层等更底层的位置建立。

构建无法绕过的治理架构

针对这个问题，原帖作者提出了一种更严密的分层架构：

Agent
  ↓
Agent Gateway
  ↓
LLM Gateway / Governed Tools
  ↓
Models + APIs + 网络/出口强制 + 身份 + 影子发现

这个架构的关键在于，它不再假设"把流量路由过网关就等于 Agent 被治理了"，而是通过多个层次共同构建治理边界：

出口强制（Egress Enforcement）

这是从网络层堵住绕过路径的关键。即便 Agent 拥有凭证和绕过意图，如果网络层面限制了它能访问的出口目标，它就无法直接连接到未经治理的模型或工具端点。这把治理从"应用层的自愿"变成了"网络层的强制"。

影子发现（Shadow Discovery）

影子发现用于检测那些绕过网关的隐蔽路径。在一个分布式的 Agent 环境中，你很难保证所有 Agent 都规规矩矩地走网关。影子发现的作用是主动识别出这些"影子流量"和"影子端点"，从而暴露并关闭绕过路径。

身份（Identity）

身份层确保每个 Agent 的每次调用都有明确的、可验证的身份归属。这是把访问控制策略真正落地的前提——没有身份，就谈不上精细化的授权和审计。

原帖提到 Lyzr Open Controller 在这方面比较有意思：它将网关与出口强制、影子发现配对使用，专门用于检测和关闭绕过路径，而不是简单假设"路由即治理"。

为什么这个问题会越来越重要

作者预判，随着 Agent 部署环境（agent estates）变得越来越分布式，这个问题的严重性会持续放大。今天的 Agent 可能分散在：

Kubernetes 集群
云端 Agent 运行时（cloud agent runtimes）
MCP 服务器
内部自托管服务

在如此碎片化的环境中，"所有流量都乖乖走网关"这个假设越来越难以成立。每一个拥有凭证和网络访问权限的 Agent，都是一个潜在的绕过点。

这引出了原帖最尖锐的一问：如果一个 Agent 同时拥有凭证和网络访问权限，能够直接调用模型或工具，那么究竟是什么在真正阻止它绕过？

结语：架构图之外的真实答案

这场讨论的价值，不在于给出一个标准答案，而在于戳破了一个普遍存在的架构假象。原帖作者最后特别强调，他想听的是在真实生产环境中真正有效的做法，而不是架构图上"应该有效"的设计。

这提醒我们，Agent 治理的落地远比画图复杂。从工程实践角度，几个方向值得深入思考：

收紧凭证分发：Agent 是否真的需要能直接调用提供商 API 的原始凭证？还是应该只发放经过网关代理的短期令牌？
网络层强制：通过 egress 策略、防火墙规则或服务网格，在网络层面切断绕过路径，让"走网关"从可选变成唯一选择。
持续发现与审计：假设绕过一定会发生，通过影子发现机制持续暴露它，而非依赖一次性配置。

归根结底，一个真正的控制平面（control plane），必须是 Agent 无法绕过的。当绕过成为可能时，网关就只是一个"可选的便利设施"，而非"治理的边界"。这个区别，正是从"看起来受控"走向"真正受控"的分水岭。