Agent时代，数据栈被重排了一遍

过去十年，数据平台的「主要用户」是分析师和老板——他们要看报表、看大盘、看趋势。现在，这个位置正在被一种不吃不睡、按调用计费的程序接管。阿里云近期借 肖战凯 之口，把 Agent 时代的数据基础设施完整链路一次性摆上台面：从采集接入、OpenLake 全模态湖仓、Agent-Ready 数据管线，到 ApsaraLakebase 湖库同源，再到业务语义本体与知识图谱。这不是又一次产品发布会式的功能罗列，而是一次数据栈的重新排序——谁先承认「主要用户变了」，谁就先拿到下一轮架构设计的入场券。

📈 主用户换了：从分析师到 Agent

金句先行：数据平台的历史，就是「主要用户」不断改写需求的历史。

先讲一个老场景。十年前你进一家电商公司做数据仓库，典型的一天是这样的：业务方提需求，ETL 工程师写脚本，凌晨跑批，早上九点分析师打开看板，发现昨天的数据差了两行，回工单，排查，补数，下午三点给业务方一个「修正后的 GMV」。整套流程以「人」为圆心展开——人提需求、人写管道、人看报表、人发现错误。

Agent 出现后，这个圆心挪走了。一个跑在客服、运营或研发场景里的 Agent，一天内可能发起成百上千次数据请求，而且是不打招呼、不分昼夜的。它不看你精心排版的看板，它要的是：准确的数据、可理解的语义、够快的响应。 肖战凯 把这个变化压缩成了一条完整链路——采集与接入、清洗与转换、存储与治理、数据语义，四层依次递进，最终服务于 Agent 的消费。

这条链路值得认真读一遍，因为它暗含一个产业判断：Agent 时代的数据基础设施，不是给现有产品贴个「AI」标签，而是把每一层都按「程序是主用户」重新设计一遍。 存储要考虑 Agent 取数的模式，管线要考虑 Agent 构建的方式，语义要考虑 Agent 理解的边界。

「Agent 如何用数据」成为数据战略的第一命题，在公开层面已经能找到佐证：Gartner 在 2025 年发布预测，到 2027 年底，超过 40% 的 Agentic AI 项目将因成本不达预期或价值无法证明而被取消，而其中被反复点名的首要瓶颈正是数据基础设施的「Agent 就绪度」不足；Databricks 在 2025 年发布 Agent Bricks，把 Agent 的数据接入、评估与治理做成原生能力；Snowflake 也在同期把 Cortex Agents 纳入产品主线。云厂商三巨头在同一窗口期密集押注，说明这不是某一家的话术包装，而是被客户的真实负载逼出来的共识。

🌊 OpenLake：一份数据，多个引擎平权

金句：数据工程的浪费，一大半花在「同一份数据的反复搬运」上。

做过湖仓的人都知道那种痛：数据湖里一份原始数据，数仓里一份加工数据，实时链路里又一份，为了不同引擎的计算特性，同一张表复制三四份，存储成本翻倍还在其次，真正的成本是一致性的对账——哪个副本是权威版本？口径漂移了怎么办？半夜数据对不上，第一反应永远是「是不是又搬出分叉了」。

这个痛有多大，可以从数据盘子上量一量：IDC 预计全球数据总量将从 2025 年的约 250ZB 增长到 2028 年的 394ZB，其中大量新增数据是日志、文本、图像、视频等非结构化形态——按传统「一种引擎一套存储」的玩法，复制份数和口径对账成本只会指数级放大。

OpenLake 给出的答案是「全模态湖仓」+「一份数据多引擎平权计算」。拆开看两个关键词：

全模态，意味着结构化表、半模态日志、非结构化的文本图像视频，都能进同一个湖，不用为每种数据形态单建一套存储。

多引擎平权，意味着不管是批处理引擎、流式引擎还是面向 AI 的计算引擎，访问这份数据的权限和效率是同等的，不会因为「数据原本是为某个引擎准备的」而产生三六九等。

这张链路图里最值得玩味的是「平权」二字。存算分离解决的是「存储和计算解耦」，而引擎平权解决的是「计算与计算之间的门户之见」。前者是上一个大版本，后者是下一个。当 Agent 成为数据的主要调用方时，它不会像人一样「认引擎」——它只关心哪个引擎对这个任务最优。基础设施必须默认这种多引擎并发访问的常态。

把 OpenLake 放进行业坐标系，能更清楚地看出位置：Databricks 和 Snowflake 在 2024 年先后拥抱 Apache Iceberg 开放表格式——前者以约 10 亿美元收购 Iceberg 背后商业公司 Tabular，后者宣布原生托管 Iceberg 表——两大封闭生态同时向开放格式低头，本质上是承认「一份存储、多引擎读取」是客户用脚投票的方向。OpenLake 的差异点在于走得更进一步：不仅表格式开放，还在同一底座上让流式与 AI 计算引擎获得与批处理平权的访问效率。产业逻辑很清楚：湖仓赛道的下一程，比的不再是「能不能存」，而是「一份存本能被多少种计算范式无损地用起来」。

🔧 数据管线：从「人写 ETL」到「Agent 自建」

金句：过去数据管线是工程师的作品，以后它可能是 Agent 的中间产物。

第二环节是「清洗与转换」， 肖战凯 用了一个很有野心的定语：Agent-Ready 数据管线，并且明确说方向是「从人构建到 Agent 自主构建」。

这句话的分量需要放在行业语境里掂。今天一条生产级数据管线的诞生流程是：业务方提需求、数据团队评审、工程师开发、测试、上线、监控、运维——周期以周计。而 Agent 时代的需求节奏完全不同：一个正在执行任务的 Agent，可能在几分钟内发现「我需要一张按新口径聚合的表」，它等不起两周。

所谓 Agent 自主构建，就是让管线本身变成 Agent 可以生成、可以调度、可以校验的对象——元数据、血缘、质量规则不再是给人看的文档，而是 Agent 的操作手册和护栏。

用一个旅程图直观感受这种变化：

注意图中第三个环节——「自建或复用管线」评分只有三分。这正是当下的真实水位：愿景是 Agent 全自主，现实里仍需要人在质量与合规上兜底。第三方研究同样印证了这个水位：Gartner 那条「40% 的 Agentic AI 项目将在 2027 年前被取消」的预测，列出的头号风险就是治理与成本失控。Agent-Ready 管线的关键不是「能不能生成代码」，而是生成之后的校验、回滚与权限体系是否配套——这也正是这条链路里「存储与治理」层存在的意义。

🔋 ApsaraLakebase：放得下、放得起、醒得快

金句：衡量新一代湖库的标准，就藏在三个动词里。

第三环节是 ApsaraLakebase，核心提法是「湖库同源」，官方给了三个非常口语化却极其精准的标准：数据放得下、放得起、醒得快。

这三个词对应三个长期无解的矛盾：

放得下——数据量与数据模态的爆炸。训练语料、行为日志、多模态资产，体量早已超出传统数据库的舒适区，但 Agent 又要求它们可查询。

放得起——湖便宜但慢，库快但贵，企业长期被迫在成本和性能之间二选一，或者干脆两套都建，付两份钱。以公有云公开定价作参照，对象存储的标准单价与高性能数据库 SSD 存储的单价差距通常在一个数量级以上（例如对象存储约 0.02 美元/GB/月，而多数云数据库的单节点存储报价在 0.1–0.2 美元/GB/月区间），这正是「两套都建、付两份钱」的成本根源。

醒得快——冷数据沉在湖里很便宜，可一旦 Agent 需要唤醒它做即时分析，「从冷到热」的唤醒延迟往往是业务不能承受的。

把市面上几类方案放在成本-时效坐标系里看，湖库同源的位置一目了然：

「湖库同源」的本质，是把「湖」和「库」从两套系统变成同一份底座的两种访问形态：数据只存一份，既享受湖的成本，又享受库的时效。消灭的不仅是搬运的存储成本，更是那份最隐性的成本——两套系统之间的口径对齐。

这个方向上阿里云并非独行者，第三方对比可以看出各自的解法差异：Databricks 的 Lakehouse 路线以 Delta Lake/Iceberg 开放表格式为核心，强调开放生态；Snowflake 通过托管 Iceberg 表和内部渐进式裁剪实现湖表的分析加速，强调无需迁移；ApsaraLakebase 则把「湖」和「库」做成同一底座的两种形态，重点解决冷数据按需唤醒的时效问题。三条路线殊途同归——都在把「两份存储、两套口径」的行业默认配置往「一份存储」上压。

把这个三层诉求整理成一张金字塔，会发现它和传统存储的优先级是倒过来的：

🧠 语义层：从记忆到知识，关键在可控

金句：Agent 可以有记忆，但企业必须有知识。

链路的最后一环最容易被低估：业务语义本体 + 知识图谱。 肖战凯 的表述很克制，却点中要害——「从记忆到知识是可控的」。

先说痛点。今天的企业 Agent 各自带着各自的上下文：客服 Agent 知道「复购率」的一种算法，运营 Agent 知道另一种，财务 Agent 用的口径又不一样。大模型的记忆能力再强，也只是在各自会话里打转——记忆是局部的、易逝的、不可审计的；知识必须是全局的、沉淀的、可验证的。 把业务语义抽成本体、织成知识图谱，就是让所有 Agent 在同一套企业语义上对话，而不是让大模型的幻觉来定义「我们的客户到底是什么」。

「可控」二字尤其值得展开。生成式模型天然带不确定性，但企业数据的语义不容许概率性解释。本体与知识图谱在这里扮演的角色，是给 Agent 的理解划定边界：能查证的走图谱，需要推理的走模型，两条路径随时可回溯。语义不统一对 Agent 落地的拖累，已有公开数据可以佐证：Gartner 2024 年调研将「数据质量与治理」列为生成式 AI 落地受阻的首要原因之一；Databricks 2025 年发布 Agent Bricks 时也公开承认，企业 Agent 最大的工程难题是让模型理解各家公司私有且互相冲突的业务语义——语义层解决的正是这个最难标准化的问题。

值得注意的是，语义层在整条链路里是最不像基础设施的一层，没有算力和存储那样肉眼可见的资源曲线，但它决定了前面所有层的投资能否被 Agent 正确消费。湖建得再好，语义不通，Agent 拿到的也只是一堆无法互认的字节。

🎯 小结

把五节串起来看，阿里云这条链路的真正含义是：数据栈正在从「为人做报表」转向「为程序供知识」。 OpenLake 解决「一份存本怎么被多种计算公平使用」，Agent-Ready 管线解决「管道谁来建」， ApsaraLakebase 解决「存得多、存得省、醒得快」，语义层解决「Agent 与企业如何对齐认知」。五环相扣，缺一环链路就断。

接下来的看点有二：一是 Agent 自主管线的治理护栏何时真正生产就绪——参照 Gartner 的预测窗口，2025 到 2027 年是这层能力从演示走向生产的淘汰赛；二是语义本体的构建成本能否随工具成熟而大幅下降——Databricks、Snowflake 与阿里云几乎同时把「企业语义/知识层」做成产品化能力，竞争本身就会压低门槛。Agent 时代的竞争，不在模型发布会，而在数据底座的每一层细节里。

参考资料

1. Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027（2025 年 6 月）

2. IDC Global DataSphere 预测：2028 年全球数据总量达 394ZB（IDC 官方博客，2024）

3. Databricks, Introducing Agent Bricks（2025 年 6 月，Databricks 官方博客）

4. Snowflake, Apache Iceberg Tables in Snowflake（2024 年，Snowflake 官方文档/公告）

5. Databricks 收购 Tabular 公告（2024 年 6 月，交易金额约 10 亿美元，据双方官方新闻稿及 TechCrunch 报道）

6. AWS/阿里云等公有云对象存储与云数据库公开定价页（2025 年查询，单价随区域与配置浮动）