AI Agent + Tabular Editor：让大模型直接操作Power BI模型的实战指南

做Power BI模型开发的朋友，对Tabular Editor这个名字应该不陌生。最近半年我把这个工具和AI Agent组合到一起，摸索了一套“让大模型直接动手改Power BI模型”的开发工作流，今天把整套思路和踩坑记录完整聊一遍。无论你是刚开始接触Power BI建模，还是已经在维护一套复杂语义层，这篇文章都值得花十分钟看完——我会把工具选型、原理、脚本、常见问题全部拆开讲，顺便回答一个很多人问过的问题：AI Agent和普通的大模型到底有什么区别，为什么它和Tabular Editor放在一起会产生化学反应。

1. 先把概念对齐：Power BI里的“模型”和AI Agent有什么关系

1.1 别把语义模型和机器学习模型搞混

在Power BI语境里，“模型”这个词指的通常是表格语义模型（Tabular Model），也就是你打开Power BI Desktop后，在“模型视图”里看到的那一堆表、关系、度量值、计算列、行级安全规则。它本质上是一份元数据，决定了报表能查出哪些数据、指标怎么算、权限怎么控。

很多刚接触AI的人会把这里的“模型”理解成GPT、DeepSeek那种大模型。两者完全不是一回事。搜索热词里同时出现“照片修复模型”“JVM内存模型”“Transformer模型”，就是因为“模型”这个词在不同领域里被反复占用。在Power BI开发里，我们操作的模型是数据结构的骨架；在AI语境里，模型是一套参数化函数。这篇文章里我一直说“模型”，指的都是前者，AI部分我们会用“LLM”或“Agent”来区分。

这个区分非常重要，因为后续所有自动化逻辑都建立在同一个前提下：AI要能“理解”你的语义模型结构，还得能“操作”这份结构。理解靠LLM，操作靠Tabular Editor，两者一结合，就是标题里说的Power BI模型AI Agent开发工具的组合打法。

1.2 Tabular Editor 3在生态里的地位：躲在Desktop背后的“建模引擎”

如果你只用Power BI Desktop做可视化报表，那你可能很少碰Tabular Editor。但只要你进入到模型优化、团队协作、自动化部署这些阶段，Desktop自带的建模体验很快就会成为瓶颈。

Tabular Editor 3（社区里常简称TE3，有人也叫它TE X，我理解这个X是“扩展/实验”的意思）是目前最主流的第三方Power BI建模工具。它最核心的能力是：绕过Power BI Desktop的界面，直接读写Analysis Services实例中的表格模型元数据，而且全部通过C#脚本化操作。

Desktop更像是一台自带内饰的整车，开起来舒服但改装空间小；Tabular Editor是把发动机拆出来放在操作台上，你能直接拧每一颗螺丝。建模人员通过它打开模型后，能看到所有表、列、关系、度量值的完整属性，能批量修改FormatString，能一键跑Best Practice Analyzer检查模型健康度，更能用C#脚本完成所有重复性工作。

关键点在于：它和Power BI Desktop之间的关系不是替代，而是连接。TE3可以连接到正在Desktop中打开的模型实例，两者实时同步。你在TE3里建了一个度量值，切回Desktop就能看到它出现在字段列表中。这就是后面AI Agent能够“隔空操作”的基础设施。

1.3 为什么AI Agent一定要通过Tabular Editor才能“动模型”

有人可能会问：既然DeepSeek、Claude这些大模型这么聪明，我直接把模型的DAX代码复制给它，让它给我生成新度量值不行吗？当然行，但那是“人工搬运”模式。真正要让Agent成为一个自动化的开发工具，它必须能做到三件事：

第一，自己查看模型结构。AI需要知道你的模型里有几张事实表、几张维度表、表名是什么、粒度是什么、现有度量值是怎么写的。第二，自己执行修改。AI生成一段DAX或一个计算列之后，要能直接写进模型里，而不是让用户复制粘贴。第三，自己检查结果。改完之后，AI要能重新读一遍模型，验证脚本有没有生效、有没有破坏现有规则。

这三件事都要求有一个“程序化接口”，而Power BI Desktop本身不提供对外开放的命令行或脚本入口。Tabular Editor恰恰补上了这个口子——它支持C#脚本，支持命令行执行，支持读取模型对象模型，支持把模型导出成JSON/TMSL格式。这些恰好是大模型最容易生成、最容易解析的模态。

所以我一直认为：Tabular Editor是AI Agent操作Power BI模型的最佳“手和脚”。没有它，AI只是一个聊天窗口；有了它，AI才能真正成为开发工具链上的一环。

2. AI Agent在模型开发里能干什么：我的场景拆解

2.1 模型、LLM与Agent的边界

先花一小节把概念理清，因为热搜词里专门有人在问“Agent和LLM和AI模型有什么区别”，也有人在问“DeepSeek属于哪个”。

• AI模型（Model）：泛指一套从数据中学习到的参数化系统，比如Transformer架构的语言模型、图像模型、多模态模型。DeepSeek、GPT、Claude都属于这一类产品。
• LLM（大语言模型）：专指以文本为主要输入输出的大规模语言模型，是AI模型的一种。DeepSeek、GPT、Claude也是LLM。
• AI Agent：一个以LLM为“大脑”的自主系统。它不仅会生成文本，还能把任务拆成步骤、调用外部工具、接收工具返回的结果、根据结果继续执行下一步，直到任务完成。Agent = LLM + 工具调用 + 记忆/上下文 + 执行循环。

用一句大白话总结：LLM是只会“想”和“说”的实习生，Agent是给他配上电脑、数据库、代码编辑器，让他自己查资料、动手干活、干完检查再汇报的项目专员。

在我们这套工作流里，LLM负责理解需求、生成DAX表达式、生成C#脚本；Agent负责感知模型状态、执行脚本、把执行结果喂回给LLM形成闭环。Tabular Editor就是Agent手里的“扳手”。

2.2 哪些建模工作适合交给AI，哪些不能

我把日常建模工作按“能否自动化”分成了四类，供大家参考。

第一类，适合交给AI但需要人工审核的：DAX指标生成、格式化字符串批量设置、模型文档生成、DAX表达式解释与优化建议。这类工作AI做得快，但口径对不对需要人来判断。

第二类，适合完全自动化的：重复性检查（比如找出所有没有FormatString的度量值）、批量命名规范校验、模型结构对比、把旧的Excel口径文档转成Markdown数据字典。这类工作规则明确，AI错误率低。

第三类，不建议一开始就交给AI的：模型关系推断、行级安全权限设计、粒度定义。这些任务高度依赖业务上下文，AI看不到数据分布和业务语义，硬让它做会给出“看起来合理但实际危险”的方案。

第四类，绝对不要交给AI的：生产环境部署操作、数据源凭据修改、任何影响数据刷新安全性的变更。这类操作哪怕脚本写得再漂亮，也应该放在人工确认的流程里。

我始终建议把AI Agent定位成“开发助手”，而不是“全自动驾驶”。这不仅是技术能力的限制，更是责任边界的问题。模型规则出了问题，最后背锅的一定是建模师，不是AI。

2.3 我推荐的一个MVP工作流

如果你也想试，我建议第一版MVP不要做太复杂，闭环跑通即可。我自己的MVP是这样的：

第一步，Agent读取模型结构，生成一份结构摘要。第二步，Agent根据摘要执行一个明确的小任务，比如“检查所有度量值是否都设置了FormatString，缺失的列出来”。第三步，Agent生成C#修复脚本，Tabular Editor执行。第四步，Agent重新读取模型，确认修复结果。

这个流程看起来简单，但已经包含了Agent最核心的“感知-规划-执行-验证”四个环节。后面所有复杂功能，比如批量建度量值、自动生成数据字典、根据BPA规则修复模型，都是在MVP基础上叠加场景。

3. 手把手实操：把Tabular Editor变成AI Agent的“手”

3.1 环境准备：装TE3、连接Power BI Desktop

实操部分我们从零开始。你需要准备三样东西：Power BI Desktop（注意Windows版，Mac版不支持外部工具和本地AS实例）、Tabular Editor 3、以及一个能调用LLM的环境（自己用OpenAI、Claude、DeepSeek API，或者直接用网页版都行，因为核心脚本是代码，不是聊天界面）。

安装TE3后，第一次连接的推荐路径是：先打开Power BI Desktop，加载一个.pbix报表文件，然后在“外部工具”选项卡里点击Tabular Editor的按钮。它就会自动识别当前Desktop实例的本地端口并连接上去。如果外部工具按钮不显示，可以在Power BI Desktop的“选项 - 全局 - 安全”里确认外部工具脚本已启用，或者直接运行Power BI Desktop安装目录下的TabularEditor.exe并手动输入localhost端口。

连接成功之后，TE3的界面会显示整个模型的树形结构。左边是表、列、关系、角色、度量值的层级列表，右边是属性面板，下方是C#脚本编辑器。到这里，基础设施就绪了。

3.2 用C#脚本让AI“看见”模型结构

AI无法直接“看到”TE3界面，它只能看到文本。所以第一步是把模型结构转成文本。

在TE3的C#脚本编辑器里，最常用的全局对象是Model，它代表整个表格模型。最简单的模型结构导出脚本可以这样写：

var sw = new System.IO.StringWriter(); sw.WriteLine("# 模型表清单"); foreach (var table in Model.Tables) { sw.WriteLine($"## {table.Name}"); foreach (var col in table.Columns) sw.WriteLine($"- 列: {col.Name} [{col.DataType}]"); foreach (var m in table.Measures) sw.WriteLine($"- 度量值: {m.Name} | {m.Expression} | Format={m.FormatString}"); } System.IO.File.WriteAllText(@"C:\temp\model_structure.md", sw.ToString(), System.Text.Encoding.UTF8);

这个脚本会把模型里所有表、列、度量值定义导出到一个Markdown文件。为什么用Markdown？因为LLM对结构化文本的解析能力最好，Markdown标记简单，不会像JSON那样消耗大量上下文。

如果你嫌文件太复杂，也可以只输出摘要，比如表名列表和度量值数量。上下文窗口永远是最稀缺的资源，后续我会专门讲怎么裁剪。

导出之后，把这个文件内容粘贴给LLM，或者通过API读取，Agent就拿到了“模型的地图”。这是整个自动化流程的感知层。

3.3 用C#脚本让AI“动手”改模型

光能“看”还不够，Agent得能“改”。TE3的脚本能力让这件事变得非常直接。

比如AI要新增一个度量值，脚本可以这样写：

var table = Model.Tables["Sales"]; var measure = table.AddMeasure( "毛利率", "DIVIDE(SUM('Sales'[利润]), SUM('Sales'[销售额]))", "毛利率 = 利润/销售额" ); measure.FormatString = "0.0%"; measure.Description = "由AI Agent生成，基于利润与销售额计算";

脚本执行后，模型里立刻多出一个“毛利率”度量值，格式是百分比，还带描述。切回Power BI Desktop，刷新一下字段列表就能看到。

批量场景更实用。假设你要给所有没有格式化的度量值统一加上两位小数格式，可以写：

foreach (var m in Model.AllMeasures) { if (string.IsNullOrEmpty(m.FormatString)) { m.FormatString = "0.00"; Info($"已设置: {m.Name}"); } }

这里的Model.AllMeasures是TE脚本里的便捷访问器，实质是遍历模型中所有表下的度量值对象。执行完后再让Agent重新导出结构，对比哪些已经修复，这就形成了一个完整的执行闭环。

3.4 一个端到端的协作实例：AI生成同比度量值

我用一个最常见的需求走一遍完整流程：让AI生成一个“销售额同比”度量值。

第一步，Agent读取模型结构摘要，得到以下信息：有一张名为Sales的事实表，包含[Amount]金额列和[OrderDate]订单日期列；有一张名为Date的日期维度表，包含[Date]列和[Year]列；Sales与Date已经建立关系。第二步，Agent规划：同比需要返回当前年销售额与上一年销售额的差额比例，用CALCULATE配合SAMEPERIODLASTYEAR或DATEADD实现。第三步，Agent输出度量值表达式：

销售额同比 = VAR CurrentYearSales = SUM(Sales[Amount]) VAR PreviousYearSales = CALCULATE(SUM(Sales[Amount]), SAMEPERIODLASTYEAR('Date'[Date])) RETURN DIVIDE(CurrentYearSales - PreviousYearSales, PreviousYearSales, 0)

第四步，把这段DAX包进C#脚本，在Tabular Editor中执行：

var measure = Model.Tables["Sales"].AddMeasure( "销售额同比", "VAR CurrentYearSales = SUM(Sales[Amount])\n" + "VAR PreviousYearSales = CALCULATE(SUM(Sales[Amount]), SAMEPERIODLASTYEAR('Date'[Date]))\n" + "RETURN DIVIDE(CurrentYearSales - PreviousYearSales, PreviousYearSales, 0)", "衡量当前年度销售额相对上一年度的增长情况" ); measure.FormatString = "0.0%";

第五步，Agent重新读取模型，发现新度量值已经存在，FormatString正确，表达式语法无误，任务完成。

整个过程中，建模师只需要确认业务口径（同比口径是自然年还是财年，是否排除空值），剩下的代码生成、脚本执行、结果验证都可以由Agent完成。这就是我所说的“半自动建模助手”。

4. 跑通之后踩过的坑：版本、上下文、回滚和编码

4.1 连接不上Desktop：先查这三件事

连接问题是所有人第一次用TE3时最容易卡住的地方。我遇到过三种典型情况。

第一种，外部工具按钮显示但点击无反应。大概率是Power BI Desktop版本过低，或者TE3版本过新/过旧，导致AS实例协议不匹配。建议把Desktop和TE3都升级到最新版，然后重启再试。第二种，TE3能启动但连不上本地实例。检查Power BI Desktop里是否真的打开了.pbix文件，因为Desktop只有在加载了模型文件后才会启动内置的Analysis Services实例。第三种，提示“无权限访问对象”。在Power BI Desktop的“选项 - 全局 - 安全”中确认“允许来自外部工具的脚本”已勾选。

另外提醒一句：TE3连接的是Desktop当前正在编辑的内存实例，所以模型正处于未保存状态时，你在TE3里做的修改，最终要通过Desktop保存到.pbix文件里。不要以为TE3执行完脚本就等于文件已保存。

4.2 上下文窗口被模型元数据撑爆怎么剪

大型企业项目的模型动辄几十张表、几百个度量值，如果全量导出模型结构，很容易把一个几万token的Markdown文件塞进LLM上下文，费用高不说，Agent的注意力也会被噪声分散。

我的做法是把模型结构分层导出。第一层是目录级信息，只包含表名、表行数预估、列数、度量值数量等。第二层是明细级信息，包含指定表的所有列、关系、表达式。第三层是目标级信息，只导出和当前任务相关的表和度量值。比如处理“销售额同比”，Agent只需要Sales表和Date表的完整结构，其他表给个名字就够了。

还可以在脚本里做过滤。比如让Agent只读取包含“Sales”、“Date”、“Customer”关键字的表。这样上下文消耗能降到全量导出的十分之一，成本和使用体验都有明显提升。

4.3 脚本安全：AI改坏了怎么办

AI生成的脚本不会永远正确。最危险的是：一段看似合理的C#脚本，执行后批量删除了几十个列，而你在几分钟后才反应过来。所以我在实际使用中建立了三条安全规则。

第一条，执行任何写操作前先备份。TE3的脚本里可以直接调用Serialize相关方法，或者更简单的方式是：先用脚本导出一份完整模型的JSON到本地。

System.IO.File.WriteAllText( @"C:\temp\model_backup.json", Model.SaveToJson(), System.Text.Encoding.UTF8 );

第二条，尽量在副本库上测试。Power BI Desktop里可以另存一个.pbix文件作为测试环境，让Agent先在测试模型上跑脚本，确认无误后再应用到真实模型。第三条，避免使用破坏性操作。在Agent的System Prompt里明确要求：禁止在脚本中使用Delete、Remove等危险方法，如需删除必须改为“先标记后人工确认”。

这三条规则执行到位后，我把“AI改坏模型”的概率降到了很低。但请注意：这里的“低”不等于零，所以备份永远不能省。

4.4 中文乱码与编码坑

Power BI模型里大量使用中文表名、列名和度量值名称。在脚本导出和导入时，编码问题非常坑。

早期我用System.IO.File.WriteAllText写文件时，默认使用UTF-8无BOM格式，结果喂给LLM时中文显示正常，但把AI生成的含中文的脚本再写回TE3时，偶尔会出现中文变问号的情况。原因出在Power BI Desktop的AS实例对字符串内容的传输编码要求。

我的解决办法很简单：所有写文件操作统一显式指定UTF-8编码，所有读文件操作也是。读文件时用System.IO.File.ReadAllText(path, System.Text.Encoding.UTF8)，写文件时也用带BOM的UTF-8。TE3脚本里中文变量名虽然能用，但建议所有脚本局部变量都用英文，只有写入模型的元数据名称、描述才使用中文，能少踩很多编码层面的坑。

4.5 常见问题速查表

4.6 我的几条核心使用原则

踩了这些坑之后，我给自己定了几条使用原则，也分享给想尝试的人。

第一条，AI负责写，人负责审。DAX指标的口径、业务含义、安全性，必须由人确认后再进模型。第二条，自动化只应用于“规则明确”的环节。格式批量设置、BPA规则修复、文档生成这些最适合，关系推断和权限设计暂时不要碰。第三条，每次会话开始时都要重新读取模型结构。模型可能随时被修改，Agent依赖的“认知地图”过期了，再聪明的规划也会跑偏。第四条，脚本里所有写操作要有日志。每执行一步，用一个List记录操作内容，结束后输出到文件，方便追溯。

这些原则不是凭空想的，都是我实际跑这个工作流吃了几次亏之后沉淀下来的。模型开发这个行当，最怕的不是出错，而是出错后不知道错在哪一步。Agent把步骤变快了，也把错误的链条变长了，所以日志和备份比以往任何时候都重要。

最后再分享一个我个人的小技巧。我在Agent的System Prompt里放了这样一段话：“你是一个Power BI建模专家。当需要执行修改操作时，你必须先输出脚本，说明脚本的预期影响，等用户确认后再执行。永远不要在未告知用户的情况下删除任何对象。”这句话看起来简单，但它非常明确地约束了Agent的行为边界，很大程度上避免了“AI自由发挥导致模型混乱”的情况。如果你也准备给Agent配上Tabular Editor这个工具箱，不妨先从这段话开始。