微软Fabric开放MCP架构，AI代理直连数据平台

企业数据平台花了四十年建墙，微软现在给AI发了把钥匙——不用拆墙，不用写一行集成代码。

一个协议终结重复造轮子

每次工程团队想让AI代理连上数据平台，都得从零搭同一套基础设施：OAuth2流程、令牌管理、速率限制、API版本控制、错误处理。代理还没干正事，人已经累了。

更麻烦的是多工具并存。一家公司同时跑GitHub Copilot、Claude、Cursor、Copilot Studio，每个都要单独对接。集成面爆炸，维护成本失控。

根子问题在于：AI工具和企业系统之间没有通用语。每次对接都是定制开发，脆弱、耗时，而且往往由本来有更重要事情的人顺手搞定。代理拿到的上下文要么太少、要么太多，对着生产环境输出的结果难以预测。

微软Fabric现在放出两个MCP入口，对应两种自主级别。

本地版已上线：开发者的对话式控制台

Fabric Local MCP正式可用。这是一个开源服务器，跑在开发者本地机器上，让AI助手深度理解Fabric的API。

它能做什么？本地到云端的数据操作——上传数据到OneLake、创建数据项、检查表结构——全在一个对话里完成。Local MCP可以把Fabric命令行工具包装成可调用的工具，意味着CI/CD流水线能无人值守地部署变更。认证内置，不用手动管令牌。

推荐安装方式是VS Code扩展，一键配置。

开发者场景很具体：写数据管道时，让GitHub Copilot或Claude查正确的Fabric API规范、生成代码、上传数据、验证结果——全程在一个对话线程里。代理不再瞎猜API参数名，不再幻觉。

远程版预览中：云端代理的入口

Fabric Remote MCP处于预览阶段。这是云端托管服务器，无需本地配置。AI代理可以直接在Fabric环境里执行认证操作：管理工作区、处理权限、代表团队执行任务。

这是Copilot Studio里自主代理的入口，不是给终端前结对编程的开发者用的。

两个版本都跑在Fabric现有的安全模型、审计追踪、基于角色的访问控制边界内。代理只能访问认证用户能访问的东西。不需要额外配角色，没有影子权限，没有新增攻击面。

MCP协议：从Anthropic到行业事实标准

底层协议是MCP——模型上下文协议（Model Context Protocol），Anthropic原创，现在GitHub、Cloudflare、Stripe和越来越多企业平台采用。

逻辑很直接：不给每个AI工具做定制集成，把平台暴露成MCP服务器，任何MCP兼容客户端都能秒连。

微软Fabric

角色分工清晰。开发者用Local MCP在对话里完成端到端数据操作；Copilot Studio的自主代理用Remote MCP在云端执行团队级任务。同一套协议，两种部署形态，覆盖从个人编程到组织自动化的完整光谱。

数据收束

微软Fabric的两个MCP入口——Local MCP正式可用，Remote MCP预览中——标志着企业数据平台开始原生支持AI代理协议层。 Anthropic发起的MCP协议，正在被GitHub、Cloudflare、Stripe、微软等主流平台采纳，成为AI工具与企业系统之间的通用接口标准。 对数据团队来说，这意味着OAuth2流水线、令牌管理、API版本控制的重复建设可以终结，AI代理首次能够以统一、安全、可审计的方式直连生产数据环境。