一种用于管理 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