DataWorks Data Agent 又升级了：数仓人的哪些活儿能交给 AI，哪些真不能

如果你最近打开 DataWorks，大概率已经被 Data Agent 的入口、实战课堂和开通页包围了。7 月初官方宣布了 Data Agent 的新一轮升级，实战课堂系列一直更新到 8 月 19 日，淘宝直播的数据研发团队也把基于 Data Agent 的全托管实践拿出来公开分享。

但有意思的是，社区里同时存在另一条路线：有资深数仓开发直接把自己的开发主场搬去了 Codex 和 Claude，靠逆向 DataStudio 的执行接口把 SQL 执行能力接进本地，DataWorks 在他们那里"沦落到部署上线和生产治理最后的关卡"。知乎知乎上甚至还有这样的问题在吵：Data Agent 被称作基于大模型的新物种，是不是"旧瓶装新酒"，有回答直接点破：“DataAgent（数据智能体）的核心不是Agent，而是DataEngineering（数据工程）”。知乎
一边是官方全力推的原生 Agent，一边是极客们自建的"外挂"路线，再加上观望者"这玩意儿到底能不能上生产"的疑虑——如果你正在用 DataWorks，这可能是眼下最值得想清楚的一道选择题。这篇文章把两边的真实进展、分工边界和踩坑点一次性摊开。

先对齐事实：现在的 Data Agent，已经不是去年的 Copilot

很多人对 DataWorks 的 AI 印象还停留在"写 SQL 时补全代码"的 Copilot 阶段，但按阿里云大数据团队自己的梳理，这条线已经走了五个阶段：代码补全 → 问答辅助 → IDE Copilot → ChatBI → 全自动驾驶的 Data Agent。前四个阶段都是"副驾驶"，而 Data Agent 的定位是给一个目标，端到端完成需求理解、数据探查、写代码、上线甚至归因分析，官方称之为从"辅助驾驶"到"全自动驾驶"的模式跃迁。知乎
架构上它是双模式：CLI 模式负责工程开发，能读工程文件、表变更日志、上下游血缘，生成方案后写代码、调试、配质量规则，最后交给人 Review 发布；Claw（龙虾）模式负责运维和突发，跟钉钉、企微、飞书打通，半夜报警时在群里问一句"这个任务为什么没处理好"，它会自己读日志、读变更记录、给出处理建议，你回复一个"好"，它就执行。两个模式共享同一份上下文和权限体系，底座直接跑在 DataWorks 资源组上，复用现有的调度、权限和工作空间体系。

7 月初这轮升级的关键信息值得单独划出来：底层换成 Qwen Code Daemon 引擎，运行内存占用降了下来，官方口径是 1~2 CU 的低规格实例就能支撑代码生成、SQL 优化、任务排障这类常见活儿，入门成本明显压低。知乎新版 Chat 把对话和 CLI 融合，“对话即操作，Chat 即终端”；专家套件把特定场景需要的技能、MCP 服务和执行规则打包，安装即用，还支持把团队内部工具打包成自定义套件；MCP 管理有了可视化入口，资源组可开通公网访问（官方提醒按需开启、注意数据安全）。实战课堂系列则一路更新到第五期，把数据集成 Agent 的能力推到了多模态数据处理。

在官方 B 站账号里，它被直接称作数据开发人的"数字同事"。哔哩哔哩

另一条路线也真实存在：把 Codex 接进 DataWorks

如果只用官方视角看这事，会漏掉社区里相当活跃的另一条路线。

典型代表是一线数仓开发的真实操作：日常开发主场迁到 Codex 和 Claude，理由很直白，“不是 DWs的 Agent 不好用，而是Claude太好用”，通用编码 Agent 更擅长读本地知识库、写脚本、把一次性经验沉淀成可复用工具。知乎缺的只是最后一公里：让 Codex 能连上 DataWorks，真正执行 SQL 拿到数据。

他们的解法也很朴素：打开浏览器开发者工具，观察 DataStudio 的 XHR 请求，找到两个核心接口。一个负责提交 SQL，把 scriptContent、projectId、资源组这类参数交给 DataStudio 后端，返回一个 jobCode；另一个再根据 jobCode 拉取执行结果。知乎把这两个接口的 cURL 复制下来交给 Codex，让它自己解析 URL、Header、Cookie、CSRF token，生成本地 runner。之后 Codex 读自己的 Skill 说明，调用本地 runner 向 DataWorks 提交 SQL、等结果、继续分析。写一段、跑一段、看空值率、重复率、分区数、新旧口径对比——这些琐碎但高频的数据探查摩擦，就这么被消掉了。

这条路线的吸引力在于：本地工程体验顺滑、知识沉淀自由、迭代快。但它的代价同样明显——执行链路绕在平台治理体系之外，权限、审计、血缘、调度都不会自动跟上，本质是"个人提效工具"，不是"团队生产体系"。

两条路线的真正区别：体系内员工和体系外专家

把两边放在一起看，区别其实不在"谁更聪明"，而在"归谁管、能不能沉淀"。原生 Data Agent 的运行底座完全搭在 DataWorks 现有基础设施上，Agent 的调度、执行与负载都由资源组和云原生运行时统一承载，权限、血缘、治理体系都是现成的。知乎而 Codex 路线强在本地灵活，治理链路却要自己补。

一句话概括：原生 Data Agent 是"体系内的数字员工"，强在治理闭环和生产交付；Codex 路线是"体系外的外聘专家"，强在灵活和个人手感。它们不是替代关系，更像是内外两条腿。

按任务分工：哪些活儿能交，哪些交了就出事

真正有参考价值的是淘宝直播数据团队的落地方式——他们没有赌"AI 全自动"，落地主线就一句话：“以工程的确定性，约束大模型的不确定性”。知乎在这个前提下，任务被切成了明确的层级。

放心交给 AI 的： 标准场景的代码生成、自动建表和 DDL 变更、数据探查和质量检查、临时取数。他们的实践里，标准化输入下 AI 生成代码的准确率从 50% 提到 80%，配合轻量人工修正做到 24 小时交付，代码生成渗透率接近 100%。知乎其中 70% 以上的代码量走的是"自然语言 → DSL → SQL"的可审计路径，临时取数和老任务修改才走 Agent 直出。

AI 辅助、人主导的： 需求澄清、技术方案设计。他们的流程明确分成"澄清期"（人为主，构建 AI 友好的方案）和"执行期"（AI 全量驱动，人只做关键验收）两个阶段。

坚决不交给 AI 的： 数据建模决策、指标口径判定、复杂业务翻译——这三件事的最终责任在人。淘宝直播团队把话说得很清醒：关键节点保留人工确认"不是能力妥协，而是设计原则"。知乎
对普通数仓人来说，这个分层的价值在于：它把"AI 能不能上生产"这个吵不清的问题，换成了"哪一层可以上"。

上手前必须看清的三个边界

第一，AI 的准确率上限，卡在你的元数据质量上。淘宝直播特别强调，面向 AI 的数据交付绝不能止于建表，表结构、字段注释、枚举值必须精准且持续保鲜，“否则 AI 生成的代码将始终伴随概率性偏差”。知乎翻译一下：如果你们的表注释还停留在"同名字段"、口径散落在离职同事的脑子里，先别急着上 Agent，先还元数据的债，不然 Agent 只会把错误生成得更快。

第二，别跳过人工验收节点。目前公开的企业实践里，没有任何一家把生产核心链路做成全自动——确认节点是设计出来的，不是没做出来。

第三，把账算细。低规格实例确实把体验门槛打下来了，官方也明确会继续优化 Token 消耗；但新的计费项在变多，4 月 DataWorks 公告调整了标准版、专业版用户的 API 免费额度，取消每日调用数量限制并支持按量付费。哔哩哔哩资源组开通公网访问也有额外的费用提示。小团队试水没问题，规模化跑之前建议先把用量监控搭起来。

三类人的行动清单

个人开发者 / 学习者： 两条路线都值得摸。用低规格实例把 Data Agent 的对话式开发跑通一遍，像视频文件周期增量同步这类多模态处理任务，用一句自然语言就能创建和修改，不用再一项项配表单和算子。知乎同时把 Codex 接进自己的探查流程，哪边顺手用哪边，不冲突。

企业数据团队： 可以直接抄淘宝直播的作业——中心化跑标准化需求，本地化跑高频迭代；用规范文件（Spec）固化每个环节的输入输出，让 AI 输出可追溯、可 Review；把"指标口径、建模决策"明确写进人的责任清单。

观望派： 不用急着动生产。先从数据探查、临时取数、运维诊断这些低风险任务用起来，重点观察三个信号：Token 成本的下降速度、Agent 持久化记忆的成熟度（淘宝直播正在把本地 Agent 从"每日清空的实习生"养成"懂业务的老员工"）、以及 ChatBI 方向业务方买不买账。这三个信号任何一个兑现，都是加大投入的时机。

说到底，这一轮 DataWorks 的变化不是"要不要用 AI"，而是"AI 接管哪一段、人守住哪一段"。把分工线画清楚的人，才是真正吃到这波红利的。