智能体上岗前，先读完你家的数据

做数据库的人都知道一个不成文的共识：备份不算本事，恢复得快才算。最近两件事把这个老话题翻了出来——Databricks 的 Lakebase Postgres 推出了基于分支的恢复能力，Microsoft 则把 Microsoft Fabric 明确定位为『企业智能体学习公司如何运转的地方』。一个管的是『数据坏了怎么快速找回来』，一个管的是『智能体怎么快速看懂你的生意』。表面上是两条产品线，底层其实是同一个判断：数据平台的下一个服务对象，正在从人变成智能体。

🔧 恢复慢，是托管OLTP的老毛病

任何一个带过生产库的工程师，都经历过那种凌晨三点被叫醒的场景：线上数据被误删，或者一次错误的批量更新打穿了几张核心表，唯一的办法是做一次时间点恢复（PITR）。然后就是漫长的等待。

Lakebase Postgres 团队在发布这个功能时的表述很直白：在托管式 OLTP 里，恢复一直都是出了名的慢，而且规模越大越慢。这句话背后是所有 DBA 都懂的机制问题——传统恢复要做的是把归档日志一段一段重放，从备份点一路追到你想要的时间点。数据量是百GB还是TB级，日志重放的时长完全是两个世界。恢复窗口从几十分钟拖到十几小时并不罕见，而对业务来说，这期间核心交易能力是残缺的。

分支式恢复的思路是换一条路：不再『重放历史』，而是『挂载快照』。借助数据库分支（通常基于写时复制机制），把某个时间点的数据状态直接以分支指针的方式暴露出来，秒级就能得到一个可查询的完整副本，确认无误后再切流量。

这个动作的产业含义比功能本身大：恢复能力第一次从『运维兜底项』变成了『平台竞争力项』。 当恢复速度与数据量基本解耦，服务商敢承诺的 RTO 就不再是含糊的『尽快』，而是一个可以写进 SLA 的硬指标。做托管理的产品，拼到最后拼的就是这种不出事时没人看见、出事时决定生死的能力。

🤖 Fabric 想当智能体的『入职教材』

再看 Microsoft 这边。Microsoft Fabric 作为微软整合的数据平台，新定位说得很明确：它是企业智能体去学习『一家公司如何运转』的地方。

这句话值得咀嚼。过去数据平台的客户是人——分析师拖拽报表、数据工程师写管道、业务方看驾驶舱。平台交付的价值是『人做决策的依据』。而现在微软的叙事是：当 Copilot 生态里的智能体要替人执行业务动作——处理一张订单、回复一个客户、调整一次排产——它必须先理解这家公司的数据语义：什么叫『有效线索』，什么叫『大客户』，财务口径和运营口径差在哪。

据多位接触过微软数据侧路线图的人士的说法，智能体上下文正在被当成 Fabric 的一等公民能力来规划，而不只是报表工具上加个聊天框。私下里业内流传的说法更直白：『报表是给人看的，上下文是给智能体用的，后者才是真正的高频调用。』

逻辑推演下去，这会改变数据平台的交付形态。报表可以一周更新一次，智能体的上下文却要求低延迟、强一致、带血缘和权限边界。数据平台需要回答的新问题是：我的语义层能否被机器消费？我的血缘能否支撑智能体回答『这个数字为什么是这样』？我的权限体系能否做到智能体只读到它该读的那一格？

⚔️ 两条路线，同一张考卷

把两个动作放在一起看，会发现 Databricks 和 Microsoft 其实在答同一张考卷：当智能体成为数据平台的新用户，平台必须供给两种东西——可信的数据副本，和可理解的业务语义。

Lakebase Postgres 的分支恢复解决前者：智能体要跑实验、要回滚、要验证一个自动化决策，前提是能快速拿到一个和生产一致又不影响生产的副本。Fabric 解决后者：把分散在 ERP、CRM、数仓里的口径和关系，整理成智能体能读懂的上下文。一个是物理层的可信，一个是语义层的可信。

这个闭环一旦跑通，数据平台的商业逻辑就变了。过去平台的价值按『多少人用它看报表』衡量，未来要按『多少智能体调用它拿上下文』衡量——后者是机器级的调用频次，量级完全不同。这也是为什么两家几乎同时在这个方向上压注。一位做企业数据架构的朋友私下评价：『以前我们争论湖仓还是数仓，现在发现真正的考题是，你的平台能不能被一个不是人的东西安全地用起来。』

💰 工程师真正该算的成本账

落地视角看，分支式恢复的价值远不止灾备。写时复制机制意味着分支几乎不占额外存储——只有新写入的部分才产生增量成本。于是同一套分支机制可以被反复复用：恢复只是它最戏剧化的场景。

对工程团队来说，更现实的收益在开发环节。过去搭一个预发布环境，要么忍受一份滞后且昂贵的全量拷贝，要么用脱敏后的假数据测不出真问题。有了低成本的分支能力，预发布环境可以直接从生产分支出来，用真实数据形态做验证，测完即弃。

据几位在金融和电商行业做数据平台的人士反馈，客户问得最多的甚至不是『恢复能多快』，而是『分支能不能拿来搭环境、做灰度』。这很说明问题：企业买从来不只是一个功能，而是功能背后那套可复用的机制。

📌 给实践者的三条判断

第一，别急着为智能体重构平台。先做实的应该是两件朴素的事：一是把副本供给能力建起来——无论用 Lakebase Postgres 的分支，还是自己搭的克隆机制，目标是让『一份可信的生产数据副本』的获取成本降到接近于零；二是把语义层整理成机器可读的形态，口径、血缘、权限边界，这些是智能体不跑偏的地基。

第二，灾备指标要重新谈。当恢复速度与数据量解耦成为头部托管产品的标配，RTO 的行业水位会被快速拉高。还在用小时级恢复承诺的服务商，会在下一轮比价中很被动。

第三，警惕叙事泡沫。『智能体上下文』今天更多是方向而非成熟产品形态，企业该做的是在自己的数据平台上预留机器消费的接口——API 化的语义层、细粒度的权限、可审计的调用日志——而不是推翻重来。

小结

恢复快不快、语义清不清，过去是数据平台的『内功』，如今正在变成智能体时代的『入场券』。Databricks 用分支机制回答了副本供给，Microsoft Fabric 用上下文定位回答了语义供给，两条路殊途同归：数据平台的价值锚点，正从服务人的报表迁移到服务智能体的可信数据。2026 年值得盯的指标只有一个——你的平台，每天被机器调用了多少次。