飞轮科技 CEO 马如悦：Agent 时代，实时分析引擎正在成为企业数据栈的新入口

导读：随着 AI Agent 加速进入企业生产环境，数据基础设施正在迎来新一轮演进。飞轮科技 CEO 马如悦认为，当企业智能化的重心从模型训练转向推理，实时数据访问能力将成为决定 Agent 应用体验的关键因素。本文围绕这一变化，探讨 Agent 时代企业数据栈的演进方向，以及实时分析引擎的新定位。

过去一年，Agent 正从技术概念走向企业智能化落地现场。

在这一过程中，变化的不只是应用形态，更是人与软件、人与数据之间的交互方式。过去，用户需要理解不同系统的使用方式，在多个工具之间切换，并将业务目标拆解成一系列明确操作；而在 Agent 模式下，用户只需要表达目标，Agent 负责理解意图、拆解任务、选择工具、调用数据并完成执行。

这意味着，企业应用的入口正在发生变化：从“人使用软件”，走向“人提出目标，Agent 调度能力”。

当 Agent 成为新的应用范式，数据基础设施也需要随之演进。尤其是在企业生产环境中，Agent 能否稳定运行，很大程度上取决于它是否能够在推理过程中快速、准确、低成本地获取上下文数据。这也让实时分析引擎重新站到了数据架构演进的前台。

Agent 统一的是人和能力的接口

回看互联网早期，Email、FTP、Gopher、IRC、Telnet 等应用各自独立，拥有不同协议和客户端。Web 最初只是其中一种应用形态，但最终却吸收并重塑了大量应用。Webmail 替代了传统邮件客户端，网页下载弱化了 FTP 的存在，Web 化协作工具也改变了即时通信和内容分发方式。

Web 的关键价值，不只是体验更好，而是统一了“人”和“信息”的接口：一个浏览器、一个 URL，用户就可以访问大量信息和服务。

今天，Agent 与 LLM 的关系也有类似之处。

从技术形态看，LLM 应用包括直接调用、RAG、Workflow、代码执行、工具调用和 Agent 等多种模式。但这些能力并非彼此孤立。Agent 更像是一种更高层的组织方式：RAG 是 Agent 获取知识的方式，代码执行是 Agent 使用工具的能力，Workflow 是 Agent 决策路径被预定义后的特例，直接调用则是 Agent 在没有外部工具时的简单形态。

因此，Agent 真正统一的，是“人”和“能力”的接口。用户不再需要判断应该打开哪个系统、调用哪个 API、查询哪张表，而是通过自然语言提出目标，由 Agent 自主规划、选择和执行。

这也是 Agent 被认为可能重塑软件应用形态的原因。

企业智能化的重心正在从训练转向推理

理解 Agent 对数据基础设施的影响，需要先回到软件智能的演进逻辑。

第一阶段，软件的智能主要来自规则。工程师将业务逻辑写入代码，系统按照确定规则执行。这个阶段，数据基础设施的核心是关系型数据库，用于存储业务状态、支持事务处理并保障系统稳定运行。

第二阶段，智能更多来自数据训练。企业通过大量数据训练模型，获得预测、推荐、识别等能力。这个阶段推动了 Lakehouse 的兴起。企业希望在一个统一底座上，同时支持 SQL 分析、BI、Spark 计算以及机器学习训练。

第三阶段正在发生变化。随着基础大模型能力不断成熟，越来越多企业不再从零开始训练模型，而是基于预训练模型构建面向业务场景的智能应用。此时，关键工作流不再是“清洗数据、构建特征、训练模型、部署模型”，而是在推理过程中为 Agent 提供最新、最相关、最可信的上下文。

智能的来源发生变化，数据栈的重心也随之迁移。

Lakehouse 的位置正在变化

Lakehouse 过去最有吸引力的叙事，是“一份数据，两种用途”：同一份存储在对象存储上的数据，既可以用于 SQL 分析和 BI，也可以交给 Spark、PyTorch 等工具进行模型训练。

在企业普遍认为自己需要训练模型的阶段，这一架构具备很强的工程价值。分析团队和数据科学团队共享同一份数据底座，既降低了数据复制成本，也提升了治理一致性。

但进入 Agent 时代后，这一假设开始出现变化。

首先，训练和推理对数据系统的要求并不相同。Lakehouse 更适合批处理、离线分析和大规模扫描；而 Agent 需要的是在一次对话、一次推理、一次任务执行过程中，快速完成点查、过滤、聚合、全文检索、向量检索等操作。

对于 Agent 来说，数据查询不是后台任务，而是推理链路中的实时环节。一次查询慢 200 毫秒还是 3 秒，对于传统报表用户而言可能只是体验差异；但对于需要多轮检索和多次工具调用的 Agent 而言，延迟会被不断叠加，并直接影响最终响应体验。

其次，数据共享的逻辑也在发生变化。当企业智能能力越来越多来自预训练大模型，而不是自研模型训练时，数据科学和智能应用开发的重点也会转向推理阶段的数据供给。企业更需要的是可实时查询、语义清晰、支持混合检索的热数据，而不只是等待批量扫描的冷数据。

这并不意味着 Lakehouse 会失去价值。它在企业数据治理、合规归档、历史数据管理、大规模离线处理，以及模型厂商自身的预训练 Pipeline 中仍然重要。变化在于，它正在从前台的数据访问入口，逐渐回到更偏后台的基础设施位置。

而走向前台的，是能够直接进入 Agent 推理链路的实时数据系统。

实时分析引擎成为 Agent 数据访问的关键环节

当数据的主要消费者从“人”扩展到“智能体”，分析型数据库的架构优先级也会被重新定义。

首先，亚秒级延迟从优化项变成基础要求。

传统分析型数据库主要服务分析师和报表系统，用户可以接受一定查询等待时间。但 Agent 面向的是连续交互场景。用户在对话窗口等待结果，Agent 在后台不断拆解任务、调用工具、查询数据和补充上下文。每一次数据访问的延迟，都会被叠加到最终响应时间中。

这要求数据引擎具备更细粒度的数据裁剪和更高效的执行能力。以 Apache Doris / SelectDB 为例，Short Key Index、ZoneMap、Bloom Filter、倒排索引等能力，不再只是数据库性能优化手段，而是支撑 Agent 进入实时业务场景的基础能力。

其次，混合检索需要统一入口。

Agent 不会关心底层使用的是 SQL、全文检索还是向量检索。它只会基于任务目标寻找最合适的上下文。在一次任务中，Agent 可能先做点查，再做聚合分析，随后进行相似度检索，最后通过全文检索补充证据。

但当前技术生态往往是割裂的：向量数据库擅长相似度检索，却缺少完整 SQL 分析能力；全文检索系统擅长关键词搜索，但在复杂分析和实时聚合上存在边界；传统数仓擅长分析，却未必适合低延迟混合检索。

Agent 需要的是一个统一的数据访问入口：能够融合 SQL、全文检索、向量检索等能力，并将结果组织成更适合 LLM 消费的上下文。Doris / SelectDB 近年来持续强化实时分析、倒排索引、全文检索和向量检索能力，正是面向这一趋势的架构演进。

第三，Schema 语义化会成为数据库的重要能力。

Text-to-SQL 的准确率，不只取决于 LLM 能力，也取决于 Schema 是否容易被机器理解。传统数仓中，大量表名和字段名高度工程化，例如 ods_usr_bhvr_pv_log_di 这类命名，对业务人员可以通过数据字典理解，但对动态生成 SQL 的 Agent 并不友好。

未来数据库需要把“让机器理解数据结构”作为重要设计目标。表注释、列注释、示例数据、语义标签、指标口径、数据血缘等能力，过去更多属于治理和文档工作；在 Agent 时代，它们将直接影响 Agent 是否能够正确理解数据、生成 SQL、调用工具并完成任务。

第四，高并发、低成本和弹性能力会更加重要。

一个分析师一天可能只写几十条 SQL，但一个 Agent 在一次复杂任务中就可能生成几十条查询。当企业内部大量 Agent 同时运行，查询量可能达到传统分析场景的数十倍甚至上百倍。

这要求数据系统不仅要快，还要能够承受高并发；不仅要稳定，还要具备足够好的成本效率；不仅要能扩展，还要支持更细粒度的弹性调度。

对 Apache Doris、SelectDB 这类实时 OLAP 引擎来说，这意味着需要在存算分离、共享存储、弹性计算和高效执行之间取得平衡，以支撑面向 Agent 的实时数据访问。

不是替代，而是数据栈重新分层

需要明确的是，实时分析引擎并不是要替代 Lakehouse。

更准确地说，企业数据栈正在重新分层：热数据进入 Doris / SelectDB、ClickHouse 等实时 OLAP 引擎，用于服务 Agent 的实时查询、混合检索和低延迟上下文获取；冷数据则继续保存在 Lakehouse 中，用于长周期归档、合规备份、历史分析和大规模离线处理。

Lakehouse 的价值不会消失。开放格式、对象存储、数据治理、ACID 和统一数据管理仍然是企业数据架构的重要组成部分。但当 Agent 每天产生大量实时查询，而训练任务频率相对有限时，真正靠近业务交互和智能体推理链路的数据系统，将捕获更多增量价值。

在这一背景下，Apache Doris 这类实时分析引擎，正在从企业数据架构中的“可选项”，变成智能化系统中的关键基础设施。

结语

Agent 时代并不是一个停留在概念层面的趋势。它正在从客服、运营、BI、知识库、数据分析等场景进入企业，并逐步扩展到更多核心业务流程。

当 Agent 真正进入生产系统，企业对数据基础设施的要求会发生变化。实时、低延迟、混合检索、语义化、高并发、低成本弹性，这些过去看似分散的能力，将共同构成 Agent 时代的数据底座。