此内容由人工智能翻译，尚未经过人工编辑审核。图像和图表保持其原始语言。
要点速览
- AI 可以查询或修改语义模型。 能使用工具与语义模型交互的 AI，就是智能体。 读取并查询语义模型的智能体只是在回答用户数据问题（例如 Copilot 或 Microsoft Fabric 中基于语义模型的数据智能体）时，为对话式 BI 和数据探索提供支持。 修改语义模型的智能体会借助工具直接或以编程方式更改模型元数据。
- 智能体式开发对语义模型可能很有用。在合适的场景并做好充分准备的前提下使用智能体，可以帮你节省时间、减少麻烦。 但如果准备不足，或用在不合适的场景中，智能体未必能缩短开发时间或提升质量，甚至可能增加开发耗时和成本。 使用这项技术时，你还必须考虑相关的注意事项、局限性以及数据安全风险。
- 像 Claude Code 这样的编码智能体提供了最有意思的用例。即使没有编码智能体，你仍可以在 Power BI 中使用 Copilot，或在代码中调用 API，将 AI 应用于语义模型。 不过，随着 GitHub Copilot 等编码智能体的出现，尤其是像 Claude Code 这样驻留在终端里的智能体，正在涌现出更有意思、也更实用的场景。
- 编码智能体可以通过三种不同方式修改语义模型。它们可以 直接修改模型元数据，也可以使用语义模型 MCP 服务器，或者直接使用命令行工具和库。 每种方式都有优缺点。若你在做智能体式开发，很可能会三者结合，用来增强传统的开发工作流。
- 本系列文章将探讨语义模型的智能体式开发。我们会对每种方式做深入分析，并讨论各自的优缺点。 这些文章虽然聚焦于语义模型，但其底层概念同样适用于其他成果物（如报表）的智能体化开发，以及更广义的软件智能体化开发。
本摘要由作者撰写，并非由 AI 生成。
<！--more-->在语义模型中使用 AI 智能体
自从 ChatGPT 出现后，大家就开始尝试用 AI 来帮助编写 DAX 和构建语义模型。 此前，这通常局限于从聊天机器人复制粘贴代码、在 Power BI 中使用 Copilot，或在脚本和 Notebook 中调用 API。 而现在，Anthropic 的 Claude Code 等编码智能体的出现，让这件事变得更有意思，也更可行。 编码智能体是一类 AI 系统：大语言模型（LLM）可以在循环中借助工具生成并执行代码。
在语义模型的语境下，智能体大致可分为两类：
- 用于查询语义模型的智能体：浏览元数据，并针对模型生成查询，以检索信息并回答用户的数据问题。 我们通常把这称为 对话式 BI，以区别于传统 BI：用户通过模型查询得到的 Visual 或表格来查看数据。 消费型智能体的例子包括 Copilot 的“提问数据”体验，或 Microsoft Fabric 中基于语义模型的数据智能体。
- 用于修改语义模型的智能体：读取并修改语义模型元数据，可以直接修改，也可以通过编程方式修改，同时还能与语义模型周边环境交互。 我们将其称为语义模型的 智能体式开发。 这类智能体不仅可以修改属性、生成 DAX 或 Power Query 表达式，还可能下载、部署并管理语义模型。 能修改语义模型的智能体通常也能查询它；例如，你可以用任何编码智能体（如 Claude Code）查询语义模型，但此处的查询通常是为了给特定修改提供依据或进行验证。
在本系列文章中，我们聚焦于用于语义模型开发的智能体。 更具体地说，我们会梳理当前的工具与方法版图，讨论每种方式的潜在用例、收益与注意事项。
展示一个智能体是什么，比解释它更容易。 为了演示，下面是一个在受控环境中由 Claude Code 对语义模型进行修改的示例。 具体来说，它在重构模型中的度量值：让它们改用某个 DAX 函数，并将这些度量值重命名，以符合一套标准命名规范：
在这个演示里，智能体可以访问本地模型元数据、一个 Power BI MCP 服务器，以及 Tabular Editor CLI，用来运行 C# Script 脚本，在语义模型上执行操作。 它可以在模型中搜索需要重构的度量值，读取必须使用的函数以理解其语法，然后修改所有度量值的 DAX，最后由用户验证结果。 像这样重构 DAX，是智能体式模型开发的一个很实用的用例。
注意
在使用或开发语义模型时，你无需在 AI 和非 AI 方法之间二选一。 相反，你可以两者并用，并针对具体问题或场景选择合适的方法。 通常（至少目前）如果现有工作流能承载，你会用 AI 方法来增强它们。
如果你想更全面地了解在哪些场景可以更广泛地利用 AI 和智能体式开发，作者已在 SQLBI 上做了详细阐述。 参阅 这篇文章 和 白皮书。
什么是语义模型的智能体式开发？
这意味着智能体可以访问工具来查看并修改模型元数据。 它可以读取表、列、DAX 度量值以及其他对象的名称、表达式和其他属性。 智能体可以创建、修改，甚至删除它们。 通常，智能体用来执行这些操作的工具，会让 LLM 生成属性值，例如显示文件夹名称或度量值说明。
下图用简单的方式展示了这个流程的样子：
流程如下：
- 用户提供提示词，指示智能体对语义模型执行某项操作，通常通过聊天机器人界面完成。
- 智能体会摄取某种上下文，例如其他文件、对话历史以及它的系统提示词。 最常见的是你在电脑上编写的 Markdown 文件，智能体会在会话开始时或进行过程中读取这些文件。
- 智能体会在循环中使用工具与语义模型交互，并读取工具返回的结果。 智能体可以一次发起多个工具调用，或（取决于系统）并行调用。
- 最终，智能体退出工具调用循环，并将输出返回给用户；用户可以在 Tabular Editor、Power BI Desktop 或 VS Code 等客户端工具中验证结果。
我们会讨论智能体如何做到这一点，但先看看为什么智能体式开发可能有用。
为什么以及何时要进行智能体式开发？
从理论上讲，你可以用智能体端到端地开发并管理整个语义模型。 事实上，自今年年初编码智能体兴起以来，这一点就已经成为现实，正如我们在之前的文章中讨论并演示的那样。 的确，用自然语言在环境中执行操作的新鲜感既令人印象深刻，也让人兴奋！
不过，把智能体式开发用在合适的场景里，往往更有用也更高效（在成本和时间上都是如此）。 原因包括：
- 智能体在不同任务上的表现差异很大。例如，智能体很擅长重构代码，但不太擅长生成对空白字符敏感的代码或元数据，例如。 TMDL 文档。
- 智能体可能执行破坏性操作。在语义模型中哪怕只改动、移动或删除一个度量值，都可能导致 Report 损坏、用户不满并浪费时间。 使用智能体时，你需要严格管理版本控制、检查点、自动化测试以及智能体权限，以避免发生意外。
- 要想表现出色，智能体需要针对任务的详细指令和信息。你需要投入大量时间在指令文件中为智能体编写这些上下文，而且无法保证这笔成本一定会带来投资回报，也就是更快或更高质量的开发。 让 AI 替你编写这些上下文也并不可靠；往往甚至会让结果更差。
- 编码智能体和 LLM 通常会给组织带来各种数据安全和隐私风险。大多数免费/公开的智能体都受一些条款约束，这些条款可能与很多组织的数据隐私和安全政策不一致。 除非你拥有已通过雇主审查并批准、且允许用于你们组织数据的企业订阅，否则应将工作限制在仅处理非敏感数据和元数据。 对于希望用编码智能体来协助处理客户数据或元数据的顾问而言，这一点尤为重要。
- 这是一项尚处早期（新兴）的技术。很多人仍在摸索如何让智能体更好地工作、降低成本并缓解风险。 最佳实践很少，变化频率高、幅度也大。 更糟的是，针对特定任务，智能体的性能很难衡量。 基准测试在很大程度上只是“表演式”的、缺乏细致度的指标，用来单独比较模型，而且忽略了其他因素（提示词、上下文、工具和环境）。 许多此类测试“缺乏科学严谨性”，在真实世界的应用中可能既不实用也不可靠。
需要注意的是，上述注意事项并不一定意味着要完全忽视或拒绝智能体式开发。 恰恰相反，这些点很值得你记在心里：这样你才能最大化利用这项技术，同时把风险降到可控范围。 智能体开发能带来收益的方式有很多。 以下是一些用例示例，说明何时将 LLM 与语义模型结合使用更合适：
注意
我们希望聚焦一些用例：在这些问题上，我们认为 LLM 相比现有的非 AI 方案，确实能带来改进。 这些改进可能源于 LLM 方法本身的优势，也可能只是给用户带来便利——但只有在充分权衡现实中的风险与注意事项之后，这些改进才成立。
- 帮你搜索或总结模型的部分内容：当你接手别人做的模型时，往往很难在“一团乱麻”里理清结构。 这时，用 Haiku 4.5 这类更高效的模型，能更好地帮你定位特定对象、模式或问题（而不是用 Sonnet 4.5 之类的模型，因为 Haiku 4.5 通常更快，在搜索与摘要上更高效）。 例如：
- 查找某些列或度量值：它们的对象名称与用户或其他开发者的习惯叫法不一致。
- 识别 DAX 或 Power Query (M) 表达式中存在问题的模式。
- 发现不常见的属性设置，例如某些列将 AvailableInMDX 设为 False，或某些表将 IsPrivate 设为 True, 或某些表禁用了刷新，或配置了自定义分区。 你也可以让 LLM 帮你编写自定义的 Best Practice Analyzer (BPA) 规则，以便用 Tabular Editor 或其他工具自动发现这些问题。
- 执行批量操作：当你需要在模型的多个位置应用同一项更改时，智能体可以通过执行代码，或生成 C# Script 和宏（配合 Tabular Editor），或生成 Python Notebook（配合 Semantic Link Labs）来帮你完成。你可以在执行前先审阅这些内容，从而得到确定且可重复的结果。 例如：
- 批量创建度量值，例如时间智能或常见聚合。 比如，将现有度量值重构为使用支持自定义日历的全新增强版时间智能。
- 设置属性，例如（动态）格式字符串、SummarizeBy、DataType 或 SortBy。
- 修改或格式化 DAX 与 Power Query (M) 表达式。 一个明确的例子是：在 Power Query 中，将导入分区的连接字符串参数化。
- 为不易脚本化的枯燥重复工作节省时间：智能体可以完成一些不太容易用脚本实现的任务。 通常做法是：智能体先修改元数据，然后由你再手动审阅结果。 例如：
- 基于一些示例与模板，起草度量值、列和表的说明（然后你再自己审阅）。
- 建议、创建并更新翻译和透视。
- 重构表、列、度量值和函数名称，使其符合标准化命名规范。
- 整理与审计模型：承接上一点，如果你给智能体提供清晰的说明与提示，它可以帮助你改进语义模型，或改进围绕它的流程。 例如：
- 查找并修复一些众所周知的反模式，这些反模式会导致模型体积膨胀或查询性能变差。
- 将 DAX 表达式重构为使用新定义的函数。
- 将包含 Report 与语义模型的“厚 Report”拆分为不同的 Power BI Desktop 或 Project 文件（一个“薄 Report”和一个模型）。
- 将一个大模型拆分为多个更小的模型，或反向合并。
警告
如果你只是对智能体说“优化我的模型”或“整理我的模型”，就别指望能得到好结果。 对不同模型、不同开发者来说，“优化”和“整理”的含义在具体语境中并不相同。 这正是你值得投入时间去写一个可复用 Prompt 的典型场景：把上下文与步骤讲清楚，让智能体知道在当前这个场景里，“优化”和“整理”对你意味着什么。
即便如此，你也应该预期需要迭代几轮，才能拿到一个不错的首版结果。
智能体修改语义模型的不同方式
智能体能做什么、如何做到、效果如何，取决于多个因素：
- 其底层大语言模型
- 你提供给它的上下文或说明，或它能自行检索到的上下文
- 你用来开启会话的 Prompt 或说明
- 智能体可用的工具、它如何发现这些工具，以及这些工具的设计方式
- 智能体所运行的环境。
逐一分析这些要素很有意思，但本系列会把重点放在工具上。 在这个语境下，你可以用多种不同方法借助 AI 来促进模型开发。 首先，有两种常见方法完全不依赖代码智能体：
- Power BI Desktop 中的 Copilot 提供了多项功能，可辅助模型开发。 具体来说，Copilot 可以生成单个度量值说明、语言模型中的同义词，以及 DAX 查询视图中的 DAX 查询。
- Tabular Editor 中的单个 C# Script，以及 Fabric (semantic link labs) 中的 Python Notebook 可以让你在执行代码时调用 LLM API，你可以提示它生成属性值（例如表达式或说明）等更多内容。
这些方法可行，但能力远不如代码智能体强大。 像 Claude Code 或 GitHub Copilot 这样的代码智能体，可以通过以下方式与语义模型协作：
注意
这里只是高层概览。 我们会在后续的单独文章中详细讨论每种方法，包括优缺点，以及基于我们经验的一些提示与建议。 由于安全是最基础也最关键的考量，我们也写了一篇单独的文章来深入讨论这一点。
- 基于模型元数据的代码智能体: 代码智能体可以使用内置工具，例如 Read 或 Write 直接查看并修改模型元数据。 采用这种方式时，你会把模型保存为 Power BI Project，或将其定义保存到本地，然后让智能体在这些文件上工作。 它适用于 model.bim (TMSL)、TMDL，以及 Tabular Editor 的“保存到文件夹” Database.json 格式。 这种方式很简单，不需要额外工具；但更容易出现导致元数据无效的错误，而且在做变更时可能不如其他方法高效，尤其是面对更大或更复杂的模型时。
- 搭配 Model Context Protocol (MCP) 服务器的代码智能体：MCP 服务器可以暴露一些工具，让代码智能体以编程方式与 Tabular Object Model (TOM) 交互。 采用这种方式时，你需要将代码智能体配置为使用一个由你或他人构建的 MCP 服务器。 编码代理可以自然地发现并使用这些工具，从而更便捷地更改模型元数据、Power BI Desktop 中打开的模型，或已发布到服务中的模型。 这种方式可能比直接操作元数据更高效、更稳健，因为这些工具可以进行验证、支持批量操作，并引导 LLM。 不过，MCP 服务器会在上下文窗口中占用大量 token，这可能导致代理性能衰减，并更快触及使用限制。 它们也可能不够灵活，因为代理只能按照工具既定的方式使用，且无法修改工具本身。
- 使用命令行工具或 API 的编码代理： 最好的编码代理会提供一个 Bash 工具，让它们能够在命令行中执行命令。 这意味着编码代理可以使用带命令行界面的工具，例如 Tabular Editor、Fabric CLI 等，以及其他工具。 代理也可以直接使用 API 或它们的封装库。 用这种方式时，你先安装一个 CLI 工具，然后让代理用它来修改模型，例如。 C# 脚本。 这种方式适用于本地元数据文件、Power BI Desktop，以及 Power BI 服务中已发布的模型。 它能赋予代理最大的灵活性，同时还能进行验证，并避免让上下文窗口变得臃肿。 不过，这些 CLI 工具需要为代理式使用而精心设计；而且对于训练数据中覆盖较少的新 CLI 工具，代理也需要足够充分的上下文信息。
如你所见，这几种方法各有优缺点；没有哪一种是客观上更好的选择。 事实上，如果你在进行语义模型的代理式开发，很可能会把这三种方法组合使用，以获得各自的优势。
再强调一次，这些方法也都不是对 Power BI Desktop、Tabular Editor 等传统开发工具的替代。 相反，它们是在你的工作流之上进行增强：带来一些新且有意思的可能性，帮你节省时间，并促进规格驱动开发。
结论
只要给对工具，AI 就可以查询、汇总并修改语义模型。 这些语义模型代理在特定任务上很有用；它们可以增强传统开发工具或工作流，但不能替代它们。 代理与语义模型协作主要有三种方式：处理元数据文件、使用 MCP 服务器，或使用代码与命令行工具。
本系列接下来的文章会从直接修改模型元数据开始，逐一深入介绍这些方法。 在此继续阅读第一部分。