微软 WorkIQ 深度解读：为 AI Agent 注入工作上下文

在企业级 AI 应用中，一个被反复强调的核心词是「上下文」（Context）。模型可以写出漂亮的代码、生成流畅的文案，却无法凭空知道你今天上午 11 点要去 7 号楼开会、这场会上你和同事到底讨论了什么。微软在一场面向开发者的分享中，正式把这块拼图命名为 WorkIQ——一个为 AI Agent 提供组织工作上下文的智能层。

本文基于微软 WorkIQ 产品团队（包括开发者关系负责人 Aysha、技术顾问 Anthony Shah、GPM Tolga 等）的现场演示整理，拆解 WorkIQ 的定位、与 Microsoft Graph 的区别，以及开发者如何将其接入自己的 Agent。

WorkIQ 是什么：模型推不出来的组织上下文

WorkIQ 的本质，是把 Microsoft 365 里散落的工作信息——会议记录、邮件、Teams 消息、PowerPoint 文稿——整合成模型可以直接消费的上下文层。

Anthony 用自己的真实场景做了演示：他习惯在会议开始前 20 到 30 分钟打开 Copilot，直接问「我这场跟 Copilot 的 fly 要准备哪五件事」。即便拼错了单词、没给会议时间和日期，Copilot 依然准确识别出目标会议，并给出结论：会议在 7 号楼、11 点开始、他还没 RSVP、需要负责 WorkIQ 的讲解部分。

这背后的关键，正是 WorkIQ 在替 Copilot 做重活——它引用了演示用的 PPT、团队的会议录音，知道三位讲者各自负责的内容。「组织上下文是模型无法仅凭 prompt 推断出来的东西」，这句话点出了 WorkIQ 存在的根本理由。

值得一提的是，Anthony 还展示了 Copilot 移动端的语音能力，并提到其已集成 CarPlay 与 Android Auto。他在开车送孩子、赶往会议的路上，用同样的方式口头询问会议准备事项，WorkIQ 提供的上下文让这一切成为可能。

WorkIQ 不是 Microsoft Graph 的替代品

现场被反复问到的一个问题是：WorkIQ 是不是要取代 Microsoft Graph？团队给出的答案是明确的「不是」。

Graph 已经存在很久，提供超过 200 个 endpoint，负责发送邮件、创建日历邀请、检索某人的全部邮件等具体操作。但问题在于——在 Agentic 开发中，让一个 Agent 在 200 多个 endpoint 之间判断该调用哪一个，并不容易。

WorkIQ 的解法是在平台之上构建一个智能层。它不把一堆 endpoint 直接丢给 Agent，而是在幕后提供一组动态工具（dynamic tools），让 Agent 更容易理解和选择。换句话说，Graph 面向的是「操作」，WorkIQ 面向的是「让 Agent 读懂并利用工作数据」，两者解决的是不同层面的需求。

这种设计思路，与当下主流的「工具调用」范式一致：与其暴露庞杂的底层 API，不如抽象出语义清晰、数量可控的工具集，降低模型的决策负担。

Microsoft Graph 是微软统一的 REST API 入口，2017年推出后逐步整合了原本分散在 Exchange、SharePoint、OneDrive、Teams 等各产品线的独立 API。开发者通过单一端点（graph.microsoft.com）即可访问 Microsoft 365 生态中几乎所有数据与服务，包括用户信息、邮件、日历、文件、群组、Teams 频道等。其授权模型基于 OAuth 2.0，支持委托权限（以用户身份操作）和应用权限（后台服务无用户交互时使用）。Graph 的设计理念是「一个端点，连接所有数据」，但这也意味着开发者需要熟悉数百个接口的语义和参数。在 Agentic 场景下，让模型自主选择正确的 Graph endpoint 并构造合法请求，对推理能力和上下文长度都提出了相当高的要求，这正是 WorkIQ 试图在其之上建立抽象层来解决的问题。

三种接入方式：REST API、A2A 与 MCP

对开发者而言，WorkIQ 提供了三条标准化的接入通道，覆盖不同的架构偏好：

REST API

适合将 WorkIQ 集成进 Web 应用、移动应用。使用 REST 时，背后调用的是同一套智能工具集，获得的是与 Copilot 体验一致的智能能力。

A2A（Agent-to-Agent）协议

如果你在构建多 Agent 编排（无论是通过 Copilot Studio、Foundry 还是自定义 SDK），都可以用 A2A 协议把 WorkIQ 作为其中一个 Agent 纳入协作体系。

MCP（Model Context Protocol）

WorkIQ 同样以 MCP server 的形式提供，工具集与数据与其他通道完全一致。

团队强调，无论你用的是 Copilot Studio、GitHub CLI 还是完全自定义的应用，接入方式都是统一的——「对 builder 和 developer 没有区别」。选择哪条通道，取决于你的 Agent 架构和使用习惯。

在权限管理上，WorkIQ 走的是企业级的严谨路线。管理员可以在 admin center 的 agent 配置里看到 WorkIQ MCP 的全部工具，并精细控制权限——例如允许创建、更新，但禁止删除，同时追踪策略。开发者接入自定义 Agent 前，需要在租户中注册应用，并在 API 权限中按需选择 WorkIQ 相关权限（如 WorkIQ agent ask），做到最小权限原则。

MCP（Model Context Protocol）是由 Anthropic 于2024年底提出的开放协议，旨在为 AI 模型与外部工具、数据源之间建立标准化的交互接口。其核心思想是把「工具」、「资源」和「提示模板」三类能力封装进一个 MCP Server，客户端（通常是宿主模型或 Agent 框架）通过统一协议发现和调用这些能力，无需针对每个服务单独适配。A2A（Agent-to-Agent）协议则是 Google 于2025年推出的多 Agent 协作标准，定义了不同 Agent 之间如何互相发现、委托任务和传递结果，核心抽象是「AgentCard」（描述 Agent 能力的元数据）与基于 HTTP 的任务生命周期管理。WorkIQ 同时支持这两种协议，意味着它既可以作为工具被单一模型调用，也可以作为一个独立的 Agent 节点参与更复杂的多 Agent 工作流编排。

配套工具：开源 WorkIQ OS 与交互式 Demo

为了降低上手门槛，团队推出了两个重要配套。

其一是 WorkIQ OS——一个直接调用 WorkIQ API 的业务线应用示例，将以 MIT 协议开源，托管于 GitHub（演示时尚未上线，称正在处理法务事宜）。它内置 action items、meeting intelligence、daily eval 等 widget，实时更新，并提供完整源码。开发者可以替换自己的 logo 与 UI 主题，把其中一部分或整体集成进自己的业务应用；它还内置了 developer tools 与 inspector view，帮助理解正在调用哪些 API，甚至可以直接把配置工作交给浏览器内的 GitHub Copilot 会话完成。

其二是交互式 Demo 网站，被形容为「新一代的 Graph Explorer」。开发者可以在这里直接测试 REST、A2A、MCP 三种方式下的工具调用。最有价值的是 API log 功能——每次调用后都能看到 headers、body 以及 WorkIQ 如何处理请求的完整细节。演示中展示了通过 A2A 协议查询「who am I」、通过 MCP 的 fetch 工具获取用户 profile，以及尝试用 create entity 创建日历邀请（现场创建邀请环节遇到了租户相关的小插曲，这也侧面说明了演示的真实性）。

实战案例 Margo：一个管理「25 万封邮件」的 Chief of Staff

整场分享最生动的部分，来自 GPM Tolga 构建的 Agent「Margo」。

Tolga 的痛点极其具体：主收件箱有 25 万封邮件、未读 5 万封、全部文件夹加起来超过百万，每周收到 92 到 120 个会议邀请，并且他开始追踪一个荒诞的 KPI——25 分钟会议时段内的冲突数，峰值竟达到 8 个。

他最初构建的不是 Agent，而是一个「skill」，目标是管理一天的会议与邮件、排优先级。他从一开始就立下规矩：不经授权不采取任何行动、必须给出引用来源以避免幻觉。随后他把这个 skill 连接到 WorkIQ——因为邮件、Teams 消息等所有数据都在 WorkIQ 里。

具体的工具编排逻辑清晰：用 fetch 获取元数据与数据供推理，用 retrieve 和 ask 做任务 grounding，用 do action 来创建邀请、起草和发送邮件、发 Teams 消息。最终成品 Margo 可以在收到「让我知道现在什么情况」这样的指令后，自动查日历、找到会议、调取 prep meeting 录音并总结出「要和谁合作、要传达什么信息」的 prep summary。

Margo 还支持个性化偏好：所有会议默认推迟 5 分钟开始（因为 Tolga 背靠背排了 120 场会议），所有以他名义发出的邀请必须署上 Margo 的名字——让每个人都知道这是 Agent 代劳。此外，他用 GitHub Copilot 的 cron job 设置了每小时任务，自动盘点「过去一小时发生了什么、有没有遗漏的决策」。

Margo 的项目已开源在 github.com/TolgaKR/Margo。至于命名，Tolga 问 Margo 自己它给出的缩写是 Managing Actions, Relationship, Goals and Obligations——但真正的来源，是英剧《Beyond Paradise》里经营 Shipton Abbot 警局的角色 Margo Martins。

Margo 的工具调用分层设计体现了当前 Agentic 开发中一个重要的工程原则：读写操作的权限分离与操作可追溯性。fetch 和 retrieve 属于只读操作，用于收集信息和建立推理基础；ask 是语义检索，允许模型以自然语言查询结构化数据；而 do action 才真正触发写操作（创建日历邀请、发送邮件等）。这种分层不仅降低了误操作风险，也让 Agent 的行为在审计层面更清晰——管理员可以通过 admin center 的日志还原每一次 do action 是由哪个 Agent 在什么上下文下触发的。Tolga 坚持「不经授权不采取行动」并要求署名「Margo」的设计，在工程上对应的正是让所有写操作在执行前都需经过用户确认步骤，并在产物（邮件、邀请）中保留 Agent 操作的元数据标记，这也是当前企业级 AI 落地中关于透明度与可信赖性讨论的实践缩影。

小结：上下文层正在成为 Agent 生态的新基建

WorkIQ 代表了一种值得关注的产品思路：当 Agent 要在真实企业环境里干活时，瓶颈往往不是模型能力，而是它能不能拿到对的上下文、以及能否安全地读写企业数据。

通过把 Microsoft 365 的工作数据抽象成一个智能层，提供 REST / A2A / MCP 三种标准接入、租户级权限管控、开源示例应用与交互式调试工具，WorkIQ 把「组织上下文」做成了可编程、可治理的基础设施。对于正在构建企业级 Agent 的开发者来说，这类上下文层的成熟度，可能比底层模型的参数量更能决定产品的实际价值。