今天是三月最后一天。我看着这个月的行业回顾，觉得有些事情已经在发生了——不是"即将"，是"正在"。

3 月 18 日那天，如果你同时刷着 FabCon 的直播、Snowflake 的新闻稿和 Databricks 的博客，你会撞见一个不太寻常的画面：三家公司在同一天分别宣布了自己的 AI Agent 战略。三条路线，方向完全不同。

一周后，#Oracle 从另一个方向又加了一个变量。

这不是撞车。这是数据平台行业十年来最重要的路线分歧，正式摆上了台面。

---

同一天，三个不同的答案

三家回答的是同一个问题：Agent 时代，数据平台到底该往哪走？ 但给出的答案截然不同。

微软选择了"治理控制平面"路线。 FabCon 2026 上，Fabric 发布了有史以来最大规模的更新。Database Hub 把 Azure SQL、Cosmos DB、PostgreSQL、MySQL、SQL Server 收拢到统一管理视图。但真正值得注意的是 Fabric IQ——它通过 MCP（Model Context Protocol）服务器，把数据语义层开放给 #AIAgent。微软的逻辑很清晰：Agent 不应该直接读物理表，而应该通过一个带有业务语义和权限控制的标准协议层来消费数据。语义层成了 Agent 的入口。

Snowflake 选择了"业务生产力"路线。 Project SnowWork 的定位很明确——把 AI Agent 部署到业务用户的桌面上，让它直接执行多步骤工作流，而不是只回答一个查询。CEO Sridhar Ramaswamy 说了一句值得记住的话：企业当前的核心瓶颈不是算力，也不是数据量，而是"分析师积压"——业务部门的数据需求远超数据团队的交付能力。SnowWork 要跳过这个排队环节。#Snowflake 不再满足于做分析师的工具，它想直接面向业务用户。

Databricks 选择了"平台外扩"路线。 同一周 Real-Time Mode GA（流处理毫秒级延迟，声称比 Flink 快 92%）、AI Runtime 公测（Serverless GPU 训练即开即用）。几天后又发布了 Lakewatch——一款基于湖仓架构的开源 Agentic SIEM，正式进入安全市场。Databricks 的逻辑不是在平台上加 Agent 功能，而是让 Agent 成为平台向外扩张的触手：训练、流处理、安全分析，都纳入同一个湖仓。

一周后 Oracle 给出了第四条路线。 在 AI World Tour 上，Oracle 发布了 Unified Memory Core、Deep Data Security 和 Private Agent Factory，核心主张是：数据库，而非 LLM，应当成为企业 Agent 的控制点。 Agent 的认证、权限、执行，都应该锚定在数据库内核里，而不是外挂一层应用。微软、Snowflake、#Databricks 都在从数据湖/湖仓向外扩展；Oracle 在从数据库向内收敛。方向相反，但交汇点是同一个问题：谁来做 Agent 的可信运行时？

---

这意味着什么

把视角拉远一点看，四家公司争夺的是同一件东西：Agent 时代，谁是数据的操作系统。

过去十年，#数据平台 的竞争维度是存算分离、湖仓一体、查询性能、成本效率。这些指标当然还重要，但它们正在从"决定胜负的变量"降级为"入场的门槛"。新的决定性变量是：你的平台能不能让 AI Agent 安全、高效、可控地消费企业数据。

这不只是我的判断。Gartner 在 3 月的 D&A Summit 上给了一组值得认真对待的数据：60% 仅依赖 MCP 的 Agentic 分析项目将因缺乏一致语义基础而失败；到 2030 年，通用语义层将被视为与数据平台和网络安全同等重要的关键基础设施。 语义层——这个过去被很多团队当作"有了更好"的东西，正在成为 Agent 能否落地的硬前提。

对企业数据团队来说，一个不太舒服但需要面对的现实是：你选的数据平台，越来越等于你选的 AI 路线。 你的湖仓在 Databricks 上，Agent 生态大概率围绕 Unity Catalog + Genie + Mosaic 展开；在 Fabric 上，Fabric IQ + MCP 就是你的 Agent 接入层；在 Snowflake 上，Cortex + SnowWork 就是你的路径。这些选择不是不可逆的，但切换成本在变高——不只是数据迁移的成本，而是整个 AI 工具链和治理体系的耦合成本。

IBM 在同一周用 110 亿美元买下 Confluent，则从基础设施层面佐证了这个趋势：实时数据流不再是可选的中间件，而是 Agent 基础设施的核心组件。Forrester 的分析师说得很直接——IBM 买的不是 Kafka 管道，而是 AI Agent 的实时数据运行时。当 Agent 需要基于持续更新的数据做决策而不是昨晚的批处理快照，实时流就从锦上添花变成了底层依赖。

---

你应该怎么看

不急着站队。这些战略发布里，很多关键能力还在 Preview 甚至 Research Preview 阶段。Fabric IQ 的 MCP 服务器是预览版，SnowWork 是研究预览版，Lakewatch 刚进入安全市场能走多远还需要验证。路线分歧已经清晰，但胜负远没有分出。

但"不急着站队"不等于"什么都不做"。可以开始评估的是：你当前的数据平台，离 Agent-ready 还有多远？

几个可以自检的维度：

• 可调用性——你的数据资产能否通过标准协议被外部 Agent 发现和调用，还是只能通过内部 BI 工具访问？

• 语义层完备度——Agent 拿到的是有业务含义的语义模型，还是一堆物理表名？

• 权限与链路控制——当 Agent 代替人执行查询时，权限模型是在应用层拦截还是在数据层强制执行？

• 状态追踪——Agent 执行的多步操作，能否回溯每一步的数据依据和决策路径？

• 结果验证——Agent 给出的答案，有没有机制让人类确认或纠正？

这套自检框架来自我今年 1 月写的《AI Agent 如何重塑企业数据平台》——从平台工程视角拆解了 Agent 介入数据平台的路径，包括六层架构分析、两类 Agent 划分和五项必备能力。上面的清单是那篇的浓缩版，如果想看完整展开，可以找来对照。

---

最后

这场路线之争刚开局。三月定义了问题，答案要到下半年才会逐渐清晰——Databricks 的 Data+AI Summit 在 6 月，IBM-Confluent 的整合路线图预计 Q2 发布，阿里云和百度的算力涨价 4 月 18 日生效后企业 TCO 的实际冲击才会浮现。

确定的是方向，不确定的是节奏。我会在「边界层笔记」持续跟踪。

---

科里（Coralyx），发表于「边界层笔记」2026.03