

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 代理商遇见多租户
<a name="agents-meet-multi-tenancy"></a>

人们很容易将代理视为构建块，其中代理被视为一系列自主组件，这些组件是为了支持特定领域或业务问题的需求而组装的。更有趣的是，当我们开始考虑提供商如何打包和使用这些代理时。在许多方面，代理商成为企业的成本和收入来源。代理提供商必须考虑消费其服务的不同角色、角色的消费特征以及允许代理提供商创建与消费者一致的定价和分层模型的获利策略。

代理提供商可以支持多种模式来部署其代理以满足客户需求。下图显示了两种主要代理部署模型的概念视图。

![代理部署模型的两个示例。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/agentic-ai-multitenant/images/agent-deployment-models.png)


图的左侧显示了客户专用代理模型。代理提供商通过为每个已注册客户部署单独的代理实例来构建代理。通过这种方法，代理的能力及其获取知识的能力将仅限于给定客户环境的范围。这最终代表了一种以客户为单位的体验，它继承了支持专用客户环境的一些复杂性和优势。

相比之下，图右侧的图表中只有一个部署在提供商环境中的代理。代理处理来自多个客户的请求，并根据所有客户的集体经验不断发展和学习。添加的每个新客户仅代表代理的另一个有效客户。代理像代理即服务 (AaaS) 模型一样运行，使用共享结构来支持客户的需求。在这两种情况下，代理使用者都可以是应用程序、系统，甚至是其他代理。

您可以通过两种方式来查看 AaaS 模型。上面的模型为所有客户提供了相同的体验。这意味着代理的内部结构将不包括任何考虑请求客户背景的专业化级别。通常，对于这种模式，假设代理的范围、目标和价值的性质围绕着一组共同的资源、知识和成果，这些资源、知识和结果普遍适用于所有客户。 

AaaS 的另一种方法是，客户环境会影响代理的体验和实施。下图提供了此上下文中 AaaS 代理足迹的概念视图。

![带有租户上下文的 AaaS。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/agentic-ai-multitenant/images/aaas-with-tenant-context.png)


在这个 AaaS 视图中，传入请求的来源和上下文会严重影响代理的占用空间。作为代理底层实现一部分的资源、操作和工具可能因每个传入的租户请求而异。代理的价值与其利用租户上下文得出受租户状态、知识和其他因素影响的行动和结果的能力有关。有些请求可能会产生独特的租户结果，而另一些请求可能会为每个租户带来更量身定制的结果。这为代理人的学习能力增添了新的维度，其中可能包括更具情境性，以及获取和应用知识以增强目标成果。

对于提供商而言，AaaS 模式具有许多优势。由于多个客户使用单个代理，提供商有更好的机会实现规模经济、提高运营效率、控制成本和创建统一的管理体验。这有可能为代理业务带来更大的灵活性、创新性和增长。

这些品质与推动采用软件即服务 (SaaS) 模式的相同原则重叠。从本质上讲，AaaS 模型是作为一种多租户服务构建的，它继承了 SaaS 环境中许多相同的规模、弹性、隔离、入职和运营属性。在许多方面，AaaS的经验在很大程度上借鉴了SaaS提供商使用的策略和实践，但将这些术语区分开来是合理的。就我们的目的而言，重点主要放在需要多租户支持的建筑和运营代理所带来的影响上。

对于一个可以平等对待所有用户并且不需要管理持久、敏感或客户特定数据的系统来说，租赁的概念对他们的代理的影响微乎其微。对于需要在保持数据隔离、自定义和情境感知的同时为多个客户提供服务的系统，支持多个租户可能是代理设计、策略和目标的重要组成部分。下图显示了如何在代理环境中使用多租户。

![多租户代理。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/agentic-ai-multitenant/images/multi-tenant-agent.png)


此图的左侧是经典的多租户架构。它包括一个 Web 应用程序和一系列实现业务逻辑的微服务。多个租户使用此环境的共享基础架构，可以扩展以满足不断演变的租户群体不断变化的工作负载。所有租户均可通过单一管理平台运营和管理环境。

想象一下这个心理模型是如何映射到这张图右边的特工的。一个代理运行由一个或多个租户使用的 AaaS 模型。代理可能来自多个提供商，租户上下文在它们之间流动，因为一个代理的单个实例必须处理来自多个租户的请求。

此图中间的示例是一个混合模型，其中代理是整体 SaaS 体验的一部分。系统的某些部分采用更传统的模型实现，而系统的其他部分则依赖代理。这种模式在许多 SaaS 产品中可能很常见，特别是对于正在过渡到代理体验的组织而言。这种模式通常会持续下去，因为并非所有系统都以纯粹的 AaaS 形式交付。另请注意，多租户仍然适用于模型的代理。虽然代理可能嵌入在系统中，但它们仍可能处理来自多个租户的请求。

问多租户是否真的很重要是很自然的。你可能会争辩说代理处理请求，因此支持租赁可能效果不大。但是，当我们深入研究多租户代理的含义时，租赁可能会直接影响代理如何影响访问、部署和配置工具、内存、数据和其他代理部分以支持单个租户的方式。租赁还会影响扩展规模、限制、定价、分层和其他业务方面如何应用于您的代理架构。

由此得出的一个结论是，有些代理用例需要多租户支持。挑战在于确定多租户如何塑造您的代理体验的整体设计和架构。对于某些代理来说，多租户支持是一种与众不同的能力，它允许代理将租户特定的上下文应用于提供目标结果的代理。

在随后的章节中，您将看到我们为描述多租户 SaaS 架构而创建的术语和设计模式将如何发挥作用。AaaS 模型可以通过借用有用的方面来采用这些概念，从而在需要时引入新的代理特定概念。

## 身份、租户上下文和代理系统
<a name="identity-tenant-context--and-agentic-systems"></a>

向单个代理添加租户上下文并不是特别困难。在许多情况下，团队可以依赖典型的机制，这些机制将用户和系统绑定到租户，并将租户感知令牌传递给代理。当我们考虑租户上下文和身份如何支持多个代理时，这很重要。在此模型中，租户必须绑定到跨越所有协作代理的身份。

总的来说，代理领域需要一个更具交叉性的身份模型，该模型要与代理系统当前和新出现的需求保持一致。代理提供商需要支持操作代理系统附带的独特安全、合规和授权模型的身份机制。在系统由客户或其他代理组成的环境中，这尤其具有挑战性。每个已加入的代理都必须将其身份和租户上下文与代理交互关联起来。下图突出显示了作为 agent-to-agent (a2a) 交互一部分的潜在身份和租户上下文挑战。

![身份、租户上下文和代理系统。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/agentic-ai-multitenant/images/identity-tenant-context-and-agentic-systems.png)


此图显示了一系列由提供商构建的代理作为我们所涵盖的代理系统的一部分进行交互。现在，它已通过身份和租户环境进行了改造。此场景是支持多个入口点的代理系统的示例。我们假设该系统中的每个代理都需要自己的身份验证机制才能将系统或用户解析为给定的租户。当这些代理交互时，租户上下文将传递给 JSON Web 令牌 (JWT)，该令牌将用于授权访问并将租户上下文注入代理。

从概念上讲，这种情况的主要区别在于代理独立部署和运行，这意味着每个代理必须能够解析其身份并授权访问。关键是它的身份必须具有一定的分布式能力来处理更广泛的代理系统的需求。在代理如何共享租户上下文方面也必须保持一致。

## 将 SaaS 的商业价值应用于 AaaS
<a name="applying-saas-business-value-to-aaas"></a>

通常，当我们考虑在 as-a-service模型中运行任何系统时，我们会考虑体验的性质以及其技术和运营足迹如何推动业务成果。例如，在采用 SaaS 时，组织利用规模经济、运营效率、成本概况和灵活性来推动增长、利润和创新。

以 AaaS 形式交付的代理可能会瞄准类似的业务成果。通过支持多个租户，代理可以使资源消耗与租户活动保持一致。这产生了传统 SaaS 环境所带来的规模经济。AaaS 还允许组织以支持频繁发布和提高代理提供商灵活性的方式管理、操作和部署代理。关键是AaaS模型不依赖于技术。它创建并推动业务战略，以促进增长、简化采用和简化运营。