你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
注释
本文档指的是 Microsoft Foundry（新） 门户网站。
大多数企业不希望只使用聊天机器人。 他们希望自动化更快且出错更少。 这可能意味着汇总文档、处理发票、管理支持票证或发布博客文章。 在所有情况下，目标是相同的：通过卸载重复性和可预测的任务，释放人员和资源以专注于更高价值的工作。
大型语言模型（LLM）引入了一种新型自动化，其中包含可以理解非结构化数据、做出决策和生成内容的系统。 在实践中，企业可能难以从演示阶段过渡到实际生产。 LLM 可能会偏移、不正确且缺乏责任。 如果没有可见性、策略执行和编排，这些模型很难在实际业务工作流中获得信任。
Microsoft Foundry 旨在改变这一点。 它是一个平台，将模型、工具、框架和治理合并为一个统一的系统，用于生成智能代理。 该系统的核心是 Foundry 智能体服务，它支持智能体在开发、部署和生产全流程运行。
Foundry 代理服务将 Foundry 的核心部分（例如模型、工具和框架）连接到单个运行时。 它管理对话、协调工具调用、强制实施内容安全，并与标识、网络和可观测性系统集成。 这些活动有助于确保代理安全、可扩展，并准备投入生产。
通过抽象基础设施的复杂性并在设计中实现信任和安全，Foundry Agent Service 可以帮助您从原型自信地转移到生产环境。
什么是 AI 智能体？
代理做出决策、调用工具和参与工作流。 它们有时独立执行这些任务，有时与其他代理或人类协作。 它们是真正的流程自动化的基础。
通过 Foundry 创建的代理不是单一实体。 它们是可组合单元。 每个代理都有一个特定的角色，由正确的模型提供支持，并配备了正确的工具。 每个代理部署在安全、可观察和可管理运行时内。
代理有三个核心组件：
- 模型（LLM）：赋能推理和语言理解。
-
说明：定义代理的目标、行为和约束。 它们可以具有以下类型：
- 声明式：
- 基于提示：以声明方式定义的单个代理，它将模型配置、指令、工具和自然语言提示组合在一起，以驱动行为。
- 工作流：一种以代理为中心的工作流，可以表示为 YAML 或其他代码，用于协调多个代理共同工作，或在特定条件下触发某项操作。
- 托管：在代码中创建和部署的容器化代理，并由 Foundry 托管。
- 声明式：
- 工具：让代理检索知识或采取措施。
代理接收非结构化输入，例如来自其他代理的用户提示、警报或消息。 它们以工具结果或消息的形式生成输出。 在此过程中，他们可能会调用工具来执行检索或触发动作。
Foundry 中的代理的工作原理是什么？
将 Foundry 视为智能代理的装配线。 与任何现代工厂一样，Foundry 汇集了负责塑造最终产品的一部分的专业工作站。 代理工厂使用模型、工具、策略和业务流程来生成安全、可测试和生产就绪的代理，而不是机器和传送带。 下面是工厂分步工作原理：
1. 模型
当您选择一个能够赋予代理智能的模型时，装配线将启动。 从不断扩充的大语言模型 (LLM) 目录中选择，包括 GPT-4o、GPT-4、GPT-3.5 (Azure OpenAI) 以及 Llama 等其他模型。 该模型是代理的推理核心，可告知其决策。
2. 可自定义性
调整模型以适应用例。 使用微调、提取或特定于域的提示自定义代理。 利用从真实对话内容和工具结果中捕获的数据，编码智能体行为、特定角色知识以及过往表现模式。
3. 知识和工具
为代理配备工具。 这些工具允许代理人访问企业知识（如必应、SharePoint 和 Azure AI 搜索），并执行实际操作（通过 Azure 逻辑应用、Azure Functions、OpenAPI 等）。 此步骤增强了代理扩展其功能的能力。
4. 业务流程
代理需要协调。 连接的代理 协调整个生命周期，例如处理工具调用、更新聊天状态、管理重试和日志记录输出。
代理需要协调。 工作流 协调整个生命周期，例如处理工具调用、更新聊天状态、管理重试和日志记录输出。
5. 可观测性
代理经过测试和监视。 Foundry 可以在每个步骤中捕获日志、跟踪和评估。 借助完整的对话级可见性和 Application Insights 集成，团队可以检查每个决策，并随着时间的推移不断改进代理。
6. 信任
请确保代理适合并能可靠地完成其被分配的工作负荷。 Foundry 应用企业级信任功能，包括通过 Microsoft Entra 的身份验证、基于角色的访问控制（RBAC）、内容筛选、加密和网络隔离。 您可以选择代理的运行方式和位置，使用平台托管或自定义基础设施。
结果是一个具备生产就绪的代理：具备可靠性、可扩展性，并在各个工作流中安全地部署。
为何使用 Foundry 代理服务？
Foundry 代理服务为在企业环境中部署智能代理提供了生产就绪的基础。 下面介绍了它如何跨关键功能进行比较：
| 能力 | 代理服务 |
|---|---|
| 对对话的可见性 | 完全访问结构化 对话，包括用户到代理和代理到代理消息。 非常适合用于 UI、调试和培训。 |
| 多代理协调 | 对于代理到代理消息传送的内置支持。 |
| 工具编排 | 在服务器端执行和重试工具调用，并记录结构化日志。 无需手动编排。 |
| 信任和安全 | 集成的 内容筛选器 有助于防止滥用并缓解提示注入风险（XPIA）。 所有输出均受策略控制。 |
| 企业集成 | 能够自带 存储、 Azure AI 搜索索引和 虚拟网络 来满足合规性需求。 |
| 可观测性和调试 | 对话、工具调用和消息追踪的完整追溯能力; 用于使用数据的Application Insights 集成。 |
| 标识和策略控制 | 基于 Microsoft Entra 构建，完全支持 RBAC、审核日志和企业条件访问。 |
开始使用 Foundry 代理服务
若要开始使用 Foundry 代理服务，需要在 Azure 订阅中创建 Foundry 项目。
可以使用所需的资源创建项目。 创建项目后，可以部署兼容的模型，例如 GPT-4o。 部署模型后，还可以使用 SDK 开始对服务进行 API 调用。
可以在 GitHub 上使用新的 Python 代理 SDK 找到官方示例列表。
代理的 BCDR
为了支持服务复原能力，Foundry 代理服务依赖于客户预配的 Azure Cosmos DB 帐户实现业务连续性和灾难恢复（BCDR）。 这种依赖有助于确保在发生区域性中断时可以保留和恢复代理状态。
作为 Azure 标准客户，可以预配和管理自己的单租户 Azure Cosmos DB 帐户。 所有代理状态都存储在此帐户中。 备份和恢复依赖于你控制的 Azure Cosmos DB 中的本机功能。
如果主要区域不可用，则代理通过连接到同一 Azure Cosmos DB 帐户自动在次要区域中可用。 由于所有历史记录都保留在 Cosmos DB 中，代理可以继续运行，几乎没有中断。
我们建议客户预配和维护其 Azure Cosmos DB 帐户，并配置适当的备份和恢复策略。 如果主要区域不可用，则此工作有助于确保无缝连续性。
相关内容
- 详细了解 通知代理的模型。