Agent 应用范式下，企业数据基础设施正在重写：为什么云器 Lakehouse 会成为 AI 时代的数据底座

先看一眼市场侧的信号。

企业对 AI 的投入在持续扩大，AI 正在从试验走向生产，Agent 正在加速进入企业应用，而 BI 也在被生成式 AI 和 Agent 工作流重新定义。

如果把这些公开数据放在一起看，这个判断会更直观：

Gartner 在 2023 年的预测中提到，到 2026 年，超过 80% 的企业将使用生成式 AI API、模型，或在生产环境中部署 GenAI 赋能的应用；
Gartner 在 2025 年进一步预测，到 2026 年底，40% 的企业应用将集成 task-specific AI agents，而 2025 年这一比例还不到 5%；
McKinsey 在《The State of AI in 2025》中提到，接近 90% 的受访组织已经在常规使用 AI，88% 的组织已经在至少一个业务职能中常规使用 AI；
MarketsandMarkets 预计，AI Agents 市场将从 2025 年的 78.4 亿美元 增长到 2030 年的 526.2 亿美元 ，2025---2030 年的 CAGR 为 46.3%；
Technavio 则明确指出，生成式 AI 与 agentic workflows 的集成，正在成为推动 BI 市场继续扩张的重要因素。

这些数字未必说明所有企业都已经完成了 AI 转型，但它们至少说明了一件事：AI-Native 数据分析与 Agent 化应用，已经不是"要不要做"的问题，而是"会先从哪里落地、需要什么样的数据底座来承接"的问题。

也正是在这个背景下，再回头看企业数据基础设施，就会发现一个很现实的问题：原来那套主要服务报表和人工分析的数据平台，正在面临新的要求。

过去十年，企业数据基础设施的主线，是围绕"人如何看数据"来建设的：离线 ETL、数仓分层、BI 指标体系、报表分析、少量实时链路补充。这套体系支撑了企业经营分析，也推动了数据平台从 Hadoop、数仓到 Lakehouse 的持续演进。

但到了今天，真正推动架构变化的，不再只是 BI，也不只是大模型本身，而是 Agent 正在成为新的数据消费者与执行者。

当企业开始让 Agent 参与问数、运营分析、流程决策、客服协同、销售辅助、风险审核、知识检索甚至半自动执行时，数据基础设施面临的问题已经变了：它不再只是要把数据"存下来、算出来、展示出来"，而是要让机器在业务语义之上，持续、低延迟、低成本地理解数据、消费数据、触发动作，并在反馈中修正行为。

从这个角度看，AI 时代真正需要的 Data Infra，已经不只是传统意义上的 Data Lake，也不只是"能跑 SQL 的 Lakehouse"，而是一套向 Semantic Data System 演进的数据底座。

而这恰恰是云器 Lakehouse 值得被重新讨论的原因：它不是在旧的数据平台上简单外挂 AI，而是在 增量计算、统一 Lakehouse、Semantic Layer、AI Function 这几条关键线上，逐步搭出一个更适合 Agent 应用范式的数据基础设施方向。

一、传统企业数据基础设施的问题

传统企业数据基础设施的设计前提，默认主要有三个：

第一，数据消费者主要是人。也就是说，系统的最终出口通常是报表、看板、OLAP、导出数据，或者由分析师人工解释后再进入业务流程。

第二，数据生产以批处理为核心。多数链路仍以 T+1、小时级、批量 ETL 为主，即使有实时链路，也往往是局部补丁，而不是统一范式。

第三，数据语义主要沉淀在人员经验里，而不是系统里。同一个"收入""活跃用户""转化率"，在不同系统、不同团队里经常有不同口径，真正知道语义的人，通常是少数数据开发、分析师或业务 owner。

这套体系在"人读数据"的时代是可以工作的，但在 Agent 应用范式下会暴露出几个明显问题：

1. 数据时效与业务动作脱节

Agent 不是只做离线分析，它会在任务执行过程中持续请求上下文、调用工具、重试策略、更新状态。如果底层数据仍主要依赖批式 ETL，那么 Agent 能看到的世界天然是滞后的。结果就是：模型看起来很聪明，但做判断时用的是昨天的事实。

2. 数据链路复杂，维护成本高

很多企业 today 的数据平台依然是"批处理引擎 + 流处理引擎 + OLAP 引擎 + 搜索/缓存系统 + 语义拼装层"的组合。系统能跑，但工程复杂度极高。一旦进入 Agent 场景，这种复杂性会被进一步放大，因为 Agent 的访问模式更频繁、更碎片化，也更依赖端到端一致性。

3. 业务语义缺位，AI 很难稳定消费数据

传统数据平台的问题不只是"数据分散"，更关键的是"语义不完整"。表名、字段名、枚举值、业务口径、实体关系、主外键约束、常用过滤条件、指标定义，很多时候并没有被系统化表达出来。对人类专家来说，这些知识可以靠经验补足；但对 Agent 来说，如果缺乏统一语义层，它就只能在模糊上下文中猜测业务含义，最终让问数、分析、行动建议的可靠性变得不可控。

4. 数据平台是分析系统，不是执行系统的底座

传统架构更多面向"看结果"，而不是"驱动动作"。但 Agent 的价值，不在于生成一段自然语言答案，而在于围绕真实业务对象做出连续动作：识别异常、判断优先级、获取上下文、调用接口、写回结果、进入下一步流程。要支撑这种模式，底座必须同时具备数据、语义、状态更新和反馈闭环能力。

二、传统 Lakehouse 在 Agent 时代仍然存在的问题

Lakehouse 相比传统数仓和数据湖，已经是明显进步：它统一了存储与分析边界，降低了多套数据系统割裂的问题，也为开放格式、统一元数据、弹性计算创造了更好的条件。

但如果把时间点放到 Agent 时代，仅仅拥有一个传统意义上的 Lakehouse，仍然不够。

1. 很多 Lakehouse 仍停留在"统一存储"，没有真正统一计算范式

不少 Lakehouse 的价值更多体现在存储统一、批流共存、开放格式兼容上，但真正进入生产后，企业经常还是要同时维护离线链路、实时链路、服务化链路和附加索引系统。换句话说，数据放在一起了，不代表处理范式真的统一了。

而对 Agent 而言，最麻烦的恰恰不是数据存在哪里，而是：

新变化能不能快速进入可消费状态；
同一套 SQL 和逻辑能不能同时覆盖离线与近实时；
面对延迟数据、更新数据、回溯修正时，系统能不能低成本维持一致性。

如果这些问题解决不了，Lakehouse 仍然只是更现代的"分析底座"，还不是 Agent 可直接依赖的 Data Infra。

2. 传统 Lakehouse 的语义层往往不足以支撑 Agent

在很多实现中，语义能力仍停留在 BI 指标定义、少量指标口径管理或轻量元数据目录层面。它能帮助报表统一，但未必足以让 Agent 理解复杂业务对象之间的关系。

Agent 需要的不是一个"字段中文名映射表"，而是一整套可被机器消费的语义结构，包括：

实体及关系；
维度、指标与过滤条件；
业务同义词与命名差异；
指标口径与聚合逻辑；
面向自然语言调用的可解释接口。

没有这一层，Agent 做的不是"业务理解"，而更像"SQL 猜谜"。

3. 传统 Lakehouse 更擅长承载分析，不一定擅长承载持续反馈闭环

Agent 系统并不是一次性查询，它是多轮的：接收事件、读取上下文、做判断、触发动作、获得反馈、更新状态，再进入下一轮。此时，数据底座需要的不只是吞吐能力，而是对"变化本身"的高效处理能力。

所以在 Agent 时代，Lakehouse 是否先进，不能只看它能否支持开放表格式、是否支持湖仓一体，更要看它是否具备：

面向变化数据的原生处理能力；
面向语义调用的建模能力；
面向 AI 的函数和接口能力；
面向业务闭环的低成本持续刷新能力。

三、未来会从 Data Lake 演进到 Semantic Data System

如果说 Data Lake 解决的是"海量原始数据如何低成本存储"，Lakehouse 解决的是"数据湖与分析系统如何统一"，那么再往前一步，AI 时代要解决的问题是：

如何让企业数据不仅能被存储、处理和分析，还能被 Agent 稳定理解、调用、验证与驱动行动。

这意味着下一代数据基础设施，正在从 Data Lake / Lakehouse 演进到一种更完整的形态------Semantic Data System。

Semantic Data System 是一种面向 AI 与 Agent 时代的数据基础设施形态。

它不仅负责存储和计算数据，还负责持续维护业务语义、状态变化与可执行上下文，使机器能够在统一治理边界内稳定理解、调用并作用于企业业务系统。

这个系统至少包含四层能力：

1. 统一的数据承载层

底层仍然需要 Lakehouse 作为统一存储与计算底座，承接结构化、半结构化乃至部分非结构化数据，并通过开放格式和统一元数据，减少系统割裂。

2. 面向变化的计算层

系统不再默认"全量重算"，而是默认"围绕变化做计算"。新增、更新、删除、补数、迟到数据、回放修正，都应该成为一等公民。因为 Agent 依赖的是持续更新的业务现实，而不是周期性批处理快照。

3. 面向业务的语义层

这层把底层物理表、字段、连接关系、指标定义、过滤逻辑、业务别名，抽象成机器和业务都能理解的语义对象。它不是 BI 的附属品，而是机器理解业务世界的关键桥梁。

4. 面向 AI 的函数与调用层

当 AI Function、自然语言接口、MCP/API 化能力进入数据平台后，数据系统就不再只是被动响应 SQL 请求，而是开始具备"可被 Agent 编排与调用"的特征。Agent 可以在受控边界内，直接让数据平台完成抽取、过滤、生成、理解、查询与反馈。

从这个意义上说，未来真正有竞争力的数据底座，不是"能不能接大模型"，而是 能不能把数据、语义、变化处理、AI 调用放进同一套基础设施里。

四、为什么 Semantic Layer 会成为核心

过去很多企业会把语义层理解为一个"更方便做 BI 的东西"。但在 Agent 时代，语义层的重要性被显著抬高了，因为 Agent 使用数据的方式，与人类分析师不同。

分析师可以看到一张表之后自己理解上下文，但 Agent 不会天然知道：

revenue 是含税还是不含税；
customer_id 对应的是个人、企业还是账号；
"活跃"是日活、周活还是月活；
"订单"是支付单、履约单还是子订单；
哪些表应该 join，应该按什么粒度聚合；
某个口径在不同区域、不同业务线是否适用。

这正是语义层成为核心的原因。它不是给数据"起个中文名"这么简单，而是在做三件更关键的事情：

1. 把物理结构翻译成业务语言

根据 IBM 对语义层的定义，语义层的核心作用，是把复杂的数据存储系统转换为业务上有意义的术语与对象，让使用者不必直接理解底层表结构、ETL 管道与查询细节。这个定义在 Agent 时代不仅没有过时，反而更重要，因为现在的"使用者"不仅是人，也包括机器。

2. 把分散口径收敛成统一事实

云器 Lakehouse Semantic View 可以以声明式方式集中管理表关系、维度和指标，帮助统一"数据口径"，并让用户无需编写复杂 JOIN 即可跨表查询。对 Agent 而言，这意味着业务理解不再只是 prompt 里的自然语言提示，而是被放进了系统级定义中。

3. 把自然语言调用连接到可执行数据系统

更关键的一点在于，语义层是连接自然语言和可执行数据系统的桥梁。云器文档中提到，Semantic View 可以通过维度、指标、同义词和注释帮助 AI Agent 理解业务术语，并结合 Lakehouse MCP Server 进行自然语言或结构化调用。这意味着语义层不再只是"给 BI 看"，而是开始成为 Agent 与数据系统对接的核心接口层。

所以，未来企业真正要建设的，不会只是一个"更全的数据平台"，而是一个"语义上可理解、计算上可持续、接口上可调用"的数据系统。

五、未来数据基础设施的核心变化：从 ETL 转向 Event + Incremental

如果要用一句话概括数据基础设施在 AI 时代最重要的转向，我会认为是：

从以 ETL 为中心的批式加工体系，转向以 Event + Incremental 为中心的持续响应体系。

这里的变化，不只是技术选型变化，而是系统抽象层级的变化。

传统 ETL 的默认思路是：

周期性抽数；
周期性加工；
周期性产出结果；
由人或系统在下一个环节消费。

而在 Agent 场景下，更自然的链路是：

业务事件持续发生；
变化被实时接入数据系统；
增量计算持续刷新中间结果与语义对象；
Agent 基于最新状态做判断与执行；
执行结果再次成为新事件，进入下一轮闭环。

这时，系统关注的重点不再是"每天重算一遍"，而是：

哪些数据变了；
这些变化影响了哪些结果；
哪些语义对象需要刷新；
哪些 Agent 任务需要重新触发；
如何以尽量低的成本维持全局最新状态。

这正是 Event + Incremental 的价值所在。它让数据系统开始更像"持续运行的业务状态机"，而不只是 ETL 管道集合。

六、为什么通用增量计算会变得更关键

在这个转向过程中，通用增量计算的重要性会被迅速放大。

原因很简单：Agent 场景的核心矛盾，不只是实时性，而是 实时性、复杂逻辑、成本、正确性 必须同时成立。

如果只有实时，但实现方式依赖大量定制流作业、复杂 watermark 逻辑和高昂状态维护成本，企业很难大规模推广；

如果只有离线吞吐，但结果无法跟上业务变化，Agent 又拿不到足够新的上下文；

如果每次变化都要求全量重算，那么随着数据量和链路复杂度增长，成本一定会快速失控。

云器对通用增量计算（GIC）的描述有几个点值得注意：

它试图统一批处理、流处理和交互式分析；
当上游数据变化时，只计算变化部分，再与历史结果合并；
动态表（Dynamic Table）可以基于复杂 SQL 定义，并自动识别依赖关系与刷新逻辑；
对迟到数据，系统可以把它识别为新的增量批次，并自动刷新结果，而不是依赖传统流处理中的复杂等待机制；
在从离线向近实时改造时，可以尽量保留原有 SQL 逻辑，通过调整表定义把批作业转为动态增量作业。

这些能力为什么关键？因为它们直接对应企业最现实的几个诉求：

1. 让"从 T+1 到近实时"不必推倒重来

很多企业不是没有数据系统，而是没有办法用低风险、低成本把现有数仓链路升级到 AI 可用的状态。若增量计算可以尽量复用既有 SQL 和数据模型，那么升级路径就会更平滑。

2. 让复杂业务逻辑也能进入持续刷新模式

Agent 依赖的往往不是单表明细，而是经过 join、union、聚合、过滤、口径处理后的业务对象。如果增量计算只能处理简单 append-only 场景，那么对企业核心业务帮助有限。通用增量计算真正重要的地方，在于它能把更复杂的业务逻辑纳入增量体系。

3. 让成本与时效之间不再是硬冲突

这也是云器反复强调"提高效率、降低成本"的原因。对企业来说，真正有价值的不是追求最极致的毫秒级，而是在业务可接受的新鲜度范围内，以更低成本维持持续可用。Agent 时代不是所有场景都要极致实时，但大量场景都需要"足够新、足够稳、足够便宜"的持续刷新。

从这个角度看，通用增量计算不是 Lakehouse 的一个性能增强项，而是 AI 时代 Data Infra 的关键执行语义。

七、AI Function：数据平台不再只是存算底座，而是 Agent 的能力底座

如果说增量计算解决的是"变化如何被持续处理"，Semantic Layer 解决的是"业务如何被机器理解"，那么 AI Function 解决的，就是"数据平台如何直接成为 AI 执行环境的一部分"。

云器Lakehouse 其 AI 原生数据平台强调将 AI 能力内嵌至 SQL 中，而不是以外挂 API 的方式存在，并提供如 AI_COMPLETE、AI_EXTRACT、AI_FILTER 等 AI Function。

这件事的意义，不只是"在 SQL 里调一下模型"这么简单，而是意味着数据平台角色发生了变化：

1. 从数据处理平台走向数据 + AI 一体执行平台

过去，数据平台负责准备数据，AI 系统负责理解数据，两者之间往往通过额外的服务层、ETL 或中间接口拼接。AI Function 的价值在于把这层割裂缩短：某些理解、抽取、分类、过滤和生成动作，可以在数据系统内部直接发生。

2. 让非结构化数据更容易纳入统一数据底座

企业真正有价值的数据，并不只存在于结构化表里，还在文档、工单、客服记录、会议纪要、图片、音视频等"暗数据"里。如果 AI Function 能与 Lakehouse、向量/索引和语义层结合，数据底座的边界就会从结构化分析扩展到 AI 可消费的统一知识环境。

3. 让 Agent 更容易在受控治理边界内工作

企业不是缺模型，而是缺一个既能让模型工作、又能被治理约束的运行环境。AI Function 如果运行在同一治理框架下，就更容易与权限、审计、口径控制、数据安全结合，而不是让 AI 使用过程游离在平台之外。

因此，AI Function 的意义不在于替代应用层 Agent，而在于为 Agent 提供一个更接近数据、更受治理约束、也更容易形成闭环的执行底座。

七、为什么说云器 Lakehouse 更像未来 AI 时代的 Data Infra

把上面几条线放在一起，就能更清楚地理解云器的差异化位置。

云器值得强调的，不只是"它也是一个 Lakehouse"，而是它在几个关键方向上，指向了更适合 Agent 时代的数据底座形态：

1. 它不是只强调统一存储，而是强调统一增量计算语义

对 Agent 来说，真正重要的不是数据落在湖上还是仓里，而是变化能否低成本进入可消费状态。云器以动态表、CDC、增量刷新、迟到数据处理等能力为核心，实际上是在强化数据系统对"变化"的原生响应能力。

2. 它不是只做分析平台，而是在强化语义可消费性

Semantic View 把逻辑表、维度、指标、过滤器、同义词、描述等能力纳入系统级对象，这让数据平台不只是提供数据，更开始提供可被 Agent 理解和调用的业务语义结构。

3. 它不是简单外挂 AI，而是在把 AI 纳入数据平台内部能力

AI Function 与语义层、Lakehouse、接口化能力结合后，数据系统开始具备"既能处理数据，又能理解数据，还能服务 Agent 调用"的基础特征。这一点，对未来 Data Agent、智能问数、业务协同 Agent、运营自动化等场景都会越来越重要。

4. 它提供的是一条更现实的企业升级路径

对于大多数企业来说，最重要的问题不是"有没有一个全新的 AI 原生系统"，而是"现有数据基础设施如何低风险升级到 AI 可用"。如果平台能够尽量复用现有 SQL 逻辑、缩短从离线到近实时的改造路径，并把语义与 AI 能力逐层叠加上去，那么它就更接近企业真正愿意采用的 Data Infra。

结语：未来的数据底座，不只是存储事实，更要组织语义、处理变化、服务 Agent

企业数据基础设施的下一阶段，不会止步于"把数据统一起来"，而是要进一步回答三个问题：

业务变化如何持续进入系统；
业务语义如何被机器稳定理解；
AI 与 Agent 如何在治理边界内直接消费并作用于数据。

因此，未来的数据底座，不再只是 Data Lake，也不只是传统 Lakehouse，而更像一套 Semantic Data System：它既能承载原始数据，也能表达业务语义；既能支持分析，也能支持持续反馈；既是企业事实层，也是 Agent 的行动底座。

从能力布局上，云器 Lakehouse 在增量计算、Semantic View 与 AI Function 上的组合，已经不只是传统数据平台升级，而是在尝试回答一个更面向未来的问题：

当 Agent 成为企业应用的新范 式时，什么样的数据基础设施，才配得上成为 AI 时代的 Data Infra？

如果沿着这个问题继续看下去，云器的优势并不只在于"更快的数仓"或"更现代的 Lakehouse"，而在于它试图把 变化处理、业务语义与 AI 执行能力 放进同一套数据底座中。对于正在从报表驱动走向 Agent 驱动的企业而言，这很可能不是一个功能增强，而是一条架构分水岭。

如果今天我们还把企业数据基础设施理解成"给 BI 和报表服务的后台系统"，那这个理解大概率已经不够了。因为当 Agent 开始成为新的数据消费者，数据平台要处理的就不再只是把数据存下来、算出来，而是要让机器在业务语义之上更稳定地理解数据、消费数据，并在必要时参与业务动作和反馈闭环。也正因为这样，未来真正有竞争力的数据底座，可能不只是一个更大的 Data Lake，也不只是一个更现代的 Lakehouse，而是在向一种面向 Agent 的 Semantic Data System 演进。云器 Lakehouse 值得关注，恰恰是因为它在增量计算、语义层和 AI Function 这几个方向上，已经搭出了一条比较清晰的技术路线