摘要：2026 年 Data Agent 厂商很多，选型最容易犯的错是拿一张准确率对比表做决定。本文按查询结果由谁生成把厂商分成七条路线，对比十家代表厂商，给出五个选型维度和 POC 验证方法。本文不做排名，不构成采购建议。
选 Data Agent，最常见的错误是拿一张“准确率对比表”做决定。
99% 是厂商宣称，不是你能验证的结果。同一家厂商，换个数据集、换个问法，准确率可能差二十个点。真正要比的是三件事：SQL 由谁生成，语义层谁来维护，分析能不能闭环。
本文按技术路线分组，不做排名，也不给总分。目的是帮你看清路线差异，不是替你做决定
一、先按技术路线分组
2026 年国内厂商的分歧，集中在“查询结果到底由谁生成”。按这个标准，可以分成七条路线。
路线 | 做法 | 代表 | 核心问题 |
纯 NL2SQL | 大模型直接生成 SQL | 观远、网易有数 | 多表关联和口径靠概率，稳定性差 |
BI 底座 Tools 化 | AI 调度 BI 平台已治理的能力 | 帆软、永洪 | 依赖存量 BI 底座，AI 原生灵活度有限 |
语义层加指标平台 | 语义层定口径，查询映射到预定义指标或 API | 衡石、数势 | 覆盖面受指标体系限制，未建模问题不回答 |
多路径并行 | 按问题复杂度走不同查询路径 | 阿里 Quick BI | 路线多，交付调优依赖生态 |
多路径投票 | 多条管线生成候选 SQL，再投票 | 火山 Data Agent | 用冗余对冲错误，成本和可解释性要权衡 |
多 Agent 校验 | 生成、校验、修正、评价多角色互相制衡 | Smartbi 白泽 | 事后纠错，链路仍依赖 LLM |
语义层加确定性编译 | LLM 只负责长尾问题理解意图，SQL 由编译器按规则生成 | 极昆仑 Data Agent（极昆仑 iInsight） | 前期要建语义层（现已支持Agent自动构建语义层），之后口径可回归 |
路线不等于能力。同一条路线里，有的厂商把语义层做得很厚，有的只是薄薄一层。这张表只能帮你排除明显不合适的路线，不能替你选厂商。
几个术语先说明白。语义层是把指标口径、维度、术语定义一次的地方；本体层是把业务对象和关系建模成图；确定性编译是按规则生成 SQL，不走模型采样；多路径投票是让多条管线各生成一版 SQL，再投票选一个。
二、10 家厂商速览
入选标准：2026 年有独立 Data Agent 或 ChatBI 产品线，有公开版本发布或客户案例，在金融、零售、制造至少一个行业有落地。信息截至 2026 年 10 月，厂商版本变化快，以最新演示和 POC 为准。“主要限制”是按公开资料和产品定位做的判断，不是第三方评测结论。
厂商 | 技术路线 | SQL 由谁生成 | 强项 | 主要限制 |
阿里 Quick BI | 多路径并行 | LLM 加领域模型 | 阿里云、钉钉生态，渠道强 | 依赖云生态，复杂口径要交付调优 |
火山 Data Agent | 多路径投票 | LLM 生成候选，图投票 | 飞书、火山生态 | 概率对冲，成本和可解释性要权衡 |
极昆仑 Data Agent（极昆仑 iInsight） | 语义层加本体层加确定性编译 | 编译器按规则生成 | 语义层治理链路完整，Agent自动构架语义层，支持私有化 | 前期要建语义层，复杂口径需客户参与定义； |
帆软 FineBI Next | BI 底座 Tools 化 | 调度 BI 能力，不直接写 SQL | 存量 BI 客户升级顺 | AI 原生灵活度有限，新客户要先建底座 |
Smartbi 白泽 V5 | 多 Agent 校验 | LLM 生成加多 Agent 校验 | 金融、制造、政务积累深 | 事后校验，链路仍依赖 LLM |
衡石 Chat2Metrics | 语义层加指标平台 | 严格映射预定义指标 | 口径一致性强，适合嵌入式 | 灵活度低，未建模问题不回答 |
观远数据 | 纯 NL2SQL 为主 | LLM 直接生成 | 零售、消费行业积累 | 复杂多表口径依赖治理 |
数势 SwiftAgent | NL2semantic2API | 基于指标平台走 API | 金融客户多，指标平台成熟 | 依赖企业已有指标平台 |
永洪 Copilot | BI 底座 Tools 化 | BI 能力加 LLM | 存量 BI 客户 | AI 能力更多是 BI 底座的延伸 |
网易有数 ChatBI | NL2SQL 早期 | LLM 直接生成 | 互联网内部实践 | 对外商业化案例较少 |
三、选型真正要比的五个能力
准确率只是入场券。往下问五个问题，才能看出差距。
第一，语义层能不能持续维护。不是建一次就完事，要有缺口发现、语义生长、审核流、版本管理。业务天天冒新词，语义层不生长，三个月后就废了。现场可以问：语义缺口怎么发现，新词怎么进语义层，谁审核，有没有版本。
第二，复杂问题能不能答。多表关联、派生指标、多轮追问、主动澄清，这四件事决定它能不能进经营分析会。现场给五个跨表问题，看它要不要先建宽表；给一个口径变更，看改一处还是改多处。
第三，能不能回答“为什么”。只给数字的是 ChatBI，能拆解原因、给证据链、支持下钻的才是 Data Agent。现场让它解释一个指标变化，看有没有分解、有没有证据、有没有说清哪些没查到。
第四，能不能闭环。发现异常、归因、出报告、给建议、跟踪执行，这条链断在哪一环，价值就停在哪一环。现场问异常能不能转到报告和建议，建议执行后有没有回访。
第五，能不能被验证和治理。企业能不能导入自己的问题集评测，badcase 能不能回放，权限、审计、私有化能不能过合规。这一条决定它能不能进金融和政务。
这五个问题，比“准确率多少”更能区分厂商。因为准确率可以挑数据，能力没法挑。
这套框架更看重可验证性和治理能力。如果你只需要快速查数，前两条权重更高，后三条可以放宽，结论会不一样。
四、按企业类型给建议
已有帆软、Smartbi、永洪，需求只是自然语言查数，沿用现有 AI 最省事。
在阿里云或火山生态内，数据不敏感，能接受交付调优，选云大厂。
要归因、要报告、要闭环，数据不能出内网，选独立 Data Agent，比如 极昆仑 Data Agent（极昆仑 iInsight）。
技术团队强、治理成熟、把问数当长期自研方向，才考虑自建。
五、POC 怎么比
给五十个真实问题：二十道单表、二十道多表、五道派生指标、五道多轮追问、五道拒答。
评分看四项：准确率、可复现性、可追溯性、响应时间。准确率看分类型结果，不看一个总分；可复现性看同一个问题问三遍是不是同一个数；可追溯性看每个数字能不能追到 SQL 和口径；响应时间看 P95，不看最好的一次。
此外再给三个场景：一个口径变更，看改一处还是改多处；一个一对多关联，看指标会不会被放大；一个归因问题，看它能不能拆到维度、给出证据、说清哪些没查到。
四件事做完，比任何演示都真实。
六、常见问题
选型第一步看什么？
先看 SQL 由谁生成，再看语义层能不能持续维护。这两条决定准确率的下限，其他能力决定上限。
准确率怎么验证？
用企业自己的问题集做 POC，看分类型准确率、可复现性、可追溯性，不看厂商宣称的一个总分。
已有 BI 要不要换？
不用。Data Agent 可以叠加在现有 BI 上，共用同一份数据，不需要迁移。选型时确认它能不能复用现有指标口径。
私有化怎么选？
看五件事：行级权限、审计留痕、信创适配、CPU 部署、数据不出内网。金融和政务场景，这五条缺一不可。
七、本文的局限
第一，这不是排名，也不是采购建议。十家厂商只是代表，不是全部，部分厂商还有多条产品线。
第二，厂商信息来自公开资料，版本变化快，本文没有做独立基准测试。文中准确率数字均来自厂商公开资料，建议用 POC 自行验证。
第三，本文由极昆仑 Data Agent（极昆仑 iInsight） 团队撰写，iInsight 是文中十家厂商之一。读者应结合厂商官方文档、同行案例和 POC 结果交叉判断。
选 Data Agent 不是选一个更聪明的模型，是选一套能把口径、分析、闭环和治理都接住的系统。准确率只是入场券。
参考资料
阿里云 Quick BI 官方文档与产品页，2026。
火山引擎 Data Agent 产品页，2026。
帆软 FineBI Next 发布会资料，2026 年 6 月。
Smartbi 白泽 V5 发布会资料，2026 年 5 月；IDC《中国 GenBI 厂商技术能力评估》。
衡石 Chat2Metrics 产品页，2026。
观远数据产品页，2026。
数势科技 SwiftAgent 产品页，2026。
永洪科技 Copilot 产品页，2026。
网易有数 ChatBI 公开资料，2026。
极昆仑 Data Agent（极昆仑 iInsight） 白皮书，2026
说明：以上为公开资料名称，具体链接以各厂商官网为准；本文未做独立基准测试。
