五条 Data Agent 技术路线：别用同一把尺子比较不同产品

同样叫 Data Agent，有的系统把一句业务问题翻译成 SQL，有的会连续运行查询和 Python、写出一份分析报告，还有的直接修改数据管道。这些产品共享了一个名字，却不应共享同一套验收标准。

判断路线时，我更愿意先看一个具体工作流，而不是厂商首页上的产品名称：它接收什么输入，替人完成哪段工作，最终交付什么，以及失败后会影响谁。按这四个问题，Data Agent 大致可以分为五条路线。

这张图有两个刻意的设计。第一，五条路线是并列的任务类型，不是从低到高的成熟度等级；第二，路线决定系统“做什么”，语义上下文、运行时、权限和评测共同决定它“能否可靠地做”。

一、企业问数与语义层：把业务语言变成可信查询

这条路线解决的是高频、相对标准化的业务问题，例如“华东区上周新增付费客户是多少”“下降主要来自哪个渠道”。Agent 需要把业务词汇映射到指标、维度、表和连接关系，再生成查询并解释结果。

它看起来像 NL2SQL，真正的难点却通常不在 SQL 语法，而在语义：什么算“新增”，退款是否回冲，订单按支付日还是发货日归属。没有指标定义、实体关系、权限和可复用的正确样例，模型越会写 SQL，越可能快速给出一个格式正确但口径错误的答案。

Snowflake Cortex Analyst要求通过语义模型描述业务概念，并继承 Snowflake 的访问控制；其 Verified Query Repository 用经过验证的问句—SQL 对提升稳定性。Microsoft Fabric Data Agent也把自然语言问题转成面向 Fabric 数据源的查询，并按调用者权限执行。它们说明了这条路线的核心：不是聊天界面，而是“语义约束下的只读数据访问”。

验收重点：业务口径命中率、查询执行正确率、权限不越界、无答案时能否拒答或澄清。仅用 SQL 字符串与标准答案逐字比较，往往会低估等价查询，也会漏掉“SQL 正确但业务答案错误”的情况。

二、端到端分析与报告：从一个问题走到可复核的判断

如果问题变成“为什么本月留存下降，应该先排查什么”，单次查询就不够了。Agent 要拆解假设、选择比较基线、运行多轮查询或代码、制作图表，并把证据与结论组织成报告。

这条路线的产品价值来自缩短分析闭环，但也最容易制造“看起来很专业”的错觉。一份排版完整的报告可能用了错误分母，忽略了样本结构变化，或者把相关性写成因果关系。因此系统应保存分析计划、查询与代码、关键中间结果、图表数据和引用，让读者能够沿证据链回查。

验收重点：问题拆解是否覆盖关键假设，结论能否由已执行的证据支持，统计方法是否适用，重跑是否得到一致结果。报告文笔只是最后一层，不是核心质量。

三、自动化数据科学：让实验可运行，也让失败可解释

数据科学 Agent 会参与探索性分析、特征处理、统计检验、模型训练与评估。它与报告型 Agent 的区别，是交付物不只有洞察，还包括可运行代码、数据切分、模型指标和实验记录。

Google Data Science Agent把自然语言目标转成 Colab Enterprise 笔记本中的分析计划、代码与结果。这类系统可以显著减少搭脚手架的时间，但仍无法替代对标签泄漏、时间穿越、抽样偏差和评估设计的专业判断。

验收重点：环境与依赖能否复现，训练/验证边界是否正确，指标是否匹配业务成本，异常和失败是否被暴露。一个能跑通的 notebook 只是起点，不是模型可上线的证明。

四、异构与多模态分析：在多种证据之间建立连接

真实调查常同时涉及数据库、Excel、PDF、网页、图片、日志甚至音视频。此时 Agent 的主要工作不再是生成某一种查询，而是检索、解析、实体对齐、跨源聚合，并说明每个判断来自哪里。

例如排查供应商履约问题，既要读仓库里的交付数据，也要从合同 PDF 提取时限条款，再从工单文本识别异常原因。任何一个实体匹配或时间对齐错误，都可能让最后的综合结论失真。

验收重点：解析覆盖率、实体链接准确率、来源定位、冲突证据处理与引用完整性。系统应把“没有找到”“无法确认”和“推断得到”分开，而不是用流畅文字抹平证据缺口。

五、数据治理与数据工程：从回答问题走向改变系统

这条路线面向元数据维护、质量规则、血缘与影响分析、数据模型开发、管道排错和运维。它的输出可能是一份变更建议，也可能是 Dataform、dbt 或编排系统中的代码和配置。

一旦 Agent 能写入生产环境，评价标准就必须从“答案是否有用”升级为“变更是否安全”。BigQuery Data Engineering Agent可以生成和修改数据管道及 Dataform SQLX，但官方文档明确说明它不能代替用户执行、运行或调度管道。这个边界很有价值：生成变更与授权变更是两件事。

验收重点：影响分析、测试覆盖、最小权限、审批、幂等性、回滚与完整审计。高风险写操作不应因为模型“置信度高”就自动放行。

五条路线共享的，不只是大模型

路线不同，可靠系统需要的底座却高度相似：

• 语义与业务上下文：指标定义、实体关系、数据血缘、领域规则和经过验证的案例。
• Agent Harness 与状态：任务计划、工具协议、执行状态、重试、停止条件和成本预算。
• 身份、策略与审批：调用者身份透传、行列级权限、读写隔离以及高风险动作的人审节点。
• 评测与可观测性：离线任务集、线上反馈、执行轨迹、错误分类、延迟与成本。

这也是为什么只比较底层模型经常得不出有用结论。模型相同，语义层、工具、验证器和权限设计不同，生产表现可以相差很大。

混合型产品怎么分类

一个产品完全可以横跨多条路线。不要给整个产品贴唯一标签，应给具体工作流分类。例如，同一平台中：

• “查询本季度收入并解释口径”属于企业问数；
• “分析收入下滑并形成经营复盘”属于端到端分析；
• “训练流失预测模型”属于自动化数据科学；
• “结合访谈文档与行为数据解释流失”属于异构分析；
• “修复产生重复订单的管道”属于数据工程。

拆到工作流后，权限、验收集和人机边界才容易设计。同一平台不同功能的自主等级也可能完全不同。

选型时先问这八个问题

五条路线不是为了再造一套名词，而是为了让讨论回到工作本身。先确定 Agent 要接手哪段工作，再谈模型、自治等级和产品形态；否则，比较得越精细，可能离真实需求越远。