作者：马如悦，飞轮科技创始人
每个数据团队都熟悉这样的期待：业务用户用自然语言问一句："上季度亚太区月活用户数是多少？"或"为什么华东仓的履约时效在过去两周下降了？"系统就能立即给出准确、可追溯、可行动的答案。这正是 Agentic Analytics 正在描绘的下一代分析体验。
相比传统 BI，Agentic Analytics 的变化不只是把问题换成对话框。它希望让 AI Agent 主动拆解问题、探索数据、验证假设，并在必要时触发后续行动。也因此，越来越多数据平台和 BI 厂商开始把它视为下一阶段的核心方向。
但许多 POC 项目很快会撞上现实：AI 助手不理解企业内部的业务口径，回答看似流畅却经不起追问；关键数据散落在数据库、数据湖、对象存储和历史数仓里，Agent 很难获得完整上下文；一旦查询稍微复杂，数十秒甚至数分钟的等待就会打断整个对话式体验。
这时，最常见的判断是： "模型还不够好。"
模型当然重要，但它不是唯一变量。一个再强大的 LLM，如果面对的是低性能、碎片化、缺少业务语义的数据系统，也很难稳定完成分析任务。Agentic Analytics 能否落地，很大程度上取决于底层数据基座是否具备三项能力：交互式分析性能、跨源数据统一访问，以及可被 Agent 理解的业务语义。
核心观点：Agentic Analytics 的瓶颈往往不只在模型，而在数据基础设施。SelectDB / Apache Doris 通过实时分析引擎、湖仓一体联邦查询、语义建模能力与 MCP 接口，为 AI Agent 提供更快、更广、更可理解的数据访问能力。
Agentic Analytics 对数据基座的三项要求
- 交互式极速分析：Agent 的推理循环会反复经历 Schema 探测、数据采样、SQL 生成、执行和修正。只有亚秒到数秒级响应，分析对话才能保持连贯。
- 跨源数据统一访问：企业数据分布在 RDBMS、数据湖、数仓和对象存储中。Agent 需要直接访问完整数据视图，而不是等待长期 ETL 改造完成。
- 内置语义上下文：LLM 并不知道企业内部如何定义"活跃客户"或"流失率"。语义层让 Agent 能按统一业务口径理解和查询数据。
这三项能力不是锦上添花，而是 Agentic Analytics 的基础条件。SelectDB 作为基于 Apache Doris 的云原生实时数据仓库，正好在这些维度上提供了完整支撑。
支柱一：实时极速分析，让 Agent 保持思考节奏
Agentic Analytics 与传统 BI 的重要区别在于：查询负载更加探索性，也更难预测。 仪表盘通常围绕固定指标和固定查询设计；AI Agent 则会根据问题不断调整聚合维度、筛选条件和时间窗口，生成大量相似但不完全相同的查询。底层引擎一旦响应缓慢，Agent 的分析链路就会被迫中断。
这正是 Apache Doris 擅长的场景。作为 MPP 实时分析数据库，Doris 面向高并发、低延迟的 OLAP 查询而设计，能够为 Agent 的多轮探索提供稳定的交互式性能。
- 大规模低延迟查询：Doris 支持在大规模数据集上进行亚秒到秒级 OLAP 查询，让 Agent 的探索式分析能够及时返回结果。
- 实时写入与即席查询并存：借助 Flink CDC、Kafka 等实时摄入能力，Agent 不仅能分析历史数据，也能观察正在发生的业务变化。
- 物化视图与查询缓存：Agent 常常会产生大量相近查询。Doris 的物化视图和查询缓存可以减少重复计算，降低延迟与资源开销。
支柱二：湖仓一体，让 Agent 看见完整数据
在真实企业环境中，数据很少只存在于一个系统里。核心交易数据可能在 MySQL 或 PostgreSQL，分析数据在 Iceberg、Hudi 或 Hive 表中，日志和归档数据则分布在 S3、OSS、HDFS 等对象存储上。
如果为了让 Agent 工作而先发起一场大规模迁移，成本和周期都会非常高。更关键的是，在迁移完成之前，Agent 始终看不到完整数据，业务价值也会被延后。
SelectDB / Doris 采用更务实的方式：通过湖仓一体与联邦查询，把已有数据源纳入统一分析入口。 Doris 的 Multi-Catalog 架构支持透明访问多类数据源：
这意味着 Agentic Analytics 可以更早进入真实业务场景。Agent 不必等待所有数据完成搬迁，而是可以通过 Doris 的联邦查询，用统一 SQL 访问跨源数据。在产生业务价值之后，企业仍然可以逐步把高频数据迁移或优化到更合适的湖仓架构中。
支柱三：语义层与 MCP 接口，让 Agent 理解业务
LLM 本身并不了解企业内部的业务口径。它不知道"活跃客户"是指 30 天内有交易，还是 7 天内打开过 App；也不知道"流失率"应该按账户、用户还是设备计算。面对 tbl_usr_trx_v5 这样的表名，它更难判断背后业务含义。
这就是 语义层 的价值：把表、字段、指标和业务定义转化为 Agent 可以理解并稳定调用的上下文。SelectDB / Doris 可以从几个层面提供支撑：
- 语义建模能力：SelectDB 和 Doris 已经支持 MetricFlow 等语义模型。Agent 访问的是治理过的指标口径，而不是直接面对裸表猜含义。
- 统一 SQL 接口：无论数据来自实时写入、联邦查询还是湖上表，Agent 面对的都是统一 SQL 入口。这让"月收入""活跃客户"等指标可以在跨源数据上保持一致定义。
- MCP 接口（Model Context Protocol） ：SelectDB 可通过 MCP Server 让 Claude、ChatGPT、Cursor，以及基于 LangChain / LlamaIndex 构建的自定义 Agent，以标准化方式发现数据集、查询 Schema、检索语义上下文并执行受治理的 SQL。
借助 MCP，Agent 不需要为每个数据系统单独适配接口。一次接入后，主流 AI 客户端和自定义 Agent 就可以通过统一入口获得数据发现、语义理解和 SQL 执行能力。
不止于引擎：SelectDB Cloud 如何降低落地成本
Agentic Analytics 还会带来一个容易被低估的问题：查询负载更难预测。传统 BI 往往有固定刷新节奏和固定报表周期；Agent 则可能因为一次业务追问、一次异常检测或一次自动化任务，在短时间内发起大量临时查询。
这种负载模式天然适合弹性架构。SelectDB Cloud 通过存算分离和 Serverless 能力，让企业更容易控制 Agentic Analytics 的基础设施成本：
- 存算分离、弹性扩缩容：计算资源和存储资源独立伸缩。查询高峰到来时扩容，高峰结束后缩回，避免为峰值长期保留闲置资源。
- Serverless 免运维：数据团队可以把更多精力投入语义层建设、权限治理和 Agent 场景设计，而不是持续管理集群和容量水位。
- 适合 Ad-Hoc 查询：Agent 会产生大量探索式、一次性查询。弹性架构可以按照实际使用量计费，降低试错和探索成本。
此外，阿里云 SelectDB 已推出 Serverless 版本。根据阿里云官方信息，该产品已于 2026 年 3 月正式商业化，可提供秒级弹性能力，为面向 Agent 的分析场景进一步降低基础设施成本。
SelectDB / Doris：Agentic Analytics 的最佳数据基座
回到 Agentic Analytics 对数据基础设施的核心要求，SelectDB / Apache Doris 的价值可以概括为： 
换句话说，SelectDB 把实时分析引擎、湖仓联邦查询、语义建模、MCP 标准接口和弹性计算能力放在同一平台中。无论是 Claude、ChatGPT、Cursor，还是企业自建的 Agentic 应用，都可以通过统一入口，在治理过的语义视图之上，对跨源数据进行探索式分析。
"Agentic Analytics 的落地，不只取决于选择哪个 AI 模型，也取决于企业能否提供一个足够快、足够统一、足够有语义的数据基座。SelectDB / Apache Doris 的价值，正是在这里被放大。"
Agentic Analytics 正在改变数据分析的方式，让系统不仅回答问题，还能主动探索数据、发现业务洞见。但真正落地，需要的不只是模型，而是一套能够支撑实时分析、跨源访问、语义理解和弹性计算的数据基座。
6 月 11 日（本周四） ，SelectDB 产品发布会将系统展示 Doris / SelectDB 在实时分析、混合检索、Agentic Analytics、AI Agent 可观测、多模数据处理等方向上的最新能力，帮助企业为 AI Agent 打造稳定、可观测的分析环境。