企业级Agentic AI扩展：如何避免厂商锁定

在整个企业范围内扩展 AI 智能体需要既能保持灵活性又能避免供应商锁定的架构模式。本文是我们关于大规模多智能体系统系列的第 2 部分。在本文中，我们探讨了机器学习（ML）团队如何在"多一切"（multi-everything）环境中运行 AI 智能体系统——这里的"多一切"包括框架、模型和提供商。我们还涵盖了使这些系统能够协同扩展的原则。

在《Amazon 大规模多智能体编排模式的高级微调技术》中，我们探讨了如何在单一用例或领域内设计和优化多智能体编排。该文重点介绍了需要多个 AI 智能体通过协调工作流、分解任务和通过结构化协作提高准确性来处理复杂性的场景。

然而，在实践中，企业 AI 系统很少被限制在单一领域内。

随着采用的扩展，大型企业的 ML 平台团队遇到了不同的挑战。问题不再是如何在单个系统中编排 AI 智能体，而是如何在"多一切"环境中运营多个这样的系统。多个框架、模型、提供商和团队在同一企业内共存，每个都在按自己的节奏演进。

随着组织扩展这些系统，一致地构建、自定义和部署模型的能力变得至关重要。在实践中，这需要一种统一的方法来进行模型生命周期管理和大规模推理。Amazon SageMaker 在支持企业级一致性的同时不限制灵活性方面扮演着基础角色。

本文探讨了在保持灵活性并避免供应商锁定的同时扩展 AI 智能体系统所需的架构原则和模式。

多一切环境的现实

企业 AI 系统默认会演变成异构环境。不同团队根据其需求采用不同的框架。有些优先考虑结构化工作流，有些专注于协作式 AI 智能体交互，还有些优化确定性、模型驱动的管道。同时，组织将定制构建的 AI 智能体与软件即服务（SaaS）功能及现有企业系统结合使用。

模型层引入了另一个维度的可变性。基础模型（FM）持续快速演进，每个都提供不同的成本、延迟和能力权衡。因此，大多数企业在多个模型提供商之间运营，而不是标准化为单一选项。

随着时间的推移，这导致了一种稳态现实：跨多个团队和用例运营的多模型、多框架、多提供商系统。

挑战不是如何避免这种结果，而是如何在不引入碎片化的情况下管理这种结果。

作为要管理的约束条件的可选性

在第 1 部分中，我们专注于优化特定系统内的 AI 智能体行为。在企业级别，问题发生了变化。可选性不再是关于实验的问题。它成为一个必须被刻意管理的约束条件。

在框架或模型级别强制执行标准化的尝试通常会产生摩擦。团队会绕过约束，采用变慢，或者系统在批准架构之外出现分歧。同时，紧耦合应用程序到特定模型或提供商会限制随着环境演变而调整的能力。

一种更有效的方法是在应用程序层之下进行标准化，专注于共享控制平面，如身份、策略执行、可观测性和路由，同时允许 AI 智能体的构建和执行方式保持灵活性。

这种方法不会消除异构性。它限制了异构性的影响，使系统能够演进而不会破坏更广泛的架构。

多一切系统的核心挑战

随着系统多样性增长，一组可预测的挑战随之出现。治理在每个都定义自己控制模型的框架中难以一致执行。集成复杂性增加，因为 AI 智能体、工具和服务暴露了不兼容的接口。在没有动态优化的情况下，成本和性能权衡变得更难管理，通常导致资源使用效率低下。

同时，安全边界扩大，因为 AI 智能体与工具、数据和其他 AI 智能体动态交互，使访问模式更难预测。持久内存引入了关于数据保留、隔离和一致性的额外复杂性。最后，企业用例需要领域特定的性能，这是通用配置无法单独实现的。

这些挑战相互关联且随时间累积。需要系统级方法而不是孤立解决方案来管理它们。

管理大规模复杂性的实用框架

下图总结了在成功的多一切环境中反复出现的核心架构原则：控制和执行平面分离、统一可观测性、集中化治理、动态路由、设计韧性、分阶段编排演进和内置优化。

图 1：管理多一切环境中复杂性的核心架构原则

在多一切环境中成功运营的组织围绕一套平衡灵活性与控制力的架构原则趋同。

一个基本原则是将控制平面与执行平面分离。身份、策略执行、可观测性和成本归属集中化以促进整个企业的一致性，而 AI 智能体执行和开发保持去中心化以支持团队自主性和可扩展性。

可观测性成为有效运营这些系统的先决条件。通过建立统一的遥测层，组织可以获得跨框架和环境的 AI 智能体行为可见性。这种可见性帮助他们监控性能、追踪故障并持续改进系统，而不依赖特定框架的工具。

治理在实现为平台能力时最为有效，而不是嵌入在单个 AI 智能体内。集中化执行支持一致的安全性和合规性，即使框架、模型和执行环境在演变。

随着工作负载多样化，路由成为核心系统功能。组织根据成本、延迟和准确性要求动态匹配任务与资源，而不是静态分配模型或基础设施。这帮助系统实时适应并在规模下保持效率。

生产系统还必须设计明确的保证。延迟、可用性和隔离要求应明确定义，以及处理故障的机制。重试、断路器和回退路径有助于在现实条件下保持韧性。

许多组织从集中化编排模型开始，以保持对 AI 智能体交互的可见性和控制。随着系统增长，它们演变为更分布式和事件驱动的架构，这提供了更大的可扩展性同时保持一致性。

最后，优化必须从一开始就被嵌入到系统中。成本和性能考虑是规模化运营的基础，动态模型选择、缓存和高效执行模式等技术有助于促进长期效率。

这些原则共同为管理多一切环境固有复杂性提供了一个实用的框架。

如何使用 AWS 服务实现框架无关的规模化

前面概述的架构原则需要跨框架、模型和团队一致运营的能力。AWS 服务提供这些构建块，组织可以使用它们来实现框架无关的平台同时保持灵活性。

在大规模下，模型层成为复杂性的主要来源之一。不同的用例需要不同的模型、定制策略和推理模式。

Amazon SageMaker 作为管理这种大规模复杂性的核心执行和定制层。它为模型开发、微调、部署和推理提供统一层，允许组织标准化整个企业构建和运营模型的方式。通过支持实时、异步和批量推理，以及 Inference Components 和模型监控等功能，Amazon SageMaker 帮助团队将基础设施与工作负载需求对齐。这在整个企业内保持一致的运营模式。

在此基础上，Amazon Bedrock 提供了一个简化托管接口，用于访问基础模型，支持快速实验而无需管理底层基础设施。虽然 Amazon Bedrock 加速了模型访问和集成，但 Amazon SageMaker 提供了自定义和生产级推理所需的深度、控制力和可扩展性。两者共同使组织能够将模型访问与模型执行分离，支持灵活且有弹性的架构。

编排和控制通过 AWS Lambda、AWS Step Functions 和 Amazon API Gateway 等服务实现，这些服务支持动态路由和工作流协调。

诸如 AWS 上的 Agent Orchestration 等新兴功能进一步扩展了这一层。它们为智能体编排提供了专用构建的抽象，帮助团队以更高的一致性和控制力管理复杂的多智能体工作流。

身份和治理通过 AWS Identity and Access Management (IAM) 和 AWS Organizations 集中管理，而可观测性则使用 Amazon CloudWatch 和 AWS X-Ray 标准化。

Amazon EventBridge、Amazon ElastiCache 和 Amazon CloudFront 支持集成和性能优化。

在这个架构中，Amazon SageMaker 有效地成为模型执行的运营骨干，而 Amazon Bedrock 则加速了对新兴基础模型能力的访问。它们共同帮助组织在创新与控制之间取得平衡。

关键要点 Amazon SageMaker 为大规模模型自定义和推理提供运营骨干，而 Amazon Bedrock 支持快速访问托管基础模型。两者共同支持企业级灵活、与框架无关的架构。

摘要：将架构原则映射到 AWS 服务

下表总结了这些架构原则如何映射到支持与框架无关扩展的原生 AWS 服务。

面向多元素系统的企业模式

当这些原则被应用时，组织往往会在少量架构模式上趋同。这些模式并非规定性的。它们反映了团队如何根据工作负载需求和运营约束来构建智能体系统。

重要的是，这些模式并不相互排斥。大多数企业在不同业务部门和用例中组合实施其中多种模式。挑战不在于选择单一模式，而在于帮助它们在共享环境中共存。

模式 1：用于业务流程自动化的内部智能体平台

一个常见的起点是内部智能体平台，当多个团队开始独立构建智能体时就会出现。随着时间推移，这可能导致基础设施重复、治理不一致以及组织内有限的重用。

为解决这一问题，组织引入集中式或混合平台模型。共享平台层提供通用能力，如模型访问、治理、可观测性和成本管理，而各个团队保留对智能体构建和部署方式的自主权。

在这个模型中，平台充当控制平面，标准化智能体访问模型、执行策略和发出遥测数据的方式。同时，执行保持去中心化。业务部门继续拥有其应用逻辑、数据集成、持续集成和持续交付（CI/CD）流水线以及框架选择。

这种分离减少了重复并强制执行一致性，同时不约束创新，同时还支持跨多个用例重用通用能力。

模式 2：面向客户的智能体平台（ISV 和 SaaS）

当智能体对外暴露时，架构优先级转向多租户、隔离和可靠性。

在这个模式中，系统设计为强制执行强租户边界。每个请求在整个系统中携带租户上下文，确保智能体仅访问该租户范围内的数据和工具。身份和访问管理成为核心关注点，通常与外部身份提供者集成，同时在平台内保持一致的执行。

基础设施决策也随之演变。许多组织采用混合租户模式，为标准工作负载结合使用共享基础设施，为有更严格监管或性能要求的客户使用专用环境。这种方法在成本效率与隔离和合规需求之间取得平衡。

可靠性是这个模式的定义特征。系统必须在不均匀工作负载下满足对延迟、可用性和吞吐量的明确期望。因此，故障转移、速率限制和优雅降级等弹性机制成为核心平台能力。

模式 3：针对实时应用推理延迟的优化

对于实时系统，延迟成为主导架构约束。对话助手和交互式工作流等应用需要在严格的时间范围内响应，延迟直接影响用户体验。

在这些环境中，优化必须被设计到系统中。路由决策是动态的，根据复杂性、延迟敏感性和成本考虑评估每个请求。这种路由实时选择最合适的模型和基础设施层。

执行策略也演变为支持并行性，允许独立操作并发运行并减少总体响应时间。缓存在减少冗余计算和提高延迟和成本效率方面发挥关键作用。

这个模式强调系统级优化，性能被视为主要设计约束而非事后考虑。

用统一平台桥接模式

每种模式都解决一组特定需求。然而，在多元素环境中，它们很少孤立存在。企业通常同时运行内部自动化智能体、客户面向系统和实时应用。这些系统通常由不同团队使用不同框架和模型构建。

如果没有共享基础，这些模式可能变得孤立。治理会分歧，集成会倍增，优化工作会在系统间重复。

统一智能体平台通过提供位于各模式之下的通用能力集来解决这一挑战。它标准化了跨领域关注点，如身份、策略执行、可观测性和路由，同时允许每个系统独立演进。

这种区分很重要。模式描述了智能体系统如何针对特定工作负载进行结构化。平台确保这些系统能够作为统一企业架构的一部分一起扩展。

在本系列的第一部分中，我们专注于单一用例内的多智能体编排，其中多个智能体需要处理定义域内的复杂性。

在这篇文章中，我们将范围扩展到企业级，此时挑战变为在多元素环境中管理许多这样的系统。

成功的组织并非那些消除复杂性的组织，而是那些结构化复杂性的组织。通过标准化身份、策略、可观测性和路由等关键控制层，同时保持执行的灵活性，他们可以运营异构系统而不失去控制。

要开始应用这些模式，请探索 Amazon SageMaker、Amazon Bedrock 和 Amazon Bedrock AgentCore 如何支持模型自定义和与框架无关的访问，并参阅 AWS Well-Architected Framework 获取本文引用的控制平面实践。在评论中分享哪些模式正在塑造您的企业智能体架构。

本系列的后续文章将探讨 ML 平台团队如何从支持单一业务用例演变为运营共享企业智能体平台。我们将介绍抽象、治理模型和共享服务，让各个团队在采用增长时保持灵活性。