过去十年，数据工程的主线，是 Modern Data Stack 对传统数仓体系的一次拆解与重组。
- 我们把数据采集从数据库里拆出来，形成了 Data Ingestion，用FiveTran、Airbyte、Apache SeaTunnel来解决ELT / CDC / Reverse ETL；
- 把计算从存储里拆出来，形成了 Snowflake、Databricks、Iceberg、Hive 这样的云数仓和湖仓体系；
- 把调度从脚本里拆出来，形成了 Apache Airflow、Apache DolphinScheduler 这样的 Orchestration；
- 把 SQL 开发、数据建模、血缘、质量、BI、AI 分析，又拆成了一系列独立工具。
这套体系当然是进步，它让数据工程从"一堆脚本 + Crontab"的原始阶段，走向了云原生、弹性计算、工程化治理和开放生态。
Modern Data Stack 最大的贡献是"拆分"，最大的副作用也是"拆分"。 工具越来越多，能力越来越强，但数据工程师也被迫在更多系统之间切换：数据源在一个地方，同步配置在一个地方，任务配置在一个地方，DAG 在一个地方，日志在一个地方，SQL 在 Git 里，Snowflake / Iceberg / 云数仓的执行结果又在另一个环境里。
结果是，很多数据工程师真正的时间，并没有花在数据建模、业务理解、指标口径、架构设计和成本优化上，而是花在配置数据源、设置字段映射、拖拽 DAG、修改 SQL、查看日志、重跑任务这些 Dirty Work 上。这就是 Modern Data Stack给数据工程师的困扰：数据工程师被困在工具里了。
而 Codex/ClaudeCode 这类编程类 AI 的出现，正在改变整个编程的流程。但是如何让数据工程师也可以顺利的Vibe-Coding？这正是我在探索的方向，也是本文主要讨论的内容。
我认为未来的数据工程，不会再只是"人操作工具"。而变成：Codex + Data Engineering Skill& Harness + Data Engineering SaaS+云端数仓能力。 简单来讲就是过去，Modern Data Stack 默认"人是操作中心"：人理解工具、人点击界面、人串联流程、人承担上下文切换。但在 AI 和 Agentic 开发时代，未来的数据工程不应该再只是"人操作一堆工具"，应该是人定义目标，Codex/ClaudeCode 拆解并自动开发、调试，Data Engineering Skill & Harness 提供工程边界并翻译给云端SaaS，Snowflake/ Iceberg/ 云数据仓库承载云端计算，底层调度与同步引擎保障系统稳定运行，人类负责对产生的结果进行Review、治理和最终判断。
当 Codex / Claude Code 开始参与数据工程之后，是不是可以将数据工程师从各种 Modern Data Stack的Dirty Work中解救出来，让数据工程重新从"工具操作"回到"工程创造"。
我认为这是在AI和Agent时代下，数据工程组织方式必然要发生的变化。
1. Modern Data Stack的问题：不是工具能力不够，而是人被复杂工具和设置过程消耗太多
今天很多数据平台功能已经很完整。数据源管理、离线同步、实时 CDC、SQL 开发、工作流调度、实例日志、告警监控、权限审计、血缘分析，基本都可以覆盖。但功能越多，平台越复杂。菜单越来越多，配置越来越细，流程越来越长。
数据工程师不是在驾驭工具，而是在适应工具，曾经红极一时的Modern Data Stack就是让工程师学一堆东西，美其名曰DataStack，而实际上工程师成为了"一堆工具"的奴隶， 工程师应该驾驭工具，而不是一遍一遍迭代学习各种越来越多的工具。
一个看似简单的 MySQL 到 Snowflake 同步任务，背后可能涉及源端表结构、目标端 database/ schema/ warehouse/role、字段类型转换、同步策略、工作流依赖、失败日志、下游 SQL、最终报表口径，哪怕用最先进的可视化的工具也需要拖拉拽好几步才可以完成整个流程。
真正消耗人的，不是某个技术点特别难，而是上下文和工具切换太多。数据源在一个地方，任务配置在一个地方，工作流定时在一个地方，日志在一个地方，SQL 文件在 Git 或本地目录里，Snowflake 的执行结果又在云端环境里。
在过去没有更好的方式，所以人只能亲自做。
但当 Codex/ClaudeCode 这样的工程型 AI 出现后，很多判断都可以通过大模型来进行处理，细碎动作开始具备被自动拆解、自动调用、自动执行、自动反馈，这就让Data Engineering Harness工具的出现成为了的可能。
Data Engineering Harness 本质上不是一个新的数据开发平台，而是一套面向 AI 和工程型 Agent 的数据工程能力框架。
它把数据源管理、数据同步、CDC、SQL 开发、任务调度、日志诊断、权限审计、运行观测、成本控制和人工接管等能力，封装成 Codex/ClaudeCode 可以调用、人类可以审查、企业可以治理的工程能力。
换句话说，Harness 要解决的不是"让 AI 会不会写 SQL"的问题，而是解决：
- AI 写完 SQL 之后，能不能安全地运行；
- AI 创建任务之后，能不能被追踪和审计；
- AI 调用 Snowflake 之后，能不能控制权限和成本；
- AI 生成工作流之后，能不能被人理解、确认和接管。
所以，Data Engineering Harness 的价值，不是替代数据工程师，也不是简单替代数据平台，而是把数据工程从"人手工操作工具"，升级为"人定义目标，Codex 执行任务，平台提供边界，企业沉淀 Know-how"的新范式。
2. 为什么不能让 Codex 直接写脚本？
很多人会想：既然 Codex 能写 SQL、能写 Python、能调用命令行，那为什么还需要Data Engineering Harness？ 直接让它连接 MySQL 和 Snowflake，生成脚本跑起来不就行了吗？
这个想法在个人实验里可以成立，但在企业级数据工程里行不通。
因为企业数据工程不是和Java开发一样"把一段脚本跑通"这么简单，在企业生产环境里，数据任务必须进入一个可管理、可审计、可运维、可协作的数据工程体系，至少他可以解决如下问题:
- 如何在开发环境、生产环境有效限制CodeX/ClaudeCode操作，避免Agent"删库跑路"？
- 如何设计、运行时出现的错误让CodeX/ClaudeCode理解和重新设计运行？
- 如何可以快速让其它人/Agent/代码工具看懂我的Agent写的数据工程？
- 失败之后能不能自动恢复（重跑、补数）？可以通过重试、断点续传、失败节点重跑等机制处理；
- 这个表修改有没有影响下游？可以通过可视化 DAG 看到上下游依赖关系；
- 数据同步，ETL、DataMapping是否可以可视化展示？DAG如何可视化操作？
- 出了问题谁来审计？可以通过运行实例、操作记录、日志和告警信息回溯；
如果每次都让 AI 临时生成脚本，本质上只是把"人手写脚本"变成"AI 生成脚本"。短期看起来快，长期会形成新的技术债：脚本风格不一、日志不统一、权限不清晰、失败不可控、运维不可追踪，让整个数据工程回到了"Shell+Crontab时代"。
所以，未来企业级 AI 数据工程的关键，不是让 Codex 裸奔，而是给 Codex 一个清晰的工程边界。
这就是 Data Engineering Harness 的意义，也是我设计WhaleStudio Harness Suite的目标。 Harness 不是限制 Codex/ClaudeCode，而是让 Codex/ClaudeCode 的能力变得可视化、可管理、可生产化。
3. Data Engineering Harness 设计理念
未来的Data Engineering Harness 不再只是传统意义上"给人点"的数据开发平台，而是面向 Codex/ClaudeCode 和 Agentic 开发重新组织的数据工程 Harness和Skill 套件。
以我们根据这套理念制作的WhaleStudio Harness Suite来讲下Data Engineering Harness的组成大家更容易理解：过去，Apache DolphinScheduler 解决调度和Orchestration问题，Apache SeaTunnel 解决多数据源数据批量同步和 CDC 问题，WhaleStudio 把这些能力整合成all-in-one平台加上企业级功能，给企业数据工程师使用。
但在大模型和Codex/ClaudeCode时代，仅仅给人提供 GUI 已经不够了。
未来的数据工程系统，既要让人能看懂、能审查、能接管，也要让 Codex Codex/ClaudeCode能通过 CLI、接口和工程上下文稳定调用与反馈。
这意味着，WhaleStudio 要把商业版 DolphinScheduler 和 SeaTunnel 的核心能力，包括调度、同步、CDC、SQL 任务、实例运行、日志诊断、权限审计、可观测性，重新设计、组织成 Agent 可调用与调试、人类工程师可快速审查、企业可治理的能力层。
这不是在旧的数据开发平台上加一个 AI 按钮或者一个聊天窗口，而是重新以Agent作为最终用户，根据AI和大模型的记忆习惯、调用能力、反馈机制重新针对软件的交互"界面"进行设计。
换句话来讲：从底层的引擎、到上层的调用、开发、调试反馈的能力要变成 AI 可以理解、调用、观测和受控执行的工程系统。
未来的数据工程平台，不再只是功能集合，而会成为企业Agent数据工程 Know-how 的容器。
企业积累的调度规则、同步经验、SQL 迁移经验、Snowflake /云数据仓库成本控制经验、发布流程、异常处理机制，都应该沉淀进 Harness和其相关Memory和Skill当中，让 Codex/ClaudeCode调用的不是一个裸接口，而是一套被验证过的企业工程能力。
4. UI 不会消失，但会从操作入口变成可观测性与微调的窗口
有了Codex/ClaudeCode 之后很多人会觉得 企业软件的UI 不重要了。
我认为不是。
UI 不会消失，但它的角色会变化。过去 UI 是操作入口。人通过 UI 创建数据源、配置任务、拖拽 DAG、设置调度、上线工作流、查看日志。
未来，很多动作会由 Codex/CluadeCode 完成，但人仍然必须看清楚 Agent 做了什么。它创建了哪些任务？用了哪些数据源？写入了 Snowflake 哪个 schema？哪些 SQL 被修改？DAG 依赖是否合理？运行失败是什么原因？是否影响下游？是否需要人工接管？不同的人员之间需要协同，团队合作。
总不能让所有人都翻另一个人的Prompt聊天记录来看如何开发的吧？这就是诞生了可观测性+可微调的UI界面需求。
未来 UI 的核心价值不是"让人一步步操作"，而是建立高度可观测性"让人可以快速进行Reivew、微调，从而对开发过程、运维情况与结果建立信任"。它要把 Codex 的执行计划、任务变更、SQL Diff、DAG 依赖、运行状态、失败日志、成本风险，以人能理解的方式快速呈现出来。
简单来说：CLI 适合 Codex 执行。GUI 适合人类审查。Harness 负责把两者连接起来。
未来最好的 UI，可能不是固定页面，而是围绕一次具体工程动作动态生成的审查界面：SQL 转换 Diff、同步任务确认、DAG 风险检查、成本评估、上线审批。
UI 会是建立一个让人类对大模型产生的信任界面，让人类可以快速理解大模型产生的ETL、DataMpaping，DAG，让人类之间可以进行工作交接，协同工作。
5. 未来数据工程师：从工具熟练工到工程指挥官
未来数据工程师不会消失。但数据工程师会分化。
一类人仍然停留在工具操作层：会点平台，会配任务，会改 SQL，会查日志，会手工拖 DAG。这些能力仍然有用，但会越来越容易被 Agent 自动化。
另一类人会往上走：能定义业务目标，能设计数据模型，能判断指标口径，能控制云数据仓库成本，能理解调度、同步、CDC 和 SQL 工作流之间的关系，能把团队经验沉淀进 Harness，让 Codex/ClaudeCode 在正确边界内稳定执行。
未来优秀的数据工程师，不一定是最会Modern Data Stack的人，而是最能组织工程能力的人。
他知道哪些事情可以自动化，哪些事情必须人工确认；哪些规则可以交给 Harness，哪些判断必须留给人；哪些任务可以临时生成，哪些能力必须沉淀成企业资产。
过去，数据工程师围着工具转。未来，工具、Codex/ClaudeCode 和云端能力要围着工程目标转。
小结：未来的数据工程，不是没有人，而是人终于站到了更高的位置
未来，只会手工操作Modern Data Stack工具的数据工程师就会像只会手工编写Java的工程师一样被淘汰。但能够理解业务、理解数据工程、理解云数仓、理解 CodeX/ClaudeCode工作方式，并且能把这些能力组织成 Harness 的数据工程师，会越来越重要。
而这不是一个遥远的设想。
在我下面的的实验Demo里，我已经完成了用 Codex 结合 WhaleStudio Harness，只需要花10分钟完成了一个从 MySQL 到 Snowflake 的数据ETL+自动化建立SQL Orchestration的工程流程：通过 CLI 调用能力，自动识别数据源，创建同步任务，生成可视化 DAG，执行工作流，查看日志，并把 SQL 转换成 Snowflake 可运行的任务链路，并自动调试错误，修正内容。
通过这个Demo，你可以体会到，未来数据工程师是如何工作的。
数据工程的下一个十年，工具不会更多，而是AI开始深度融合工具当中，开始理解目标、服从边界，并接受人的审查，而这就是 Data Engineering Harness。