上下文争夺战：微软Fabric如何成为AI应用的新基石

做 AI 应用这一年多，我对 Context 这个英文单词已经产生了生理性反应。不是因为它难懂，而是几乎每个星期都要跟它搏斗：好好的 Agent 跑着跑着，突然抛一个 400 错误，说模型的 maximum context length 是 1048576 tokens，你把太多东西塞进去了，直接爆掉；运气差一点，还会遇到context is too large and auto-compaction could not recover this，连自动压缩都救不回来，只能重置对话，从头再来。

就在这种日常拉锯里，微软把 Microsoft Fabric 推上了 AI 基石的位置——这场关于 Context 的争夺战，已经不只是技术参数层面的内卷，而是一场新的 AI 基础设施战略布局。这篇文章我想从自己实操和观察的角度聊聊：上下文为什么成了兵家必争之地，Fabric 凭什么被选中，以及作为工程师或架构师，我们能从这场争夺战里拿到什么可落地的思路。

1. "上下文"凭什么成为 AI 时代的核心战场

1.1 那个让我血压升高的报错

先说一下我日常遇到的真实场景。用 Claude Code、Cursor 这类 AI 编程工具跑一个跨模块的重构任务，跑着跑着终端里就会冒出来类似这样的报错：

api error: 400 this model's maximum context length is 1048576 tokens. howeve...

1048576 这个数字其实是 2 的 20 次方，看起来很大，但对真正干过 AI 应用的人都知道，这些 token 根本不够用。一次代码审查要贴进去的文件、一次架构设计要参考的历史决策记录、一次跨系统数据排查要关联的表结构，随随便便就是几万甚至几十万 token。更麻烦的是，token 不仅要看得见，还要留得住——对话越深，历史上下文占用的空间就越大，最后模型能用来"思考"的空间反而越来越小。

还有个更隐蔽的问题：上下文越长，推理延迟越高，单次请求的成本也越高。按现在主流厂商的计费方式，输入 token 也是要花钱的。你把公司过去一年的业务数据全塞进去，模型确实"知道"了，但你的账单也会知道。

所以你会看到整个行业在疯狂加长上下文窗口：从最早的 4K、8K，到 128K、200K，再到 1M，这个军备竞赛背后就是大家默认"上下文就是 AI 的记忆容量"。但我一直觉得，这个方向有点跑偏了。把窗口做大，解决的是"装得下"的问题，而真正的问题是"该装什么"和"装进去的东西够不够可靠"。后者才是企业级 AI 应用的核心矛盾。

1.2 上下文其实有三个层次

如果只把上下文理解成"聊天记录"，那格局就太小了。在我搭过的系统里，上下文至少分三层：

第一层是对话上下文。就是用户和 AI 之间你来我往的聊天历史，包括用户意图、中间过程、已经确认的结论。这类上下文是短暂的，一轮任务结束基本就可以归档。

第二层是系统上下文。包括当前任务的状态、工具调用的输入输出、执行环境的信息。比如一个 Agent 在操作数据库时，它已经执行了哪些查询、拿到了什么结果、下一步该做什么，这些都属于系统上下文。这一层的核心是"状态管理"，处理不好就会出现 Agent 重复执行、上下文漂移这类问题。

第三层是企业数据上下文。这是最重的一层，也是我认为微软真正在抢的一层。它指的是企业沉淀下来的业务数据、流程规范、知识库、权限边界、历史项目经验。一个 AI 助手能不能给出靠谱的回答，不取决于它有多聪明，而取决于它有没有在回答之前拿到对的业务上下文。

前两层是任何做 AI 应用的人都要处理的技术细节，第三层才是决定 AI 产品能否在企业里真正落地生根的胜负手。

1.3 上下文入口就是数据入口

为什么"上下文"这个词会从技术术语变成战略概念？因为谁掌握了上下文的供给，谁就掌握了 AI 应用对世界的理解方式。

打个比方，大模型像是一个能力很强但不带记忆的顾问。你问它问题，它只能靠训练时学到的"常识"来答。如果你希望这个顾问能针对你公司的具体情况给建议，就必须在每次提问时，把相关的业务背景、历史数据、决策规则一起递过去。这部分内容就是上下文。而一个 AI 应用的好用程度，几乎完全取决于它的"上下文供给系统"有多顺滑。

这时候你再回头看标题里的"上下文争夺战"，逻辑就通了：微软不是在争一个 API 参数，它争的是企业在构建 AI 应用时，默认会把哪套系统当成"企业记忆"的来源。每一次 AI 调用都要经过上下文这个管道，这个管道的建设者手里握着的，是整个 AI 生态里最有黏性的位置。

2. 压上 Fabric：数据平台如何成为"AI 基石"

2.1 从数仓到湖仓，再到"Data + AI 统一平面"

要理解微软为什么押注 Fabric，得先看数据平台这十几年的演进路径，这不是技术考古，而是理解"基石"这个词的上下文。

第一代是传统数仓。以 Teradata、Oracle 数仓为代表，特点是结构化数据、强 Schema 约束、ETL 流程严整。它解决的问题是企业"报表怎么出"，但对非结构化数据几乎无解，扩展性也差。

第二代是数据湖和湖仓一体化。以 Databricks、Snowflake、AWS 生态为代表，核心思路是"先把所有数据都放进来，后面再慢慢整理"。这个阶段解决了数据"装得下"的问题，但带来新的麻烦：数据入湖之后很快就变成一潭死水，业务部门找不到、不敢用、不知道怎么用。

第三代就是现在正在发生的：Data + AI 的统一平面。单纯把数据存起来已经不够了，平台要能天然地被 AI 消费。这也是为什么微软把 Fabric 从"数据分析平台"重新定义为"AI 基石"——它不再是给报表工程师准备的，而是给 AI 应用提供上下文的中枢系统。

2.2 Fabric 全家桶里到底有什么

微软官方对 Fabric 的定义是"一套 SaaS 化的统一数据平台"，这个描述比较抽象。我拆开来看，它其实是把微软过去散落的数据产品打包成了一个有内在连接的整体：

这套组合最关键的变量是 OneLake。它本质上是一个基于 OneDrive 体验打造的企业级数据湖，不需要单独配存储集群、不需要维护权限体系，开通 Fabric 就自带。在 OneLake 里，一份数据可以被湖屋（Lakehouse）、数仓（Warehouse）、Power BI 语义模型、AI 应用同时引用，不用复制来复制去。这一点对 AI 场景太重要了——上下文如果分散在十几个系统里，每次调用都要做数据搬运，那这个 AI 应用就别想有好的实时性。

2.3 为什么是 Fabric，而不是其他平台

Databricks 和 Snowflake 也都在讲 AI 和上下文，但 Fabric 有几个它们不好复制的条件。

第一个条件是统一治理。Purview 与 Fabric 的深度集成意味着，从你决定把某张表作为 AI 上下文的那一刻起，它就已经处于数据分类、敏感度标签和访问审计的覆盖范围里。企业做 AI 最怕的是什么？不是模型不够强，而是数据和权限边界失控。Fabric 在这一点上是把治理做进了底层，而不是事后补插件。

第二个条件是全家桶打通。Fabric 和 Microsoft 365、Azure OpenAI、Power Platform 是同一套账号体系和鉴权体系。这意味着企业内部已经躺在 SharePoint、Dynamics 365、甚至 Excel 里的数据，可以通过 Data Factory 在几步之内进入 OneLake，再成为 AI 的上下文。对绝大部分企业来说，这些存量数据才是真正的富矿，而不是从零开始建的"AI 专用数据仓库"。

第三个条件，也是我自己比较看重的一点：Fabric 的语义层和 Power BI 的数据模型天然同源。Power BI 里已经建好的度量值、维度和表关系，可以直接复用到 AI 应用中，作为"企业上下文的公共语言"。这一点我在后面第 4 节会展开讲具体玩法。相比之下，很多平台有数据、有模型，但缺少一个被业务广泛接受的语义中间层，AI 调用时还是各说各话。

3. 微软的明牌：Copilot 与 Agent 都把 Fabric 当"上下文中枢"

3.1 Copilot 的地基问题

聊微软的 AI 战略，绕不开 Copilot。现在市面上有一大堆 Copilot 产品：讲 PPT 的、写代码的、做报表的。但用过的人都有一个体感：同样的 Copilot，在有些公司里很聪明，在有些公司里很智障。差别不在模型，而在它拿没拿到靠谱的企业上下文。

最典型的翻车场景是：你问 Copilot"这个季度销售为什么下滑"，它不知道你公司有几条产品线、渠道结构是什么、哪些客户是战略客户，于是只能泛泛而谈"可能受市场环境影响""建议加强营销"。这种回答有天理但没信息量。要让它答到点子上，必须把销售明细表、产品线口径、同比基期、甚至销售团队的组织架构一起作为上下文喂进去。这些数据在哪？大部分在企业的湖里、仓里、业务系统里——也就是 Fabric 想统一的那一层。

所以微软把 Fabric 推到 AI 基石的位置，本质上是在给 Copilot 铺路。光有模型和入口不够，模型背后的数据地板如果不平，上面所有 AI 应用都是豆腐渣工程。

3.2 Agent 时代对上下文的新要求

如果说 Copilot 还只是"问答式"的 AI，那 Agent 就是"执行式"的 AI。AI Agent 要自己拆解任务、调用工具、检查结果、迭代执行，它对上下文的需求比 Copilot 高一整个量级。

我最近在玩多 AI 协作的场景，感受特别明显。多个 Agent 配合完成一个复杂任务时，它们之间需要共享一套"工作记忆"：谁已经完成了什么、产出了什么结论、有哪些约束条件、下一步交给谁。这套记忆如果只放在对话窗口里，很快就会爆掉，而且 Agent 一重启就全部丢失。热词里频繁出现的"多AI协作""AI Native 研发范式"，背后都指向同一个问题：Agent 需要一套持久化、可检索、有权限管理的上下文系统，而不是一次性把整个对话历史重新灌进去。

这就变成了一个工程问题，而工程问题的答案通常会落到基础设施上。Fabric 提供的 OneLake 存储、语义模型和 Purview 治理，恰好可以作为 Agent 记忆层的载体：历史执行记录落在湖屋里，共享的业务口径用语义模型表达，权限边界由 Purview 统一管控。

3.3 Fabric 在企业 Agent 架构里的实际位置

按我目前比较认同的架构方式，Fabric 在企业级 Agent 系统里至少承担四个角色：

第一，知识检索底座。Agent 在回答之前，先通过 RAG（检索增强生成）从 OneLake 中存好的知识库、历史工单、产品文档里检索相关内容，再把这些内容作为上下文拼进 prompt。这一步解决的是"模型不知道企业内部细节"的问题。

第二，记忆持久化仓库。Agent 多轮执行的中间状态、工具调用日志、已确认结论，落到 OneLake 里按会话维度管理。Agent 实例重启之后，可以基于湖屋里恢复的上下文继续干活，而不是一切归零。这对生产环境的稳定性非常重要。

第三，业务工具的数据边界。Agent 调用工具（查订单、改配置、发通知）之前，必须知道自己的权限边界。Purview 里定义的访问策略直接约束 Agent 能读到哪些表、不能写哪些表。这一点做不好，Agent 越权就是安全事故，而不只是技术事故。

第四，语义层与实时上下文。Agent 每次收集到的实时数据（库存、订单、系统状态）通过 Real-Time Intelligence 进入 Fabric 之后，会自动按语义模型组织，Agent 拿到的不是一堆 JSON，而是一套被业务口径校准过的数据视图。

3.4 一个串起来的场景

举个我自己实践过的例子。做一个供应链异常处理的 Agent：半夜某个大客户订单延迟了，Fabric 的 Real-Time Intelligence 从 ERP 里接入延迟事件，触发 Data Activator 发消息给值班 Agent。Agent 收到事件后，先从 Fabric 语义模型里查询这个客户的优先级和历史履约率，再从 OneLake 索引的仓库知识库中检索同类异常的处理预案，然后调用工单系统创建任务、在 Power BI 报告里标记异常。整个过程中，模型本身没有变，变的是它每一轮决策都能拿到对的上下文——而且这些上下文全部来自 Fabric 这一个底座。

这个场景要是换成传统方式做，光是把 ERP 数据同步到一个向量数据库、再单独写一套权限校验、再维护历史记录表，就够一个团队干半年。Fabric 的定位就是把这些"上下文工程"的脏活统一收编。

4. 落地：把 Fabric 当成公司级上下文系统来搭

4.1 第一步：OneLake 收口散落数据

如果你所在的企业已经在用 Fabric，或者准备试用，我建议别急着追新功能，先做一件事：把散落在各处的数据接入 OneLake。

实际操作上，就是用 Data Factory 把几类核心数据源纳入管理：数据库（SQL Server、PostgreSQL、MySQL）、业务 SaaS（Salesforce、SAP、Dynamics）、文件共享（企业内部知识库、历史报表）。这一步的价值不是把数据搬个家，而是建立一个"所有 AI 上下文都必须从这个统一入口过"的规矩。

我在接数据时踩过一个坑：一开始图省事，直接把生产数据库的表原样复制到湖屋，结果字段命名混乱、敏感字段一大堆，后面建语义模型时返工了两个月。正确做法是先做一遍轻量梳理：敏感字段脱敏、统一主键、给每张表配上业务描述。这些元数据在后续做知识检索时就是现成的"字段级上下文"。

4.2 第二步：语义层让"上下文"可复用

真正让 Fabric 区别于普通数据湖的，是它的语义层。

Power BI 里有数据集（Dataset）和语义模型的概念，你可以把公司统一的指标口径、维度定义、计算逻辑放在这一层。比如"销售额"到底是含税还是不含税、"活跃客户"的定义是什么，在语义模型里定死。这个语义模型不只是给报表用的，它可以直接作为 AI 上下文的公共语言。

具体到实现：你在 Fabric 里建一个 "Core Metrics" 语义模型，里面定义好收入、毛利、客户分层等关键指标。之后不管是 Copilot 回答问题、Agent 查数据，还是业务部门自己做分析，拿到的口径都是一致的。AI 应用不需要在 prompt 里反复解释指标定义，只引用语义模型里的度量名就行，既省 token，又避免口径混乱。

这是我在实际项目中感知到价值最大的部分，也恰恰是最容易被忽略的部分。很多人用 Fabric 只盯着数据接入和湖屋建模，语义层一直闲置，结果 AI 应用还是要靠人工维护一堆口径文档，等于把上下文管理做回了石器时代。

4.3 第三步：给模型提供上下文的代码示例

下面给一个简单的示例，展示如何用 Python 从 Fabric OneLake 读取数据，做一些基础切分，再拼装成可用的上下文片段。这里假设你已经开通 Fabric 工作区，并且有一个湖屋里存了业务知识表。

# 用 Semantic Link 读取 Fabric 湖屋中的表 import semantic_link as sl # 连接到 Fabric 工作区中的湖屋 df = sl.read_table("Warehouse", "sales_dimension") # 只保留对 AI 回答有价值的关键字段 context_df = df[["customer_id", "customer_name", "segment", "region", "account_owner"]] # 把每一行转成“业务上下文描述”，方便模型理解 def row_to_context(row): return ( f"客户 {row['customer_name']}（ID: {row['customer_id']}）属于" f"{row['segment']} 客户，负责区域为 {row['region']}，" f"当前客户经理是 {row['account_owner']}。" ) context_lines = context_df.head(20).apply(row_to_context, axis=1).tolist() compacted_context = "\n".join(context_lines) # 拼装进 prompt prompt = f""" 请基于以下客户信息回答业务问题： {compacted_context} 问题：华东区的大客户分布情况如何？ """

这段代码的核心不在读取本身，而在于把数据转换成"模型好消化的上下文语言"。真实项目中，你还需要对长文本做分块（chunking）、向量化、建立召回索引，这个环节用 Azure AI Search 或 Fabric 集成的向量能力都能做。有一点要提醒：别把所有数据都无脑塞进 prompt，"上下文不是越多越好"这条原则，我在第 5 节会专门讲。

4.4 第四步：用 Purview 管住上下文边界

上下文系统上线后最容易被忽视的就是权限边界。为什么这么说？因为开发阶段大家用的是测试数据，怎么接都行；一旦接上生产数据，AI 上下文里包含的客户信息、财务数据、人事信息全部变得敏感，必须搞明白"谁能把什么数据喂给哪个模型"。

Purview Hub 在 Fabric 里承担的就是这个职责。实际配置上，至少要做三件事：

• 对敏感数据列打标签（如客户手机号、身份证号、合同金额），并设置访问策略，禁止它们进入面向通用模型的上下文。
• 给不同 AI 应用分配不同的数据范围。比如销售助手只能读销售模型，财务助手只能读财务仓库，不能一个应用通吃所有湖屋。
• 开启审计日志，记录每一次 AI 调用实际使用了哪些数据表。这个日志不仅是合规需要，也是排查"AI 回答为什么失真"的第一手线索。

我在权限上吃过亏：曾经为了开发方便，给了 Agent 一个比较高权限的服务账号，结果它在执行任务时把一张包含几万行合同明细的大表全量读进了上下文，不仅把 token 打爆，还把敏感数据送到模型厂商那边。之后我用 Purview 把数据列级别的策略收紧了，才彻底治好这个问题。

4.5 小团队的最小可行路径

如果你的团队不大，暂时用不上完整 Fabric，也不要觉得跟自己没关系。最小可行路径是可以逐步靠近的：

• 先统一数据格式与命名规范，每张核心表都带业务描述；
• 用一套语义层（哪怕是维度表和指标词典的 Excel）把公司关键指标定义固定下来；
• 在 AI 应用侧做一层"上下文服务"，集中管理"哪些数据可以进 prompt、以什么格式进、多久更新一次"；
• 等数据量和复杂度上来之后，再平滑迁移到 Fabric 这类统一平台。

思路比工具重要。Fabric 真正提供的不是某一个单点功能，而是那套"上下文管理"的框架感。

5. 上下文管理的边界：来自真实报错的教训

5.1 不是所有上下文都值得塞进 token

写到这里，我想回到开头那个报错。很多人的第一反应是"模型上下文窗口不够大，所以要换更大窗口的模型"。但这个思路治标不治本。你把窗口从 128K 换成 1M，只是把"塞得下"这件事往后推了，并没有解决"该塞什么"的问题。

我在实践中养成的习惯是：每次准备给模型提供上下文之前，先问三个问题。这段信息跟当前任务直接相关吗？这段信息是最新的吗？这段信息能通过更短的表达传递同样价值吗？大多数情况下，你会发现真正必须要进 prompt 的内容只有你想象中一半左右。

举个例子，某天要 AI 分析本月退货率异常。你不需要把全年的订单明细都塞进去，只需要给它：当月退货率的聚合值、异常品类的明细、去年同期作为对比基线、以及相关业务备注。这几样合计不超过几千 token，效果反而比塞几十万行明细好得多。

5.2 auto-compaction 为什么会救不回来

我遇到过很多次context is too large and auto-compaction could not recover this，这个报错的字面意思是：上下文体积已经超过模型窗口，工具尝试自动压缩，但压缩也无法把体积降到限制以内。

经过反复测试，我总结出这个报错最常见的三种成因：

第一种是上下文里存在"不可压缩的硬内容"。比如一段完整代码文件、一份必须逐字保留的合同文本、一长串日志。摘要算法很难无损压缩它们，为了保真只能保留原样，体积始终下不去。

第二种是压缩过程本身也消耗上下文。自动摘要需要把历史对话读一遍再生成摘要，这个步骤也要占用窗口空间。如果原始上下文已经逼近上限，摘要引擎连"读"的空间都不够，就会直接放弃。

第三种是触发太晚。很多工具的自动压缩是在即将超限时才触发，而那时候上下文里已经堆了大量无效的中间过程，摘要出来之后，关键信息反而被淹没了。

知道了成因，应对办法就很简单：不要依赖自动压缩，要在设计阶段控制上下文质量。具体做法包括：把长任务拆成多段短任务，每段完成后把结论沉淀下来再清空中间过程；对必保原文的大文件提前做分块提取，只保留与任务目标相关的部分；设置人工触发的摘要节点，在上下文还处于可控范围时就主动压缩。

5.3 企业里的上下文分级策略

顺着这个思路，我给自己搭建了一套上下文分级策略，现在很受用。大致框架如下：

这套分级的核心思想是双重的：一方面，能不放原文就不放原文，尽量用摘要、聚合值、检索结果替代原始数据；另一方面，敏感内容和通用分析隔离，必须在权限和手段上都做隔离。

5.4 我现在坚持的几个习惯

最后分享几个我在项目里坚持了很久的习惯，你可以直接抄作业。

第一，给所有 AI 应用接入上下文之前，先建一张"上下文地图"。标明每个应用场景需要哪些数据、数据在哪、更新时间、负责人。没有这张地图，后面所有优化都是打地鼠。

第二，强制规定 prompt 里必须包含引用来源。每次 AI 回答基于哪些数据表或文档，都要能追溯到。这既是为了排查问题，也是为了让业务方信任 AI 的输出。

第三，把上下文管理当作性能问题来优化。每次调用前先计算预期 token 数，超过阈值就必须精简。把这个动作写进代码审查规范，而不是只靠个人自觉。

第四，优先做语义层，而不是优先堆功能。很多团队把 Fabric 用得像个豪华版 ETL 工具，忽略了语义层这个最值钱的部分。一次投入建好口径，后面所有 AI 应用都受益。

最后说点实在的

这场"上下文争夺战"表面上看是微软和各大 AI 厂商在抢技术制高点，但落到我们这些干活的人身上，其实是一场关于数据组织方式的认知升级。模型能力会继续进步，窗口会继续变大，但无论技术怎么演进，AI 应用都要回答一个不变的问题：它凭什么相信你给它的数据是对的、是有时效的、是经过授权的。

我自己最大的体会是：不要等模型来适应你的上下文，而是主动把上下文系统做成工程。微软把 Fabric 推上 AI 基石的位置，恰好给了我们一套可以沿着走的路线——用 OneLake 收口数据、用语义模型统一口径、用 Purview 守住边界、用 Real-Time Intelligence 提供实时感。哪怕你现在还在观望，至少可以先做一件事：盘点一下公司里哪些数据属于"上下文级别"的资产，然后开始给它建目录、定口径、设权限。

这个动作不需要花一分钱买新工具，但它会决定未来你的 AI 应用到底是聪明的助手，还是只会说漂亮话的聊天机器人。