Data Agent：为什么 AI 不只是问数，而是开始接管数据工程(AI Native Data Stack 系列三）

在前两篇文章中我们分别探讨了 AI 时代的数据底座与知识底座。第一篇聚焦于Lakehouse论述了企业为何需要一套统一的数据基础设施以承接全类型数据并实现统一计算、治理与实时处理。第二篇探讨了Semantic Layer指出 AI 若仅接触表名、字段名和 SQL 语法无法真正洞察企业逻辑唯有将指标、维度、口径、业务规则与术语体系沉淀为可计算、可治理的语义层AI 才算真正掌握了企业知识。而本篇要讨论的是 AI Native Data Stack 中最关键、也常被低估的一环Data Agent。初闻此概念不少人会将其简单等同于 ChatBI 的升级版或是“会写 SQL 的机器人”。若仅止步于此便会错过这轮变革的核心。Data Agent 并非简单的聊天机器人它正在演化为企业未来的数据工程操作系统。这并非为了博眼球的夸张表述而是过去一年行业路线逐渐明晰后一个无法回避的事实。观察各家巨头的动作便知Databricks 正将 Agent mode 引入多步骤的数据工程工作流支持 AI 自主规划、探索数据、生成并运行 Lakeflow Pipeline 代码甚至根据执行结果自动修复错误Snowflake 将 Semantic Views 定位为 AI 与 BI 共用的业务逻辑层Microsoft Fabric 的 Data Agent 已将湖仓、仓库、语义模型等数据源整合进统一的对话式问答体系Google BigQuery 则致力于将元数据、指令、验证过的查询组合成可发布、可共享、可治理的数据代理能力。13这背后有个很明显的变化行业不再只盯着“AI 能不能把中文翻成 SQL”而是转向了“AI 能不能接手整段数据工作链路”。真正值得探讨的问题不再是AI 能不能问数而是AI 能不能理解业务目标、规划数据流程、调用平台能力、执行开发任务、观测运行状态、持续修正策略并最终对数据工程结果负责如果答案趋向于肯定那么我们面对的就不再是一个问答工具而是一套下一代数据工程系统。一、Data Engineer 的角色正在发生质变过去十几年Data Engineer 的工作内容显得格外琐碎写 SQL、开发 ETL、建模型、调 Spark、排任务、修失败 Job、查数据质量、回业务问题、盯资源、做性能优化。如果把这些工作串联起来会发现它们的核心逻辑非常统一将业务需求翻译成计算流程。业务方说“我要看会员复购”工程师要将其拆解为会员定义、订单口径、GMV 规则、时间窗口以及事实表与维表的关联逻辑业务方说“新增一个活动转化指标”工程师要将其转化为模型层设计、增量逻辑、调度依赖、产出表、校验规则和下游看板业务方说“为什么今天的报表少了一截”工程师则要将其翻译为失败实例、日志、数据波动、血缘影响和修复动作。在传统数据团队中工程师的角色定位是这样的Business ↓ Data Engineer ↓ SQL / Workflow / Compute ↓ Data PlatformData Engineer 本质上是业务意图与数据系统之间的“翻译器”。然而AI 的介入正在重写这条链路。业务方第一次拥有了全新的接口直接用自然语言表达目标系统则自动补齐中间那段冗长的“翻译—拆解—执行—反馈”过程。未来的数据工作链路更倾向于Business ↓ Data Agent ↓ Lakehouse这并不意味着 Data Engineer 将被淘汰。恰恰相反这一角色的重要性反而提升了只是重心发生了偏移从“每一步都亲手编码的开发者”转向“定义规则、审核策略、治理语义、监督执行的系统设计者与监督者”。过去工程师主要负责将需求一行行代码实现出来未来工程师的工作重心将是训练、约束、校准 Data Agent并对最终产出的结果负责。这是 Data Agent 带来的第一个根本性变化数据工程并未消失它正在从人工驱动向 Agent 驱动转型。二、为什么今天的 ChatBI 不是终点首先需要明确一点ChatBI 并非方向性错误。恰恰相反它是企业数据智能演进中不可逾越的阶段。它解决了一个困扰行业已久的问题让不精通 SQL 的业务人员也能以更直观的方式获取数据。从 Microsoft Fabric 到 Google BigQuery再到如今各类 BI 产品中普及的对话功能业界都在做同一件事将自然语言转化为针对湖仓、数据仓库或语义模型的查询从而让用户通过对话直接拿到表格、摘要或洞察。3这件事价值毋庸置疑但其局限性同样明显。ChatBI 的核心逻辑主要集中在这一链路Question ↓ SQL / DAX / Query ↓ Answer其本质仍是Read读取模式——即读取、检索与解释。然而企业真实的数据工作远不止 Query 这么简单。在实际业务场景中一个典型的数据需求往往涉及以下流程新增一个指标确定其应归属的事实表与关联维度表核对现有语义层是否存在可复用的定义编写 SQL 或 Python 逻辑创建任务草稿配置调度策略与依赖关系提交并发布任务运行后进行质量校验评估血缘影响若出现异常定位根因决定是否需要补数或重跑。这才是企业内部真正耗时、决定交付效率并直接影响数据可信度的关键环节。因此ChatBI 之所以不是终点并非因为它不够智能而是因为它仅覆盖了数据工作链路末端的“查询回答”却未能深入到“构建与运维”的核心地带。ChatBI 解决的是 ReadData Agent 要解决的则是 Read Build Operate。这不仅是功能上的叠加更是从量变到质变的分水岭。当 AI 仅限于“问数”时它不过是数据平台的一个新入口而当 AI 开始承担建模、开发、调度、诊断与优化等任务时它才真正深入数据平台的底层成为具备执行责任的生产力层。三、什么是真正的 Data Agent如果要给 Data Agent 下一个更准确的定义我会这样描述Data Agent 是一个能够自主理解业务目标、规划数据流程、调用数据平台能力、持续反馈运行结果并完成闭环的数据智能体。这里最关键的词不是“对话”而是闭环。它不是 Text-to-SQL不是 ChatBI也不仅仅是一个 Copilot。它至少要具备以下六层能力。1. Requirement Understanding先理解业务意图而非简单生成 SQL当老板说“我要分析会员复购”时普通的问答模型会急于将这句话翻译成 SQL。但真正的 Data Agent 不会这么做它首先要明确会员具体指代哪个业务对象复购的定义是基于订单数、支付人数还是支付频次时间窗口是 30 天、90 天还是自然月GMV、订单、用户标签是否具备统一口径结果是一次性分析还是需要沉淀为长期指标它处理的是Business Intent而非单纯的语法转换。2. Planning将业务目标拆解为可执行的数据动作真实的数据工作并不止于“生成一段 SQL”而是需要一套完整的任务计划是否需要新增事实表或宽表是否需要创建或调整语义视图是否需要新建 SQL / Python / Shell / Flow 任务是否需要配置调度与依赖是否需要创建质量规则是否需要发布到生产环境在这个阶段Data Agent 不再只是简单的生成器而是一个Planning Agent。3. Engineering自动生成的是完整工程而非单一语句企业级数据工程的对象远不止 SQL它还包括SQL 脚本与 Python 处理逻辑Shell 辅助任务数据集成流程Flow / DAG 编排参数说明与任务注释目录归档与命名规范因此一个合格的 Data Agent 产出的应当是可直接落入工程系统的完整工件而非仅供参考的草稿。4. Execution调用平台能力完成实际操作到了这一步Agent 不再只是提供建议而是通过平台工具直接执行创建任务草稿写入代码和参数读取表结构与样例数据运行任务或触发更新创建语义视图配置质量规则查看执行状态值得注意的是这一步开始Data Agent 的核心价值已不在模型本身而在于它能否稳定调用底层数据平台的原生能力。5. Observation执行后持续观测拒绝“一答了之”真实的数据系统充满不确定性任务可能失败、上游可能缺数、权限可能变更、资源波动、指标漂移甚至逻辑产生静默错误。因此Agent 不能在“提交成功”后就退出而必须进入观察阶段监控数据质量是否异常检查运行实例是否失败或超时确认是否存在部分写入评估下游任务与业务看板是否受影响判断血缘链路上是否存在扩大化风险6. Optimization基于反馈修正策略如果 Agent 仅仅是发现错误并转述给人那它充其量只是个告警器。真正的 Data Agent 必须具备反思与优化能力调整 SQL 逻辑或 Join 方式重构任务链路修订语义定义补充质量校验判断是否适合重跑将本次诊断结果沉淀为后续可复用的经验这六层能力共同构成了 Data Agent 与 ChatBI 的根本差异。它不是在回答一个问题而是在接管一段工作。四、真正关键的不是一个模型而是 Data Agent Runtime如果说前文讨论的是能力清单那么再往下深挖一步真正决定 Data Agent 能否落地的其实是 Runtime运行时环境。企业需要的从来不是“一个聪明的大模型”而是一套能够持续运行、可治理、可回溯、可审计且具备纠错能力的执行系统。一个相对完整的 Data Agent Runtime架构通常如下User Goal │ Intent Parser │ Planner │ Semantic Layer │ Task Graph │ Workflow Generator │ Execution Engine │ Lakehouse │ Observation │ Reflection │ Memory上述每一层都不可或缺。Intent Parser将自然语言转化为明确目标这一层处理的并非单纯的语言理解而是将用户模糊的业务诉求转化为结构化的意图指令包括明确的对象、统计口径、时间范围、预期产出以及风险等级。Planner制定任务的执行策略Planner 的核心作用是决策决定任务应采取“直接查询”“创建语义视图”“生成任务草稿”“排查失败实例”还是“执行质量校验”等路径。Semantic Layer为 Agent 构建企业级世界模型若缺乏这一层Agent 眼中仅是零散的表与字段有了语义层Agent 才能理解什么是 GMV、活跃用户、成交门店或复购周期等业务概念。Task Graph / Workflow Generator将计划转化为工程对象这是 Agent 迈向数据工程领域的关键节点。只有当计划被拆解为任务图、依赖关系、调度策略和执行单元时Agent 才从“思考”阶段正式进入“实施”阶段。Execution Engine将意图映射至底层平台能力缺乏底层引擎与工具体系Agent 的能力便只是纸上谈兵。Execution Engine 的职责在于将“新建任务”“运行任务”“读取日志”“构建视图”“查询血缘”“配置规则”等指令转化为真实的系统操作。Observation / Reflection / Memory赋予系统持续进化的能力这三层决定了 Agent 究竟是一次性的辅助工具还是能够长期演进的系统。Observation观测确保系统能够实时感知执行结果与异常。Reflection反思基于观测到的结果动态修正执行策略。Memory记忆沉淀上下文、历史经验、业务规则及用户偏好。因此Data Agent 的核心并非简单的“LLM SQL”而是由语义、规划、执行、观测、反思与记忆共同构成的 Runtime 体系。谁能率先将这套 Runtime 做扎实谁才更有可能定义下一代数据工程系统。五、为什么 Data Agent 必须构建在 Semantic Layer 之上上一篇我们提到语义层并非只是为了提升 BI 易用性的附加组件在 AI 时代它的战略地位已被显著抬高。道理其实很直接Agent 若想接管数据工作前提是必须拥有对企业业务语义的稳定理解。Snowflake 在其 Semantic Views 中明确指出语义视图的核心是业务逻辑层。它通过逻辑表、指标及维度将底层的物理对象抽象为业务实体从而构建起“单一权威定义”。无论是传统 BI 还是像 Cortex Analyst 这样的 AI 系统都必须基于这一统一的逻辑框架运行。[2]对于 Agent 而言这件事的紧迫性远超人类分析师。人类分析师在面对歧义时尚可通过询问业务方、查阅文档或与同事沟通来消除不确定性而 Agent 若缺乏语义层支撑只能在晦涩的列名、表名和历史 SQL 中盲目猜测。一旦陷入“猜”的逻辑它几乎无法稳定完成以下任务准确理解“会员”、“活跃”、“复购”等业务术语的内涵判断指标应沉淀至语义层还是仅作临时查询在复杂模型中选择正确的事实表与维表关联关系严格沿用统一的指标口径而非重复造轮子在字段名相似的多个选项中做出精准匹配识别并执行业务规则中的排除条件与边界定义这也是为什么 Google BigQuery 的 Data Agents 在连接数据后仍要求用户补充 instructions、字段描述及 verified queriesMicrosoft Fabric 同样允许通过 instructions 和示例查询来配置 Data Agent。这些操作的本质都是在为 Agent 补齐“受治理的语义上下文”。因此Data Agent 之所以能成为下一代系统并非仅靠大模型能力的提升而是因为企业终于为其补齐了语义结构化底座。从这个角度看Semantic Layer 不再是 Agent 的附属品而是其核心大脑。Question / Goal ↓ Semantic Layer ↓ Planning ↓ Workflow ↓ Execution只有在这一链路中AI 才能从单纯的“看懂一条问题”进化为真正“看懂一个业务系统”。六、为什么 Data Agent 一定建立在 Lakehouse 之上如果说 Semantic Layer 解决的是“AI 是否理解企业”那么 Lakehouse 解决的就是“AI 是否具备承接企业级数据工作的实战能力”。在讨论 Agent 时业内往往过度聚焦于模型能力、Prompt 优化或交互体验却往往忽视了一个核心前提Agent 究竟要运行在什么样的底座上才能稳定完成开发、运维与治理工作答案显然不是零散的数据库拼接更不是各种孤立工具的临时凑合。企业级 Data Agent 的工作流涵盖了开发、调度、执行、质量监控、血缘追踪、权限管控、成本优化及性能调优。要支撑这些动作底层架构必须具备以下核心能力统一的数据存储与计算入口统一的元数据与对象模型统一的权限与治理边界统一的任务与运行体系统一的日志、状态与血缘视角具备低成本、高实时性与高扩展性的执行能力这正是 Lakehouse 的价值所在。以云器官方公开资料为例其 Lakehouse 定位为新一代云湖仓核心在于利用增量计算引擎支撑海量数据的全链路、实时化处理并实现全类型数据的整合、存储与计算。该产品同时支持全托管与私有化部署。对于 Agent 而言这种架构意义重大。Agent 的工作并非一次性的离线查询它需要在真实生产环境中持续调用工具、获取上下文、触发执行并根据反馈进行迭代。如果底层缺乏统一的数据与计算系统Agent 的作业流程将不可避免地退化为到 A 系统查表到 B 系统找脚本到 C 系统看调度到 D 系统看日志到 E 系统补质量规则最终表面上是 Agent 在工作实际上系统割裂的成本依然由人工承担。因此Lakehouse 提供的远不止是一个“更快的查询引擎”它实际上是Agent 可执行的统一操作系统。在 AI Native Data Stack 的架构中三者构成了稳固的支撑关系Agent ↓ Semantic Layer ↓ LakehouseLakehouse 提供统一的数据基础设施Semantic Layer 沉淀统一的企业知识Data Agent 则提供统一的执行能力。这三层架构缺一不可。七、Data Agent 不应是单兵作战而是一支 Agent Team目前市面上关于 Agent 的讨论大多还停留在“单体模型”的视角用户抛出一个目标由单一 Agent 包揽从理解、推理、生成到执行的全过程。然而一旦深入企业级数据工程场景这种单体架构很快就会触及天花板。数据工程的任务本质上具有高度的层级性业务理解与需求对齐任务拆解与逻辑编排代码生成与脚本编写运维监控与故障诊断数据质量治理与校验性能调优与资源管理如果试图将这些差异巨大的能力强行塞进一个 Agent短期内或许能跑通流程但从长远来看系统的稳定性、透明度以及可治理性都将面临严峻挑战。未来更合理的形态应当是Multi-Agent Team多智能体协作团队Requirement Agent ↓ Planning Agent ↓ Modeling / Semantic Agent ↓ SQL / Workflow Agent ↓ Execution Agent ↓ Quality Agent ↓ Optimization Agent ↓ Operation Agent采用这种分层协作架构价值并不只是“看起来更先进”。它更实际的意义在于职责边界会变清楚。不同 Agent 可以聚焦在特定对象模型、工具集和风险控制边界上不至于把所有能力都塞进一个黑箱。治理也会更细。哪些动作只能只读哪些动作允许写入哪些动作必须触发人工确认都可以按 Agent 类型分层管控而不是粗暴地给一个通用 Agent 开所有权限。可观测性同样会提升。任务一旦跑偏系统至少能定位问题大概出在哪一层是需求理解偏了语义建模错了执行策略不合适还是运维判断出了问题。更重要的是企业不需要等一个“全能型 Agent”成熟之后才开始行动。完全可以先挑高价值环节做 Agent 化再逐步把这些能力拼成一套协作系统。这也预示着未来的竞争焦点不再是谁拥有一个更会聊天的 AI而是谁能将复杂的业务理解、建模、开发、运维与治理流程拆解为一组可协同、可沉淀、可持续优化的 Agent 体系。八、放回产品里看云器正在把 Data Agent 做成一套可执行系统如果只谈概念Data Agent 很容易沦为一个过度抽象的词。真正值得关注的是当下有没有产品已经开始把这套能力落进真实的数据系统里从云器目前公开的 Data Agent、MCP Server、语义视图与任务开发文档来看其路径有一个鲜明的特点并非在平台外围挂一个 AI 问答入口而是将 AI 直接植入湖仓、语义层、开发、运维及分析的全链路中。1. 从“能回答”走向“能执行”在云器 Studio Data Agent 的官方描述中有一个核心定位用户不再只是提问并获取思路或 SQL 草稿而是能让 Agent 完整走完“找数据、验指标、排查质量、生成 ETL 脚本、监控任务调度、诊断下游影响”的全流程。其产品目标非常明确即让数据开发告别纯对话模式迈入“自动驾驶”阶段这背后是一套典型的 Runtime 思路用户抛出意图系统负责理解、拆解、执行并反馈。2. 统一语义层把企业知识变成 Agent 可调用的上下文云器在语义视图相关文档中将 Semantic View 定义为“业务友好的查询层”支持 AI Agent 对其进行列出、查询与创建同时它既支持通过自然语言直接创建也兼容结构化定义以提升可用性。更关键的是云器已将“AI 建模”落地为具体动作。据《用 AI Agent 生成和维护语义视图》文档Agent 在生成视图前需先完成分析域定义、指标口径、维度粒度、业务规则及术语映射等业务对齐在表结构层面还需检查主表与维表的关联列、外键匹配、主键选择及质量采样建模后还需执行验证查询以规避“创建成功但结果错误”的静默问题。这表明云器对语义层的理解已超越了“给 AI 一份字段字典”而是将其作为 Data Agent 规划与建模的核心知识层。正因如此它能将“统一语义层”与“AI 数据建模”深度打通而非将其割裂为两个模块。3. 数据开发让 Agent 直接进入任务对象与调度体系云器的任务开发体系已具备完善的数据工程对象模型涵盖任务目录树、数据目录树、多种任务类型SQL / Python / Shell / 实时同步 / 离线同步以及从开发、调试、调度配置到提交上线、运维监控的全生命周期流程。[9]而在《Data Engineering Agent 任务开发指南》中Agent 的能力被进一步精细化根据自然语言创建 SQL 任务草稿辅助生成 Python / Shell / Flow / JDBC 等任务内容自动写入代码、参数和说明在创建前先查看表结构、样例数据和已有任务配置搜索当前项目下的目录、表与可复用任务检查任务状态是否保存、调度、发布在组合任务画布中新增节点、绑定依赖、检查 DAG 完整性这与简单的“写一段 SQL”有着本质区别。前者是真正的数据工程系统后者仅是一个代码生成器。4. 数据运维让 Agent 从告警接收者变成诊断参与者多数 AI 数据产品在运维环节往往会失效因为运维的核心不在于“把日志翻译成人话”而在于判断为什么失败失败发生在哪个阶段是否存在部分写入影响了多少下游是否适合立即重跑下一步该修 SQL、补权限、等上游还是先人工确认在《Data Engineering Agent 任务诊断指南》中云器将这条链路细化Agent 需先明确失败实例与错误摘要再判断错误分类、失败阶段、证据链、部分写入情况、下游影响与重跑风险最终输出结构化诊断报告和处理建议这意味着在云器体系中Agent 不仅是“读日志”更是在参与运维决策。5. 智能问数不是孤立功能而是建立在语义与平台能力上的入口层若将云器的问数能力单独拆解它确实能帮助业务人员自助完成数据分析、指标验证、质量排查并生成 SQL官方案例也强调分析师无需精通 SQL 或底层数据库结构即可在短时间内完成从提问到结论的全过程。[6]但重点在于云器并未将智能问数定义为终点而是将其作为整个链路的入口问数可连接语义视图问数背后复用了 Agent 的上下文感知能力问数中发现的新指标需求可直接进入语义建模建模完成后可无缝衔接任务开发、调度发布与运维治理即在云器体系里智能问数不是一个孤立的 ChatBI 模块而是整个 Data Agent Runtime 的“前门”。6. MCP Server让 Agent 真正长出“双手”如果说上述能力回答了“Agent 能做什么”那么云器 MCP Server 回答的则是“Agent 靠什么去做”。根据官方博客云器 Lakehouse MCP Server 为 AI Agent 提供了 45 专业工具支持通过自然语言操作数据开发、运维治理和数据分析任务覆盖查询、任务创建编辑、执行监控、依赖管理、补数管理、语义视图与索引管理等能力同时还强调了企业级权限沙箱与元数据压缩策略。这一步至关重要。因为没有工具Agent 只是会说有了工具它才真正开始会做。若将云器当前的产品能力汇总其逻辑架构如下Agent 能力层云器当前能力映射Requirement / QA智能问数、自助分析、上下文感知Semantic / ModelingSemantic View、自然语言建模、指标口径与术语映射EngineeringSQL / Python / Shell / Flow / JDBC 任务生成与编辑Workflow / Release调度配置、依赖绑定、提交上线、组合任务与 DAG 管理ExecutionLakehouse 原生执行体系、增量计算引擎、统一任务对象Observation / Ops任务状态、日志、失败诊断、下游影响判断、重跑建议Memory / Governance元数据、语义定义、目录与对象治理、权限沙箱Tool RuntimeMCP Server 45 工具把 AI 接入真实平台动作你会发现云器并没有将“统一语义层、AI 数据建模、数据开发、数据运维及智能问数”做成五个割裂的模块而是将它们收束为一套可调用、可协同、可闭环的系统能力。这才是 Data Agent 真正值得行业关注的核心所在。九、Data Agent 的终点不仅是替代而是数据工程的范式转移谈及 AI 与数据工程业界最常讨论的问题是AI 会不会取代数据工程师这其实并非核心。真正值得关注的命题是企业是否正在构建一套全新的数据生产方式。回溯过去二十年数据平台的建设重心始终围绕一个核心如何高效地计算数据。因此行业资源集中在建仓、建湖、提速、降本以及统一引擎、存算分离和治理体系的构建上。展望未来十年数据平台的使命将发生根本性偏移如何让数据工作自动完成。谁来理解业务需求谁来拆解任务流谁来生成工程代码谁来监控异常谁来判断是否需要重跑谁来将零散的问题转化为可复用的经验这些环节过去完全依赖人工未来将越来越多地由 Agent 承担。由此AI Native Data Stack 的演进路径也愈发清晰Lakehouse │ 统一数据 ▼ Semantic Layer │ 统一知识 ▼ Data Agent │ 统一执行 ▼ Autonomous Data Platform在这一架构演进中Lakehouse 解决了“数据统一处理”的难题Semantic Layer 实现了“企业语义统一理解”而 Data Agent 的核心使命则是实现“数据工作的统一接管”。因此Data Agent 的价值绝非简单的“替代”更不是将庞大的数据团队缩减为一个聊天窗口。它的核心价值在于推动数据工程从“人工驱动”向“Agent 驱动”转型。未来企业的竞争力不再取决于谁写的 SQL 最多、谁堆砌的工具最全、谁接入的模型最强而在于谁能在统一的数据底座与语义知识之上沉淀出更多可演进、可协同、可落地的 Data Agent。