agents microsoft-foundry agent-framework enterprise observability security

利用Foundry Agent Service和Agent Framework将代理部署到生产环境。

销售准备代理如何从本地代码过渡到基于业务数据、在Microsoft 365中部署的、具有身份限定、沙箱化且受监控的环境。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 11 分钟2634 词

来源: Foundry Agent Service + Microsoft Agent Framework Explained

从原型到生产级智能体

让人工智能智能体在笔记本电脑上运行是相对简单的部分。而在大型企业中，更艰巨的任务是为成千上万的用户安全地运行这些智能体：为它们分配身份、限制其可读取的内容、记录其操作行为，并将它们集成到用户已打开的工具中。Microsoft Foundry Agent Service 与开源的 Microsoft Agent Framework 正是为填补这一空白而设计的。前者提供具备企业级管控功能、可衡量性及可发现性的托管服务，同时允许用户使用自己喜欢的工具来构建智能体；后者则帮助用户通过编排技术构建单个智能体或多种智能体组成的工作负载。

其理念是：代理可以直接从本地环境部署，以具有受限权限的安全身份运行，并且可以逐次监控其交互行为，从而便于调试、优化和扩展，同时确保无人会失去控制。这些代理还可以被集成到常见的工具中，所有操作均可被追踪、管控和隔离。

另一方面的重点则是落地性。只有当代理能够处理真实的业务数据时才能发挥作用：电子邮件、会议记录以及运营系统能够提供个性化的洞察、文档和演示内容。团队可以使用熟悉的框架进行开发，随后随着代理数量的增长，对所有代理的性能、成本和质量进行统一管理。

为何企业级部署如此困难

构建智能体已经变得容易多了。但在整个组织中安全可靠地部署智能体却并非如此。目前正在开发的许多智能体早已超越了小规模试点阶段。有些是数千名员工使用的聊天工具，还有一些则在后台默默运行，偶尔会与关键系统相连。

所有这些都需要相同的基础架构：身份与访问控制、私有连接，以及针对单个代理和整个代理群的遥测与追踪功能。手动将这些组件整合在一起十分复杂，而这正是Foundry服务旨在解决的问题，从而让代理能够安全、大规模地运行，并具备完整的可见性。想象一下另一种情况：如果某个团队自行托管代理，就必须决定代理如何进行身份验证、借用哪个服务账户、日志应存储在哪里、如何确保不同用户的数据相互隔离，以及当代理出现异常时该通知谁。每一个问题的答案都相当于一个小项目，在代理能够访问日历或客户记录之前，安全审查都会逐一核实这些问题。

示例：销售会议准备代理

这个示例中的智能体能够帮助销售团队为客户会议做准备。其代码已经用 Python 和 Microsoft Agent Framework 编写完成，不过也可以使用其他框架或语言。该智能体定义了众多工具、一些中间件逻辑以及工作流程，目前所有功能都在本地运行。

目前尚未解决的问题是如何将其升级为一种在企业范围内安全、可扩展、符合规范且可靠的解决方案。在 Visual Studio Code 中，扩展 AI Toolkit 后会提供“部署到托管智能体”的功能。该功能会按照现有代码将智能体打包，并在 Foundry 中作为托管智能体进行部署。原本在本地运行的同一智能体现在会出现在 Foundry 平台界面中，开发者可以通过测试环境调用它，从而了解托管层带来的功能提升。

询问它本周有哪些重要会议，这体现了新型智能体的工作方式。该智能体运行在安全的沙箱环境——即微虚拟机中，在其中它能够进行推理、查看日历，还能编写和执行代码，这与GitHub Copilot CLI或Claude Code等编程智能体的功能类似。

身份、隔离与约束机制

智能体一经部署就会触发多项操作，下图展示了门户界面中身份与权限设置的具体呈现位置。

智能体会从Microsoft Entra获取唯一的身份标识。它执行的任何操作，比如查看日历，都可以被追溯到该智能体。凭借这一身份，它可以在自身权限范围内自主访问资源，或者使用相关用户的权限来代表该用户执行操作。
每位启动智能代理会话的用户都会获得一个专用的安全微虚拟机。如果两名销售人员同时提问，他们将各自拥有独立的代理实例，因此每个会话的信息都会在独立的空间内被读取、写入和存储。
对于每一次交互，该服务都会检查组织所设定的规则与限制，这些规则涉及内容过滤、防止提示注入以及版权材料的使用等方面。智能代理能够执行的操作和访问的内容，都是通过部署时自动完成的配置来精确控制的。

回到游戏场中，智能体给出了它的答案。根据其收集并逐一分析的信号，有一个客户账户“Zava DIY”被确定为最高优先级。在这种情况下，智能体以该用户的身份和权限代为操作，查看日历并找出需要关注的账户。由于系统需要读取收件箱、日历以及数据和文件存储，因此具备适当的访问控制正是构建合规系统所必需的。

监控与发布

Foundry还提出了另外两个企业级需求。首先是可观测性。该平台提供监控和追踪功能，让你能够跟踪每一条对话，了解智能体是如何回答每个问题的，同时还能检查智能体的整体运行状况。

第二点是可发现性。一旦智能体开始运行，它仍需被需要它的人找到，没人愿意开发新应用后还指望所有人都能发现链接并将其加入书签。如果一家公司已经在使用 Microsoft 365 和 Teams，那么“发布”按钮就可以将 Foundry 中部署的任何智能体注册到这些服务中。这样人们就能在日常工作的场所，无论是桌面端还是办公室外的手机上，找到并使用它。在 Microsoft 365 中，该智能体会出现在 Copilot Chat 功能中，同时在 Teams 中也可使用。

基于事实的回答背后的智能层

Foundry 还与微软的统一 AI 智能层相集成，这一层能确保智能体始终基于正确的知识与业务背景工作，从而让它们的输出更具相关性。这远远超出了单一来源 MCP 服务器所能提供的功能。该智能层由三部分组成。

Work IQ 提供有关个人工作方式的背景信息：与电子邮件、日历、过往会议、Teams 聊天记录、文件等的关联。
Fabric IQ 则为相关的业务运营提供背景信息，例如销售数据、客户记录或物流信息。
Foundry IQ 聚合了多种知识来源，为智能体提供支持，包括结构化数据与数据库，以及云存储中的非结构化资料，甚至智能体流程还能检索图片。

在首次运行时，仅能看到日历查询功能，即 Work IQ 的功能。更高级的智能体则会使用全部三种功能。

更完整的运行：为 Zava 会议做准备

该智能体凭借所拥有的工具和技能，能够访问全部三种智能体系统。在模拟环境中，其先前输出中的一条备注指出了一个重要的Zava会议，因此接下来的请求便是要求它协助准备该会议。

在沙箱环境中，它执行了上述操作：它会查询Work IQ以获取与Zava相关的邮件和Teams对话记录；从Fabric IQ中调取使用数据、采购模式及合同细节；并通过Foundry IQ搜索销售支持和营销资料，找出对该客户最相关的信息。

该智能体还具备基于常用智能体技能框架开发的几项功能：一项功能可用于生成PowerPoint演示文稿，另一项功能则能制作Word格式的简报文件。它最终会返回两个关联文件：一份供内部团队使用的Word简报，以及一份专为Zava准备的定制演示文稿。

该简报整合了来自情报层的背景信息、CRM系统中的客户关系数据、用户近期通信记录、关于业务健康状况、使用情况及计量数据的分析结果，以及工单系统中的支持请求。最终形成一份包含建议讨论主题的完整准备文档。
演示内容针对此次特定的客户交流进行个性化设计，并采用了公司的品牌色彩。它将Fabric IQ和Foundry IQ中的资料整合为演讲要点及针对客户近期活动的分析见解，同时还包括业务运营数据、营销活动指标，以及能够进一步深化合作的新机遇与服务。

其价值不仅体现在部署层面：这些智能代理运行在智能层之上，能够代表用户获取工作数据、业务数据及组织知识，并与 Microsoft 365 实现深度集成。

实现方式

对于希望构建类似功能的开发者而言，起点比完整示例更为简单。例如，Azure Developer CLI 可以用来初始化一个新项目，比如一个销售准备智能代理。基于聊天的智能代理备受支持且依然十分流行，任何框架都可以使用，包括 LangGraph，该服务也支持新兴的模式。模板会提供所需的文件结构，开发者可以在此基础上在本地进行调试并完成部署。这就是通过模板生成的简单智能代理，同时还有很大的定制空间。

再来看看高级智能体背后的实现原理。该代码定义了各种工具和知识源，包括三种智能指数，以及如今可以添加到编程智能体架构中的其他类型技能。其核心是使用 GitHub Copilot SDK，该 SDK 会针对已定义的工具集运行智能体循环。这个循环会对数十个文件、邮件、之前的会议记录以及运营和服务数据进行分析，最终生成相应的建议。

Microsoft Agent Framework将各组件整合在一起，并添加了中间件等功能。例如，如果编码智能体试图在缺乏三个IQ提供的足够数据的情况下生成文档，中间件会阻止这一操作，因为没有这些可靠数据支撑的输出几乎必然会是虚假内容。在扩展企业级部署时，这类机制非常重要，它能够为整个销售团队提供质量管控，并设置额外的防护措施。只有将框架与这类模式相结合并部署在Foundry Agent Service中，才能充分发挥其优势。

管理智能体集群

一旦有多个代理在运行，接下来的问题就是如何监控和管理它们，而这得益于所有操作都在Foundry内部完成。该平台可在一个界面中展示整个代理集群的性能与成本信息：包括代理的健康状况及警报情况（在演示中所有代理均处于正常状态且暂无警报）、预估成本、成功率以及令牌使用情况，同时还能深入查看表现最佳的代理的运行数据。根据成功率排序出的最佳与最差代理能帮助识别需要重点关注的那些。

从实验环境到生产环境，再到向所有终端用户发布，所需的一切功能都已内置，并具备完善的可观测性。其核心目的在于降低在组织内部安全可靠地构建和部署代理的复杂性。对于想要尝试的人而言，只需在Foundry门户中创建第一个项目，然后浏览微软提供的公开示例来找到合适的SDK即可。

基于以上分析，可以得出一个实际的操作步骤：首先从模板中创建一个小型智能体并在本地运行它。接着逐个添加工具和知识源，同时使用会在缺少基础数据时阻止后续操作的中间件。尽早将系统部署到托管环境中，这样在真实用户到来之前就能对身份识别、隔离和追踪功能进行测试。只有在追踪数据表现正常后，才将其发布到人们已经在使用的聊天工具中；当多个智能体开始运行后，要持续查看整体状况，因为成本上升和成功率下降的问题通常会首先在此显现。遵循这一流程的团队往往能在问题还容易解决时就发现它们。

为何本地运行与托管运行的表现如此不同

应当将开发者编写的代码与平台添加的功能区分开来。销售代理中的工具、中间件和工作流都属于普通的应用程序代码，无论在笔记本电脑上还是云端，它们的运行方式都相同。部署之后发生变化的，是围绕这些代码的所有要素——身份认证机制被建立，会话被隔离，每次交互时都会评估相关策略，操作轨迹会被记录，同时还会出现发布路径。所有这些都不需要重新编写代理程序，正因如此，演示中将部署视为编辑器中的单一操作，而非迁移项目。

三个问题可以概括这种方法，每个问题都对应上述的某一层。

谁在执行操作？Entra身份认证系统可以回答这个问题，即代理程序是使用自身定义的权限，还是借用其他用户的权限。
工作在何处进行，谁可以查看？基于用户的微虚拟机沙箱可将不同会话隔离开来，同时组织的内容管理与注入策略会应用于每一次调用。
它完成了什么任务，表现如何？通过追踪记录、对话视图、健康状况指标以及成本和成功率汇总，可以针对每个智能体及整个系统群组了解相关情况。

代码中的管控机制

平台层面的约束机制并不能替代嵌入在代理程序本身的约束规则。当三个智能指标未能提供足够数据时阻止文档生成的中间件规则就是一个很好的例子，因为它设定了普通策略无法知晓的质量标准。即便没有CRM历史记录或使用数据，生成的简报依然可能看起来很完善，销售人员也可能会凭借编造的细节去参加客户会议。在代码层面、在文件生成之前就加以阻止，比事后才发现问题要便宜得多。

同样的思路也解释了为何演示版本会将技能拆分为独立的、可重复使用的组件。用于构建牌组的技能与用于撰写简报的技能都可以分别进行测试、版本控制，并被其他智能体重复使用，而智能体循环则负责决定何时调用这些技能。通过结合该循环、框架的中间件以及托管层，便形成了三个可以实施控制的层面：智能体的推理方式、它被允许输出的内容，以及环境允许它执行的操作。

复制该模式前需考虑的因素

该示例展示的是理想情况，即所有数据源都已连接且权限设置合理。实际上，汇报的质量取决于底层CRM系统、工单处理系统及分析数据的质量。只有当权限真正被限定在特定范围时才能发挥作用，而使用自身访问权限的客服人员能够看到该用户所能查看的所有内容，因此权限过宽的账户会导致客服人员的权限也过宽。车队控制面板有助于识别表现最差的客服人员，但仍需有人仔细查看相关记录，判断低成功率是由于模型问题、工具问题、数据源缺失，还是限制措施过于严格所致。