导读
数据开发领域有一个再熟悉不过的场景：
业务方周五下班前扔来一个需求，要分析最近三个月各险种的赔付率趋势，顺带看看代理人违规行为和业绩之间有没有相关性。你打开数据库，面对几十张表名语焉不详的业务表，先花半天时间找数据、问口径、确认字段含义；再花半天写 SQL、跑结果、发现口径对不上又改；周一交付，业务说分析维度变了……
周而复始，变成行业常态。
这个行业里有两种人在各自努力，却都没能解决根本问题：一种人在 AI 上押注，做出的产品 Demo 惊艳，一进生产就翻车；另一种人在工具上打磨，平台功能越来越强大，工程师却越来越累。
这篇文章想说清楚三件事：
- 第一，套了 AI 外壳的数据产品为什么永远停在 Demo——缺的不是模型能力，是企业级的工程底座；
- 第二，传统数据开发为什么停留在工具层面——工具做到极致，人依然是最累的那个节点；
- 第三，云器 Data Agent 做了什么——在企业级能力底座之上，让数据开发真正「自动驾驶」。
Demo 很好看，生产跑不起来
过去两年，「AI + 数据」赛道热闹非凡。Text-to-SQL、AI 问数、智能报表……各种产品层出不穷，演示效果令人兴奋，但真正在企业生产环境里跑起来的，寥寥无几。
原因并不复杂：这类产品把 LLM 的通用能力直接暴露给了数据场景，没有做垂直化的深度适配。具体表现是
- 生成的 SQL 语法正确，但不兼容 Lakehouse 的方言和内置函数，跑不起来；
- 能识别表名，但不理解企业数仓的分层规范（ODS / DWD / ADS），推荐的表压根不是生产可用的；
- 没有上下文记忆，每次对话都要重新解释数据背景；
- 输出的是文字建议，执行还得靠人，和平台操作完全脱节。
演示时用精心准备好的 Demo 数据、标准表结构，效果很好；到了真实的企业环境，面对几十甚至几百张历史遗留表、各种方言混用的 SQL、复杂的调度依赖，就开始频繁出错。
问题更根本的地方在于定位：这类产品把 AI 当成了对话入口，用户说「分析一下赔付率趋势」，AI 返回一段思路和 SQL 草稿，判断、修改、执行、调试还是得用户自己来——绕了一圈，换了个界面的搜索引擎。
传统数据开发：工具足够好，但人还是太累
另一个方向，是传统数据开发平台的思路：把工具做得越来越强大，让工程师的每一步操作都有产品支撑。
这条路走了二十年，工具确实越来越好用。元数据管理、血缘图、调度配置、质量监控……每个环节都有对应的产品能力。但工具越强大，操作路径就越复杂，学习成本越高，人依然是这套体系里最忙的那个。
一次运维排查的真实路径
以日常运维中最常见的「任务失败排查」为例，标准流程是这样的：
接到告警 → 登录 Studio → 在任务列表里找对应任务 → 打开实例详情→ 查看报错日志 → 判断错误类型 → 打开血缘图 → 手动展开依赖层级→ 逐层确认下游影响范围 → 决定修复方案 → 修改 SQL → 重新提交
每一步都有界面支持，但每一步都需要人来操作、判断、决策。凌晨两点收到告警的运维工程师，要在睡眼惺忪的状态下走完这十几个步骤，容错率极低。
更普遍的日常困境是：业务分析师想做一个探索性分析，需要先找数据开发工程师排期取数，等数据拿到手，分析思路可能已经变了；运营同学想看某个指标，却不会写多表关联 SQL，只能等人排期……
「等排期」是传统数据开发体系里效率损耗最严重的地方，而这个问题工具本身无法解决，因为工具的设计前提就是「需要专业人操作」。
Data Agent：在企业级能力底座上，让数据开发「自动驾驶」
云器 Data Agent 的核心逻辑是：让 AI 真正承担执行工作，用户只需要表达意图，Agent 负责理解、拆解、执行、反馈——整个过程对用户而言，就像坐在副驾驶座上，看着数据开发自动完成。
支撑这件事的，是两块缺一不可的基础：深度的垂直场景适配，以及和产品的无缝集成。少了任何一块，所谓自动驾驶就只是方向盘转一半又转回来。
3.1 垂直智能：懂 Lakehouse，懂业务，懂产品
Data Agent 在 LLM 通用能力之上，做了三层垂直化适配：
第一层：懂底层语法
关键问题只有一个：生成的 SQL 能不能在生产环境跑。Data Agent 深度融合了 Lakehouse 的方言体系、内置函数和特有语法结构，输出的是生产级别的高性能脚本，而不仅仅是语法上说得通的 SQL。
一个典型例子是数据同步场景。用户说「把 MySQL 的订单表同步到 Lakehouse」，传统方式需要工程师手动处理十几个配置细节。Data Agent 自动完成的内容包括：
- 类型映射：UNSIGNED BIGINT → BIGINT，避免溢出风险
- 编码转换：GBK → UTF-8，防止中文乱码
- 目标表识别：有则导入，无则自建，逻辑自洽
- 增量识别：自动发现 updated_at 字段，推荐 MERGE INTO 策略
- 调度建议：周期、重试次数、间隔时间，一次配置完整
背后是对 Lakehouse 同步链路的完整理解，而不是往模板里填空。
第二层：懂产品操作
这一层解决的是「AI 输出能不能转化为产品操作」的问题。Data Agent 了解 Studio 不同产品模块的操作细节——数据源同步的字段映射规则、调度配置的约束条件、内置质量规则模板的参数范围等。
这意味着 Agent 给出的不是「建议」，而是「可直接执行的操作」。创建的任务支持点击跳转，生成的 Pipeline 直接渲染 DAG 拓扑图，运维诊断输出结构化的诊断报告，数据血缘展示可交互的依赖链路图。
AI 的输出，直接成为产品里可操作的对象。
第三层：懂业务知识
通用答案能不能适配企业自己的场景，是第三层的核心。Data Agent 支持接入企业自身的元数据信息、数仓模型规范和业务知识，用户输入需求时，Agent 会自动匹配云器最佳实践，结合企业上下文给出最贴合实际的答案。
在保险行业场景里，工程师要构建代理人风险管控看板，数据来源横跨保单、理赔、代理人评分等多张业务表。Agent 不仅能快速梳理表关联关系，还能主动发现「fact_claims 里理赔日期早于保单起保日期」这类业务逻辑异常——这种问题，老工程师靠经验才能想到，新人容易直接漏掉。
3.2 极致体验：从「操作产品」到「表达意图」
能做对只是第一步，用户愿意用才算数。Data Agent 在交互设计上有两个地方值得说。
上下文感知
Agent 能记住用户在产品内的一系列操作上下文，自动关联历史信息。用户不需要每次都重新解释「我在分析哪张表」「之前的指标口径是什么」，Agent 会主动维护这个上下文，让对话更连贯。
智能预判下一步
用户创建了一个 SQL 脚本任务，Agent 会主动问「是否需要设置调度？」；确认后设置完调度，Agent 继续问「是否帮您提交任务？」；提交后问「是否查看周期任务详情？」
这不是简单的对话引导，而是 Agent 理解了数据开发的完整链路逻辑（脚本 → 调度 → 提交 → 监控），主动帮用户把下一步串起来。对于不熟悉平台操作流程的用户，这相当于有一个随时在线的老手带着走。
两个真实场景的拆解
场景一：业务数据分析——从「等排期」到「自助探索」
用户想分析 2025 年 10 月到 12 月期间，工作日和周末用户点击行为的差异。这个需求看似简单，但对非技术背景的业务分析师来说，每一步都是障碍：
- 找数据：不知道哪个库、哪张表里有流量埋点数据
- 理解数据：不知道字段 click_event_name 具体指什么，也不知道数据质量是否可信
- 写 SQL：工作日 vs 周末的分组逻辑需要用到 DAYOFWEEK 函数，普通业务人员搞不定
Data Agent 的处理路径是：
用户：「帮我看一下 public 库下有哪些跟流量 tracking、点击行为有关的表」Agent：列出 6 张相关表，标注各自的业务用途，推荐优先看的核心表 用户：「帮我看下 dwd_studio_event_tracking_log_dd_i 的字段，没有描述的帮我翻译」Agent：输出完整字段列表，自动推断字段含义，标注空值率 用户：「帮我分析工作日和周末 top 5 的 click_event_name 数据情况」Agent：生成完整 SQL，包含 DAYOFWEEK 分组逻辑，自动处理窗口函数
整个过程，业务分析师不需要懂 SQL 语法，不需要了解数据库结构，不需要等工程师排期——从提问到拿到分析结论，30 分钟以内。
保险场景则展示了更复杂的数据工程链路：从数据摸底、指标可行性验证、数据质量排查，到最终生成 ETL 加工脚本，Data Agent 覆盖了数据工程师在看板开发前置阶段的所有工作。
其中数据质量排查的部分尤其值得关注。Agent 主动检查了三类高风险问题：保费金额出现负值（退保冲销 vs 测试数据的判断）、理赔日期早于起保日期（业务逻辑异常）、单笔赔付超过保额上限（数据合理性）。这三类问题依赖工程师的个人经验才能发现，新人容易漏掉，带到 ADS 层就是脏数据。
场景二：日常运维——从「人肉排查」到「智能诊断」
运维工程师想监控直播业务的任务调度情况：
用户：「帮我看一下包含'直播'、live 关键字的任务，其中已经提交的是哪些」Agent：找到 4 个匹配任务，列出任务 ID、类型、文件夹位置、发布状态 用户：「看一下这两个任务在 1 月 29 日的执行情况」Agent：输出任务执行情况分析报告——计划执行次数、实际执行次数、执行占比、失败实例详情 用户：「这个失败实例会影响哪些下游」Agent：即时输出影响分析：2 个第一层下游、3 个第二层下游，量化影响范围，给出修复建议
原本需要十几步手动操作、多个界面跳转才能完成的排查，浓缩成了三句话的对话。更重要的是，Agent 给出的不只是「哪里出了问题」，而是「影响了多少、影响了几层、建议怎么处理」——这是从信息查询到辅助决策的跨越。
“自动驾驶”的边界在哪里
自动驾驶不等于无人驾驶。人仍然需要设定目的地，仍然保持对方向的掌控，只是把「踩油门、打方向盘、看后视镜」这些机械动作交给了系统。
Data Agent 目前的定位类似 L3 级别——意图明确的情况下，能完成复杂的执行链路；遇到模糊地带或高风险操作，仍然会提示用户确认，不会自己闷头跑。
从产品路线图来看，云器接下来的迭代方向包括：
- 加强 Text-to-SQL 的底层语法能力，覆盖更多复杂查询场景
- 补全数据质量创建、运维操作等产品能力的 Agent 化
- 基于用户路径进行功能串联，智能预判并引导下一步操作
- 提升场景化的信息展示——多任务 Pipeline 的 DAG 图、血缘依赖图、诊断报告等
往后的方向，是让数据平台从「需要专业技能才能用好」，变成「知道自己要什么就能用好」。
写在最后
套了 AI 外壳的数据产品停在 Demo，是因为 LLM 的通用能力遇上了企业数据的复杂现实——方言、规范、血缘、调度，每一层都要真正适配，糊弄不过去。传统工具做到了极致，却始终没能跨过「工具需要人操作」这道坎，工程师越来越忙，业务等待的时间越来越长。
云器 Data Agent 把企业级能力装进 Agent，让 AI 接管执行链路。用户只需要说清楚要什么，从找数据、验指标、排查质量问题，到生成 ETL 脚本、监控任务调度、诊断下游影响，Agent 把这条链路走完。
数据开发领域长期存在一堵隐形的墙：会写 SQL 的人不懂业务，懂业务的人写不了 SQL。工具再强，也只是让墙的某一侧跑得更快。让这堵墙消失，得有人把两侧都接上——这件事，只有 AI 能做。
这是数据开发进入「自动驾驶」时代真正的意义——让每一个和数据打交道的人，都能直接开车上路。
