Agent 为什么需要实时数据？Lakehouse 不再是唯一答案

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

在传统软件模式下，用户需要打开系统、选择功能、输入条件、查询数据，再根据结果做下一步判断。而在 Agent 模式下，用户只需要表达目标，例如“帮我分析最近一周客户投诉增长的原因”，Agent 会自动拆解任务、查询数据、调用工具并生成结果。

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

但要让 Agent 真正进入生产系统，一个核心问题是：它能否快速、准确地获取企业数据。

Agent 查询数据，不是后台任务

传统 BI 报表中，一次查询慢 1 秒还是 5 秒，很多时候用户可以接受。但 Agent 不一样。

Agent 在一次任务中可能会多次访问数据：

• 先查询用户基本信息；

• 再过滤最近行为；

• 再做聚合分析；

• 再检索相似案例；

• 最后生成回答。

如果每次查询都需要 2 秒，整个任务可能就会变成 10 秒、20 秒甚至更久。

所以对 Agent 来说，数据查询不是后台分析任务，而是推理链路中的实时环节。

Lakehouse 更适合批处理，不天然适合实时推理

Lakehouse 的优势在于统一存储、开放格式、低成本和大规模离线计算。它非常适合以下场景：

• 历史数据归档；

• 大规模 ETL；

• 离线分析；

• 模型训练；

• 合规数据管理。

但 Agent 场景更常见的是：

• 点查；

• 小范围过滤；

• 高频聚合；

• 低延迟查询；

• 全文检索；

• 向量检索；

• 多轮上下文获取。

这类请求并不总是适合通过 Lakehouse 批量扫描完成。

Agent 更需要实时 OLAP

实时 OLAP 引擎的特点是：

• 查询延迟低；

• 支持高并发；

• 支持明细查询和聚合分析；

• 支持索引加速；

• 更适合在线交互场景。

以 Apache Doris / SelectDB为例，它们面向实时分析场景，提供了列式存储、向量化执行、索引加速、倒排索引、存算分离等能力，能够更好地支撑 Agent 对企业热数据的实时访问。

实时数据为什么重要？

Agent 的回答质量取决于上下文质量。

如果数据不够新，Agent 可能给出过时结论。

如果查询太慢，用户体验会下降。

如果数据语义不清晰，Agent 可能生成错误 SQL。

如果系统并发能力不足，大规模 Agent 应用就无法上线。

因此，Agent 时代的数据基础设施，需要同时具备：

• 实时性；

• 低延迟；

• 高并发；

• 混合检索；

• 语义化 Schema；

• 成本可控。

一句话总结

Lakehouse 依然适合做企业数据底座，但 Agent 更需要一个靠近实时业务的在线数据入口。

这个入口，很可能就是Apache Doris / SelectDB 这类实时 OLAP 引擎。