Data Agent 厂商地图：按系统位置比较，不按名字排队

Thu, 17 Sep 2026 00:00:00 +0000

Data Agent 市场最容易画错的一张图，是把云平台、BI 应用、内部自建系统、开源框架和学术项目放成一排 Logo，再暗示它们彼此竞争。它们可能解决不同任务，处在技术栈不同位置，也承担不同的生产责任。

更有用的地图以系统位置为纵轴，以交付形态为横轴。先找同类，再比较能力。

第一轴：产品位于系统哪一层

数据平台

Snowflake、Databricks、Google BigQuery、Microsoft Fabric、AWS Redshift 等平台拥有数据、计算、权限与治理入口。平台原生 Agent 的优势是能复用这些控制面，限制则是能力通常围绕自身生态展开。

例如 Snowflake Cortex Analyst建立在 Snowflake 语义模型与访问控制上；Microsoft Fabric Data Agent面向 Fabric 数据源并按用户权限查询；Google 同时提供面向分析、数据科学和数据工程的不同 Agent 入口。

语义与治理

这类能力维护指标、实体、关系、血缘、质量和权限。它们不一定以“Data Agent”命名，却决定 Agent 是否理解“收入”和“客户”。选型时要问：语义资产能否被 BI、Agent 和其他应用共同引用，版本和责任人如何管理，而不是只看是否有聊天框。

Agent 平台

平台提供模型、连接器、工具协议、运行时、状态、评测和治理，让团队构建自己的数据工作流。2026 年 9 月发布的 ChatGPT Work Data agent已是面向企业的产品，与 OpenAI 1 月分享的内部自建 Data Agent不是同一个交付边界。内部案例能提供架构经验，不能直接等同于可采购 SKU。

分析应用

BI、Notebook 和分析工作区把 Agent 放进业务用户或分析师已有界面。它们通常在问数、探索、代码分析、图表与报告交付上做得更完整，但底层语义、权限和执行可能依赖外部平台。评估时要沿调用链确认责任，不能只看前端体验。

数据工程与运维

这类 Agent 面向元数据、质量、dbt/Dataform、管道、成本和故障处置。它们可能产生代码或变更建议，甚至写入生产，因此测试、审批、幂等和回滚比问数准确率更重要。

第二轴：它以什么方式交付

形态	适合什么情况	需要承担什么
内部自建	数据和流程独特，已有强数据平台团队	架构、评测、安全、运维和长期迭代全部自担
平台原生	核心数据已集中在一个平台，希望快速复用权限与语义	生态绑定、跨源能力和区域可用性要核实
独立应用	需要跨平台体验或特定分析工作流	连接器、身份透传和数据出口责任要厘清
开源框架	需要可控部署、研究或深度定制	生产语义、权限、维护和支持不会随代码自动获得
学术项目	研究新方法、基准和能力边界	论文结果不等于生产 SLA 或产品支持

同一家厂商可以横跨多层，同一产品也可能在不同版本提供不同形态。地图不是互斥分类，更不是市场份额图。

厂商地图 on DataAgentX