一种用于管理 AI 变革步伐的演进式架构模式

本文由 InfoQ 认证架构师在线活动的参与者撰写。这是他们工作的集大成之作，反映了该期活动的参与者在 AI 与现代软件架构交叉领域中所获得的集体见解。

简介

企业级 AI 的集成层如今已经成为大多数系统中发展最快的部分，但目前尚无任何一方将其作为一个统一的层来处理。在压力下推进项目的团队各自选择自己的模型、工具和防护措施。

这首先是一个演进式架构问题，其次才是 AI 问题。AI 能力的变革步伐不太可能放缓。新模型、新协议和新故障模式将继续以一种企业系统从未要从设计上进行应对的节奏涌现。关键的问题不在于如何减缓这种变革，而在于应将其置于架构中的什么位置，以便系统的其余部分能够保持现状。

AI 网关是其中的一个解决方案：一个架构接缝，在这里，AI 系统中变化最快的组件（防护措施、模型路由、代理身份、行动策略和审计）可以按照自己的节奏演进，而其背后的系统则保持稳定。当 AI 系统正在自主行动而非仅仅生成文本时，这种模式尤为重要。调用大语言模型（LLM）的服务面临的问题范围是有限的，而能够感知、决策和行动的代理系统，则带来了范围大得多的关注面。本文探讨了该模式、其中的权衡取舍，以及在何种条件下值得采用该模式。

图 1：AI 网关作为稳定的企业系统与快速发展的 AI 生态系统之间的纽带，通过一个控制平面承载四种流量类型：LLM 同步服务、代理到 LLM、代理到 MCP 以及代理间通信（图片来源：作者原创）

演进失调

当今企业级 AI 面临的最大挑战之一并非模型性能，而是生态系统的变化速度。通常，企业系统以稳定性为核心构建。核心业务平台、集成层、治理流程和安全控制措施往往需要数年而非数月才能完成演进。而 AI 生态系统的运作方式则截然不同。如今，主要模型供应商每年都会多次发布新模型、更新和功能。这不是随着技术成熟就会消失的短期挑战，而是源于 AI 与企业系统的发展速度存在根本性的差异。

图 2：2024–2026 年 AI 领域的快速变化（图片来源：作者原创）

这个问题不限于模型本身。新的协议和标准也在迅速发展。作为模型连接工具和外部数据源的一种方式，模型上下文协议（MCP）已经迅速获得了广泛的采用，但其规范仍然在不断完善之中。随着应用范围的扩大，身份验证、传输机制和工具发现等功能也发生了变化。与此同时，支持自主代理之间通信的代理间（A2A）协议也正在兴起。尽管前景可期，但目前还缺乏明确的行业标准，不同供应商采取的方法也略有差异。对于架构师和工程师而言，他们如今集成的技术栈的某些部分，在 12 个月后可能会呈现出截然不同的面貌。

安全性问题又增添了一层复杂性。每次新增模型集成、工具连接或代理工作流，都会引入新的攻击面。提示注入攻击、数据泄露、工具权限过高以及代理之间的信任问题，都是架构团队如今必须考虑的隐患。例如，连接到内部知识库和工单系统的客户支持代理，可能会被隐藏在客户消息中的恶意提示所操控，从而导致其泄露敏感信息或执行超出预期范围的操作。与传统的企业集成（其接口可能数年间保持稳定）不同，AI 集成往往会随着底层模型和协议的变化而不断调整。

正因如此，应将这一挑战视为架构问题而非 AI 问题，因为 AI 仅仅是必须与现有系统集成的另一种工具。借助演进式架构中的概念（如适应度函数、架构量子和演进压力），问题便变得清晰起来：变化最快的组件应归属于何处？如果这个边界设计不佳，变化将蔓延至整个系统；如果设计得当，企业平台的大部分便可以保持稳定，同时 AI 层仍然可以持续演进。

为什么这不只是一个 API 网关的问题

当企业开始将 AI 集成到其系统中时，第一反应往往是将模型和代理视为普通的 API 调用方。这种逻辑可以理解：企业已经拥有能够处理身份验证、速率限制、路由、可观测性和策略执行的 API 网关。既然网关已经部署在平台的边缘，为何还要引入另一个架构组件呢？挑战在于，代理系统违背了传统 API 网关设计所做的假设。这并不意味着现有的网关已经过时，但确实可以表明仅靠它们已经不够。

图 3：传统 API 网关与 AI 网关的对比（图片来源：作者原创）

第一个假设是决定论。传统的网关部署在服务之前，而这些服务的行为通常是可预测的。在输入相同的情况下，API 通常会产生相同的输出或执行相同的操作。而代理系统并非如此。相同的提示可能会产生不同的响应、不同的推理路径，甚至不同的工具选择。这使得测试、审计和事件调查都变得困难许多。网关可以告知你请求已发出，但无法解释代理为何调用某个工具，或是为何选择某项操作而非另一项。

第二个假设是故障发生在模式层。API 网关非常擅长检测格式错误的请求、无效令牌、缺失的参数，或是超出策略限制的流量。而代理故障往往是语义层面而非技术层面的。一个请求从协议角度来看可能完全有效，但仍然可能代表一个错误的决策。试想有一个代理：它向错误的客户发放了退款，检索了任务中并不需要的敏感数据，或者基于被篡改的上下文执行了破坏性操作。该请求本身的格式可能是正确的，而且经过了完整的身份验证。问题在于，这个请求从一开始就不应该被发出。这带来了全新的攻击面，包括提示注入、上下文投毒以及工具滥用。

最后一个假设是，操作在到达系统之前已由客户端完全指定。传统网关假设客户端已经确定了要执行的操作。网关会验证请求，但不会评估该操作是否符合用户的目标。代理系统引入了额外的决策层。代理会解读目标、推导可能的操作，并决定调用哪些工具。因此，用户意图与系统行为之间的关系变成了间接的。理解为何采取某项操作、该操作是否合理以及是否符合政策，便成为架构层面的关注点。

模式：将防护措施作为演进式架构接缝

此类需求需要一个落脚点。这一层就是 AI 网关：它是一个用于模型路由、身份识别、操作策略、内容保护和审计的统一控制平面。由于这些组件的变化速度都快于其背后的服务，所以每个组件只需要一个而非多个执行接口。

图 4：AI 网关控制平面。每个控制平面的更新频率低于其所管理的对象，因此，网关后面的应用程序可以保持稳定。参考文献： CNCF、 NIST SP 800-207、 CSA ATF、 OWASP LLM01/02、 OTel GenAI、《欧盟人工智能法案》（图片来源：作者原创）

模型路由与提供商抽象

模型是整个技术栈中变化最快的组件。其功能、定价和排名都在不断变化。大多数系统都需要同时采用顶级模型、低成本模型、微调模型或自托管模型。网关能够隔离这些变化，从而在不修改应用程序的情况下实现模型替换、成本优化以及提供商故障转移。

安全

对于人类和已知的服务而言，身份识别与授权机制已经相当成熟，但对于代表彼此行事的代理而言则并非如此。授权委托是尚待解决的关键问题，相关协议标准也在快速更新（图 2）。一个能够承载授权委托链而非中断该链的网关，使得遵循这些快速变化的标准变得经济高效。

操作策略对代理操作采用“零信任”原则：每次操作都会根据策略进行核查，确保每项操作都遵循最小权限原则。在发生提示注入劫持之前签发的令牌仍然有效，因此，按操作进行的核查无法阻止劫持行为，但可以阻止被劫持的操作获得授权——根据 NIST SP 800-207 标准，网关作为策略执行点可以发挥这一作用。

分段控制的重点不在于代理的身份或其可能执行的操作，而在于其能够访问的范围——包括哪些代理、哪些工具，甚至是否能访问互联网——从而确保被入侵的代理无法向其他系统做横向移动。

内容防护机制旨在遏制而非彻底消除注入和信息泄露。它具有双向作用：既检查输入数据中的注入行为，也检查输出数据中的信息泄露或违规内容。由于规避技术不断演变，将检查分散到各个应用程序中不仅会延长响应时间，还会增加更新操作的复杂性。在网关处集中管理不仅高效，而且对安全至关重要：只需要在一个地方进行更新，就能跟上攻击演变的速度。

可观测性和审计

监控和记录并非可有可无；对于非确定性自主代理而言，这是基础。这两项工作有所不同：可观测性属于运维范畴，旨在捕捉系统运行过程中出现的漂移和成本激增；而审计则属于证据范畴，旨在日后向监管机构提供依据并要求保留记录，而《欧盟人工智能法案》将进一步提高这一标准。普通的日志仅记录了调用发生的事实，却无法解释代理为何采取该行动。我们需要的是语义日志：请求 → 决策 → 行动。

图 5：语义日志记录示例（图片来源：作者原创）

将该记录集中存储在网关处是演进式架构设计的一大举措：每个调用都通过该网关，因此当需求发生变化时——无论是新增合规条款、新增提供商，还是延长保留期限——只需修改一个层级，而非 N 个应用程序。这也是在存储前对个人身份信息（PII）进行脱敏或哈希处理的一个天然的单点，即存储输入的哈希值而非原始提示文本，因为保留原始提示文本本身存在违反《人工智能法案》的风险。

实际执行

这并非假设：kgateway 的 Agent Gateway、Portkey 和 LiteLLM 都已经实现了其中的一部分职责。当前正在兴起的模式是“策略即配置”（policy-as-config）：将防护措施、分段管控和路由规则声明为受版本控制的配置，在拉取请求（PR）中进行审查，并独立于网关后端的应用程序进行部署（即 OPA 采用的声明式模型）。这种模式清晰地划分了责任归属：安全团队负责策略，平台团队负责网关。CSA ATF 推荐的就是这种向“策略即代码”的转变。

# 将 code-review-agent 的网关策略作为一个配置文件# 可以进行版本控制，并在 PR 合并前进行审查agent: code-review-agent       # 身份authorization:  allow:    - repo.read    - pr.comment    - static_scan.run          # 跟踪记录中显示的工具操作  deny:    - repo.push    - pr.merge    - secrets.readtools:                         # 代理可能进行的外部调用  - github-mcp                 # MCP 服务器：get_pr_diff  - static_scanguardrails:                    # 提示词与内容保护  input:    - prompt_injection_filter  output:    - secret_redactionrouting:                       # 模型路由 / 提供商  default:  gpt-4o  fallback: self-hosted-slmobservability:                 # 记录 → 请求 / 决策 / 行动  logging: semantic

图 6：简化的代理网关策略，展示了“策略即配置”模式（来源：作者原创）

该网关为所有这些提供了一个统一的修改入口。接下来要探讨的问题是，这种集中化要付出怎样的代价。

权衡取舍以及该模式何时不适用

在采用任何解决方案时，都应该考虑可能产生的影响和取舍。

图 7：哪些情况下 AI 网关可能不适用（图片来源：作者原创）

延迟和吞吐量

每添加一项 AI 网关功能都可能影响延迟和吞吐量。部分大语言模型（LLM）的能力可能会通过协议转换的方式来提供，以实现 API 的平台无关性。代理与数据源、工具或其他代理之间的连接都将通过 AI 网关进行。供应商可能会根据其提供的套餐设置吞吐量限制。

请通过基准测试来确定新增的延迟和吞吐量限制。这种模式可能不适合对延迟敏感的工作负载，那可能需要自建、专用或专业化的 AI 网关。如果无法在预算范围内满足延迟和吞吐量要求，那么 AI 网关可能就不是一个可行的选项。

集中化

每个领域可能都有自己的 API 网关。不过，一个集中管理的 AI 网关可以简化治理工作，尤其是在环境发生变化时。需要有一个专门的团队负责管理 AI 网关，承担运营和维护方面的职责。根据团队的组织结构不同，可能还有其他团队参与管理成本控制、防护措施以及数据源、模型和工具等资源的供给。各团队可能针对特定的工作负载来管理这些内容。明确各项职责的归属，有助于变更实施时的顺利推进。

在考虑部署 AI 网关之前，可能需要识别并克服一些组织层面的障碍。

概率性防护

防护措施可以缓解某些风险，但无法彻底消除风险。误报可能会降低应用程序的有效性或引发用户不满，例如将某人的名字误判为粗俗语言（即斯肯索普问题）。误判（false negatives）则可能导致安全事件或法律问题，例如基于机器学习的防护措施未能阻止恶意用户对聊天机器人进行越狱攻击。在评估防护措施的好处时，需要权衡其对工作负载和客户满意度的潜在影响。

运营成本

提升可观测性将带来一定的财务成本。随着 API 的变更和功能的增加，负责管理 AI 网关及其连接设备的团队将需要进行维护。如果选择自主部署，还将产生资源成本。这些成本可能会影响采用率，但应当将其与后续可能引发的安全事件、超预算使用所带来的冲击放在一起进行权衡考量。

提供商原生功能

AI 网关可以提供用于访问大语言模型（LLM）能力的标准化 API。这使得切换不同的提供商变得更加容易，或者可以通过同一端点有条件地使用不同的提供商。然而，当提供商推出新功能时，从功能发布到实际可用之间可能会存在延迟（如果该功能最终会上线的话）。如果 AI 网关支持添加自定义功能（如大语言模型或安全防护解决方案），则可以减轻潜在的影响。

如果这不是正确的解决方案呢？

AI 网关提供的任何功能都可以在应用程序中实现。虽然这能降低延迟，但设计时需要避免实现层面的紧密耦合，并确保可观测性不受影响。此外，可以利用可观测性和成本控制措施来腾出预算空间，为未来采用该技术铺平道路。

这些好处与成本都需要权衡取舍。如果当前仅少量团队、大语言模型或安全防护规则投入使用，那么对于生产环境的工作负载而言，这可能并不划算。但在开发环境中，这可能有价值，不过过度使用可能会带来高昂的成本。

演进历史

整个行业都有一个整合发展的趋势，尽管各家组织所处的阶段各不相同。撰写本文的团队经历了第一阶段和第二阶段，并在相关的领域里有成熟网关模式的实践经验。根据有记录的事件和全行业普遍存在的模式，我们总结了大多数企业都会经历的四个阶段。每个阶段的具体形态因所涉及的 AI 系统是大语言模型（LLM）调用服务还是自主代理而有所不同，其中后者会带来运营风险的阶跃式变化。

第一阶段：1 个团队，1 个提供商

大多数已开始整合 AI 的企业都处于这一阶段或接近这一阶段。通常由一个团队采用一家模型提供商的服务，而且多用于内部使用。代码助手和 PR 审查工具是常见的切入点，此外还有针对特定客户群体的试点项目。其架构简单，集成直接，运营风险有限。我们的一些组织正处于或接近这一阶段，已经将 AI 部署到开发工具中，并应用于范围严格界定的用例。

第二阶段：扩大采用范围

一旦第一项能力的价值得到确认，就会迅速出现更多的功能需求。各团队会采用自己偏好的模型，通常会选择不同的供应商。每个团队都会在身份验证、提示词处理和安全防护措施方面做出自己的选择。安永（EY） AI 平台公开表示，其运营着超过 50000 个 AI 代理。Zapier 报告称，其员工队伍为 360 人，而全公司范围内部署了超过 800 个 AI 代理。这意味着该公司 AI 代理的数量超过了员工数量。我们行业社群中的部分组织目前正处于这一阶段：通过多种集成路径，基于大语言模型（LLM）的服务在多个产品线上实现生产级运行规模；标准 API 领域有成熟的网关实践，但与此同时，在特定于 AI 的控制措施（如个人身份信息处理、提示词注入检测）方面存在着公认的缺口。在部署自主代理之前，有意识地先奠定这些基础，这一决策本身就是架构应对策略的一部分。AI 事件数据库在 2025 年记录了 362 起事件，较前一年的 233 起有所增加，其中许多事件可追溯至控制措施缺失，而非模型故障。虽然尚未出现紧急状况，但目前也没有形成可以总览整体风险的统一视图。

第三阶段：核心驱动要素出现

第三阶段是碎片化状况不再能被容忍的时刻。某起事件、监管问题或成本上的意外，使得现状难以维系，组织迫于压力进行整合，而非按计划进行。虽然每个组织在第三阶段的表现各不相同，但从中得出的教训是一致的。过去 18 个 月中披露的最具影响力的事件都涉及自主代理。2025 年 7 月，Replit 的一款 AI 代理在明确的“代码与操作冻结”期间清空了生产数据库，影响了 1196 家企业和 1206 名高管的记录，并在这个过程中制造了数千个虚假用户。另有一份报告描述了一家组织，因未对员工许可证设置使用限制，导致单月在 Claude 上意外花费了 5 亿美元。这两起事件正是网关旨在遏制的故障模式，而且都表明其后果已经超出了技术事件的范畴。同一时间段内的其他事件，包括 EchoLeak（首个被武器化的提示注入 CVE）以及涉及向遭入侵的 AI 提供商授予 OAuth 权限的 Vercel 数据泄露事件，均在不同配置下呈现出了相同的模式。

第三阶段的成本很少仅限于事件本身。一起严重的事件通常会导致客户数据泄露、监管升级、品牌受损，以及长达一个季度或更长时间的补救工作，进而挤占了功能开发时间。规模较小的组织可能没有足够的缓冲余地来同时承担事件的直接后果及其后续的整合成本。受监管行业可能会面临许可证受影响的风险。面向客户的品牌一旦失去信任，便难以挽回。一旦整合从可选变为强制，在巨大的压力下构建网关的成本将远高于在需求出现前就提前构建的成本。

第四阶段：整合到共享层

处于第四阶段的组织对网关的描述大同小异：这是一个将安全、成本和路由决策集中于一处进行管理的控制层。这通常是改造项目，而非从零开始的新建项目。这个过程会明确哪些内容需要集中管理、哪些内容需要保留在应用程序中，以及团队在哪些方面存在分歧。一旦网关建成，合规状况和成本状况都会变得更加清晰。当初推动整合的架构压力，如今也成为了评估网关需要承担的其他所有任务的标准。

这些阶段是一种模型，而非一个序列

有些组织能直接从第一阶段跃升至第四阶段，因为其现有的平台实践为这一跃升奠定了基础。而另一些组织则会无限期地停滞在第二阶段，他们之所以接受这种风险，是因为整合的成本似乎高于碎片化的成本，直到某次事件迫使他们重新权衡利弊。在主动采用与被动采用之间做出选择，部分取决于如何将该组织在相邻领域的架构成熟度迁移到 AI 领域。拥有成熟 API 治理、可观测性和平台工程能力的组织，可以选择在需求出现之前就打好基础。而缺乏这种成熟度的组织，往往是在压力下才发现这一模式，并为此付出了代价。

图 8：组织在 AI 发展路径上所处的四个位置示意图。主动发展路径（绿色虚线箭头）和第三阶段驱动因素路径（红色虚线箭头）展示了通往成熟阶段的两种路径（图片来源：作者原创）

悬而未决的问题，以及接下来的发展

本文所述的模式在本文所涉及的组织中仍在逐步完善，其中有两个问题尚未解决。第一个问题是，在网关处执行的策略与在应用程序内部执行的策略之间，界限究竟该如何划分。当相关策略的变化速度快于应用程序逻辑的变化速度时，网关能够很好地适应这种变化，但应用程序往往拥有网关所不具备的上下文信息，而且随着双方的成熟，这条界限也会随之变化。第二个问题是运营层面的：运行防护机制涉及参数调优、误报分类以及值班负担。负责网关的团队便成为了安全裁决者——当裁决基于原则时，这很有用；但当该团队沦为“说不”的一方时，就会产生负面影响。

更深层次的问题超出了 AI 的范畴。无论在何处，当某个子系统的发展速度快于其所涉及的系统时，明确的架构分界线便成为设计的核心。当前，AI 代理是这一问题的具体体现。下一个类似的案例，此刻已在某处悄然酝酿。

原文链接：https://www.infoq.com/articles/evolutionary-architecture-pattern/