Microsoft Entra 代理 ID 引入了新的标识构造，以及考虑现有身份验证和授权模式的新方法。 为了更好地了解这些构造如何组合在一起，了解常见的 AI 代理部署模式以及它们如何映射到 Microsoft Entra 代理 ID 很有帮助。
本文介绍常见的 AI 代理部署模式及其映射到 Microsoft Entra 代理 ID 的方式。 本文首先回顾关键标识概念、描述权限和信任边界，然后演练常见的部署模式。
有关要创建的蓝图和代理标识数的分步决策指南，请参阅 规划代理标识体系结构。
重要概念
以下组件是 Microsoft Entra 代理 ID 的基础。 如果你不熟悉这些概念，请先了解 Microsoft Entra 代理 ID 关键概念，然后再继续阅读本文。
标识构造
本文中所述的模式中使用以下标识构造：
- 代理标识蓝图：一个或多个代理标识的模板和身份验证基础。 它保存着适用于由其创建的所有代理标识的凭据和策略。
- 代理标识蓝图主体：将蓝图添加到租户时创建的 Microsoft Entra 对象。 它实际负责获取令牌、创建代理标识，并在审核日志中代表蓝图出现。
- 代理标识：特定 AI 代理的运行时标识，具有自己对下游资源的权限。
- 代理的用户帐户：与代理标识配对的可选 1：1 帐户，仅当代理必须访问需要用户对象的系统时才需要。
权限模型
蓝图级权限和代理标识级别权限用于不同的目的：
- 蓝图权限 表示从蓝图创建的所有代理标识之间共享的最低权限。 如果希望所有代理标识以通用基线开头，请使用蓝图上的可继承权限。
- 代理标识权限 表示特定代理的区分权限。 当同一系统中的不同代理需要对下游资源的不同访问权限时，请使用这些权限。
有关详细信息，请参阅为蓝图配置可继承权限和Microsoft Entra 代理 ID 中的授权。
信任边界
信任边界是指共享的风险面，其中假设单个泄露会影响整个边界。 在具有单独服务帐户、机密和网段的独立平台上运行的代理不会共享信任边界。
信任边界是应用程序威胁建模决策，而不是由 Microsoft Entra 智能体 ID 为您定义的决策。
部署模式
以下模式基于实际代理部署。 每个都描述了代理体系结构、标识结构以及相关的权限和治理注意事项。
低代码单例代理
一个代理，可帮助处理特定任务，通常构建在低代码或无代码平台上。 代理要么始终代表已登录用户（交互式），要么始终自主行动（自主）。
结构： 一个蓝图→一个代理标识
尽管具有单个代理标识的蓝图可能看起来是冗余的，但该蓝图为代理提供一致的条件访问策略、监视、治理和审核条目，这与多代理系统所需的基础结构相同，且设置最少。
权限： 直接授予代理身份的权限。 对于单一实例情况，通常不需要蓝图的可继承权限。
代理的用户帐户： 除非代理需要访问 Exchange、Teams 或其他需要用户对象的系统，否则不需要。
域工作者（顺序多代理）
多个代理在紧密耦合的有序工作流中协同工作，为通用域目标提供服务。 代理通常共享一个代码库，在同一运行时环境中运行（例如，同一 Kubernetes 命名空间或容器），并具有相同的安全态势。 每个代理都有不同的职责和对下游资源的不同访问权限。 此模式映射到多代理设计中的 顺序编排 。
结构： 一个蓝图→多个代理标识（每个代理角色一个）
在此处使用单个蓝图是合适的，因为所有代理共享相同的信任边界。 每个代理获取其自己的代理标识，以便操作可以归因于审核和登录日志中的特定代理，并且每个代理都可以对下游资源拥有不同的权限。
示例：零售产品管理系统有三个代理：商店库存、产品比较和供应商库存。 这三个都在同一 Kubernetes 命名空间中运行，并由同一团队生成。 它们使用一个包含三个代理标识的蓝图，每个代理的权限限定为其自身的资源。
权限： 将共享基线权限设置为蓝图上的可继承权限。 将角色特定权限直接分配给每个代理身份。
代理的用户帐户： 通常不需要域工作代理的用户帐户。
具有域工作者的并发协调器
编排代理根据传入任务动态激活不同的域工作者。 域工作者可以在不同的平台上运行，由不同的团队操作，并跨信任边界。 此模式映射到多代理设计中的 并发业务流程 。
结构：
- A 蓝图 → 编排代理身份
- 蓝图 B →域辅助角色代理标识（每个角色一个，跨信任边界组）
- 蓝图 C → 另一个域工作者组，如果由单独的团队或平台运作
由于域工作者跨越信任边界（单独的运行时、机密或团队），因此它们需要单独的蓝图。 蓝图的凭据的范围限定为其信任域，因此一个域中的泄露不会影响对等代理。
临时代理标识： 此模式的变体使用临时代理标识。 业务流程协调程序在运行时创建临时代理标识，以促进特定交互（例如，与维护子系统协调），授予从蓝图继承的权限，并在会话结束时删除标识。 这会将爆炸半径限制为任务的持续时间。
注释
临时代理标识创建发生在运行时，这引入了不确定的延迟。 评估此权衡以应对延迟敏感场景。
权限： Orchestrator 和每个域辅助角色组都有自己的权限集，范围限定为各自的蓝图和代理标识。
代理的用户帐户： 通常不需要在编排器或域工作器级别，除非特定的域工作器必须访问依赖于用户对象的资源。
每用户代理 （small-n）
将为每个用户或组织单位创建单独的代理标识。 例如，SOC 分析程序可能在每个云环境中有一个实例，而审核程序可能在每个部门中有一个实例。 代理标识的数量适中（数十到低百个），而不是每个目录用户一个。
结构： 一个蓝图→每个用户、部门或环境的一个代理标识
当每个代理实例需要不同的权限、不同的审核边界或独立生命周期（例如，可以禁用部门代理而不影响其他人）时，此模式是合适的。
权限： 每个代理身份的权限根据其用户或组织单位进行划分。 从蓝图继承的权限设置最低基线，并根据需要为每个代理标识授予其他权限。
代理的用户帐户： 当每个代理充当其用户或部门的命名代表时，请考虑将每个代理标识与代理的用户帐户配对，例如，代表某个区域接收电子邮件的专用销售代理。
数字工作者（完全自治代理）
完全自主代理作为数字员工运作，并配备通常为人类员工保留的资源：Exchange 邮箱、OneDrive 共享和 Teams 活跃状态。 这是代理自治的最高级别。
结构： 一个蓝图→一个代理标识→一个代理的用户帐户
每个数字工作者都需要自己的代理用户帐户。 代理标识和代理用户帐户之间的 1：1 关系是固定的 ， 不能跨多个代理标识共享代理的用户帐户。
示例：具有真实邮箱的 AI 销售代表（在全局地址列表中列出），能够响应电子邮件，并在组织结构图中被分配了一位人类经理。
权限： 向代理的用户帐户授予所需的特定 Exchange、Teams 和 OneDrive 权限。 为不需要用户对象的系统授予代理标识应用程序级权限。 有关详细信息，请参阅 授予代理对 Microsoft 365 的访问权限。
代理的用户帐户： 必填。 为每个数字员工代理身份创建一个代理的用户帐户。
要避免的模式
横向扩展副本不需要单独的代理标识
运行同一代理代码（横向扩展）的多个实例不需要单独的代理标识。 横向扩展是运行时问题：蓝图将获取令牌作为代理标识，代理的多个实例都可以在同一标识下同时运行。 为每个副本创建单独的代理标识会导致目录对象和管理开销的增加，却没有任何审核、访问控制或责任效益的好处。
内存和上下文管理不需要单独的代理标识
代理内存通常是共享数据存储（例如 Azure Redis 缓存或 Azure AI 搜索），在检索时按会话 ID 筛选数据。 对该数据存储的访问是由代理身份的权限控制的，而不是由每个会话的单独身份来控制。 用于内存隔离的单独代理标识增加了复杂性，没有安全优势。
不要在目录中使用按对象缩放的代理标识
目前，对目录级标识而言，为每个会议、每个文档或每个临时对象创建一个代理标识并不实用。 对于高通量方案，请使用共享代理标识，并依赖应用程序层的会话或上下文标识符来区分交互。