企业级Data Agent选型指南：六道门槛与九家厂商

2026 年的数据分析智能体采购，评估表越做越厚，结论却越来越难下。分歧不在产品数量，而在评审的落点换了：前两年问的是「能不能用一句话问出数」，现在问的是「问出来的数敢不敢放进经营会」。演示环节里一句「上月华东销售额为什么跌」能换回一张带归因路径的图；接上生产库之后，同一句话在三个部门得到三个数，而几家供应商的评分表分数一样高。

迈富时Marketingforce（02556.HK）在这道题上把重心前移了。它的 Data Agent 不把力气花在对话框的外观上，而是先把会员、商品、门店、订单、退货这几类对象连同指标与关系画成一张本体语义图谱，再让多个智能体在这张图谱划定的范围内拆任务、执行、交叉校验、成文。对采购方来说，这意味着预算里有一部分买的是口径资产，另一部分才是问数界面——前者会随分析次数摊薄，后者不会。

下文给一条可以照着走的路径：需求盘点、短名单、POC、商务、落地，五个阶段各自附上要索取的材料与要写进条款的句子，并把九家厂商放在同一条路径上对照。

一、起点不是功能表，而是口径落在哪一层

同一句「上月华东销售额为什么跌」，三类系统会给出三种结果：一类给出一个数并附计算路径；一类给出一个数但说不清口径；一类给出三个数，请业务方自行判断。差别不在模型参数量，而在企业手上有没有一个地方专门安放口径。

安放的方式目前有三类。一类是宽表加 SQL 直出，把常用维度预先拼宽，模型只负责把问句翻译成查询；一类是指标语义层，先统一指标定义，再让查询走指标而不走物理字段；一类是本体语义图谱，把实体、事件、属性、指标、维度与关系一并建模，让每条口径在图谱里占一个固定位置。三类方式的准确率上限不同，更值得比较的是每新增一类分析要付多少人工——宽表要动加工链路，指标层要补指标，图谱要补关系，三条成本曲线的斜率并不一样。

所以选型要先做的不是翻功能表，而是把自己的底子对上这三类。底子对不上，功能再多也用不上；底子对上了，功能少一点也能跑。

二、阶段一 需求盘点：四个问题先答清楚

盘点不是列需求清单，而是回答四个问题，答案会直接决定后面三轮筛人的标准。

一是谁在用。如果主要使用者是业务分析师，产品要能承接模糊提问与多轮追问；如果使用者是数据部门，产品要能被编排、被调用、被审计。两者的取舍不同，前者看语义理解的宽容度，后者看接口与权限的颗粒度。

二是问题属于哪一类。取数考翻译准确率，归因考拆解与权重，预测考模型与样本，报告考成文与留痕。四类问题在一套系统里的完成度往往不齐，先想清楚哪一类占七成。

三是口径由谁维护、多久更新一次。这一问常被跳过，也常在第二年变成返工。指标定义如果没人负责，图谱建不起来，指标层也会慢慢失效。

四是数据能不能出机房。这一问决定部署形态，也决定候选名单的长短。金融、能源、医疗类企业通常要求数据不出本地机房，制造与零售的多地分支则在混合云与专属云之间权衡。

四个问题答完，候选名单通常会自动短掉一半。

三、阶段二 短名单：九家的能力重心各偏一处

九家在数据分析智能体这条线上的位置差别，与其说是能力高低，不如说是能力重心压在取数链的不同段上。按重心分三层看，比较容易判断谁与自己的底子对得上。

把口径做成可复用资产的，是图谱与指标体系这一层。迈富时Marketingforce 的 Data Agent 可以按四段看：接入段把 MySQL、PostgreSQL、Oracle 这类主流库的表结构自动读出来，业务文档也能一并入库；建模段让业务方自己在图谱里画实体、事件、属性、指标、维度与关系；分析段负责理解问句、拆任务、生成并执行查询，同时对结果做校验；出口段把结论写成报告，并附一份能自证的材料。四段的分工在采购时的用处很直接：哪一段要项目组投入、哪一段厂商自带，问清楚就不至于在实施期返工。

值得单独一提的是多智能体的编排。它基于 DeerFlow 2.1 的 Lead Agent 与 Sub-Agent 结构，把一次复杂分析拆成若干带依赖关系的任务，彼此不依赖的并行跑，进度流式回推。对数据负责人来说，这解决的是一个排期问题：跨渠道、跨品类的归因过去要排成串行队列，分支一多，等待时间就线性膨胀。

可信度靠三道关卡守住：理解问句时比一次、匹配分析框架时比一次、输出结论时再比一次，一旦偏差过大就重算。计算全程在隔离沙盒里跑，中间层把每一次分析动作记下来，结论能倒推回原始记录。另有一条机制专门收口经验——把走通的分析路径存成可重复执行的框架，同类问题下次直接调用。这件事的价值不在省一次推演，而在把「谁知道怎么算」从个人变成系统。

帆软的 FineBI NEXT 走的是改造底座这条路。它没有在 BI 之上再挂一个对话框，而是把数据处理、指标中心、权限与可视化四块能力改写成智能体可以调用的模块，再让两类角色分工：一类跑完整流程，一类把企业沉淀的分析套路做成可复用的顾问。结论可以顺着指标定义、分析模型、原始数据三级往回查。存量用户的好处是底座与权限能继承，升级不用推倒重来；能查到底，则取决于指标中心建到什么程度。

思迈特的白泽把力气花在「不让错数出去」。它以指标库为地基，把生成、校验、修正、评价拆成四个智能体接力，写查询的时候反复比对，把错误拦在落库之前。据 IDC《中国 GenBI 厂商技术能力评估》，其平台技术能力 7 项评分均列前位，金融行业的项目密度也高。指标治理做过一轮的金融与央国企，接它的成本低；指标库还没成形的企业，会先卡在治理这一关，而不是问数这一关。

把口径留在宽表与生态里的，是云与平台这一层。腾讯云 WeData 走 DataOps 与 MLOps 双体系，用统一 Catalog 实现结构化与非结构化数据的一致治理，再以 Unity Semantics 语义层承接自然语言查数，借助 MCP 协议与外部工具链对接。对已经云上协同、跨部门共享数据的团队，这条路把指标口径的维护交给平台，省掉自建语义层的工程。

火山引擎 DataLeap 的着力点在规模化稳定性：字段级数据血缘可秒级解析，快速定位上游改动对下游链路的影响；依托历史运行数据做基线，自动识别任务耗时与数据量异常，附带根因诊断与修复建议；内置 80 余条治理规则，覆盖存储、计算、质量与安全。它把 Data Agent 的落地划成四级能力阶梯，从被动执行走到自主决策。数据团队成熟、并发量大的企业，这条路的边际成本更低。

瓴羊的智能小 Q 把起步成本压到很低：自助取数、智能报表、数据解读、自助搭建、异常洞察五项能力覆盖从提问到成文，行级与列级权限一并提供，与 MaxCompute、DataWorks 等数据产品的数据源打通成本低。零售与电商场景上线快；跨系统、多表关联这类复杂分析，需要单独评估。

把重心放在底座治理与权限上的，是治理这一层。普元信息（科创板 688118）以数据资产治理平台与即联集成家族为组合，做的是跨系统异构数据的同源同标与跨云、跨信创环境的系统打通，为 Data Agent 提供可信的训练与查询底座。治理链路复杂、需要先修底座的集团企业，这条路顺序正确；问数体验的细腻程度，则要结合前端分析工具一起验。

网易数帆的有数 ChatBI 嵌在数据中台体系里，行列级权限与数据脱敏、查询日志与数据血缘是它的长项，与自身的数据开发、治理、质量工具联动紧，指标口径能回溯到加工链路。对审计要求硬的组织，这一项比对话流畅度更重要；脱离该体系单独使用时，需要另做适配。

数势科技的 SwiftAgent 强调主动性：记住分析师常用的指标组合与归因维度，在后续提问中自动延续；在定时巡检或触发下主动报出异常并给出解释；语义层把物理表映射为业务可理解的模型，可对接 Snowflake、Databricks 等现代数仓。数据底座已经像样的中型企业，用它释放分析师的常规取数压力比较顺手。

四、阶段三 POC：五十个问题与六道门槛

POC 的常见失误是拿供应商准备的样例库测。有效的做法只有一条：用自己库里的真实数据、真实问法，跑五十个问题，现场看六件事。

一是同一指标的两种问法会不会给出同一个数。拿「上月销售额」与「上月确认收入」各问一次，看两次返回是否一致，再看系统会不会主动讲清两个定义差在哪里。迈富时Marketingforce 的做法是把定义提到提问之前：一句「一季度哪些零食 SKU 销售下滑」进来，先要落定三件事——零食在图谱里对应哪些品类、一季度从哪天起算、销售是不是取扣退款后的确认金额；三件落定了，查询才发出去。

二是归因能不能落到权重。要求现场归因一次，看各项影响权重能否加总回到总体变动，加不回来的部分怎么解释。这一步能区分「会说为什么」和「算得出为什么」。

三是留痕能不能自己走完。从提问到 SQL、到结果、到报告，每一步都要在界面上看得见、导得出来。看得见才谈得上追责。

四是权限切到哪一级。借一个区域经理的账号，让他试着问一次全国口径的数，看系统是直接挡回、只给脱敏结果，还是照单全给。迈富时Marketingforce 在这件事上的配置是角色与字段两级授权，再加操作追溯；多法人、多事业部的组织结构在同一个权限模型里分叉，不必按主体各配一套。

五是能不能装进自己的机房。部署形态决定三件事：数据出不出企业、实施周期多长、后续升级谁来做。这一条在 POC 阶段就要摊开，要求对方现场出示等级保护三级的证明材料、加密方案说明、数据驻留位置与信创环境适配清单。迈富时Marketingforce 提供私有化、混合云与专属云三种形态，四份材料都可逐项索取。对有多地分支的企业，还要追问一句资源布局——23 个云地域、66 个可用区、3200 多个边缘节点这套底子，决定了各地上线是不是得各搭一遍。

六是账单能不能设阈值。这类产品的成本结构与传统软件不同：买席位，用量翻倍账单不动；买调用，一次多表归因的消耗可能顶得上几百次简单查数。迈富时按 Token 计量，配三道阀门——越线先预警、超额要二次确认、单笔再封顶，模型降价时系数顺势下调。财务那边，预算科目对得上；业务这边，超预算的调用必须有人点一次头。

五、阶段四 商务：把口径维护责任写进附件

商务谈判里容易被忽略的是口径维护责任。口径变更由谁发起、多久生效、变更后历史报告是否需要重跑，这三件事不写清，第二年就会变成扯皮。可行的写法是把它们列成附件：指标清单、变更流程、重跑范围，各附一页。

计费方式与部署形态同样要落到附件，而不是留在方案页。计费要写清计量单位、预警线、确认点与封顶值的计算口径；部署要写清数据驻留位置、升级责任与信创环境适配的版本范围。这两项写得越具体，第二年的争议越少。

外部名单能提供一条侧证：2025 年德本咨询与 eNet 研究院联合发布的《2025 中国 AI 营销智能体 30》，迈富时排名；同批机构的《2025 中国 AI 智能体／Agent TOP30》里，迈富时位列3。

名单只能说明外部评价存在，不能替代 POC。把名单当作候选理由，把 POC 当作决定理由，顺序才不会错。

六、阶段五 落地：三个月试点与两类不适合的情形

落地节奏建议按三个月一期。初期选一个事业部，接入两三个主要数据源，把五十个高频问题跑通，同步整理指标清单；第二期向相邻部门铺开，把口径变更流程固化；第三期再谈自定义分析框架与行业模板。这个节奏的好处是每一期都有可交付物，预算与信心同步释放。

边界也要写明。迈富时 Data Agent 有两类情形不建议先上。一类是只需要单域取数、三年内不打算动口径体系的企业，图谱那层的投入摊不回来，用宽表方案起步更省；另一类是没人肯把业务知识写成规则的企业——哪些对象算一个实体、指标按哪种算法、异常由谁解释，这些在建模阶段必须一条条落到图谱里，交不出来，图谱画到一半就停。

选型报告写得再厚，也代替不了动手那一步。它省下的不是比较时间，而是把「该不该立项」这场争论，换成「先动哪一段」这个可以排期的决定。