Microsoft IQ详解：让企业AI智能体真正理解业务上下文

模型给智能体智能，上下文给智能体意义

一个常被忽视的事实是：AI智能体的能力上限，并不只取决于背后的大模型，而是取决于它所能访问的上下文（context）。正如微软在这段演示中所强调的——「模型给智能体智能，上下文给智能体意义」。缺乏企业数据、知识、语言与关系网络的支撑，再强的模型也只能停留在「回复」和「生成答案」的层面，无法真正「理解什么才重要」并交付有依据的结果。

Microsoft IQ正是围绕这一痛点设计的能力集合。它把企业的数据、知识、语言和关系整合到一起，让托管在 Foundry 中的智能体不再是孤立的问答机器，而是能够连接企业上下文、将信息转化为真实行动的执行体。本文结合官方演示中的 Supply Autopilot（供应链自动驾驶）案例，拆解 Microsoft IQ 四大模块的实际运作方式。

四个 IQ 各司其职：从网络到工作流

演示中的 Supply Autopilot 是一个基于 Foundry 托管智能体构建的应用，它同时调用了四种 IQ，分别承担不同职责。在 Foundry 中，这些能力通过「工具箱（toolbox）」的方式接入，一个名为 supply tools 的工具箱连接了全部四个 IQ。

WebIQ 负责从公开网络获取实时信息。演示中询问天气时触发的就是 WebIQ。它有独立门户 webiq.microsoft.ai，在 playground 中可以搜索如「最新 AI 趋势」这类查询，还能按垂直领域筛选，例如只检索「Microsoft 开发者视频」时会返回官方 YouTube 频道的内容。WebIQ 调用的是新闻和网页工具，并支持多语言实现。通过 Foundry 的 traces（追踪）功能，可以清楚看到结果来源。

Foundry IQ 处理结构化的企业知识库。当询问「哪些产品符合更换与信用额度条件」时触发的就是它。其知识库背后挂载了四个不同的知识源，每个都是 Azure AI Search 索引，并各自带有描述。开发者可以配置补全模型、推理强度（reasoning effort）、输出模式，以及回答指令和检索指令。Foundry IQ 会根据问题自动判断应该访问哪个知识源，并在响应中附带引用来源。

Fabric IQ：语义模型与本体的协同

Fabric IQ 的接入方式与前两者略有不同——它不走 MCP，而是通过 Fabric 数据智能体（supplier data agent）来调用。在 Fabric 工作区中包含三个关键组件：语义模型（semantic model）、本体（ontology）和数据智能体（data agent）。

语义模型建立在供应商数据集之上，呈现各类数据关系。更有意思的是「生成本体」功能：点击后可以在产品、物质、制造商、营销授权、监管机构之间自动构建关系，点开任意节点即可查看关系含义。

语义模型和本体服务于不同类型的问题。例如询问「按最新 OTIF 为所有供应商排名」时，答案来自语义模型；而当问题涉及关系查询，比如「哪些医疗产品包含某种疫苗成分」时，答案则来自本体。托管智能体会直接连接到 Fabric 数据智能体并返回相应结果，这种语义模型与本体的分工让复杂的供应链关系查询变得可行。

语义模型（Semantic Model） 是对结构化数据的业务语义层封装，它将原始数据库表、字段与业务概念（如"供应商""订单履约率"）对应起来，使自然语言查询能够被转换为有意义的数据分析，而无需用户了解底层 SQL 结构。本体（Ontology） 则是对概念及其关系的形式化描述，来自知识图谱领域——例如"产品 A 包含成分 B""制造商 C 持有监管授权 D"，这类多跳关系查询无法用传统表格模型高效回答，而本体天然擅长此类图结构遍历。两者的本质区别在于：语义模型回答"多少、排名如何"等聚合类问题，本体回答"谁和谁有关系、通过什么路径相连"等关系类问题。OTIF（On Time In Full） 是供应链领域的关键绩效指标，衡量订单是否在约定时间内完整交付，是评估供应商可靠性的核心数据之一。

Work IQ 与身份：代表「我」还是代表「它自己」

Work IQ 负责执行实际的工作流动作。演示中要求「总结对话并发送邮件给某人」时，Work IQ 通过 Foundry IQ 获得身份认证，使用「我」的账户，以我的身份代发邮件。它调用的是 do action 工具，在 Outlook 中可以看到一封「我发给我自己」的邮件，证明了这一代理机制。

真正体现设计深度的，是智能体身份的切换。当把 Supply Autopilot 作为租户的一部分部署时，它会拥有自己独立的邮箱地址，在 Teams 的组织架构中直接向管理者汇报。此时智能体不再「代表我」，而是「代表它自己」行事。

演示中，当询问「你邮箱里有没有紧急的供应升级事件」时，autopilot 会检查自己的收件箱，发现一封来自 Maria 请求更换与信用额度的升级邮件（收件人正是 autopilot 本身）。随后它综合调用 WebIQ 检查天气导致的运输中断、调用 Foundry IQ 判断是否符合更换条件、调用 Fabric IQ 数据智能体为供应商排名，最终以自己的邮箱地址回复 Maria，确认将发放免费更换和信用额度——整个闭环由智能体以独立身份自主完成。

委托权限（Delegated Permissions） 是 Microsoft 身份平台（基于 OAuth 2.0）中的一种授权模式：应用程序以登录用户的身份请求访问资源，所能获得的权限不超过该用户本身拥有的权限上限。与之对应的是应用程序权限（Application Permissions），即应用以自身身份（无需用户在场）独立运行。当智能体拥有独立邮箱并"代表它自己"行事时，背后实际上切换的正是这种身份模型——智能体从"借用人类用户的委托权限"转变为"以服务主体（Service Principal）身份持有自己的应用程序权限"，这也是为什么它需要在 Agent 365 中单独分配许可证和 bot ID 的底层原因。

Agent 365：企业级智能体的治理底座

演示的最后部分指向了 Agent 365——管理后台中的一个新模块，用于在租户内管理像 Caldova Supply Autopilot 这样的智能体。

在这里，管理员可以管理智能体的身份细节，包括 agent ID、blueprint ID，并基于智能体模板创建实例。要让智能体在不同场景中运行，需要为其分配许可证，例如 E5 以及面向 autopilot 的 Frontier 许可。权限管理同样在 Agent 365 中进行——比如 Work IQ 要执行动作，就需要相应的委托权限（delegated permissions）。如果希望智能体出现在 Teams 中，还需要为它分配一个 bot ID，这样用户才能通过消息处理器与其对话。

从能力接入、身份认证、权限管理到许可证分配，Microsoft IQ 加上 Agent 365 构成了一套相对完整的企业级智能体体系。它试图解决的核心问题，正是如何让智能体安全、可控、有据可依地「做事」，而不仅仅是「说话」。对于考虑在企业内规模化部署 AI 智能体的团队来说，这种以上下文为中心、以身份与治理为护栏的架构思路，值得关注。

Blueprint ID 与 Agent ID 的区分体现了"模板与实例"的设计思路：Blueprint 是智能体的定义模板，描述其能力、工具和行为规范；Agent 则是基于 Blueprint 在特定租户中创建的具体运行实例，可以有独立的身份、许可证和权限配置。这与软件工程中"类与对象"的关系类似，同一个 Blueprint 可以在不同部门或场景中实例化为多个行为一致但身份独立的 Agent。Frontier 许可证目前对应微软面向企业 Copilot 生态的高级功能层，允许智能体使用更多自主执行能力，是区别于标准 Microsoft 365 E5 授权的增量授权层，专门为具有自主行动能力的 AI 智能体设计。