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

引入和应用租户上下文

如果我们构建支持多租户的代理，则必须首先考虑如何设置租户上下文，该上下文将用于在代理的实施中应用特定于租户的策略、策略和机制。

在最基本的层面上，您可以通过我们在经典多租户架构中使用的常用工具和机制将租户上下文引入代理。这可以通过 API 密钥或其他各种验证机制实现。 OAuth这方面的许多示例都侧重于将经过身份验证的系统或用户解析为包含租户上下文的 JSON Web 令牌 (JWT) 密钥。然后 JWT 通过系统传播。当我们考虑如何组成代理系统时，这会变得更加有趣。下图显示了两种代理环境的示例。

在此图中，左侧的模型表示一个代理系统，其中所有代理均由一个实体拥有、管理和托管。当你完全控制整个体验时，你可以使用典型的策略让租户通过每个代理。

右侧的模型可能更常见，它表示跨越多个实体的代理系统。代理是独立构建、管理和操作的，因此每个代理都有自己的身份验证和授权方案。这里的挑战是，我们需要一种通用的方法来解决和共享这些代理之间的租户背景。这依赖于更加分布式的模型，在这种模型中，每个代理都必须能够对系统或用户进行身份验证，并根据所应用的机制将其解析给租户。

建造具有租户意识的代理

多租户会影响我们实现单个代理的方式。在代理处理请求时，请考虑租户上下文如何影响代理访问数据、做出决策和调用操作的方式。为了更好地了解多租户如何以及在何处影响代理的个人资料，请首先确定构造如何成为任何代理的一部分。

面临的挑战在于，代理的范围、性质和设计绝非具体，因为提供商对代理体验的设计做出自己的选择。归根结底，代理的重点在于它是一种自主学习服务，可以访问一系列工具、数据源和内存，以确定如何最好地解决任务。

确切地知道代理使用了哪些策略和模式并不重要。在多租户模型中，更重要的是确定代理的各个部分是如何配置、访问和应用的。考虑一个依赖一系列资源和机制来实现其目标的潜在代理环境。下图显示了此类代理的示例。

这张图代表了全面的代理可能性，展示了可以组合起来实现目标的各种工具和机制。在图表的左侧，请注意代理如何依赖内存作为其上下文的一部分、定义指导其活动的策略的护栏以及针对特定任务的工作流程。有些人可能会争辩说，工作流程不应包含在这种背景下，但可能在某些情况下，工作流程是代理体验不可或缺的一部分。

图表的右侧显示了知识和工具等输入如何提供额外的见解和背景信息，从而增强代理的能力。然后，代理会输出操作，例如编写代码或访问系统。图的底部显示了代理如何依赖一个或多个内部或第三方代理，这些代理可以作为更广泛的系统的一部分进行编排。

我们现在可以考虑引入多租户意味着什么。租赁迫使我们考虑代理如何以及在何处引入决定行为和行为的策略和机制。这为我们如何看待代理人的知识、学习、工具和记忆力增添了另一个维度。

现在让我们考虑如何修改此模型以支持多租户。下图显示了多智能体模型的示例。

在此图中，我们介绍了租户角色，这些角色旨在塑造代理如何整合租户上下文。例如，在图的左侧，代理内存被更改为支持租户特定的内存。图的右侧也是如此，代理支持租户特定的知识和工具。同样的支撑也适用于护栏。

这可能是一个极端的例子，因为并非多租户代理的所有方面都需要每个租户的资源。关键是，你应该考虑如何为特定租户量身定制代理可以提高其有效性。这种方法使您的代理能够提高其影响力和价值，在响应中提供更相关的背景信息，并发展专业能力。然后，代理将能够学习、适应和执行特别适合不同角色的任务。

主要思想是，租户上下文直接影响您构建代理的方式。它还可以塑造租户与外部实体（包括其他代理）的互动。构建多租户代理会带来传统挑战，例如邻居吵闹、租户隔离、分层、限制和成本管理。您的代理的设计和架构必须解决这些基本的多租户概念，我们将在下一节中探讨这些概念。