Azure 逻辑应用中具有 AI 代理和模型的工作流（预览版）

适用于：Azure 逻辑应用（标准）

Azure 逻辑应用支持使用具有大型语言模型（LLM）的代理完成任务的工作流。 代理使用迭代循环过程来解决复杂的多步骤问题。 LLM 是一个经过训练的程序，可识别模式并执行无需人工交互的作业，例如：

• 分析、解释以及推理信息，例如说明、提示、输入和其他数据。
• 根据结果和可用数据做出决策。
• 根据代理的说明制定答案，并将其返回给提问者。

可以生成使用自治代理或对话代理的工作流。 代理使用自然语言与你和连接的模型进行通信。 代理还使用模型生成的输出来执行与人机交互或不使用人工交互的工作。 该模型可帮助代理提供以下功能：

• 接受有关代理角色、操作方法以及如何响应的信息。
• 接收和响应说明和请求，或 提示。
• 根据可用信息处理输入、分析数据并做出选择。
• 选择用于完成完成请求所需的任务的工具。 工具基本上是一个由一个或多个行动组成的序列，这些行动共同完成一个任务。
• 适应需要灵活性且变化多端、动态、不可预知或不稳定的环境。

通过使用 1,400 多个连接器 构建供代理使用的工具，代理工作流能够支持范围广泛的场景，从中充分受益于代理和模型的功能。 根据你的方案，创建一个没有人工交互的自治代理工作流，或者创建具有人工交互的对话代理工作流，以最符合解决方案的需求。

本概念指南介绍关键概念、自治代理工作流与聊天代理工作流之间的差异、代理工作流和非代理工作流之间的差异、代理结构、其他示例方案以及基本计费信息。

重要概念

下表提供了关键概念的基本简介：

自主代理工作流与对话代理工作流

为了帮助你更好地了解这些代理工作流类型的不同之处，以下各节介绍并显示每个代理工作流类型的示例。 这两种工作流类型都使用代理和工具获取当前天气，并在电子邮件中发送该信息。 所有代理都有一个信息窗格，可在其中使用所需的模型设置代理，并提供有关代理的角色、其功能以及响应方式的说明。

自动化代理工作流

以下高级步骤描述了基本自治代理工作流的行为：

1. 工作流从任何受支持的触发器开始。

   在触发器和代理之间，可以选择性地运行零个或多个动作。

2. 智能体接受系统指令和非人工提示或输入，例如触发器或前一个操作的输出。

3. 代理使用 Azure OpenAI 服务中部署的模型 或 Azure AI Foundry 项目中的已部署模型 来解释和了解说明和请求。 代理还使用模型来处理和分析提供的输入。

4. 根据代理说明，模型有助于规划代理需要调用哪些工具来执行必要的任务。

5. 代理返回工具结果，并响应工作流调用方或指定的收件人。

以下屏幕截图显示了一个基本的自治代理工作流示例：

对话代理工作流

以下高级步骤描述了基本聊天工作流的行为：

1. 工作流始终以名为 “聊天会话启动时”的触发器开始。

   在触发器和代理之间，可以选择性地运行零个或多个动作。

2. 代理通过集成聊天界面接受系统指令和人工提供的提示或输入，例如 ，西雅图的天气是什么？

3. 代理使用 Azure OpenAI 服务中部署的模型 来解释和了解说明和请求。 代理还使用模型来处理和分析提供的输入。

4. 根据代理说明，该模型有助于规划代理为必要任务调用哪些工具。

5. 代理返回工具结果，并通过聊天界面响应人工提示者。

以下屏幕截图显示了基本的聊天代理工作流：

以下屏幕截图显示了可从设计器工具栏或 Azure 门户中 “工具 ”下的工作流边栏菜单访问的集成聊天界面：

对话代理工作流还支持 Azure 门户之外可供其他人使用的聊天客户端。 若要为此外部聊天客户端提供和安全访问，需要在 逻辑应用上设置 Easy Auth，以便对用户进行身份验证和授权。

代理与非代理工作流

使用代理的工作流可以超出对非代理工作流施加的限制。 代理工作流可以适应发生意外事件的环境，根据提示、输入和可用数据选择要使用的工具，不断提高其性能，处理非结构化数据，支持复杂方案，并提供更高级别的适应性和灵活性。 非代理工作流在稳定环境中表现最佳，遵循预定义的规则，并执行静态、可预测和重复的任务。

下表提供了代理工作流和非代理工作流之间的更多比较：

探索代理工作流结构

若要在适用于 AI 自动化和集成解决方案的单租户 Azure 逻辑应用中生成新的代理工作流，请创建标准逻辑应用资源，并添加具有以下工作流类型之一的工作流：

• 自治代理
• 对话代理

这些工作流类型包括标准有状态工作流中的所有功能以及代理功能，专门用于处理代理。 这些工作流类型自动包括空代理。

例如，以下屏幕截图显示了新的自治代理工作流：

以下屏幕截图显示了新的对话代理工作流：

如果有现有的有状态工作流，以下屏幕截图显示了如何添加智能体操作以包括自主智能体和 LLM 功能：

以下屏幕截图显示了代理的连接窗格，可在其中指定有关要使用的已部署模型的信息：

创建与模型的连接后，代理需要提供说明来描述代理可以扮演的角色、代理可以执行的任务以及其他特定的规范性信息，以帮助代理响应提示、回答问题并执行请求的任务，例如：

连接到模型的空代理可以响应仅使用模型功能的提示，因此代理不必包含工具。 但是，为了使代理使用 Azure 逻辑应用中可用的操作，代理需要你创建工具。 您可以首先从连接器图库中添加一个操作，以开始创建工具。

下方示意图显示了画廊，你可以在其中浏览并选择动作以构建工具。

下图显示了一个天气代理，可以获取天气预报并在电子邮件中发送该预测：

更多示例方案

以下部分介绍代理可以在工作流中完成任务的几种方法：

抵押贷款代理

假设你的银行使用抵押贷款代理，该代理通过单个协调循环执行以下任务来自主处理贷款，或者在必要时进行人工干预：

• 与客户交谈以回答问题。
• 查看贷款申请。
• 收集财务信息以评估贷款资格。
• 检索和分析风险数据。
• 提交时请求和汇总房地产评估。
• 包括边缘事例的人工审阅者。
• 批准或拒绝应用程序。
• 将决策传达给相关方。

订单履行代理

假设你的企业使用订单履行代理来执行以下任务：

• 与客户互动，根据企业知识回答产品问题。
• 创建订单，但在必要时将其传递给人类。
• 通过智能化升级提供全天候支持。

还可以有一个代理来协调其他代理的工作。 例如，你可能有一个代理团队，例如编写者、审阅者和发布者，协同工作来创建和分发销售报表。

设施工作订单代理

若要支持内部设施团队，工单专员将执行以下任务：

• 与员工交谈并提供服务请求的选项。
• 根据员工选择打开工作订单。
• 将工作订单发送到相应的服务团队。
• 根据作业进度和状态更新工作订单。
• 作业完成后关闭工作订单。
• 请通知相关方已完成的作业。

身份验证和授权

非代理工作流通常与一组小型、已知和可预测的调用方进行交互。 但是，代理工作流与更广泛的调用方通信，例如人员、代理、模型上下文协议（MCP）服务器、工具代理和外部服务。 这种更广泛的覆盖范围会增加集成选项，但引入了不同的安全挑战，因为调用方可能源自动态、未知或不受信任的网络。 当呼叫者来自你不受控制的网络，或者当标识是外部或未绑定的标识时，你必须对每个调用方进行身份验证和授权，以便你可以保护代理工作流，特别是对话代理工作流，因为它们提供外部聊天客户端来与人员交互。

对于非生产活动，Azure 门户使用 开发人员密钥 进行身份验证和授权。 准备好在生产环境中运行会话代理工作流时，请确保设置 Easy Auth（也称为应用服务身份验证）以进行聊天代理工作流，此保护可在 Azure 门户外部启用外部聊天客户端，其他人可以在完成 Easy Auth 后使用该客户端。

以下部分介绍和比较用于对调用方进行身份验证并授权其访问代理工作流的选项。

开发人员密钥身份验证和授权

对于非生产活动（例如设计、开发和快速验证），Azure 门户提供、管理和使用 开发人员密钥 代表你运行工作流。

什么是开发人员密钥？

开发人员密钥是一种便捷的身份验证机制，仅由 Azure 门户用于在设计、开发和快速测试阶段运行工作流。 在这些阶段，开发人员密钥允许你省去手动设置 Easy Auth 或使用共享访问签名（SAS）复制触发器回调 URL 的步骤。 该密钥仅基于 Azure 资源管理器持有者令牌链接到特定用户和租户，该令牌是对对 Azure 资源管理器 REST API 的请求进行身份验证的访问令牌。

在工作流设计器中使用内置测试体验（例如运行工作流、调用 请求 触发器或与内部聊天界面中的聊天代理工作流交互）时，门户会自动注入开发人员密钥。 密钥隐式绑定到租户会话和已登录门户用户，因此由于此绑定（仅基于 ARM 持有者令牌）而无法在外部分发密钥。

开发人员密钥限制

以下列表描述了开发人员密钥的使用和设计限制：

• 密钥不能替代生产场景中的 Easy Auth、托管标识、联合凭据或已签名的回叫 URL。
• 密钥不是为大型或不受信任的调用方群体、代理工具或自动化客户端设计的。
• 密钥不是一种逐用户授权机制，因为缺乏细化的范围和角色。
• 密钥不受请求执行层的条件访问策略（仅在门户登录层）的约束。
• 密钥不适用于编程用法或 CI/CD 用法。

有关开发人员密钥与简易身份验证之间的比较，请参阅 Easy Auth 与开发人员密钥。

开发人员密钥用例

下表描述了使用开发人员密钥的合适和不适当的方案：

Easy Auth 内置的身份验证和授权功能

对于生产环境，请通过在逻辑应用资源上设置 Easy Auth，并使用专用 Microsoft Entra 应用注册来保护对对话代理工作流和外部聊天客户端的访问。 Easy Auth 仅对具有正确权限的人进行身份验证和授权，以便与您的对话代理工作流交互。 此方法隔离令牌、强制实施最低特权，并避免重用广泛的多应用程序注册。 在为逻辑应用资源设置 Easy Auth 后，您的工作流会提供一个 URL，以供用户通过 Azure 门户以外的外部聊天客户端与您的会话代理进行交互。

Easy Auth 提供了一个内置强制层，可让你更专注于构建工作流的业务逻辑，并提供以下优势：

• 在不使用自定义代码的情况下处理 Microsoft Entra 的登录、身份验证和授权。

• 将机密、长期共享访问签名（SAS）URL 和访问密钥保留在工作流外，从而减少机密蔓延、轮换开销和暴露风险。

• 通过映射对角色和作用域（而不是 IP 范围或静态键）的访问，实现最低特权设计。

• 在工作流运行之前验证访问令牌。 将验证的标识注入到每个调用方请求中，以便工作流可以做出每个请求的最小特权授权决策。

• 为发送到工作流的每个请求提供经过验证的标识，以便你可以在工作流中强制实施最低特权决策。

• 集中条件访问策略、租户限制、基于角色的访问控制（RBAC），以及一致的策略应用程序和强制实施的权限范围。

• 将规范化标识声明（例如 X-MS-CLIENT-PRINCIPAL，组、角色、范围和租户）注入到每个调用方请求中。 消除自定义中间件，并允许下游工作流操作（如 Compose 或 Parse JSON）针对声明和权限范围应用精细授权。

• 生成一致的身份验证和授权日志，用于调试、异常情况检测、诊断活动、审核和管理。

以下过程介绍了 Easy Auth 如何对客户端进行身份验证和授权以访问逻辑应用：

1. 当客户端尝试对其标识进行身份验证以访问受轻松身份验证的逻辑应用时，Azure 会将请求重定向到 Microsoft Entra ID。

2. 如果客户端成功进行身份验证，Microsoft Entra ID 向客户端颁发访问令牌。

   这些令牌由 Microsoft Entra ID 签名，包含受众 (aud) 声明、主题 (sub) 和过期时间 (exp) 等详细信息。 aud 声明指定预期的令牌接收者，稍后用于自动填充接收者逻辑应用的应用程序 ID URI。 此 URI 是一个唯一标识符，表示逻辑应用作为访问令牌中的受众，并使用以下格式：

   api://<application-client-ID>

3. 客户端使用令牌向逻辑应用发送请求。

4. 轻松身份验证截获请求、提取令牌并运行以下检查：

   • 将 aud 声明与允许的令牌受众进行比较。
   • 将 aud 声明与预期的应用程序 ID URI 进行比较。

5. 如果值匹配，则授权会继续。 否则，Easy Auth 会拒绝请求，并出现 HTTP 401 未授权 错误。

如需了解更多信息，请参阅以下文章：

• 在 Azure 逻辑应用中使用 Easy Auth 保护代理工作流
• Azure 应用服务和 Azure Functions 中的身份验证和授权

轻松身份验证与开发人员密钥

账单管理

尽管代理工作流在 Azure 逻辑应用中不会产生额外的费用，但 Azure OpenAI 服务和 Azure AI Foundry 项目中的模型使用会产生费用。 有关详细信息，请参阅以下页面：

• Azure OpenAI 服务定价
• Azure AI Foundry 定价

相关内容

• 在 Azure 逻辑应用中创建自治代理工作流
• 在 Azure 逻辑应用中创建聊天代理工作流
• 实验室：概述如何使用 Azure 逻辑应用生成代理工作流