Dataverse MCP：Claude Code/Copilot接入企业数据平台

Microsoft 刚刚交付了速度快 6 倍的 Dataverse 搜索索引，并使其可通过同一端点在 Claude Code、GitHub Copilot 和 Copilot Studio 中通过 MCP 寻址。在我们看来，这重新打开了你们架构团队此前因冷启动时间、数据陈旧或单一供应商锁定而拒绝的所有"智能体在 Dataverse 上运行"的架构决策。

方向，而非成熟度。Microsoft 的架构方向现已明确。但各类实际智能体落地的运维成熟度参差不齐。社区反馈已显示出 Copilot Studio 智能体误读大型 Dataverse 表的情况（2026 年 5 月 Reddit r/copilotstudio 帖子关于 30-40 万行 FP&A 数据误读），多轮对话 grounding 漂移，以及对话上下文保留不一致等问题。请将本文视为平台方向解读，生产落地时机请根据你们自己的试点情况评估。

在我们看来，2026 年 5 月 5 日的 Power Platform 公告比 Foundry 品牌重塑更具影响力：Dataverse 被重新定位，不再只是"Power Apps 下的数据库"，而是"一切之上的智能体数据平台"——作为 AI 智能体推理所依赖的 schema、流程和规则层，通过可与任何 MCP 兼容客户端配合工作的 MCP 服务器对外暴露。

本文是对此的深度解读。

TL;DR 及周一行动

根据 Microsoft 5 月 5 日的公告，三项内容于 2026-05-05 发布：Dataverse 搜索索引升级（GA，2026 年 6 月初扩展至 Word / Excel / Teams / Outlook）、Business Skills（公开预览，仅限托管环境）和适用于编码智能体的 Dataverse 插件（公开预览，在 Claude Marketplace 开源，同时支持 Claude Code 和 GitHub Copilot）。

周一行动：如果你此前的 AI 架构决策因"Dataverse 搜索太慢"被否决，请重新打开这些决策。据 Microsoft 称，2026 年 5 月更新后，搜索索引初始化速度最高提升 6 倍。

战略洞察：Microsoft 自家产品现已默认支持多 AI：Claude Code、GitHub Copilot 和 Copilot Studio 运行在同一 MCP 层上。

一个数据层，多种智能体：Copilot Studio、GitHub Copilot 和 Claude Code 都通过 MCP 访问同一个 Dataverse。

三层，明确命名

在深入实质内容之前，先明确这三层的名称。5 月 5 日的公告跨越了三个不同的抽象层级。混淆这些层级，是大多数解读文章变得混乱的原因。

本文讨论的是最底层。模型层和编排层独立演进；Dataverse-as-agent-data-platform（Dataverse 作为智能体数据平台）这一层处理表关系、列级元数据、安全修剪检索、流程指令和 schema 感知的工具调用，支撑其上运行的各个智能体。文章其余部分假设这种分离。

先做一个前置操作说明。采用这个平台并不免除架构师现有的职责。正确的语义建模（哪些表、哪些关系、哪些查找字段）、数据塑形（干净的记录、去重后的实体、合理的类型）、检索设计（schema 感知查询、安全修剪、范围限定到用例的知识源）以及用于计算的非智能体确定性工具（Power Automate 流、计算列、外部计算）仍然全部适用。该平台使 Microsoft 业务应用上的智能体 AI 成为可能；而架构师的规范使这种智能体 AI 变得正确。

2026 年 5 月 5 日发布了什么

5 月 5 日的公告是整合，而非发明。Dataverse MCP 服务器自 2025 年底以来一直处于预览状态；智能体搜索索引工作自 2025 年 12 月起滚动推进；2026 年上半年更早的时候，原生 M365 Copilot 边车已内置于 Power Apps 和 Dynamics 365 Sales / Customer Service 中。上周变化的是框架定位（Dataverse-as-platform 而非 Dataverse-as-database）、Copilot 在全部 M365 表面的 GA 扩展（2026 年 6 月初），以及 Business Skills + 编码智能体插件作为一等公民概念的加入。GA 有一项，预览有两项，三者都位于 MCP 服务器预览之上。

以下各节逐一解读。

Dataverse MCP 服务器是什么？（多 AI 访问层）

直接回答。Dataverse MCP 服务器是每个组织一个的 Model Context Protocol 端点，地址为 https://{dataverseOrgName}.crm.dynamics.com/api/mcp，向任何 MCP 兼容的智能体客户端暴露 Dataverse 的数据、schema 和工具。截至 2026-05-10，它处于公开预览状态，由 Dataverse intelligence 环境设置中的每客户端允许列表控制。

它向任何 MCP 兼容的客户端暴露 Dataverse 数据、schema 和工具：Copilot Studio 智能体、VS Code GitHub Copilot 智能体模式、Claude Code、Claude Desktop、GitHub Copilot CLI。每客户端允许列表在环境设置中配置。

换句话说，这就是 Microsoft 自家产品中的多 AI 宣言。一次编写的查询，可被每一个严肃企业路线图上的智能体平台所消费。

Dataverse MCP 服务器作为每个组织一个的端点，有着每客户端允许列表。同样的查询，适配所有 LLM。

Claude Code 的具体设置示例：

# 将 contoso 替换为你的 Dataverse 组织名称；先在环境设置中验证允许列表
claude mcp add dataverse https://contoso.crm.dynamics.com/api/mcp

# 验证服务器已注册
claude mcp list

对于 VS Code GitHub Copilot 智能体模式，等效操作是从命令面板中选择 MCP: Add Server，使用相同的 URL 模式。详见 VS Code Copilot 配置文档了解完整流程。

Microsoft 365 Copilot 中的 Dataverse：搜索索引提速 6 倍（GA，2026 年 6 月）

原来的边车在 2026 年上半年已内置于 Power Apps 和 D365 Sales / Customer Service 中。2026 年 5 月的公告将体验扩展到全部 M365 表面：桌面 Copilot 应用、Teams、Outlook、Word、Excel 和 PowerPoint，预计"2026 年 6 月初"可用。这次扩展是 GA，而非预览。

营销话语背后的实质是搜索索引升级。Dataverse 搜索有三种索引类型：相关性搜索（驱动全局搜索和 SearchQuery API）、结构化搜索（驱动表格上的 Copilot 和智能体）和非结构化搜索（驱动文件上的 Copilot 和智能体）。2026 年 5 月的更新主要针对驱动生成式 AI 体验的结构化和非结构化索引。

据 Microsoft 5 月 5 日公告，核心数据：

新环境初始化速度最高提升 6 倍（从数小时缩短到数分钟）

近实时数据新鲜度（更新在几分钟内出现）

通过后台刷新实现零中断的 schema 演进

Copilot 索引路径与全局搜索路径的独立管理员控制

"6 倍"是 Microsoft 报告的数字；请将其作为供应商基准，待独立验证。无论确切倍数如何，对架构师而言这一启示是真实的：如果你在 2026 年 5 月之前因冷启动时间或数据陈旧而否决了智能体在 Dataverse 上运行的架构设计，那么现在这一决策依据已经发生变化，值得重新打开讨论。

Business Skills：面向智能体的解决方案感知流程知识（预览）

在我们看来，Business Skills 是三项能力中架构意义最重大的一项。

此前，针对 Dataverse 数据的智能体有两个选项。依靠 LLM 从 schema 和指令中推断业务流程。或者将流程逻辑硬编码到智能体提示词和 Power Automate 流中。根据我们的经验，两种方式都不好扩展：提示词会漂移，流会碎片化分散到各个环境中，流程知识最终散落在多个所有者和界面之间。

Business Skills 将这些整合为一个一等公民制品。一个 skill 是一个 markdown 文档，包含名称、描述、分步说明和可选的资源文件（策略、SOP、模板、计算）。根据 MS Learn 页面，大小限制为每个资源文件 20 MB，每个上传的 skill 30 MB。关键在于，skills 是解决方案感知的：它们打包进 Dataverse 解决方案，通过 ALM 流水线部署，随表和流一起在环境间迁移。

Microsoft 的公告重点介绍了 Velrada 的 Inspection Agent 作为客户案例。根据 Microsoft 发布的摘要，该智能体使用 Business Skills 处理 HVAC 设备评估，根据设备类别和检查历史提出上下文相关的问题。请将此作为 Microsoft 公开的案例，而非独立验证的生产案例。

你会遇到的前置条件：

Managed Environment（非标准环境）

已启用 Dataverse 智能（租户级开关）

已启用 Dataverse MCP 服务器预览（环境级开关）

支持解决方案感知的 ALM（若需要在 dev、test、prod 之间干净地迁移技能）

如果你的环境治理团队仍在抵制采用 Managed Environment，那么在我们看来，这就是推动这场对话的强制力量。

一个最小化 Business Skill 在 markdown 中的样子（说明性示例；结构与微软发布的格式一致）：

---
name: log_call_transcript
description: 将客户通话记录作为活动记录到 Dataverse。当用户粘贴通话笔记并要求 AI 智能体将其记录时使用。
---

# 步骤

1. 通过通话记录中的公司名称识别相关 Account。
2. 创建一个类型为 "Call"、subject 为通话记录第一行的 Activity 记录。
3. 用完整的通话记录文本填充 Description。
4. 通过 regardingobjectid 将 Activity 关联到 Account。
5. 将新 Activity 记录 ID 返回给用户。

# 资源

- account-lookup-rules.md：如何消除相似名称公司的歧义。
- transcript-redaction-policy.pdf：存储前的 PII 处理规则。

该技能可被任何连接到 Dataverse MCP 服务器的 MCP 客户端发现。Copilot Studio、Claude Code 或 GitHub Copilot 中的 AI 智能体可以找到并执行它，无需针对每个客户端进行配置。

Dataverse Plugin for Coding Agents：Claude Code + GitHub Copilot（预览）

第三个公告是最能体现多 AI 宣言标签的一个。Dataverse Plugin for Coding Agents 是开源的，发布在 Claude Marketplace 上，并明确支持 Claude Code 和 GitHub Copilot。

根据微软 5 月 5 日的公告，该插件是四个现有工具的编排器：

根据公告，插件的价值在于编排逻辑：当开发者要求"创建一个包含字段 A、B、C 的线索表，关联到 accounts，并带有示例数据集"时，插件决定是调用 MCP 服务器获取 schema、调用 CLI 进行解决方案感知部署，还是调用 Python SDK 进行批量插入。

这与微软在 2026 年早些时候发布的 Power Pages 插件结构相似，后者使用相同的 Claude Code + GitHub Copilot CLI 模式，通过会话式斜杠命令工作。Dataverse Plugin 将该模式从特定的 Power Pages 泛化到任何 Power Platform / D365 环境。

为什么开源很重要——在我们看来。微软并未将其限制在 Power Platform Premium 之后。该插件发布在 Claude Marketplace 上，因此拥有 Anthropic Pro 订阅和 Power Platform 环境的开发者可以在无需额外 Microsoft 许可层级的情况下安装和使用它。这对微软的 AI 工具来说不同寻常，而架构师的解读是：微软将开发者插件层视为一种分发策略，而非盈利策略。

一个浓缩的工作示例。开发者提示：

> /create-table leads with columns name (text), email (text),
> account_lookup (lookup to accounts), source (choice)
> + 100 sample rows

根据微软公告，插件的编排逻辑：

调用 MCP 服务器进行 accounts 表 schema 发现（小额负载）

调用 Dataverse CLI 创建带有列 + 查找关系的线索解决方案感知表

调用 PAC CLI 确认部署到活动解决方案

调用 Python SDK 进行 100 行批量插入（比 MCP 单条创建更低 per-row 成本）

向开发者返回部署清单 + 示例记录 ID

根据子任务选择正确工具的决定逻辑，这是直接运行任何一个工具的价值所在。

工作示例：200 家供应商 AP 团队的发票异常处理

抽象架构只有在绑定到具体的丑陋工作流时才能令人信服。我们在这里运行的是中端市场应付账款中的发票异常处理。AI 智能体层无法端到端解决它。它做的是人类目前做得很差的工作，同时将平台不应该拥有的工作留给确定性工具。

背景设定。微软 Dynamics 365 Finance 中的 200 家供应商中端市场 AP 团队。三个重要的 Dataverse 表：Supplier、Invoice、PurchaseOrder。发票通过电子邮件和共享收件箱到达；8-12% 会进入异常状态（PO 不匹配、缺少 GL 代码、单价漂移超出容差、行项目算术与表头总计不匹配、与已付款发票重复）。AP 职员目前手动分类每个异常。典型处理时间：如果明显，每张发票 45-90 秒；如果不明显，则 5-15 分钟。

AI 智能体做什么。一个连接到 Dataverse MCP 服务器的 Copilot Studio AI 智能体，带有一个名为 triage_invoice_exception 的 Business Skill。该技能的指令，用纯 markdown 编写：

---
name: triage_invoice_exception
description: 将发票异常分类为五种类别之一，并提出后续操作。当发票处于 "Exception" 状态需要路由决策时使用。
---

# 步骤

1. 读取 Invoice 记录（status = "Exception"）。
2. 通过 regardingobjectid 查找读取相关的 PurchaseOrder。
3. 读取相关 Supplier 记录，获取付款条款和前期争议历史。
4. 使用确定性计算工具（而非 LLM 的算术能力）比较发票表头总计与行项目总计之和。
5. 将异常分类为以下之一：PO_MISMATCH、MISSING_GL、UNIT_PRICE_DRIFT、ARITHMETIC_MISMATCH、DUPLICATE。
6. 对于 DUPLICATE：查询 Invoice 表，查找 30 天内供应商 + 金额 + 发票日期匹配项；返回发现结果及重复记录的 record ID。
7. 对于 UNIT_PRICE_DRIFT：查询该供应商最近 5 张相同 SKU 的发票；返回带有时间戳的价格趋势。
8. 返回结构化建议：route_to（AP_clerk_review | supplier_followup | controller_approval | auto_reject）、confidence_score 和一行理由。

# 约束

- 永不批准、拒绝或支付发票。AI 智能体负责分类和路由。人类负责批准。
- 对于 ARITHMETIC_MISMATCH，始终使用确定性计算；不要"估算"数学结果。
- 如果供应商过去 12 个月有 3 次或以上争议，无论其他信号如何，均升级到 controller_approval。

生产环境中会出什么故障。架构师必须设计的三个命名故障模式：

Invoice 表的 schema 漂移。如果有人在不更新技能指令的情况下添加了新的行项目列，AI 智能体会在下一个 MCP 服务器 schema 刷新传播之前一直基于过时 schema 进行推理。缓解措施：通过清单锁定相关列，并添加 CI 检查以确保技能引用的列仍然存在。

幻觉性重复检测。LLM 给定同一供应商的 100 行发票查询结果时，偶尔会编造一个不存在的重复项。缓解措施：强制重复检查使用确定性 Dataverse 查询和显式相等性过滤器，而不是 LLM 在结果集上的模式匹配。

拥有 200+ 发票的供应商上的上下文窗口溢出。"获取同一 SKU 的最近 5 张发票"这一步看起来很便宜；但对于长尾供应商，它会拉取更宽的结果集并将对话推过上下文预算。缓解措施：通过 read_query 进行分页，使用显式的 top=5 order=invoice_date desc 子句；永不允许 AI 智能体获取无界结果。

架构带来的收益。做得正确的话，AI 智能体在 15 秒内处理 70-80% 的异常，确定性工具处理计算，LLM 处理分类 + 路由。AP 职员只需看到需要实际判断的 20-30%。这是现实的运营结果。这不是营销口号（"AI 为你做 AP"）。这是架构师可以向 CFO 辩护的实际结果。

Dataverse Agent Data Platform：命名与术语表

在表格之前有两个名称需要了解。品牌已从"Azure AI Foundry"漂移到 Microsoft Foundry 的产品表面，而 Dataverse 引用现在根据 AI 智能体表面的不同，同时出现在 Power Platform 和 Microsoft 365 文档中。Azure 资源类型保持为 Microsoft.CognitiveServices/accounts，Dataverse 保持为 Dataverse。在以下八个术语中，对架构师而言两个承重术语是 Business Skills 和 Dataverse MCP Server。其余的都是有用的别名。

如果你的团队仍在工单中写"Azure AI Foundry"，现在就重命名。未来 90 天的 Microsoft 文档将越来越 exclusive 地使用"Microsoft Foundry"和"Dataverse Agent Data Platform"术语。

你应该现在采用 Dataverse Business Skills 和 MCP Server 吗？

直接回答：如果你的 AI 智能体已经以 Dataverse 为基础，可以采用 Managed Environment，且你的开发者目前使用 Claude Code 或 GitHub Copilot，现在就构建。否则，采用 6 月的 GA M365 Copilot 扩展，并将 Business Skills 和 Dataverse Plugin 推迟到公开预览结束。

如果你的工作负载受监管

对于 GxP、SOX、HIPAA 或 FedRAMP 范围的 production 环境，无论以下条件如何组合，都应将预览功能限制在非生产租户内。在受监管生产环境中仅采用 GA 级别的功能（M365 Copilot 扩展、搜索索引改进），直到 Business Skills 和 Dataverse MCP 服务器退出预览。

五个条件决定答案：

你的智能体是否已建立在 Dataverse 数据之上？

你能否采用托管环境（Managed Environments）？

你是否能容忍 MCP 服务器和 Business Skills 的预览级依赖？

你是否具备 ALM 规范来在不同环境间整洁地迁移 Skills？

你的开发团队目前是否在使用 Claude Code 或 GitHub Copilot？

六种场景将这些条件映射到具体行动。

30 秒自助分类。下表是同一决策的参考形式。

经验法则：如果五个条件中通过三个或以上，现在就构建。否则，仅采用 GA 级别的扩展，并等待其余功能退出预览。

需要对 Dataverse + 智能体采用计划进行合理性检查？

如果你正在为企业级 Power Platform 或 D365 环境制定方案，请在确定迁移窗口前联系我们，对场景映射进行第二轮审查。

Dataverse 智能体数据平台的五个 Pilot 坑点

对于决定现在就采用的团队，以下是 Pilot 阶段容易踩坑的事项。

1. 租户级前置依赖栈：托管环境（Managed Environments）和 Dataverse Intelligence。这是两个独立的租户级开关，两者均为 Business Skills 和 MCP 服务器所必需。托管环境是全组织级治理；Dataverse Intelligence 则是控制 MCP 服务器和 Business Skills 的 AI 功能门控。两者任一缺失，其余堆栈会悄然失败。根据我们的经验，如果你的租户一直在推迟托管环境的采用，计划 4-6 周的治理审批周期。

2. 增强语义索引会带来存储成本增加。根据微软 5 月 5 日的公告，为 Copilot 和智能体提供支持的 structured 和 unstructured 索引，比 relevance search 消耗更多存储。微软截至 2026-05-10 尚未公布具体的价格差异百分比；根据我们的经验，差异主要取决于索引覆盖范围（包含多少表和文件类型），而非行数。新的管理控制允许按环境选择加入 Copilot 索引，因此在生产环境开启该功能前需预算一笔不小的增长，并根据实际的智能体应用范围调整包含的表列表。

3. MCP 服务器 URL 是按组织（per-organization）而非按环境（per-environment）。格式：https://{dataverseOrgName}.crm.dynamics.com/api/mcp，参见 Dataverse MCP 服务器配置文档。在多组织租户中规划客户端配置时需特别注意。连接还需要在环境设置中将相应的 MCP 客户端加入允许列表：Microsoft GitHub Copilot、Claude Desktop、Claude Code 等均可单独配置。

4. Business Skills 具有解决方案感知能力，但 MCP 服务器预览功能则不具备。当将 Skills 打包到解决方案中并迁移到生产环境时，Skill 内容会随之移动，但 Skills 依赖的 MCP 服务器预览工具是环境级开关。在解决方案导入前，需验证目标环境已启用正确的预览功能，否则 Skills 将在生产环境中悄然执行失败。

在我们的经验中，失败模式表现为：Skill 干净地导入到目标解决方案，智能体通过 list_skills 成功列出 Skill，但当智能体尝试调用依赖预览 MCP 工具的 Skill 步骤时（例如 retrieve_knowledge 或解决方案感知的 Skill 资源），调用返回空载荷而非错误。智能体随后仅根据指令自行编造答案，且没有缺失工具的日志痕迹。导入前验证清单：托管环境已启用、Dataverse Intelligence 已开启、MCP 服务器预览已启用、各客户端允许列表已重新应用到目标环境。在包含 Skills 的任何解决方案导入前，确认以上全部四项。

5. 大规模架构组织中 MCP schema 发现上下文成本。调用 Dataverse MCP 服务器进行 schema 发现会消耗 LLM 上下文窗口，消耗量与表和列数量成正比。根据我们在 50 表以上组织（默认 custom-column 密度）的经验，宽泛的 schema 发现在任何 productive 工作之前已消耗约 8K-15K tokens；200 表的 CRM 组织则将其推向 30K-50K 范围。规划上下文预算的方式应与规划存储预算相同，当智能体已知道哪些实体在范围内时，使用有针对性的 describe_table 调用，而非先 list_tables 再全局发现。

总结：每个坑点都可以归结为两个根本原因之一。租户级开关规范（坑点 1）帮你越过最常见的阻碍。预览感知的 ALM + 预算规范（坑点 2、3、4、5）覆盖其余全部。把这两件事做对，其余都是配置问题。