在将 AI 注入应用程序的热潮中，一种新的流量正在悄然爆发：自主 AI 代理自行调用 API 和服务。大型语言模型（“LLM”）“代理”可以规划任务、链接工具使用、获取数据，甚至启动子任务——所有这些都通过传统基础设施未监控的出站请求进行。这种由代理驱动的出站流量（称为代理流量）是当今 AI 基础设施中缺失的一层。我们有用于入站 API 调用的 API 网关和用于微服务到微服务通信的服务网格，但谁在管理 AI 代理自主发出的出站调用？

构建原生 AI 平台的软件架构师和工程领导者开始注意到熟悉的警告信号：AI API 账单上的成本突然飙升、具有过度广泛权限的机器人访问敏感数据，以及对这些 AI 代理正在做什么缺乏令人不安的可见性或控制。这是一个让人想起微服务早期的场景——在我们拥有网关和网格来恢复秩序之前——只是现在“微服务”是半自主的 AI 例程。[Gartner]已开始关注这一新兴差距。在其 2024 年 API 炒作周期中，“AI 网关”出现在创新触发阶段，作为管理 AI 消费的新兴解决方案。信息很明确：我们需要一个新的聚合和治理层来管理 AI 代理流量，并且我们需要尽快做到这一点。

代理 AI 的兴起（及其挑衅性的出站调用）

代理 AI 标志着从简单的文本生成向自主行动的转变：LLM 现在调用 API、链接工具并独立执行任务。借助[OpenAI]（https://platform.openai.com/d...）、[LangChain]（https://www.cohorte.co/blog/a...）等函数调用工具，代理可以即时查询 API 或数据库。更高级的设置使用[ReAct]（https://research.google/blog/...）等规划循环来自主追求多步目标，有效地将 AI 代理转变为运行时 API 客户端。

这逆转了传统的 API 模型。应用程序现在不是处理入站流量，而是通过其 AI 组件生成出站 API 调用。Gartner 将此称为“由生成式 AI 进行的 API 消费”，并指出 LLM 作为主要 API 消费者的上升趋势。开发人员越来越多地连接助手和代理，这些助手和代理用请求淹没 API 以满足用户提示。

问题是？大多数基础设施并非为此而构建。传统的 API 网关管理入站流量，但代理调用通常完全绕过它们，显示为正常的出站 HTTP 请求。这留下了关键的盲点。

早期采用者遇到了实际问题：

• 不可预测的成本：代理可能陷入失控的循环，在未被注意的情况下增加 LLM 或 API 的使用。单个行为不当的代理可能会通过反复调用外部服务而引发预算超支。
• 安全风险：给代理提供广泛的凭据会带来危险。在一个案例中，一个与 GitHub 连接的 AI 助手通过提示注入被欺骗，泄露了私人存储库数据——因为其令牌具有过度广泛的权限。
• 缺乏可见性或控制：如果代理行为异常或危险，团队通常无法了解发生了什么或为什么。没有适当的遥测或控制循环，很难在执行过程中进行调试或干预。

这是一个新形式的熟悉的工程挑战：对新的活动渠道实施治理。就像过去的技术创新浪潮（如[微服务]（https://en.wikipedia.org/wiki...）和云 API）需要[服务网格]（https://en.wikipedia.org/wiki...）和网关一样，代理 AI 现在也需要自己的管理层。一个新的共识正在形成——我们需要专门构建的基础设施来管理 AI 驱动的流量。

过去转变的教训：每次都会出现网关和治理

/filters:no_upscale()/articles/ai-infrastructure-aggregating-agentic-traffic/en/resources/141figure-1-1755682461248.jpg)

图 1：显示用于入站流量的 API 网关和用于管理出站代理流量的 AI 网关的企业架构（参考）

软件架构的每一次重大转变最终都需要一个中介层来恢复控制。当 Web API 兴起时，API 网关成为管理身份验证/授权、速率限制和策略的必要条件。随着微服务的出现，服务网格应运而生以管理内部流量。每次，只有在规模带来的痛苦出现后，需求才变得清晰。

代理 AI 也在同一条道路上。团队正在连接独立调用 API 的机器人和助手——这在演示中非常好，但在生产中出现成本超支或不安全访问等问题时就会出现问题。那时，组织意识到他们需要结构，而不是临时解决方案。

Gartner 已经指出了这一趋势，在其[2024 API 管理炒作周期]（https://www.gartner.com/docum...）中将 AI 网关列为新兴类别。像[Kong]（https://konghq.com/products/k...）和[Cloudflare]（https://www.cloudflare.com/de...）这样的供应商正在进入这个领域，还有像[Lunar.dev]（https://github.com/TheLunarCo...）这样的初创公司。想法是：如果 API 暴露需要治理，那么由 AI 驱动的 API 消费也需要。

AI 网关翻转了传统模型——管理内部 AI 代理如何调用外部服务。它们提供诸如提示感知策略、使用跟踪、多 LLM 路由和密钥保护等功能——这些功能是标准 API 网关未构建的。

这不是对现有基础设施的替代，而是一种补充。Gartner 设想了一种双层方法：传统网关用于入站流量，AI 网关用于出站，在所有 API 使用（人类或 AI）中创建统一的控制平面。

为什么 AI 网关变得至关重要

直到最近，尝试控制 LLM 行为的早期采用者依赖于轻量级代理或开源“[LLM 路由器]（https://www.litellm.ai/）”。这些解决方案通常范围狭窄——旨在在模型之间路由请求或注入凭据——但并非为生产规模的治理、成本管理或安全实施而构建。

虽然 AI 网关的概念仍在出现，但开发人员可以使用熟悉的[开源基础设施]（https://aigateway.envoyproxy....）启动自己的网关：

Envoy Proxy：一个强大的 L7 代理，支持过滤器和 Lua/Wasm 扩展。您可以拦截出站流量并应用自定义逻辑进行速率限制、标头注入或路由。

示例：在出站 LLM 流量中注入动态 API 密钥：

http_filters:
  - name: envoy.filters.http.lua
    typed_config:
      inline_code: |
        function envoy_on_request(request_handle)
          request_handle:headers():replace("Authorization", "Bearer my-token")
        end

随着 AI 代理变得更加自主并且像模型上下文协议（[MCP]（https://modelcontextprotocol....））这样的协议获得关注，这些 DIY 方法的局限性正在显现。曾经看似实验性的设置现在正在产生无界的 API 循环、失控的令牌成本以及对敏感系统的意外访问。

这种转变使得工程领导者越来越迫切地需要重新考虑如何管理出站 AI 流量。AI 网关正在成为一个基础控制层——提供一种一致、可扩展的方式来保护代理行为、优化成本并在快速发展的代理架构中应用使用策略。

AI 网关：AI 代理的新兴聚合层

那么，AI 网关到底是什么？其核心是一个中间件组件——可以是代理、服务或库——所有 AI 代理对外部服务的请求都通过它进行路由。而不是让每个代理独立访问它想要的任何 API，您通过网关路由这些调用，然后网关可以强制执行策略并提供集中管理。

更详细地说，AI 网关通常实现为出站代理（又名反向 API 网关），实时拦截和管理 AI 代理发起的流量。一个常见的参考设计包括几个集成组件：

• 流量拦截器：捕获来自代理或 LLM 运行时的所有出站 HTTP 流量。
• 策略引擎：根据动态规则评估请求——例如，应用速率限制、注入标头或拒绝不安全的提示。
• 路由和成本管理器：确定要调用哪个模型或提供程序（例如，OpenAI 与 Claude），同时跟踪令牌使用情况并执行成本控制。
• 可观察性和审计层：流式传输结构化日志、指标和可选的完整 HAR 捕获，用于调试、监控和合规性。

/filters:no_upscale()/articles/ai-infrastructure-aggregating-agentic-traffic/en/resources/109figure-2-1755682461248.jpg)

图 2：AI 网关管理出站 LLM 和 MCP 流量到外部提供程序。（参考）

这种架构允许组织以最小的附加延迟对 AI 驱动的流量实施护栏，同时获得对哪些代理调用什么、何时以及如何调用的完全可见性和控制。

关键功能包括：

• 安全凭据处理：网关存储和管理 API 密钥，将其与代理隔离并启用密钥轮换或额外的身份验证层。这防止了[基于提示的泄漏]（https://genai.owasp.org/llmri...）或滥用。
• 速率限制和配额：AI 代理通常会产生基于使用量的成本。网关可以应用基于令牌的限制或请求配额，以防止成本失控并强制执行预算。
• 多提供程序路由：网关不是硬编码 API 提供程序，而是抽象后端并动态路由请求——优化成本、避免供应商锁定并支持多 LLM 设置。
• 请求中介和增强：网关可以注入策略、增强提示（例如，附加企业上下文）或强制实施集中检索步骤——使代理的行为标准化。
• 输出防护栏：网关扫描和过滤来自 AI 服务的响应，在其到达最终用户之前标记或阻止不安全、冒犯性或敏感内容。
• 数据隐私执行：网关通过屏蔽敏感数据或阻止可疑的出站活动来帮助执行合规性——解决诸如无意的数据泄露等风险。
• 缓存和性能优化：通过缓存响应（甚至是语义上的），网关可以降低延迟和 API 成本。它还可以跟踪和优化[延迟]（https://latitude-blog.ghost.i...）和吞吐量。

简而言之，AI 网关充当所有 AI 驱动的 API 调用的控制点——强制执行策略、提供可见性并优化使用。它帮助组织重新获得对代理流量的监督。

由于该领域仍处于早期阶段，没有单一的解决方案能够满足所有需求。团队应根据其优先级评估选项——无论是成本控制、安全性还是合规性。现在从轻量级代理开始并在生态系统成熟后进行演进是一条实用的道路。

为 AI 代理导航安全和合规性

即使有网关到位，自主 AI 代理的安全和治理仍然是一个多方面的挑战。值得关注一些具体的问题以及聚合层如何帮助解决它们（以及其他实践）：

• 身份验证和授权：一个主要风险是代理超出其预期范围行事。网关可以通过调解凭据并注入短期、范围受限的令牌来实施最小权限。而不是依赖广泛的 OAuth 访问，每个代理到工具的交互都可以受到严格控制。一些人预测专门的“[MCP 网关]（https://www.docker.com/blog/d...）”将出现，专门用于处理安全的代理 - 工具交换。关键是将代理视为不受信任的用户——限制它们的权限。
• 人工干预控制：对于敏感操作（例如，大笔交易），网关可以暂停执行，直到获得手动批准。这就像一个断路器，在自动化和监督之间取得平衡。
• 监控和审计：通过网关聚合代理流量可以实现丰富的日志记录。这些日志——捕获谁发出了什么请求、到哪里、结果如何——应该馈入可观察性和 SIEM 工具。这使团队能够跟踪事件、检测异常并对异常行为（例如，使用量飙升或访问新端点）发出警报。
• 法规遵从性：网关可以过滤或标记敏感数据，确保代理遵守数据隐私规则。它们还提供清晰、可审计的记录，说明 AI 的使用方式——这对于满足法规和道德标准至关重要。

/filters:no_upscale()/articles/ai-infrastructure-aggregating-agentic-traffic/en/resources/90figure-3-1755682461248.jpg)

图 3：MCP 聚合点管理整个组织中的多个 MCP 服务器。（参考）

MCP 和 A2A：AI 代理生态系统中的早期标准

模型上下文协议（MCP）：由 Anthropic 引入，MCP 是连接 AI 代理与工具和数据的新兴标准。它允许开发人员定义一次连接器，使任何 MCP 兼容的代理都可以使用它们——就像“AI 代理的 USB-C”一样。这简化了集成并将代理与特定的 LLM 分离。

但更轻松的访问带来了安全风险。代理可能会滥用具有过度广泛权限的连接器或成为[提示注入或“静默重新定义”]（https://orq.ai/blog/prompt-in...）攻击的受害者。强大的范围界定、沙盒化和基于网关的控制对于防止滥用至关重要。

Agent2Agent（A2A）：谷歌的[A2A]（https://developers.googleblog...）协议专注于代理协作——允许代理在彼此之间传递任务和数据。这支持更复杂的工作流，但增加了级联故障或滥用的风险，突出了监督和治理层的必要性。

多个标准正在形成——OpenAI 工具、LangChain 协议、思科的 ACP 等。虽然所有这些都旨在简化 AI 代理开发，但它们也引入了不一致性和潜在的漏洞。组织应谨慎采用，通过适当的身份验证、审计和策略实施来保护代理 - 工具交互——理想情况下通过专用的 AI 网关。

现在准备您的基础架构（和团队）

我们仍处于代理 AI 的早期阶段，这使得在使用量爆炸之前奠定基础成为完美的时机。工程领导者可以开始构建轻量级框架、策略和工具，为规模做好准备。

从可见性开始：审计代理已经在何处自主运行——聊天机器人、数据总结器、后台作业——并添加基本日志记录。即使是简单的日志，如“代理 X 调用了 API Y”也比没有好。通过代理或现有网关以反向模式路由流量，以避免盲点。

实施硬限制：设置超时、最大重试次数和 API 预算。杀死不必要地消耗令牌或美元的循环。断路器适用于微服务——将相同的思维应用于代理。

添加网关层：您不需要立即使用商业解决方案。重新利用[Envoy]（https://github.com/envoyproxy...）、[HAProxy]（https://github.com/haproxy/ha...）或 LLM API 周围的简单包装器来控制和观察流量。一些团队在几天内构建了最小的“LLM 代理”，添加了日志记录、关闭开关和速率限制。

定义组织范围的 AI 策略：设置 AI 代理行为规则——例如，限制对敏感数据的访问或要求对受监管的输出进行人工审查。这些策略可以通过网关和开发人员培训来实施。

/filters:no_upscale()/articles/ai-infrastructure-aggregating-agentic-traffic/en/resources/59figure-4-1755682461248.jpg)

图 4：根据公司政策限制对 AI 代理的访问。（参考）

鼓励安全实验：让团队进行探索，但对代理进行沙盒化。使用虚假数据、测试帐户，并确保每个实验在出现问题时都可以快速停止。假设失败并控制它们。

代理 AI 的兴起令人兴奋，但如果没有治理，它将引发混乱。就像公司在上个十年建立云治理一样，当今的组织需要 AI 代理治理。幸运的是，许多模式都是熟悉的：代理、网关、策略、监控。现在开始，在风险较低的时候开始。一个设计良好的 AI 网关和治理层将成为未来原生 AI 系统的支柱——实现安全的规模。