F5 扩展 AI Gateway，争夺企业 AI 流量控制权

尽管企业已经面对拥挤的模型路由、护栏和代理安全工具市场，F5 仍于 8 月 18 日扩展了其 AI Gateway。Google News 的标题看起来只是又一次产品更新，但其背后的举措，是试图掌控连接员工、应用程序、AI 模型、代理和企业工具的每一项请求。

更新后的网关在统一的策略层下整合了三项功能。Model Gateway 管理模型访问、路由和 token 使用；MCP Gateway 管理代理如何访问工具；AI Guardrails 则检查提示词和响应中的威胁或敏感数据。

这种组合构成了真正的竞争焦点。企业可以为每项功能组合专门产品，也可以将多种形式的 AI 流量置于同一家基础设施提供商之下。F5 押注于，运营一致性将胜过独立工具所提供的自由度和专业深度。

该公司进入的是一个竞争激烈的领域。Kong、Cloudflare、Citrix、Palo Alto Networks、云服务提供商以及 AI 原生初创公司，都在争夺某种形式的控制平面机会。每一家都希望成为决定哪项 AI 请求能够运行、它能访问什么以及成本多少的中介层。

对于已经使用 BIG-IP、NGINX 或其分布式云服务的组织而言，F5 具有优势。这些部署位于应用程序和 API 流量附近，而策略执行原本就发生在那里。不过，既有的流量位置并不自动等同于 AI 治理领域的领导地位。

因此，关键问题并非企业是否需要更好的控制能力，而是单一网关能否在不成为又一个集中式风险的前提下，治理模型、代理、数据和成本。

F5 实际上做了哪些改变

F5 正在将其 AI Gateway 从安全检查点转变为更广泛的运营控制平面。

该公司于 2024 年 11 月首次推出 F5 AI Gateway。其早期定位强调保护和管理应用程序、API 与大型语言模型之间的流量。

最新版本扩大了这一范围。F5 现在将三个互联的网关和安全层作为一个系统呈现，而非采用策略各异的独立产品。

Model Gateway 处理发送至 AI 模型的请求。F5 表示，它会按提供商、模型、团队和个人用户记录 token 使用量。管理员还可以设置预算，并在请求处理过程中加以执行。

路由增加了一项经济功能。该网关可以将较简单的任务发送至成本更低的模型，复用合适的缓存响应，或根据可用 GPU 容量分配工作负载。这使网关既是安全产品，也是流量管理器和支出控制器。

F5 表示，这些功能无需更改应用程序即可将 token 支出降低 30% 至 60%。其当前的 AI Gateway overview 还声称，消除重复的代理工具调用，最多可将相关 token 浪费减少 90%。

这些数字属于供应商声明，并非独立基准测试。实际节省将取决于请求模式、缓存复用、模型选择、延迟要求以及既有的优化工作。已经采用严格路由策略的组织，可能获得较小的收益。

MCP Gateway 处理的是另一条流量路径。Model Context Protocol，即 MCP，为 AI 应用程序提供了一种连接工具和数据源的标准方法。这些连接可以访问数据库、内部 API、文档存储库和业务系统。

F5 表示，其注册表可以编目公共、远程和私有 MCP 服务器。管理员可以针对单个工具应用允许列表、拒绝列表、配额、预算和基于角色的访问控制。

该系统还会记录每一次工具调用。该记录可以显示哪个身份发起了请求、代理访问了哪个资源，以及发生了什么操作。当自主流程修改业务数据或访问受监管信息时，这类证据非常重要。

AI Guardrails 检查通过网关传输的内容。F5 表示，这些策略能够对个人可识别信息进行脱敏、阻止提示词注入尝试，并拦截越狱技术。故障关闭式执行会在检查层无法安全评估流量时拒绝该流量。

这些组件共同覆盖了三个不同的问题：哪个模型应处理请求？代理可以使用哪些工具？哪些信息或指令可以跨越任一边界？

F5 还将该网关纳入其更广泛的 AI Security Platform。该平台围绕承载 AI 流量的实时系统，整合 AI 治理、使用控制、安全测试和运行时保护。

集成的重要性超过了品牌本身。仅负责路由请求的网关只能看到 AI 工作流的一部分。与应用安全、API 控制和运行时监控相连的网关，则可以围绕该请求关联更多活动。

F5 计划支持 SaaS、混合 SaaS 和混合多云部署。对于无法通过外部服务传输敏感流量的受监管环境，隔离网络支持也在计划之中。

这一部署范围面向 AI 系统横跨私有基础设施和多家云服务提供商的组织。它也进一步强化了 F5 的核心论点：控制层应随流量跨环境运行，而不应隶属于某一家模型供应商。

为什么这则 Google News 标题此刻重要

这条 Google News 内容反映出一个更大的转变：企业正从试验 AI 模型，转向大规模治理 AI 推理。

F5 的 2026 State of Application Strategy 研究发现，77% 的受访组织认为推理是其主要的 AI 活动。该公司称，受访者平均管理七个 AI 模型。

推理是训练完成的模型处理实时请求的生产阶段。它涵盖员工助手、客户支持系统、代码工具、搜索应用程序以及执行业务任务的代理。

管理七个模型带来的远不止七种技术关系。团队必须跟踪这些系统中的凭据、区域、请求格式、保留规则、安全过滤器、故障切换行为、性能和使用量。

代理则引入了另一套权限结构。模型可以决定调用外部工具，而该工具可能暴露数据或执行操作。安全团队必须同时治理用户、代理、模型、工具和目标系统。

MCP 让工具集成更容易，但标准化也加快了工具扩散。开发人员无需为每个 AI 应用程序设计定制接口，便可连接新工具。中央团队可能很快失去对现有服务器及其可访问者的可见性。

安全研究人员已描述过这一扩大的攻击面。一篇关于 MCP security controls 的 2025 年论文指出，工具投毒、数据外泄、供应链受损和跨系统权限提升是其中的核心风险。

研究人员建议采用范围限定授权、来源追踪、沙箱隔离、内联数据控制和集中式网关执行。F5 的架构与其中若干建议相符，但产品功能清单并不能证明其实施有效。

安全风险上升的同时，经济压力也在增加。每个提示词、响应、检索到的文档和工具结果都可能为模型请求增加 token。代理在完成一项用户可见任务时，可能生成多次模型调用。

这使支出难以归属。一家公司或许知道其提供商账单总额，却无法可靠地在团队、应用程序、用户和自主工作流之间进行归因。

传统云预算对于部分 AI 工作负载来说也来得太晚。代理可能在月度报告发现问题之前，反复执行失败步骤或生成不必要的工具调用。实时配额和路由策略可以更早介入。

F5 首席产品官 Kunal Anand 将这一问题描述为：对承载经济、安全和治理后果的请求缺乏统一控制。这种表述服务于 F5 的平台战略，但控制碎片化的问题确实存在。

这一类别同样吸引了大量投资。据 Axios report 报道，WitnessAI 融资 5,800 万美元，以扩展其企业 AI 安全平台。PitchBook 估计，代理型网络安全公司在 2025 年期间通过近二十余笔交易筹集了近 2.5 亿美元。

不过，部署仍不均衡。同一篇 Axios 报道援引 McKinsey 研究称，大约四分之一的受访者正在实质性扩大代理型系统的规模。

这一差距解释了供应商为何现在行动。他们希望在大多数企业代理进入生产环境之前建立控制点，而不是等客户在其他地方完成标准化之后。

因此，这则 Google News 报道的意义不止于 F5 的一次功能发布。它捕捉到了一场正在形成的基础设施竞争，而主导性的企业架构尚未定型。

单一控制平面与专用 AI 工具之争

F5 的主要对手并非某一家供应商，而是由独立路由、安全、可观测性和代理治理产品组成的专业化技术栈。

专业化架构使企业可以选择用于性能优化的模型路由器、用于内容检查的护栏提供商，以及另一款用于 MCP 授权的产品。团队无需迁移整个系统即可替换其中一个组件。

这种灵活性很重要，因为该类别仍很年轻。安全技术、代理协议和模型接口仍在持续变化。当其他地方出现更强的组件时，高度耦合的平台可能难以调整。

专业厂商也可以更深入地聚焦于狭窄问题。AI 原生可观测性服务可能提供更丰富的提示词追踪或评估工作流。专注于安全的公司可能检测到通用应用平台遗漏的攻击。

代价是运营碎片化。每个组件都可能引入另一种策略语言、仪表板、代理、数据存储、身份集成和审计格式。当两款产品以不同方式解释同一用户或请求时，就会出现缺口。

F5 认为，共享策略可以减少这些缺口。其系统将预算、基于角色的访问控制、审计记录和可观测性应用于模型流量和代理工具调用。

最有说服力的案例出现在现有 F5 环境中。已经使用 BIG-IP 或 NGINX 的企业，可以将 AI 控制能力部署在处理常规应用程序和 API 流量的基础设施附近。

F5 在 2026 年 3 月强化了这一战略。其 ADSP expansion 在其应用交付产品组合中增加了 MCP 流量可见性和以代理为中心的控制能力。

根据该公告，NGINX 可以在流量路径中检查 MCP 元数据。运营人员能够观察已知或此前未被追踪的代理活动中的请求模式、延迟、吞吐量和错误。

这一位置可以减少部署阻力。团队可以扩展现有流量层，而无需插入另一台代理服务器并建立独立的运营流程。

竞争对手也在提出类似论点。Citrix 在 7 月将 MCP Gateway 功能加入 NetScaler AI Gateway，距离推出底层产品仅数月。

NetScaler 更新整合了模型路由、令牌跟踪和智能体工具治理。Citrix 还强调，可通过单一平台和仪表板同时管理模型与 MCP 流量。

Kong 从 API 基础设施切入这一领域。Cloudflare 可以将 AI 路由与其庞大的边缘网络相结合。Palo Alto Networks 正在把 AI 网关能力纳入更广泛的企业安全产品组合。

云服务提供商还具备另一项优势。Amazon、Microsoft、Google 和 Databricks 可以将模型访问控制部署在各自身份、数据和 AI 服务的近旁。

这种竞争给独立 AI 网关厂商带来压力。它们必须证明，更深入的 AI 专属功能值得在流量路径中再增加一款产品。

这也给 F5 带来压力。该公司必须证明，其成熟的应用基础设施足够深入地理解智能体行为，能够治理的不只是普通网络请求。

传统网关会检查身份、目的地、请求形态和速率限制。AI 网关还必须判断提示词内容、模型选择、工具意图、数据敏感性以及多步骤行为。

这些决策运行在不同层面。阻止未经授权的数据库工具，是明确的访问控制操作。判断一个获得授权的智能体是否正被检索内容操纵，则需要更具上下文的分析。

如果共享身份与遥测数据能够改善这些决策，平台战略就会奏效。若整合主要只是产出一个统一控制台，而专业控制能力依然浅薄，这一战略就会被削弱。

采购将放大这种张力。安全负责人通常倾向于更少的供应商和一致的证据，而开发团队则偏好快速演进且保持可移植性的工具。

不同组织的结果会有所不同。F5 无需赢得每一个新的 AI 项目。它需要让现有客户将其网关视为通往生产环境的默认路径。

网关可以执行策略，但无法证明安全性

集中式执行能够提升控制力，但并不会让模型输出或智能体行为天然值得信赖。

AI 网关能看到穿越其边界的流量。它可以验证身份、检查内容、记录决策、限制速率，并阻止未经授权的目的地。

但它并不总能判断获准操作是否正确。员工可能有正当权限访问客户记录，却要求智能体执行错误更新。该请求可能满足所有策略，却依然造成损害。

提示词注入也存在类似问题。恶意指令可能出现在网页、文档、消息或检索到的记录中。智能体可能将这些内容视为命令，而非不可信数据。

F5 表示，其防护机制可以阻止提示词注入和越狱尝试。该公司还称，其威胁库每月接收超过 10,000 种攻击模式。这些说法需要结合每位客户的应用和数据进行审慎评估。

模式覆盖并不等于完全防护。攻击者可以改变措辞、将指令拆分到多个输入中、利用应用逻辑，或在通过内容检查后瞄准已获授权的工具。

误报会带来另一种运营风险。严格的过滤器可能阻断有效的源代码、医疗语言、安全研究，或获批工作流所需的客户信息。

当网关无法检查请求时，默认拒绝行为能够限制暴露风险。但在策略服务故障或分类结果不确定时，它也可能中断关键应用。

企业将需要明确的例外处理程序。它们必须知道谁可以覆盖某项决策、该操作如何记录，以及紧急访问是否会造成长期的策略缺口。

延迟同样值得审视。每一次路由决策、内容检查、数据分类和审计操作都需要时间。对于会连续发起多次模型和工具调用的智能体而言，即使是微小延迟也会不断累积。

F5 将该平台描述为适用于高吞吐量流量，但该公司尚未针对每种检查模式发布全面的独立基准测试。买方应测试真实提示词、流式响应和长时间运行的智能体会话。

控制平面本身也会成为敏感基础设施。它可能包含模型凭证、用户身份、提示词内容、工具清单、预算规则以及内部活动记录。

一次攻破可能暴露的远不止一个应用。集中化汇聚了可见性和执行能力，也集中了运营与安全后果。

因此，部署设计至关重要。受监管组织应核实检查在何处进行、哪些数据会传达至 F5 服务、日志如何保留，以及遥测数据中是否会出现敏感内容。

一旦可用，隔离网络支持可能有助于解决部分数据驻留问题。在此之前，买方必须区分当前已交付的能力与计划中的部署选项。

合规措辞同样需要克制。与 SOC 2、ISO 标准或 HIPAA 相关控制保持一致，并不会自动使客户部署变得合规。

合规取决于配置、运营流程、合同、访问审查、保留策略以及周边应用。网关提供的是控制措施和证据，而不是自动认证。

团队还应在网关之外保留记录。事件调查需要应用上下文、模型版本、检索文档、工具结果和人工审批记录。

维护良好的技术知识库可以将这些记录与系统文档关联起来。这类上下文能帮助调查人员理解，为何一个表面上有效的请求会产生意外结果。

最后，网关只能治理经由它路由的流量。员工仍可能使用未经批准的聊天服务、浏览器扩展、直接的服务商凭证或本地模型。

F5 可以与更广泛的影子 AI 控制措施集成，但没有任何网关能够捕获绕过其执行点的流量。架构图应区分受治理的流与仅被发现的流。

F5 的成本主张需要真实工作负载证据

对于某些工作负载而言，令牌支出降低 30% 至 60% 的承诺是可信的，但没有衡量基线，这一区间说明不了太多。

语义缓存可以避免重复调用模型。它不只是匹配完全相同的文本，而是尝试在新请求与已有请求含义大致相近时复用答案。

这一方法最适用于稳定、重复性的查询。客服回复、内部政策问题和常见开发者请求，都可能带来可观的缓存复用。

当答案依赖当前数据、用户专属权限或不断变化的对话上下文时，它的可靠性会下降。复用不合适的响应或许能降低成本，却可能引入不准确信息。

智能路由提供了另一条节省路径。网关可以将常规分类或提取任务导向较小模型，同时将大型模型留给困难请求。

难点在于判断哪种请求需要哪种模型。过于激进的策略可能降低服务商账单，却同时降低回答质量或增加重试次数。

模型分层同样需要评估数据。团队需要针对具体任务的测试，在不同模型之间比较准确性、延迟、安全性和总成本。仅凭价格无法确定正确的路由。

GPU 感知型负载均衡主要适用于运营私有或自托管推理基础设施的组织。它可以通过将请求绕开过载加速器来提高利用率。

但基础设施节省与令牌节省并不相同。企业在分析中应区分服务商费用、GPU 利用率、网关成本、工程时间和失败请求开销。

令牌归因仍可立即带来价值。组织往往缺乏一种一致的方法，能够将模型消耗与团队、用户及应用关联起来。

F5 的按团队预算可以在工作负载超过既定限额之前将其停止。这比等到收到服务商账单后才发现超支更具可操作性。

不过，预算可能会制造扭曲行为的激励。团队可能将应用拆分到不同账户、绕开控制，或选择较弱的模型以维持在任意设定的限额内。

因此，成本策略应与服务级目标相衔接。欺诈系统和内部写作助手不应采用相同的路由或支出规则。

智能体工具调用让核算进一步复杂化。一名员工的一次请求可能触发规划、检索、多次工具调用、验证以及最终模型响应。

F5 表示，其 MCP Gateway 可以消除冗余调用，并将相关令牌浪费最多减少 90%。买方应询问该产品如何定义冗余，以及它是否会改变智能体的执行计划。

阻止完全重复的调用相对安全。抑制两次看似相似的调用则可能存在风险，因为底层数据可能已在两次调用之间发生变化。

团队应使用记录的生产环境追踪数据测试该网关。它们应比较总体任务完成率，而不只是单个请求消耗的令牌数。

一项有价值的评估应涵盖多个维度。应衡量成功结果、重试、缓存错误、安全拦截、延迟、服务商支出、基础设施使用情况和运维人员投入。

基线还必须反映现有控制措施。将 F5 与完全未优化的应用相比，所得表面收益会大于与成熟路由层相比的结果。

这并不意味着节省主张无效。它意味着收益属于特定工作负载和策略设计，而非“网关”这一标签本身。

该公司的经济性主张扩大了潜在买方范围。安全团队获得策略执行能力，平台团队获得路由能力，财务团队获得归因能力。

这种联盟可以加速采用。当降低支出、加强检查和加快响应将路由决策拉向不同方向时，它也可能产生相互冲突的目标。

三项信号将表明 F5 的战略是否奏效

下一场考验并非又一次功能发布，而是企业是否会将有意义规模的生产流量路由至这一整合后的控制平面。

第一个信号是有独立文档佐证的客户采用情况。F5 应展示同时使用 Model Gateway、MCP Gateway 和 AI Guardrails 的生产部署。

这些案例应包括流量规模、部署架构、策略覆盖范围以及可衡量的运营成果。相比对大型企业的匿名说法，详尽的实施案例更能建立信心。

来自受监管行业的证据将尤其重要。金融服务、医疗保健和政府客户面临严格的身份、驻留、审计和可用性要求。

在这些领域取得成功的部署将强化 F5 的统一平台论点。在实验性应用中的有限使用则会表明，该产品仍只是附加层，而非核心基础设施。

第二个信号是成本和性能主张得到验证。客户需要针对令牌减少 30% 至 60% 这一范围提供可复现的证据。

有用的基准测试应披露工作负载类型、缓存率、模型组合、路由规则、响应质量和网关延迟。缺少这些细节，百分比节省仍难以比较。

独立测试还应评估防护机制在负载下的表现。买方需要了解内容检查在故障期间会如何改变延迟、吞吐量、误报率和可用性。

强劲的结果将支持这样一种观点：安全与优化可以共用同一条请求路径。表现不佳则会更有利于将高速路由与更深入的异步分析分开的架构。

第三个信号是竞争对手的反应。Citrix 已将模型与 MCP 治理结合起来，而 Kong、云平台及安全厂商也在持续扩展各自的网关能力。

应关注这些厂商是否会跟进 F5 的共享策略模型、部署选项和应用安全集成能力。同时，也要观察企业是否会要求开放接口，以便替换单个网关组件。

向开放策略格式的转变将削弱高度捆绑的平台。若安全采购趋于整合，则将增强 F5 及其他成熟基础设施提供商的竞争力。

Google News 将持续推送有关统一 AI 治理的公告。更重要的工作发生在这些头条新闻之后：平台团队需要决定，请求在到达模型或工具之前必须经过哪些环节。

企业采购方应在选择网关前梳理实际的 AI 流量。识别直接模型调用、代理工具、敏感数据路径、未经批准的服务，以及无法承受额外延迟的系统。

随后，端到端测试一个具有代表性的生产工作流。衡量任务质量、被拦截的请求、数据暴露情况、响应时间、总成本，以及解释每项决策所需的工作量。

F5 针对 AI 工具蔓延提出了一个连贯的答案：在模型、代理和安全之间采用统一控制平面。未来三个月将揭示，客户究竟会将这一控制点视为基础设施，还是视为又一个需要治理的产品。