Snowflake 提出“自主数据工程”成熟度五阶段模型，旨在实现 AI 智能体接管数据管道维护

一句话结论

Snowflake 提出基于五阶段成熟度模型的自主数据工程框架，推动 AI 智能体从辅助转为数据管道全生命周期的构建者与维护者。

关键要点

• 80% 组织已部署 AI 数据工程工具，但 55% 的数据工程师仍将数据安全和隐私列为首要挑战。
• 自主数据工程要求团队从“自下而上”的基础设施构建，转变为“自上而下”的数据产品驱动模式。
• 数据产品不再是孤立数据集，而是包含语义定义、质量检查及智能体可消费上下文的完整业务单元。
• 团队必须建立版本控制、CI/CD 及统一治理等工程基础，方可安全运行自主智能体工作流。
• 人类角色将升维为业务决策者与架构引导者，负责定义业务问题并确保智能体输出符合业务上下文。

背景与事实

数据工程正面临双重挤压。一方面，业务需求堆积与管道成本上升使传统手工维护模式难以为继；另一方面，AI 普及带来更多样、更大量的数据资产，且内部员工开始通过编程与对话式智能体直接调用数据、甚至生成 SQL。MIT 技术评论发布的《AI 时代的数据工程再定义》报告指出，80% 的组织已部署基于 AI 的数据工程工具，但数据工程师并未因此减负，反而需应对更高复杂度。其中，55% 的从业者将保障数据安全和隐私视为最棘手的挑战。多数团队试图用 AI 加速现有流程，却仍被不断膨胀的维护需求越甩越远。

Snowflake 主张进行根本性重构：数据团队应跳出“构建和维护管道”的手工模式，将重心转向产出“数据产品”。一个合格的数据产品不仅包含原始数据，还封装了语义、质量规则以及智能体完成任务所需的完整上下文。例如，在客户忠诚度场景中，数据产品会将客户活动数据与“高风险客户”的语义定义及文档化质量检查打包。分析师与智能体访问同一产品即可获得一致、可信的答案，无需各自解读原始 Schema。

这一转变要求颠覆传统技术架构。过去团队先搭基础设施、定 Schema、建管道，最后才对接业务；如今则应从业务问题出发，先确定能解决该问题的智能体工作流，再反向梳理该智能体所需的数据，并据此构建数据产品。数据体系将围绕业务结果纵向重组，管道设计不再服务于技术层级，而是服务于最终业务产出。

通往自主数据工程的路径并非跳跃式切换，而是遵循一条五阶段成熟度曲线。团队需在每一阶段审慎评估智能体能力边界，明确哪些工作可自动化，哪些仍需“人在回路”检查。已采用软件定义生命周期、声明式数据管道或 AI 辅助开发的团队，实质上已迈出第一步。

最终，平台基础决定演进速度。领先团队并非单纯依赖最强模型，而是将数据工程师提升为业务伙伴，并构建坚实的工程底座。这些底座包括版本控制、自动化测试、CI/CD 流水线，以及确保智能体可信运行的治理与互操作机制。平台需能持续吸收数据工程与 AI 领域的新创新，避免企业自行拼装大量异构组件或从头重建系统。

影响分析

对于中文开发者与数据从业者而言，此次范式转移带来三个层面的实际冲击。第一，技术能力门槛重构：掌握 DBC 工程基础（如 CI/CD、自动化测试、版本控制）将成为操作 AI 智能体管理数据管道的先决条件，单纯会写 SQL 或调优 Spark 参数已不足以应对新架构。第二，角色定位升级：数据工程师需主动向业务伙伴转型，核心职责从“执行管道运维”转向“定义数据产品语义”与“设计智能体工作流”，人类需在关键节点介入架构决策与上下文注入，而非陷入手工排查故障。第三，平台选型逻辑改变：企业在评估数据平台时，需重点考察其是否提供统一的治理机制与智能体互操作性支持，避免构建“烟囱式”基础设施；Snowflake 提出的 Data-eng-benchmark 基准测试亦为评估智能体任务质量与 Token 效率提供了可量化的参照标准。

适用边界

该结论主要适用于已具备较高数字化成熟度、且面临数据规模与业务复杂度双重增长的中大型企业。对于数据资产规模较小、业务需求高度稳定或尚处于数据治理起步阶段的团队，直接引入全自主智能体工作流的投入产出比极低，且因缺乏成熟的数据产品抽象与治理基础，强行推行将放大安全与隐私风险。此外，在强合规行业（如医疗、金融），受限于数据不可出域及严格的审计要求，全自主模式往往仍需保留较多“人在回路”的干预节点。

孤本观察

从行业竞争态势看，数据平台厂商正通过输出方法论（如成熟度曲线与基准测试）来抢占自主数据工程的标准定义权；判断认为，未来的平台壁垒将不再是计算性能或存储成本，而是谁能让智能体更安全、更确定地“消费”数据产品。

来源：InfoQ 中文 AI