在将 AI 代理与 Microsoft Entra 代理 ID 集成之前，需要做出一系列设计决策。 本指南将引导你按顺序完成每个决策：
- 代理所需的标识类型。
- 代理采用哪种操作模式，包括获取令牌的方式及其操作的上下文环境。
- 系统需要多少个蓝图。
- 每个蓝图要创建的代理标识数。
按顺序处理这些决策，因为早期选择会塑造以后的选择。 某些单代理部署可能只需要前两个步骤。 有关这些决策如何映射到实际代理体系结构的示例，请参阅 代理 ID 设计模式。
步骤 1：选择标识类型
Microsoft Entra ID 提供了 AI 代理可能使用的多种标识类型。 对于大多数 AI 代理， 代理标识 是正确的选择。 当代理必须访问需要用户对象的系统时，除了代理标识之外，还要配置 代理的用户帐户 。 不建议为 AI 代理使用服务主体和常规用户帐户。
| 标识类型 | 在以下情况下使用... | 主要特征 |
|---|---|---|
| 代理标识 | ...代理代表自己或代表用户行事 | 强制赞助、特定的审核日志条目和由蓝图管理的凭据 |
| 代理的用户帐户 | ...代理需要访问需要用户对象的资源，例如 Exchange 邮箱或 Teams 频道 | 用户帐户以 1:1 的比例与代理标识、UPN、经理和其他用户属性进行配对。 |
| 服务主体 （不建议用于代理工作负荷） | ...工作负荷运行脚本化、可预测的操作，而无需进行自主决策 | 没有特定于代理的治理、透明度控制或生命周期管理的经典应用程序标识 |
为什么不是服务主体？
服务主体专为确定性静态工作负荷而设计。 Microsoft Entra 代理 ID 提供一些服务主体无法使用的代理特有功能，例如：
- 在登录和审核日志中具有显式条目的专用标识类型，提供难以通过通用服务主体实现的可跟踪性和透明度。
- 对某些高权限授权进行平台级别的限制，这减少了代理入侵后的影响范围。
- 强制赞助，因此每个代理标识在创建时都有一个负责的业务所有者。
- 蓝图管理的凭据和生命周期：您通过父蓝图来创建、轮换和删除代理标识，而不是单独进行这些操作。
- 支持在运行时创建的临时代理标识，这些标识具有已通过蓝图授予的可继承权限，并在任务完成后删除。
有关详细比较，请参阅 代理标识、服务主体和应用程序。
为什么不是常规用户帐户？
请勿使用常规 Microsoft Entra 用户帐户作为 AI 代理。 用户帐户专为人工登录模式而设计，并将它们分配给代理会导致每个零信任强制层出现问题：
- 条件访问 策略（如符合设备要求、多重身份验证和使用条款条件）失败，因为这些控件专为人工交互而设计。
- 标识治理 过程（如 joiner-mover-leaver 工作流、访问包和访问评审）不是针对代理生命周期模式设计的，并且可能会错误地删除代理访问权限。
- 您的AI代理将会与人为员工一起显示在全局地址列表、Teams 和 SharePoint 中，使得将AI代理与人区分开来更加困难。
不要为代理注册应用
如果你习惯于创建工作负载标识，那么你可能会下意识地为代理创建应用注册或服务主体——例如，通过运行 az ad app create、New-MgApplication、New-AzADApplication，或发出一个 POST /applications Microsoft Graph 请求。 不要对 AI 代理执行此操作。 以这种方式创建的标识是一个标准应用程序：它没有发起人、没有特定于代理的审核条目，也没有蓝图管理的生命周期。 Microsoft Entra不会将其视为代理来管理，而把它标记为“代理标识”也不会让它成为代理。
而是创建代理标识蓝图，然后从中创建代理标识。 代理标识是通过蓝图创建的独立 Microsoft Entra 对象类型 (#Microsoft.Graph.AgentIdentity)，而不是通过应用程序注册 API 创建的。
| 不要这样（标准应用注册） | 执行此操作（代理身份） |
|---|---|
az ad app create |
创建 代理标识蓝图，然后从中创建代理标识 |
New-MgApplication 或 New-AzADApplication |
将受支持的 创建通道 与 代理 ID 开发人员 或 代理 ID 管理员 角色配合使用 |
POST https://microsoftgraph.chinacloudapi.cn/v1.0/applications |
授予 AgentIdentityBlueprint.Create，然后 创建蓝图和代理标识 |
在.NET中，使用Microsoft.Identity.Web.AgentIdentities包：调用builder.Services.AddAgentIdentities()，然后使用该WithAgentIdentity(...)包获取令牌。 请参阅 从代理调用自定义 API。
有关完整比较，请参阅 代理标识、服务主体和应用程序。
步骤 2：选择操作模式
代理的操作模式确定它如何获取令牌以及它所处的上下文。 Microsoft Entra 代理 ID 支持两种主要模式：自治模式和交互式模式。
| 特性 | 自治 | 交互 |
|---|---|---|
| 用户上下文 | 不存在用户 | 用户已登录 |
| 权限类型 | 应用程序权限 | 委托权限 |
| 同意模型 | 需要管理员同意 | 用户或管理员同意 |
| 令牌主体 | 代理标识 | 用户（以代理身份执行组件） |
| 常见方案 | 后台处理、定时任务、系统对系统 | 聊天助手、面向用户的副驾驶、对用户数据执行操作的代理 |
| 访问范围 | 广泛、租户范围的访问 | 范围限定为已登录用户的数据 |
在代理时选择 自治 ：
- 运行后台任务或计划任务。
- 处理多个用户的数据。
- 在没有用户的情况下执行系统到系统操作。
选择 交互 适用于您的代理：
- 代表登录的用户进行操作。
- 需要访问该用户的数据，例如邮件、日历或文件。
- 必须尊重用户自己的权限边界。
某些代理需要两者。 例如，代理可以使用自治模式运行夜间后台同步，并使用交互式模式响应用户聊天消息。 在这种情况下，请实现所有 OAuth 流，并根据操作选择合适的令牌。
- 有关自治代理，请参阅 为自治代理请求代理令牌。
- 有关交互式代理，请参阅 在交互式代理中对用户进行身份验证。
步骤 3：确定代理身份蓝图的数量
代理标识蓝图管理从中创建的所有代理标识的身份验证。 蓝图保存用于代表这些代理标识获取令牌的凭据。 由于此功能，蓝图泄露可能会影响其下的每个代理标识。 根据安全边界设置代理身份蓝图数量。
默认值：每个信任边界使用一个蓝图。
信任边界是一个共享风险面，假设存在单一漏洞，这将影响整个边界。 共享运行时、机密、文件系统和网络的代理共享信任边界，并且可以共享蓝图。
| 决策因素 | 同一个信任边界→一个蓝图 | 不同的信任边界→多个蓝图 |
|---|---|---|
| 身份验证材料 | 可以在所有代理之间共享相同的凭据;凭据轮换或泄露会影响所有代理 | 凭据必须以加密方式隔离;凭据泄露不得蔓延到对等代理 |
| 安全边界 | 代理在同一信任边界中运行：相同的运行时、机密、文件系统和网络 | 代理程序跨越信任域边界：不同的环境、运行时或隔离域 |
以下因素 不是 添加更多蓝图的原因：
- 阻止身份验证：可以使用条件访问策略禁用单个代理标识或将其作为目标，而无需添加蓝图。
- 审核分离：每个代理标识在父蓝图下生成自己的登录和审核日志条目。
- 横向扩展或副本：运行同一代理的多个实例不需要多个蓝图。
- 内存或上下文分离：代理内存通常是在检索时按会话 ID 筛选的共享数据存储，不需要单独的蓝图。
有关蓝图的详细信息，请参阅 代理标识蓝图。
步骤 4：确定每个蓝图的代理标识数
默认值：每个逻辑代理使用一个代理标识。 为每个代理设置独特标识，可确保实现审核线索、跟踪和访问控制的最高保真度。
| 决策因素 | 多个代理身份 | 单个代理标识 |
|---|---|---|
| 审核和归属 | 操作必须归属于特定代理，以便进行调查、合规或问责。 | “系统”行为足够：无需区分代理的行为 |
| 生命周期独立 | 代理是独立创建、删除或撤销的 | 代理作为一个单元创建、删除和管理 |
| 角色分离 | 代理具有不同的责任。 例如，库存查找、产品比较和供应商数据 | 代理可互换 |
以下因素 不是 添加更多代理标识的原因：
- 水平横向扩展：运行同一代理代码的副本或实例不需要单独的标识。 横向扩展是运行时问题，而不是标识问题。
- 内存池和上下文管理：代理内存通常是在检索时按会话 ID 筛选的共享数据存储。 内存或上下文隔离不需要独立的身份。
多代理体系结构，其中多个代理标识合适，可以包含具有不同代理角色的顺序管道，以及具有专用域辅助角色的并发业务流程。 有关详细信息，请参阅 AI 代理业务流程模式。