与 Power BI 语义模型 MCP 服务器配合使用的 AI 代理

此内容由人工智能翻译，尚未经过人工编辑审核。图像和图表保持其原始语言。

关键要点

• 本文是系列文章的一部分。 从第一篇开始：点这里。
• AI 应用可以借助内置工具的 MCP 服务器来操作语义模型。 采用这种方式时，这些工具提供了以编程方式读取并修改语义模型的能力。 这通常是通过 Tabular Object Model (TOM) 来完成的。
• 可用的 Power BI MCP 服务器不止一个，其中包括 Microsoft 提供的。 其中的 Power BI modelling MCP 提供了许多实用工具和资源，用于语义模型的代理式开发。 就我们目前用过的 MCP 服务器而言，它是最成熟、最完善的之一（不仅在 Power BI 领域，在任何领域都算）。
• MCP 服务器使用和配置都很方便。 只要 AI 应用支持模型上下文协议，你就可以搭配使用。 它们自带开箱即用的上下文，能帮助代理在合适的场景下更容易找到并使用合适的工具与提示词。 Microsoft 的 Power BI modelling MCP 服务器做得非常扎实，提供了大量选项和防护机制来帮助你。
• 不过，MCP 服务器会占用大量上下文，而且工具可能不够灵活或不够透明。 使用 MCP 服务器时，它会消耗你可用上下文窗口的很大一部分。 这就像你与 AI 聊天时可用的“预算”。 当你“花”得太多时，性能下降、触发限制都会来得更快。 另外，你无法更改 MCP 服务器中提供的工具，因此它们可能不符合你的场景或用例。 要把它们用好，你需要理解有哪些工具，以及它们分别做什么。
• 我们建议你把 MCP 服务器用在本地模型元数据上。 这样你可以更高效地执行批量操作，同时也更容易跟踪、管理并回滚更改。 编程代理仍然可以直接在 TMDL 文件上完成简单修改。

本摘要由作者撰写，并非由 AI 生成。

使用 Power BI MCP 服务器修改语义模型

本系列会带你了解如何用 AI 借助代理来更改语义模型的不同方法。 语义模型代理拥有一些工具，使其能够读取、查询，并将更改写回语义模型。 以这种方式使用代理称为 代理式开发，在某些场景下，它可以作为对传统开发工具与工作流的有效补充。

AI 修改语义模型有多种方式，包括修改 TMDL 元数据文件、使用 MCP 服务器，或直接编写代码。 每种方式都有优缺点。如果你打算用 AI 来修改语义模型，那么你很可能三种都会用到。

本文将深入讨论 MCP 服务器，帮助你更好地对 Power BI 语义模型进行代理式开发。

什么是 MCP 服务器？

在上一篇文章中，我们介绍了模型上下文协议（MCP），并讨论了 MCP 服务器可能如何改变 BI 工具。 概括来说，MCP 服务器通过为大语言模型（LLM）提供可复用的上下文（资源）、提示词和工具，来扩展其能力。 工具提供特定的函数与代码，让 AI 能够与其环境交互——要么获取上下文，要么执行操作。

在 Power BI 语义模型的场景下，MCP 服务器可以使用 Tabular Object Model (TOM) 库，通过 XMLA 协议以编程方式对模型进行更改：

这与使用 SQL Server Management Studio (SSMS) 等现有方法，以及 Tabular Editor 等外部工具的思路类似。 不同之处在于：这里的 TOM 操作被封装进了 LLM 使用的工具中，而不是由用户直接操作。 这些工具决定了 AI 能做什么。 MCP 服务器可能允许你执行所有操作——这些操作要么可以通过 Tabular Editor 中的 C# Script 完成，要么可以通过手动编辑 TMDL 文件来完成。 但它也可能受到很大限制。 这取决于具体的 MCP 服务器以及其工具的工作方式。

为说明起见，下面是一个示例：Claude Code 使用 Microsoft 的 Power BI 建模 MCP 服务器来修改语义模型。

此演示展示了 Claude Code 在重新绑定 Report 后，使用 MCP 服务器补齐模型中缺失的 DAX 函数。 智能体使用 MCP 服务器连接到 Power BI Desktop 中打开的本地模型，对其进行探索，并添加这些函数，用以替换原有的 DAX 表达式。 注意，现在更难查看和跟踪这些更改；我们不再有内联 diff 来展示智能体具体改了什么——不像智能体直接操作本地元数据文件时那样。 智能体在某个时刻也会困惑，开始对错误的模型进行操作。

不过，使用 MCP 服务器更快也更方便；任何破坏性更改都会被捕获并返回错误，智能体可以据此修复问题，从而一次性只提交有效的更改。 几分钟内，智能体就能完成这些更改，然后你可以在 Power BI Desktop 或 Tabular Editor 中进行验证。

场景示意图

下图简要概述了如何使用 MCP 服务器来促进语义模型的智能体式开发：

请注意，此图展示的是一个经过简化的场景。 在实际落地中，你很可能会使用更多组件和工具——既包括传统方式的，也包括 AI 方式的。 你可以这样理解这个流程：

1. 用户要么在 Power BI Desktop 中打开其模型，要么将其发布到工作区。 你也可能把模型保存为 PBIP，以便查看并处理模型元数据。 具体做法取决于用户的偏好以及所使用的 MCP 服务器。
2. 用户整理一套基础指令（例如 AGENTS.md 或 CLAUDE.md）以及上下文（其他指令文件；通常为 Markdown），用于描述 TMDL 格式和他们希望更改的语义模型。 他们还可以根据所使用的编程智能体，按需配置其他智能体工具与组件，例如 Microsoft Docs 远程 MCP 服务器或 Claude Code 技能。 设置这些指令和上下文并不是一次性工作，需要持续整理与维护；它更像是一项沟通与写作能力，而不是技术能力。
3. 用户与编程智能体一起创建提示词或起草计划。 最佳实践是在智能体做出任何更改之前，以迭代方式和它一起完成这一步。 上下文、指令和提示词不应由 AI 生成或由智能体创建，否则可能导致性能下降。
4. 你提交提示词以启动会话。
5. 智能体会加载其指令，以及来自已配置 MCP 服务器的工具说明与资源。 这些信息会进入上下文窗口，也就是智能体在每次会话中可使用的有限 token 预算。
6. 智能体可以使用内置工具或 MCP 服务器工具来读取其他指令，或在连接后检索关于语义模型的信息 (连接后)。
7. 智能体对语义模型进行更改：要么在 Power BI Desktop 中，要么在 Power BI 服务中已发布的模型上。
8. 用户在 Power BI Desktop 或其他工具中验证这些更改。

演示：实际会是什么样

下面是几个智能体通过 MCP 服务器处理语义模型的示例。

GitHub Copilot 示例

GitHub Copilot 的智能体模式提供了对 MCP 服务器与自定义的广泛支持。 Power BI MCP 已预置了一个 VS Code 扩展，帮助你进行管理。

下面的示例展示了 GitHub Copilot 为模型中的多个度量值批量添加说明、格式字符串和显示文件夹。 注意，这里我们是在 Power BI Desktop 中操作：

Claude Desktop 示例

另一个支持 MCP 服务器的热门工具是 Claude Desktop。 与 VS Code 相比，Claude Desktop 的用户界面更轻量、更简洁，也很擅长临时生成各种概念的 ad hoc 可视化或示意图。

要在 Claude Desktop 中配置 MCP 服务器，你需要下载 VS Code 扩展的 .vsix 文件，并从中解压出可执行文件 (.exe)。 然后，你还需要在设置 JSON 中提供更详细的配置，或者创建自定义的 .mcpb 或 .dxt 文件。

下面是一个示例：Claude Desktop 使用 MCP 服务器，用一张相当潦草的图来描绘字段之间的关系：

注意，Claude Desktop 可以创建 artifacts，在应用中将代码渲染为图像。 Claude Desktop 更适合探索性任务或模型调用与分析，但不太适合开发。 通常，如果你能提供更充分的上下文，以及你对美观度与设计风格的预期示例，它在处理这类图表时表现也会更好。 对于开发，我们建议你在 VS Code 中使用 GitHub Copilot，或在终端中使用 Claude Code。

Claude Code 示例

Claude Code 有图形界面，但你也可以直接在终端中使用它。

将这个 MCP 服务器添加到 Claude Code 会稍微复杂一些，因为需要进行一些特定配置。 你可以复制下面的命令完成此操作。需要在 PowerShell 或 Bash 中运行，并将其中的路径替换为指向 powerbi-modeling-mcp 的正确路径。

claude mcp add --transport stdio powerbi-modeling-mcp --env PBI_MODELING_MCP_CLIENT_ID=ea0616ba-638b-4df5-95b9-636659ae5121 -- "C:\pathto\powerbi-modeling-mcp.exe" --start

下面是 Claude Code 使用语义模型 MCP 服务器的示例。 这里，用户让 Claude Code 添加并对 DAX 度量值做一些修改：

在这个示例中，你可以看到，在表之间移动度量值可能具有破坏性；这会导致某个 Visual 出错。 你还可以看到，智能体会基于模型中的既有模式做出某些 DAX 假设；除非你在提示词或上下文里提供足够的说明或示例，否则你不能指望它写出“好的” DAX 或 Power Query。 这也是一个不适合做智能体开发的例子；直接在 Power BI Desktop 或 Tabular Editor 中创建并调整度量值会更快、更便宜，而且大概率也更容易。

正如你在演示中看到的那样，Claude Code 特别有用，因为它会在上下文窗口中提供对当前发生情况的 Visual 拆解。 在下图中，你可以看到，在一个全新会话里，即使还没有任何提示词，上下文也已经被占用了 60%。 仅 Power BI 建模 MCP 服务器就占用了 29% 的上下文：

这是 MCP 服务器面临的最大挑战之一，所以我们在这里先强调一下。 在本文后面，我们会更详细地解释为什么这会带来挑战。

如何开始

要使用这种方法，你需要一个支持语义模型操作的 MCP 服务器，例如 Power BI MCP 服务器。 你还需要一个支持模型上下文协议（MCP，Model Context Protocol）的 AI 应用，即上面展示的那种 MCP 客户端。 完整清单如下：

• 你的模型可以是以下三种格式之一：
  • 在 Power BI Desktop 中打开。
  • 以 PBIP 格式保存，或保存为本地元数据文件。
  • 发布到 Power BI Workspace。 注意：根据你使用的 MCP 服务器，你可能需要 Power BI Pro 许可证，或支持 XMLA endpoint 的 Workspace 许可模式。
• 一个编码智能体，例如处于 Agent 模式的 GitHub Copilot、Claude Code 或 Gemini CLI。 大多数编码智能体都需要付费订阅才能使用。 我们推荐 Claude Code，我们认为它在 Microsoft Fabric、Power BI 以及总体的智能体开发方面，功能最完善、开发者体验最好。
• 理想情况下，你还应该有某种方式来跟踪和管理对模型的更改。 如需对该主题有一个基础了解，可以阅读 Microsoft 文档中的这篇文章。

与其他方法的差异

使用 MCP 服务器的智能体，与直接修改元数据或使用 CLI 与脚本相比，有几个不同点，我们会在下文展开。

优势

这种方法有一些独特优势：

• 为智能体提供工具： MCP 服务器擅长为智能体提供工具，并提供一种机制来告诉它们何时以及如何使用这些工具。 设计良好的工具能让用户更容易实现“即插即用”，而且用户不必投入太多上下文或说明文件，也能让智能体在合适的场景使用合适的工具。 对于语义模型来说，这能帮助智能体根据提示词与上下文判断：何时使用工具来修改度量值，何时去查询模型。
• 可移植的上下文与提示词：除了工具之外，MCP 服务器还可以提供资源与提示词。 资源基本上就是上下文文件，智能体可以自动读取并使用；而提示词则是可复用的提示模板，用于某些可重复执行的任务。 对于语义模型来说，这对较新的 DAX 功能尤其有用，例如函数和自定义日历。
• 更少的幻觉：与直接修改模型元数据不同，这种方法只能通过 TOM 允许受支持的更改。 当然，这取决于可用工具及其设计方式；但它有助于确保智能体只对语义模型做出有效更改，并降低幻觉发生的概率及其潜在影响。
• 相对容易设置与使用：MCP 服务器以可移植性为设计目标，因此你可以很容易把它配置到你选择的工具或模型上使用。 如果你出于安全或隐私考虑在本地模型上工作（例如通过 LMStudio），这一点尤其有用。

总之，MCP 服务器是一种很实用的方式，可以通过简单的配置为智能体提供工具。 它们很难设计得真正出色，但一旦做对了，就会非常强大且方便。 不过，它们也并非没有挑战。

挑战

下面是一些在 Power BI 语义模型场景以及更广泛场景中使用 MCP 服务器时需要注意的点：

• 更改的可见性与回滚：不同于直接修改模型元数据，使用 MCP 服务器时，你不容易看清到底改了什么。 你只能把智能体的输出与 Power BI 或 Tabular Editor 中实际发生的变化进行交叉核对。 此外，你无法撤销或回退所做的更改。 如果你不设置版本控制，一旦（不是“会不会”，而是“什么时候”）你的代理开始“脱轨”，你就可能白白浪费大量时间。 当你刚开始使用 MCP 服务器，或用它配合新模型时，这个问题尤其棘手，因为你还没有建立好高质量的指令或提示词。
• 工具设计可能不透明或过于僵硬：使用 MCP 服务器时，你会受限于开发者对工具的设计方式。 这意味着工具说明、代码或返回结果可能并不适合你的场景，甚至根本不支持。 除非 MCP 服务器是开源的，否则你很可能连这些工具都看不到，更别说修改了。 当你有独特的配置、设计，或采用复合模型等存储模式时，这会尤其棘手。 在这种情况下，你应该直接处理模型元数据，或使用 Tabular Editor 2 CLI。
• 上下文膨胀：MCP 服务器的一个已知问题是，它们会占满你会话的上下文窗口。 使用的上下文越多，代理在同一任务上的表现就越差。 也会导致会话更容易突然达到上限。 对于范围过大、更适合拆分为按需使用的模块化、场景化组件的大型“单体” MCP 服务器来说，这个问题尤其突出。
• 仍然需要指令：MCP 服务器之所以方便，是因为它们开箱即用地提供了大量关于如何以及何时使用工具的上下文信息。 但这并不意味着代理就会正确或高效地使用这些工具。 例如，如果你让代理在 Power Query 中把连接字符串参数化，它可能具备创建共享表达式或修改 M 分区的工具，但这并不代表它知道如何按你想要或需要的模式来编写 M 代码。 要做到这一点，你得提供明确指令：改什么、怎么改。 在修改 DAX 和 Power Query 表达式时，这一点尤其重要。
• 安全挑战：MCP 服务器是一项新兴且仍在演进的技术。 还有许多安全隐患或漏洞尚未被充分解决或理解。

如你所见，为了便捷使用 MCP 服务器所付出的“代价”，也伴随着其他不便和需要考虑的地方。

何时可能会使用这种方式

在以下场景中，MCP 服务器相较于其他代理式开发方式更合适：

• 批量更改与重构：Power BI MCP 这类 MCP 服务器工具，能以很优雅的方式一次性完成多项更改。 一次设置多个属性，或创建多个度量值；这类操作设置和使用都很简单。 当你想为模型创建新的透视和翻译时，这尤其有用。
• 工具提供实用且独特的功能：MCP 服务器在解决特定问题时表现最佳。 小而精的 MCP 服务器，用专门的工具帮你应对特定场景，会非常有价值。
• 你无法或不想使用命令行代理：运行在命令行里的代理，通常更适合搭配其他 CLI 工具和 API。 但如果你只使用带 UI 的工具，例如处于代理模式的 GitHub Copilot 或 Claude Desktop，你可能会发现 MCP 服务器能带来更好的用户体验。
• 大多数通用场景：在典型场景下，powerbi-modelling-mcp 目前是用于语义模型的代理式开发的最佳工具。 如果你有更具体的需求或要求，可以用其他工具来补足它。

你可能不会用这种方式的情况

有几种情况下，你可能会考虑用 MCP 服务器以外的替代方案。

• 工具不符合你的场景或用例：正如上面提到的，MCP 服务器工具可能比较僵硬、不够灵活，未必符合你的需求。 如果你需要更高的灵活性，更好的做法可能是直接操作模型元数据，或使用编程接口。
• 单次或一次性更改：通常用传统工具来做这些更改更快也更省，或者让代理直接在模型元数据上操作也行。
• 可脚本化的重复且确定性更改：当你用 AI 配合模型元数据或 MCP 服务器时，即使提示词一样，也可能得到不同结果。 如果你希望每次都得到相同结果，最好让 AI 编写并执行脚本。 例如：创建时间智能度量值、日期表，或应用常见的 DAX 与 Data model 设计模式。
• CI/CD 管道：MCP 服务器会增加不必要的复杂度和安全风险。 如果你打算把异步代理用在 CI/CD 管道里，就让它们直接读取并处理元数据。 如果不需要，就不要用智能体。 一般来说，CI/CD 讲究可复现性；而 LLM 天生就不太可复现……
• 你使用的是 Mac 或 Linux： 目前，用于以编程方式与语义模型交互的库依赖 Windows 组件，因此无法在 Mac 或 Linux 上运行。 不过，未来可能会改变。

总之，什么时候该用、什么时候不该用 MCP 服务器，取决于你的具体场景。 你需要了解有哪些可用工具、它们如何运作，以及它们有哪些局限。

使用 MCP 服务器开发智能体的成功建议

只要用得得当，MCP 服务器就会非常强大。 下面是一些我们基于自身经验的建议，不过上一篇文章里的很多建议同样适用（比如整理上下文、与其他方法组合，等等）：

• 以 PBIP 格式保存模型并定期提交更改： 这对任何方法都适用，但在这里尤其重要，这样你就能轻松查看并回滚更改。 如果你直接在 Power BI Desktop 上使用 MCP 服务器，记得在 Power BI Desktop 中保存文件，这样更改才会出现在模型元数据中。
• 只在需要时启用： 如上所述，MCP 服务器会占用非常多的上下文窗口。 每个会话中，尽量严格控制启用的服务器和工具，避免触达限制或导致性能衰减。
• 检查工具输入和响应：当你第一次使用 MCP 服务器时，务必确认它接收到的输入是什么，以及它返回了什么响应。 理解 MCP 服务器工具至关重要，才能确保你正确使用它们，也不会误解其能力，从而被 LLM 的幻觉误导。 一个具体例子是：如果你让 MCP 服务器创建字段参数，但它又不知道字段参数是什么，它可能只会创建一个配置错误的计算表格。
• 迭代并改进上下文： 和所有方法一样，随着你不断优化上下文，MCP 服务器的效果会更好。 当你发现智能体在不合适的情况下调用工具，或传入了你不喜欢的输入时，可以改进指令以获得更好的结果。

总之，MCP 服务器是进行智能体开发的便捷工具，但最好结合场景谨慎使用。 只使用来自可信作者的 MCP 服务器，并在使用前确保你清楚这些工具具体做什么。

结语

MCP 服务器为 AI 修改语义模型提供了一种有价值、也很有意思的方式。 MCP 服务器最大的优势在于可移植性：它可以让模型“知道”有哪些工具，并指示模型在何时使用它们。 不过，MCP 服务器也有明显弱点：它们会消耗大量上下文，而且工具本身也有局限。 尽管如此，当你理解这些工具并在正确场景下应用时，MCP 服务器仍然可以在某些情况下显著加速开发，尤其是 Microsoft 的 Power BI 建模 MCP。

本系列的下一篇文章将讨论第三种也是最后一种方法：让智能体以编程方式与模型交互。 这种方法与 MCP 服务器类似，只是模型不再使用预定义工具。 相反，它可以任意编写并执行代码。 这种方法的灵活性最高，但也可能带来额外风险，并需要更多上下文。