AI 基础设施缺失的一层：聚合代理流量

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

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

代理 AI 的崛起（及其不合常规的出站调用）

代理 AI 标志着从简单的文本生成向自主行动的转变：现在，LLM 可以调用 API、链接工具，并独立执行任务。有了像OpenAI、LangChain这样的 function-calling 工具，代理就可以即时查询 API 或数据库。更高级的设置使用像ReAct这样的规划循环来自主执行多步骤目标，有效地将 AI 代理转变为运行时 API 客户端。

这颠覆了传统的 API 模型。应用程序不再处理入站流量，而是通过其 AI 组件生成出站 API 调用。Gartner 将此称为“由生成式 AI 消费的 API”，并且指出，LLM 作为主要 API 消费者的趋势正在上升。开发者越来越多地连接助手和代理，通过发送 API 请求来达成用户提示。

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

早期采用者遇到了真正的问题：

• 成本不可预测：代理可能陷入失控循环，在不知不觉中累积 LLM 或 API 使用量。一个行为不当的代理可能通过反复调用外部服务导致预算超支。

• 安全风险：赋予代理宽泛的凭证引入了危险。有这样一个案例，一个连接到 GitHub 的 AI 助手被提示注入所欺骗泄露了私有仓库数据——因为它的令牌权限过于宽泛。

• 缺乏可见性或控制力：如果代理行为怪异或危险，团队通常无法看到发生了什么或为什么发生。没有适当的遥测或控制循环，很难进行调试或在执行过程中进行干预。

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

从以往的转变中吸取的教训：每次转变都会出现新的网关和治理模式

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

软件架构的每次重大转变最终都需要一个中介层来恢复控制。当 Web API 兴起时，API 网关成为管理认证/授权、速率限制和策略的必备工具。随着微服务的出现，用于管理内部流量的服务网格应运而生。每一次，只有当规模之痛浮出水面时，这种需求才会变得清晰。

代理 AI 也走在同样的道路上。各团队都在通过独立 API 调用连接机器人和助手——单纯演示的话这很好，但在生产中却会出现问题，如成本超支或不安全访问。这时，组织才会意识到他们需要的是结构化的解决方案，而非临时拼凑的权宜之计。

Gartner 已经注意到了这一趋势，在2024年API管理炒作周期中，他们将 AI 网关命名为一个新兴类别。像Kong和Cloudflare这样的供应商正在进入这个领域，还有像Lunar.dev这样的初创公司。观点就是：如果暴露的 API 需要治理，那么 AI 驱动的 API 消费也需要治理。

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

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

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

直到最近，早期采用者还试图使用轻量级代理或开源“LLM路由器”控制大型语言模型（LLM）的行为。这些解决方案的应用范围往往有限——设计用于在模型之间路由请求或注入凭据——但它们并非为生产规模的治理、成本管理或安全执行而构建。

尽管 AI 网关的概念仍处于新兴阶段，但开发者可以使用熟悉的开源基础设施来构建自己的网关。

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

示例：将动态 API 密钥注入到出站 LLM 流量：

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

随着 AI 代理的自主性增加，以及像模型上下文协议（MCP）这样的协议获得关注，这些 DIY 方法的局限性开始显现。曾经看似实验性的设置如今产生了无限制的 API 循环调用、失控的令牌成本和对敏感系统的意外访问。

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

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

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

更具体地说，AI 网关通常被实现为出站代理（也称为反向 API 网关），它们拦截并实时管理由 AI 代理发起的流量。一个常见的参考设计由以下几个组件构成：

• 流量拦截器：捕获来自代理或 LLM 运行时的所有出站 HTTP 流量。

• 策略引擎：根据动态规则评估请求——例如，应用速率限制、注入头部或拒绝不安全的提示。

• 路由和成本管理器：确定要调用哪个模型或提供商的 API（如 OpenAI 与 Claude），同时跟踪令牌使用情况并执行成本控制。

• 可观察性和审计层：流式传输结构化日志、指标和可选的完整 HAR 捕获，用于调试、监控和合规检查。

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

该架构使组织能够在尽可能不额外增加延迟的情况下，对 AI 驱动的流量实施安全防护措施，同时全面掌握哪些代理在何时以何种方式调用了哪些服务。

AI 网关的关键功能包括：

• 安全凭据处理：网关存储和管理 API 密钥，将它们与代理隔离，并启用密钥轮换或额外的认证层。这防止了基于提示的泄露或滥用。

• 速率限制和配额：AI 代理通常会产生基于使用的开销。网关可以应用基于令牌的限制或请求配额，从而防止成本失控并执行预算。

• 多提供商路由：网关抽象了后端并动态路由请求，而不是硬编码 API 提供商。这样可以优化成本，避免供应商锁定，并支持多 LLM 设置。

• 请求调解和增强：网关可以注入策略、增强提示（如附加企业上下文）或执行集中检索步骤——标准化代理的行为。

• 输出防护：网关扫描和过滤来自 AI 服务的响应，标记或阻止不安全、冒犯性或敏感内容，然后才送达最终用户。

• 数据隐私执行：网关通过屏蔽敏感数据或阻止可疑的出站活动来帮助执行合规性，从而消除像无意泄漏数据这样的风险。

• 缓存和性能优化：通过缓存响应（甚至是语义上的），网关减少了延迟和 API 成本。它还可以跟踪和优化延迟和吞吐量。

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

由于这个领域仍然处于早期阶段，目前尚没有单一的解决方案可以满足所有需求。团队应该根据他们的优先事项评估不同的选项——无论是成本控制、安全性还是合规性。一个实用的路径是，从轻量级代理开始，然后随着生态系统的成熟而演进。

AI 代理的安全与合规

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

• 认证与授权：一个主要风险是代理超出其预期范围行事。网关可以通过调解凭证和注入短期、有范围限制的令牌来强制执行最小权限。与依赖宽泛的 OAuth 访问不同，每个代理到工具的交互都可以被严格控制。有人预测会出现专门的“MCP网关”，仅用于处理安全的代理-工具交换。关键是将代理视为不可信用户，限制他们的权限。

• 人工介入控制：对于敏感操作（如大额交易），网关可以在手动批准之前暂停执行。这时网关充当了一个断路器，实现了自动化与人工监管的平衡。

• 监控与审计：通过网关聚合代理流量可以实现丰富的日志记录。这些日志——记录谁发起了什么请求，到哪里，结果如何——应该输入到可观察性和 SIEM 工具中，使团队能够追踪事件，检测异常，并在发现不寻常行为（如使用量激增或访问新端点）时发出告警。

• 合规性：网关可以过滤或标记敏感数据，确保代理遵守数据隐私规则。它们还提供了清晰、可审计的记录，说明 AI 的使用情况——这对于满足监管和道德标准至关重要。

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

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

模型上下文协议（MCP）：MCP 是一个由 Anthropic 引入的新兴标准，用于将 AI 代理连接到工具和数据。有了它，开发者只需一次性定义连接器，任何符合 MCP 的代理就都能使用它们——它就像“AI 代理的 USB-C”。这简化了集成，并使代理与特定的 LLM 解耦。

但访问简单了，安全风险增加了。代理可能会滥用权限过于宽泛的连接器，或成为提示注入或“静默重定义”攻击的受害者。强大的范围限制、沙箱和基于网关的控制对于防止滥用至关重要。

Agent2Agent（A2A）：谷歌的A2A协议专注于代理协作——允许代理之间传递任务和数据。它支持更复杂的工作流，但增加了级联故障或滥用的风险，突显了对监督和治理层的需求。

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

现在就准备你的基础设施（和团队）

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

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

• 强制执行硬性限制：设置超时、最大重试次数和 API 预算。终止那些无谓地消耗令牌或金钱的循环。断路器适用于微服务——将同样的思维应用于代理。

• 添加网关层：你不需要立即使用商业解决方案。重新利用像Envoy、HAProxy这样的工具，或者 LLM API 的简单包装器来控制和观察流量。一些团队在几天内就构建出了最小的“LLM 代理”，添加了日志记录、杀死开关和速率限制。

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

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

• 鼓励实验：让团队自由探索，但需在沙盒环境中进行。使用模拟数据和测试账户，确保任何实验在出现问题时都能迅速终止。假设会发生故障，并确保能够及时控制。

代理 AI 的兴起令人兴奋，但如果缺少治理，就会带来混乱。正如企业在过去十年中建立了云治理体系一样，当今组织也需要建立 AI 代理治理体系。幸运的是，许多模式都是我们所熟悉的：代理、网关、策略、监控。现在就开始，趁着风险还低。一个设计良好的 AI 网关和治理层将成为未来 AI 原生系统的核心——实现规模化，同时确保安全。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：

https://www.infoq.com/articles/ai-infrastructure-aggregating-agentic-traffic/