摘要
如果有一天，在 WhaleStudio 中创建同步任务、编写 SQL、搭建 DAG、排查任务异常这些工作都能交给 Agent 自动完成，那么数据工程师的价值还体现在哪里？未来的数据平台又该扮演怎样的角色？
带着这样的思考，白鲸开源 CEO 郭炜 亲自录制了一段基于 WhaleStudio 与 Snowflake 的实践演示视频。作为长期深耕数据基础设施领域的技术创业者，他在持续打磨 WhaleStudio 的过程中，始终关注 AI 与 Agent 技术的发展趋势，并不断思考未来数据产品的发展方向。通过这次演示，他尝试验证一种新的开发模式：让 Agent 接管数据同步、SQL 转换、工作流构建以及任务调试等工程工作，而数据工程师则更多聚焦于需求定义、规则制定和结果审核。
从表面上看，这是一场展示如何通过 WhaleStudio Skill 与 Agent 在 Snowflake 上完成数据同步、SQL 转换、工作流构建和任务调试；而更深层次上，它探讨的是 Agent 时代数据工程师工作方式和数据平台形态的变革。对此，郭炜曾发文撰写了文章《未来十年的数据工程：从 Modern Data Stack 到 Data Engineering Harness》，探讨了自己对于未来数据工程趋势的一些思考。
而今天，我们将通过技术的角度，来分析当自然语言逐渐成为新的开发入口，当大量重复性的工程工作被 Agent 接管，WhaleStudio 这样的数据平台将如何从传统开发工具演进为兼具执行、治理与可观测能力的基础设施？本文将结合演示内容，对其中体现的技术理念以及未来数据工程的发展趋势进行梳理与解读。
完整视频：https://weixin.qq.com/sph/Ak2x1PDPxG
数据开发正在从"操作软件"转向"对话软件"
长期以来，数据仓库开发都建立在各种工具和平台之上。
无论是数据同步、数据建模还是工作流调度，工程师都需要通过界面完成配置。一个看似简单的同步任务，往往需要创建数据源、配置表映射、设计工作流、设置调度规则，再经过测试和上线等多个环节。
这些工作虽然已经被各种可视化平台大幅简化，但本质上仍然属于"人在操作软件"。
而在本次演示中，整个过程呈现出了完全不同的交互方式。
面对一个包含多张 MySQL 表的项目，并没有进入传统的数据同步界面，也没有手工创建工作流，而是直接通过自然语言提出需求：将指定表同步到 Snowflake 数据源。
随后 Agent 开始自动分析环境、识别数据源、创建同步任务，并生成对应工作流。
整个过程中，用户几乎没有进行任何配置操作。
这种变化看似只是交互方式的变化，但背后反映的是数据开发模式的转变。未来的数据平台或许不再要求工程师熟悉每一个按钮的位置，而是让工程师直接描述目标，由 Agent 负责完成具体实现。
数据同步不再是数据工程师的主要工作
在演示过程中，Agent 接收到同步需求后，首先检查当前项目环境以及数据源状态。
当发现数据源权限存在问题时，它并没有继续执行后续操作，而是提示需要完成授权。这一过程虽然看起来简单，却揭示了企业级 Agent 与普通代码生成工具的重要区别。
在企业环境中，权限体系始终是绕不开的问题。
数据源权限、项目权限、角色权限以及环境权限共同构成了企业软件的基础治理能力。即使 Agent 具备自动执行能力，也不能突破这些边界。
因此，Agent 的价值并不是取代现有的软件体系，而是在既有体系之内完成操作。
演示中特别强调的一点是，企业原有的 RBAC 体系仍然保留。开发人员拥有开发权限，运维人员拥有运行权限，管理人员拥有管理权限。Agent 所执行的所有动作，都必须受到这些权限规则约束。
换句话说，Agent 只是执行者，而不是超级管理员。
只有建立在权限体系之上的 Agent，才有可能真正进入企业生产环境。
从数据同步到工作流生成
完成基础数据同步之后，演示进入了另一个更有代表性的场景。
项目中已经存在大量历史 SQL 文件，但这些 SQL 并非针对 Snowflake 编写。过去如果需要迁移到新的数据平台，工程师通常需要逐条检查兼容性问题，并手工修改语法。
在演示中，用户直接将 SQL 所在目录交给 Agent，并提出新的要求：
将目录中的 SQL 转换为 Snowflake 兼容版本，同时根据 SQL 之间的依赖关系自动创建工作流。
随后 Agent 开始分析文件内容。
一方面，它负责完成 SQL 语法转换；另一方面，它根据 SQL 中引用的表关系推导任务依赖，并自动构建工作流。
在整个过程中，用户并没有参与具体实现，而是在等待 Agent 完成任务。
当工作流生成完成后，系统展示出的已经不是代码，而是可视化的依赖关系图。
这意味着过去需要工程师亲手搭建的 DAG，如今正在逐渐变成 Agent 自动生成的结果。
软件界面正在从开发入口变成观察窗口
在整个演示过程中，一个非常有意思的现象不断出现。
虽然 Agent 完成了大量开发工作，但用户仍然频繁打开工作流界面、任务界面以及执行日志页面。
然而这些操作的目的已经发生了变化。
过去打开这些界面，是为了创建任务、修改配置或者调整依赖关系。
而现在打开这些界面，更多是为了确认 Agent 做了什么。
工作流是否正确生成？
依赖关系是否符合预期？
执行结果是否正常？
日志中是否存在异常？
界面正在从"操作入口"变成"观察窗口"。
演示中提到，未来的软件价值可能并不在于提供多少功能按钮，而在于能否为 Agent 提供稳定的执行环境和良好的可观测能力。
当开发过程逐渐由 Agent 接管之后，人类需要关注的重点将转向结果验证与过程追踪。
因此，DAG 图、数据血缘图、运行日志和版本记录等能力的重要性反而会进一步提升。
数据工程师正在成为 Agent 的 Reviewer
在工作流自动生成之后，演示中还出现了一个典型场景。
Agent 已经成功创建了工作流，但任务名称并不符合团队习惯。
于是用户提出新的要求：
将任务名称统一修改为指定格式。
Agent 随即重新调整工作流配置。
从这个细节可以看到，人与 Agent 的协作模式正在发生变化。
过去，工程师负责亲自实现需求。
现在，Agent 负责实现，而工程师负责审核。
当发现命名不规范时，工程师指出问题；
当发现依赖关系存在疑问时，工程师向 Agent 提问；
当发现执行结果不符合预期时，工程师要求 Agent 重新调整。
整个过程与代码评审越来越接近。
演示中甚至出现了用户质疑某个依赖关系是否正确，并向 Agent 追问原因的场景。最终 Agent 给出了自己的判断依据，而用户则根据解释完成确认。
这实际上已经是一种新的开发协作模式。
Agent 需要规范，而不仅仅是能力
虽然 Agent 已经能够完成大量工作，但演示过程中也暴露出一些问题。
例如任务命名不符合团队标准。
例如生成结果与个人习惯存在差异。
这些问题并不是能力问题，而是规范问题。
因此演示中特别提到了一种新的实践方式------将团队规范写入 Agent 的配置文件中。
包括命名规则、任务规范、开发要求以及其他约束条件，都可以提前定义。
这样 Agent 在执行任务时便能够自动遵循统一标准，而不需要每次重新说明。
从某种意义上来说，未来团队沉淀的可能不再只是开发文档和最佳实践，而是直接被 Agent 理解和执行的规则体系。
这些规则将成为 Agent 持续工作的基础。
大模型已经能够完成大量重复劳动
在整个演示过程中，最核心的观点其实并不是 Agent 能够生成代码。
真正重要的是，大模型已经能够承担大量过去由数据工程师完成的重复性工作。
例如数据同步任务创建。
例如 SQL 兼容性修改。
例如工作流搭建。
例如任务调试和错误排查。
这些工作虽然必不可少，但往往消耗了大量时间和精力。
而在新的开发模式下，Agent 已经能够较好地承担这些工作。
对于数据工程师而言，这意味着可以将更多精力放在数据模型设计、业务逻辑理解以及架构规划等更具价值的工作上。
当前 Agent 的边界仍然存在
不过，演示同样指出了当前阶段 Agent 的局限性。
对于简单查询和常规开发任务，大模型已经能够提供较好的支持。
但对于复杂业务场景下的 Text-to-SQL，仍然无法达到理想效果。
原因在于，这类任务不仅涉及 SQL 语法，更涉及业务语义理解。
大模型可以帮助工程师完成 SQL 转换，可以帮助搭建工作流，但尚不能准确理解复杂业务规则并自动构建正确的数据模型。
因此在相当长一段时间内，人类仍然需要承担业务定义和逻辑设计工作。
Agent 更多承担的是工程实现层面的任务。
WhaleStudio：Agent 驱动开发时代的数据工程执行平台
通过这次演示我们可以看到，WhaleStudio 在整个数据同步与数仓开发过程中发挥了重要作用。虽然用户与 Agent 进行自然语言交互，但真正完成数据同步、工作流构建、任务执行和结果反馈的，依然是平台本身。从某种意义上来说，Agent 负责理解需求，而 WhaleStudio 负责将需求转化为可执行的工程任务。
总结来看，在 Agent 驱动开发的时代，WhaleStudio 主要承担了三个重要角色。
首先，它是 Agent 的执行平台。当用户提出"将 MySQL 表同步到 Snowflake"或"将 SQL 转换为 Snowflake 兼容版本并自动构建工作流"等需求时，Agent 负责理解意图，而 WhaleStudio 则负责调用底层能力完成数据同步、任务创建、工作流编排以及任务执行等具体操作。平台将原本需要人工完成的一系列配置过程封装为可被 Agent 调用的能力，使自然语言最终能够转化为实际的工程结果。
其次，它是企业级治理与约束体系的承载者。演示中特别强调了权限管理的重要性。在企业环境中，数据源权限、项目权限、开发权限以及生产环境权限都具有严格边界，而这些能力并不适合完全交由大模型管理。WhaleStudio 保留了成熟的 RBAC 权限体系，使 Agent 的所有操作都运行在既定规则之内，从而确保自动化能力与企业治理要求能够兼容。这也正是演示中反复提到的 Harness 理念------平台不仅要让 Agent 能做事，更要确保 Agent 在正确的边界内做事。
最后，它还是 Agent 开发过程中的可观测窗口。随着越来越多的开发工作由 Agent 自动完成，数据工程师的职责开始从具体实现转向结果审核与过程验证。工作流、DAG、运行日志、任务状态以及版本记录等信息，成为工程师理解和检查 Agent 工作成果的重要依据。因此，未来的平台价值不仅体现在开发能力上，更体现在可观测能力上。它帮助用户清晰地了解 Agent 做了什么、为什么这么做以及最终产生了什么结果。
从整个演示过程来看，WhaleStudio 并不是简单地为大模型增加几个工具调用接口，而是在 Agent 与企业数据平台之间搭建了一层完整的执行与治理体系。它既提供能力，也提供约束；既负责执行，也负责可观测。在 Agent 逐渐成为数据开发主要入口的背景下，这种平台能力或许正是未来数据工程体系的重要基础设施。
总结
这次实践展示的并不仅仅是一个 MySQL 到 Snowflake 的迁移过程，更重要的是展示了一种新的数据开发模式。
在这种模式下，数据工程师不再需要频繁操作各种工具界面，而是通过自然语言与 Agent 进行协作。数据同步、SQL 转换、工作流构建以及任务调试等工作逐步由 Agent 完成，而人类则负责目标定义、结果审核和规范管理。
未来的软件或许不再主要服务于人，而是服务于 Agent。人类通过可视化界面进行监督和协同，Agent 则承担大部分执行工作。
对于数据工程领域而言，这种变化可能意味着一次比可视化开发平台更深刻的变革。数据工程师的价值不会消失，但工作的重心正在从"如何实现"逐步转向"实现什么"，而这或许正是 Agent 时代真正值得关注的变化。