当数据平台的用户从人逐渐扩展到Agent，真正需要改变的可能并不是数据工具，而是数据工程的组织方式。

过去十年，数据工程经历了一轮高度专业化的演进。传统的大型数据平台逐渐被拆解成由数据库、计算引擎、数据集成、数据转换、数据治理、数据编排和BI等工具组成的Modern Data Stack。工具的专业化极大提升了数据工程的效率，也让数据工程从“大系统建设”走向了更加灵活的组合式架构。

但随着Agentic AI开始进入数据工程领域，一个此前并不突出的问题正在变得越来越明显：这套数据栈虽然已经足够适合人使用，却并没有真正为Agent设计。

在2026年DTCC大会上，白鲸开源科技创始人代立冬以“Harness Engineering for Data”（数据工程的“驾驭”之道）为主题，讨论了Agentic AI时代数据工程平台可能发生的下一次变化。

在他的判断中，过去十年数据平台解决的核心问题是 “如何让人操作工具”，而未来十年更重要的问题将变成“如何让Agent在正确的上下文和安全边界内完成工程任务”。因此，Agentic Data Stack真正需要解决的并不是如何让AI生成更多SQL、代码或者Pipeline，而是如何让这些由AI生成的内容最终成为可信、可验证、可控制、可追责的生产工程。

而连接Agent与生产工程之间的关键一层，就是Harness。

一、数据平台进入 Agentic 时代的大趋势

两条路径，指向同一个终点

代立冬首先给出了一个观察：Snowflake 与 Databricks 的转型路径不同，但战略方向正在收敛。

Snowflake 的路径是：Data Warehouse → Data Cloud → AI Work Interface → Enterprise Agent Platform。

Databricks 的路径是：Data Lake → Lakehouse → Data + AI Engineering → Agent-ready Execution Platform。

两条路线最终汇聚到四个共同的核心要素上：Context（上下文）、Capability（能力）、Governance（治理）、Execution（执行）。用他的话来说："未来的数据平台，不只是保存企业数据，而是承载 Agent 的企业上下文和执行能力。"

Snowflake：数据平台开始竞争企业 AI 入口

Snowflake 的变化，不是在 Data Warehouse 上增加一些 AI 功能，而是在用 AI 重新组织数据、语义、治理、应用和 Agent。它的演进分三步：从 Cloud Data Warehouse（存储/计算/共享/治理），到 AI + Data Platform（
AI/Data/Semantic/Governance），再到 Agentic Enterprise Infrastructure（Coco/CoWork/Skill/Agent）。

这意味着三件事：第一，数据平台的价值，开始从"管理数据"扩展为"支撑 Agent 行动"；第二，企业 AI 的入口，正在从 SQL 和 BI 扩展到自然语言与 Agent；第三，数据开始以 AI Context 的方式重新表达价值。正如他引用的那句："Goodbye Data，不是数据不重要了，而是数据开始以 AI Context 的方式重新表达价值。"

Databricks：把数据与 AI 工程变成 Agent 的运行环境

Databricks 的变化同样不是把 AI 接入 Lakehouse 这么简单，而是让数据、模型、Notebook、Pipeline 和治理共同成为 Agent 的工程环境——从 Data、Models、Notebook、Pipeline、Governance 一直到 Applications，构成一个 Agent-ready Engineering Environment。

"Agent-ready"有五条具体标准：数据可发现、Schema 可理解、指标有明确语义、Workflow 可以执行、操作可以审计。代立冬特别强调："Agent-ready 不是模型可以访问数据，而是数据、语义、计算、治理和执行同时为 Agent 准备好。"

用户变了：从人类用户到 Agent 用户

更本质的变化发生在用户侧。过去，数据平台的用户是数据工程师（Data Engineer）、数据分析师（Data Analyst）、BI 用户和平台工程师（Platform Engineer）；而未来，平台的用户将变成 Coding Agent、Data Agent、Business Agent、Operations Agent 等各类智能体。

两者的需求截然不同：人类用户需要 UI、文档和操作流程；Agent 用户需要 API、Skill、Context（上下文）、Policy（策略）和 Feedback（反馈）。这一根本差异，决定了现有数据平台架构必须重新设计。

核心命题的转向

代立冬把两个十年放在一起对比：过去十年，我们建设的是给人操作的数据平台——写 SQL、配 Pipeline、拖 DAG、看日志、修失败任务；未来十年，我们要建设的是让人定义目标、让 Agent 编排执行的数据工程平台——理解目标、拆解任务、调用能力、读取反馈、修复错误。

"平台的核心问题，正在从'如何让人操作工具'转向'如何让 Agent 在正确上下文和安全边界内执行任务'。"

回望演进史，这个转向并不意外：从 Database Era（存储/查询/事务），到 Big Data Platform Era（规模/分布式计算/日志分析），再到 Modern Data Stack Era（云化/模块化/工具标准化），每一代数据平台都是因为用户、规模和工作方式变了。今天 Agent 出现了，所以数据平台需要下一次演进——走向 Agentic Data Stack Era（
Context/Skill/Control/Harness）。

二、旧栈之困：Modern Data Stack 的成功与局限

先承认成功

在推出新范式之前，代立冬先承认了一件事：Modern Data Stack 非常成功。过去十年，它解决了企业数据基础设施的关键问题：过去是重型项目、专用硬件、大量定制、长周期交付、强耦合；Modern Data Stack 带来的是模块化工程、云资源、标准工具、快速组装、可组合。"没有 Modern Data Stack，就不会有今天可快速组合的数据工程生态。"

它的价值在于让数据工程从"建设一个系统"变成"组合一套能力"：过去是采购、部署、定制、集成，且升级困难；现在是 Cloud、Open Source、SaaS、Standard API 的乐高式组合，获得选择自由、演进自由、替换自由。

而它最重要的成果，是 Tool Standardization（工具标准化）：把数据工程从一套大系统，拆成了一条专业工具链——Source（业务系统/SaaS/API）→ Ingestion（同步/CDC/文件）→ Storage（仓库/湖仓/计算）→ Transformation（SQL/模型/测试）→ Orchestration（DAG/调度/重试）→ Governance（Catalog/Lineage/权限）→ BI（报表/自助分析），每个环节都有专业化工具。

但它有一个根本局限

问题恰恰藏在成功里：Modern Data Stack 是给人设计的，不是给 Agent 设计的。

人类在使用工具时可以自动补全上下文——读文档、拼语义、处理歧义、判断风险、承担责任；而 Agent 面对 SQL、文档、DAG、日志、业务规则和 Catalog 时，无法自动完成这些补全。代立冬点破了一个很多人没意识到的真相："今天很多数据平台看起来是自动化的，只是因为背后一直有人在补全上下文。"

被 AI 放大的后果

当生成式 AI 把生成代码的成本降到近乎为零，这一根本局限被迅速放大。数据工程的稀缺价值正在迁移：SQL、Code、DAG、Config 正在快速商品化；而 Context、Verification、Controlled Execution、Accountability 仍然稀缺。过去的稀缺能力是 Write SQL、Build Pipeline、Configure DAG；未来的稀缺能力是 Context、Verification、Governance、Controlled Execution。

"AI 时代真正稀缺的，不是生成数据工程，而是把生成的数据工程安全地交付到生产。"

于是出现了新的焦虑。社区讨论的核心，正在从"AI 能不能生成代码"，转向"生成内容怎样进入生产"。工程师真正焦虑的不是 AI 会写 SQL，而是 AI 写完以后谁负责。

具体有三个问题：复杂度——工具已经足够多了，Agent 会不会制造更多隐式依赖和临时脚本？责任边界——Agent 生成 SQL、ETL 和 DAG 以后，谁确认正确？谁批准执行？谁承担错误？生产风险——真正危险的，不是 Agent 写错 SQL，而是它写错以后仍然成功执行。而水面之下，还压着 Validation、Ownership、Lineage、Security、Rollback、Audit 六个问题。"AI 可以降低生成成本，但也可能放大工程混乱。"

数据工程没有"差不多正确"。在很多 AI 场景里，回答不够准确可能只是体验问题；但在数据工程里，错误结果可能直接进入报表、财务、运营和自动化决策。数据覆盖、CDC 漏数、指标错误、无法追责，任何一环出错，都会沿着 Wrong Data → Wrong Decision → Wrong Action 的链路传导下去。

真正危险的不是 Agent 执行失败，而是它带着错误结果成功执行。

三、新解Harness，把生成能力变成交付能力

针对上述问题，代立冬开出的药方是 Harness——一个位于 Agent 与底层工具之间的工程层。

交付标准：三类证据

一个生产级 Harness，必须同时交付三类证据：

结果证据——先证明它真的改善交付，而不是只增加一个炫目的交互层：交付周期是否缩短，而不是把工作从人转移到审查环节；错误是否更早暴露；返工、切换和等待是否下降，团队是否真正更快完成闭环。

过程证据——再证明每一步都可解释、可定位、可恢复：输入、生成、审批、执行的边界能否逐步追溯；异常发生后能否快速定位到 Context、Skill、Runtime 还是 Policy；失败后能否重试、回滚、接管，而不是让人工从头再做一遍。

治理证据——最后证明高风险动作被显式约束，而不是默认放权给模型：哪些动作可以自动执行、哪些必须审批，是否由 Policy 明确定义；人工是否只介入关键决策；审计链路是否能回答"谁在何时为何执行，并产生了什么结果"。

"没有这三类证据，Agent 只是更快地产生内容；有了这三类证据，它才开始交付工程。"

验收机制：7 个 sign-off gates

进入生产前，客户至少要确认 7 个 sign-off gates（7 个签字确认节点）。这不是功能清单，而是上线前的评审清单——七项里少一项，仍然只是功能演示：

1. Intent 可核对：目标、边界、验收标准必须结构化输入，不靠口头意图；
2. Context 可补齐：业务、数据、权限、环境上下文完整，不靠模型自由猜测；
3. Plan 可审查：SQL、DAG、任务步骤对人可读、对系统可校验、对风险可审阅；
4. Execute 可控：权限、目标环境、调用路径和 Skill 选择都在 Policy 约束下发生；
5. Result 可验证：结果要过质量、口径、差异或血缘校验，而不是凭感觉通过；
6. Failure 可恢复：异常后明确是重试、回滚还是人工接管，不能让失败悬空；
7. Audit 可追责：计划、审批、执行、结果和版本变更全链路留痕，便于审计复盘。

"这 7 个 gates 不是为了让 Agent 更聪明，而是为了让客户知道何时可以放心放权。"

三条底线：正确性、能力、上下文

Harness 的成立，还取决于三个前提是否被满足：

SQL 能跑，不等于业务成立。在数据工程里，"运行成功"只是最低标准。从语法正确、执行正确、数据正确到业务正确，共有四个层级；而"正确 SQL、错误结果"至少存在五种风险：选错数据源、用错指标定义、用错时间口径、Join 产生重复、忽略业务规则。代立冬用营收计算举例：Revenue 到底该用 Order Amount、Paid Amount、Recognized Revenue 还是 Net Revenue？"SQL 正确是计算机判断的；业务正确必须由企业上下文证明。"

没有 Capability，Agent 只是在不断生成新的临时脚本。临时生成是 SQL/Python/Shell 的一次性脚本，无统一反馈、难审计、难回滚、实现暴露；而工程 Capability 是标准 Skill，可复用、结构化反馈、可审计、可回滚、能力抽象。"没有 Capability，Agent 只是把'人写临时脚本'升级成了'AI 生成临时脚本'。"

没有 Context，Agent 只是在用概率猜企业含义。企业的数据不是一组表和字段，而是一套包含业务语义、技术关系、历史规则和组织责任的上下文系统。就以"计算最近30天高价值客户的收入"为例，至少要知道：高价值客户怎么定义？收入口径是什么？时间范围如何取？用哪张表？退款怎么处理？谁负责确认？这些分别对应 Business Context、Data Context、Execution Context、Organizational Context 四类上下文。"没有 Context，Agent 不是在理解企业，而是在猜企业。"

软件的重构与系统的短板

与此同时，AI 让所有软件公司重新回答一个问题：怎样成为 Agent 可以使用的软件？

传统软件是 UI-first——人打开界面、查找功能、填写配置、点击运行、处理异常；Agent-native 软件必须 Skill-first——Skill 可发现、Context 可注入、Policy 可约束、Feedback 可读取、结果可验证。大厂有历史包袱，创业公司有重构机会，认知速度开始变得比什么都重要。"面对 Agent，每个软件都要重新做一遍。"

把这些问题放在一起，结论变得清晰：Agent 不缺聪明，缺的是把聪明转化为工程结果的系统。

今天的模型已经会做 SQL、ETL、DAG、Logs、Fix、Plan；但它不能独立承担 Context、Permission、Validation、Impact、Rollback、Accountability。Generation Capability 与 Production Capability 之间，隔着一整个 Engineering System。"Agent 的短板已经不只是 Intelligence，而是 Engineering System。"

四、Agentic Data Stack 五层架构

针对上述问题，代立冬提出了 Agentic Data Stack 五层数据架构：

• L5 Business Intent Layer（业务意图层）：人定义目标、约束和验收标准；
• L4 Agentic Orchestration Control Plane（智能编排控制平面）：规划、编排、策略、审批、恢复；
• L3 Semantic & Knowledge Layer（语义与知识层）：语义、元数据、血缘、指标、记忆；
• L2 Data Engineering Harness（数据工程管控层）：Skill、权限、验证、观测、回滚；
• L1 Execution Runtime（确定性执行平台）：数据库、湖仓、Spark、Flink、SeaTunnel、DolphinScheduler。

架构的核心设计是：Agent 通过 Context 关联 L3，通过 Control 关联 L4，不应该直接调用工具，而应该在 Context 和 Control 约束下调用 Harness。

逐层拆解

L1 确定性执行：智能不负责确定性，Runtime 负责确定性。它负责执行 SQL、同步数据、跑批处理/CDC、调度任务、输出日志和状态，底座是 Database/Warehouse、Lakehouse/Iceberg、Spark/Flink、SeaTunnel、DolphinScheduler、SQL Engine、Data Quality Engine 等确定性组件。

L2 Harness：Agent 理解目标、生成计划、发起请求之后，请求要经过 Skill Definition、Permission Check、Context Injection、Validation、Observability、Rollback 六个模块，才能变成受控 Skill 去调用 Runtime 里的数据库、操作系统、开发平台和云服务。没有 Harness 是直接脚本、直接 API、难验证、难审计；有了 Harness 是标准 Skill、边界清晰、结构化反馈、可接管。"Harness 的价值，是把 Agent 的生成能力，变成企业可交付的工程能力。"

L3 Semantic Layer：解决"哪张表可信、指标口径是什么、字段是否敏感、数据从哪里来、下游影响谁"这些问题。它由 Business Rules、Metadata、Lineage、Metric、Glossary、Ontology、Data Contract、Execution Memory 共同构成。在 BI 时代，Semantic Layer 是给人解释数据的；在 Agentic 时代，它是 Agent 执行前必须读取的上下文层。"没有 Semantic Layer，Agent 只能读懂字段名，读不懂企业。"

L4 Control Plane：把调度系统从"跑 DAG"升级为"约束 Agent 如何把目标变成可执行工程"。传统调度模式是人工定义 DAG、Scheduler 执行 Task；Agentic Orchestration 则是人工定义目标、Agent 自主规划、Control Plane 约束执行、Human 干预容错，中间有 Goal Description、Skill Checking、Policy Checking、Human Gate、Audit、Multi-task Configuration 一系列检查点。

L5 Business Intent：过去是"人描述步骤"——从 A 表同步到 B 表、写 SQL、配 DAG、每天 8 点跑；未来是"人定义目标"——每天生成高价值客户收入数据集、使用标准收入口径、不允许覆盖生产表、异常波动超过 5% 需要人工审批。人需要表达的内容包括八个维度：目标、数据范围、时间窗口、质量要求、成本限制、风险边界、审批条件、验收标准。"未来的数据工程，不是人描述步骤，而是人定义目标、边界和验收标准。"

为什么是"重新分层"

下一代数据平台，不是加更多插件，而是重新分层。旧平台的分层是 Storage、Compute、Orchestration、Governance、BI；Agentic Data Stack 的分层是 Intent、Control、Semantic、Harness、Runtime，逐层回答四个问题：Agent 从哪里获取业务目标？如何理解业务能力？调用哪些能力？谁来做执行、验收和回滚？"Agent 时代的数据平台，必须重新设计目标、上下文、能力、控制和执行的关系。"

最小闭环

五层架构的运行，靠的是 Harness 的最小闭环：Intent → Context → Plan → Skill → Execute → Validate → Review → Feedback。Intent 明确业务目标、约束与验收标准；Context 补齐业务、数据、执行与组织上下文；Plan 拆解同步、转换、质量、调度等任务；Skill 调用标准化工程能力；Execute 由 Runtime 进行确定性执行；Validate 验证数据结果、质量与规则；Review 让关键风险由人审查；Feedback 把日志、指标、异常与审批结果反哺给 Agent，形成循环。

"没有闭环，Agent 只是生成内容；形成闭环以后，Agent 才开始交付工程。"

三条设计原则

Skill 不是 Prompt，而是受控执行单元。Prompt 只是 Instruction；Skill 由 Input、Context、Policy、Execution、Validation、Rollback、Output 七个模块构成。Tool API 暴露底层操作、只定义参数、失败由调用者处理；Engineering Skill 封装完整工程意图、定义 Context 与 Policy、内置验证与恢复。"Prompt 决定 Agent 怎么回答；Skill 决定 Agent 能不能安全执行。"

CLI 给 Agent 执行，GUI 给人类审查。CLI/API 面向执行与反馈：结构化输入输出、易于自动调用、便于测试与版本控制、适合 Skill、MCP、SDK 和声明式配置；GUI 面向理解、审查与治理：查看 Agent 规划与生成内容、审查 SQL/DAG/日志与结果、观察权限与风险状态、在异常和不确定时接管。完整流程是：人通过 GUI 定义目标 → Agent 通过 CLI/API 调用 Skill → Runtime 执行 → GUI 展示 DAG、SQL、日志与风险 → 人批准或接管。

Human-in-the-loop 不是审批一切，而是守住风险边界。所有 Agent 操作先经 Policy 自动筛选，再按风险分级处置：低风险自动执行、中风险执行后通知、高风险人工审批、极高风险禁止执行或双人审批。新原则只有三条：按风险介入，而不是按步骤介入；审批关键决策，不审批机械动作；人定义 Policy，Agent 在 Policy 内执行。具体到场景：读取元数据、开发环境查询、生成文档是低风险；开发环境创建任务、低成本验证是中风险；生产写入、Schema 变更、核心指标修改是高风险；删除核心表、批量覆盖、敏感数据高风险操作是极高风险。"人不应该成为 Agent 的每一步审批器，而应该成为风险边界的设计者。"

责任划分与反馈修正

上线后的责任划分必须清楚：业务签收由业务负责人定义业务目标、约束条件、验收标准；平台治理由平台负责人定义 Policy、权限、审批、回滚和环境边界；自动执行由 Agent + Harness 补齐 Context、生成 Plan、调用 Skill、执行 Runtime，并把日志、验证与异常完整回传；审计确认由审查人与审计系统只在高风险、不确定或与验收标准冲突时接管，并对关键决策留痕与复盘。只有三类情况需要人接管：高风险动作会改写核心数据或关键业务状态；异常无法自动恢复且回滚与重试边界不明确；结果与验收标准冲突必须由人最终签字裁决。"客户最终买单的不是一个会写 SQL 的演示，而是一套目标、权限和结果都能闭环担责的系统。"

真正的 Agentic 系统，必须能从执行反馈中修正自己。Feedback Loop 有七个环节：Plan → Execute → Observe → Diagnose → Repair → Validate →
Continue/Rollback/Escalate，并由 Execution Memory（执行记忆/上下文/经验沉淀）持续支撑。反馈来源包括执行状态、日志、指标、数据质量、血缘影响和人类反馈；Agent 的应对包括自动修复（定位根因，修复配置、参数、SQL 或流程问题）、调整规划（优化计划、资源、顺序与策略）、停止或升级（无法安全修复时停止执行或升级给人）。"Agentic 的关键不是自动执行，而是执行之后知道发生了什么。"

五、实践：从案例到路径

Case Study：一次完整的数据工程闭环

这个 Demo 不是 AI 会写 SQL，而是 Agent 可以完成数据工程闭环。从业务目标出发，Agent 依次完成：发现数据 → 创建集成任务 → 执行数据同步 → 生成 SQL 转换 → 生成工作流 DAG → 执行工作流 → 读取日志与诊断 → 修复与重试 → 人工可视化审查。整个过程中，Agent Planning 负责规划，Harness Control 负责控制，Runtime Execution 负责执行。"这个 Demo 的意义，不是证明模型能够生成 SQL，而是证明 Agent 可以通过 Harness，把多个确定性工程系统组织成一次完整交付。"

两个具体的 Harness 落地

理论必须落在产品上才有说服力。白鲸开源维护的两个 Apache 顶级开源项目 ——SeaTunnel 与 DolphinScheduler，恰好构成了 Harness 落地的两个关键侧面：前者负责 "数据集成能力"，证明一个底层工具如何被改造成 Agent 可调用的受控 Skill；后者负责 "工程执行秩序"，证明 Agent 生成的内容如何变成可运行、可观察、可审查的工程程序。一个管数据怎么进来，一个管任务怎么可靠地跑完，合在一起，就是五层架构中 L1 Runtime 与 L2 Harness 在真实项目上的具体呈现。

SeaTunnel CLI：把数据集成变成一个 Skill

SeaTunnel CLI 的能力包括：数据源发现（Source/Schema/Table/Field）、自动生成 SeaTunnel Job、执行批量同步或 CDC、读取结构化执行反馈（状态/日志/行数/错误）、根据错误修复并重试。Agent Intent 会转化为 SeaTunnel Skills——DiscoverSource()、InspectSchema()、CreateBatchSync()、CreateCDC()、ValidateMapping()、RunSyncJob()——再由 Data Integration Runtime 完成 Execute → Logs → Repair → Retry 的闭环。

未来，SeaTunnel CLI的完善方向是 Context-aware Mapping、从 Batch/CDC 扩展为完整 Data Flow Skill、Self-healing Data Integration 和 AI-ready Data Pipeline。从它的发展路线来看，"SeaTunnel CLI 的终点不是命令行，而是 Data Integration Skill。"

DolphinScheduler：把生成内容变成工程秩序

DolphinScheduler 的能力包括：生成 Workflow DAG、自动建立任务依赖、创建真正的工程资产（
Definition/Instance/Version）、执行与监控（状态/时间/重试/日志）、失败修复与节点重跑、GUI 提供人类审查。从 Traditional Workflow（人定义每个 Task、人配置依赖、Scheduler 执行 DAG）到 Agentic Workflow（人定义业务目标、Agent 生成执行计划、Policy 检查边界、DolphinScheduler 执行 Workflow、Agent 修复/人类审查）。

未来，DolphinScheduler 会走向 Policy-aware Orchestration、Human Review Gate、Self-healing Workflow 和 Multi-Agent Coordination。

数据工程师不会消失，只会升级

对于职业前景，代立冬给出了乐观判断。数据工程师的角色正在经历五个阶段的演进：SQL Writer（专注编写 SQL 解决单点问题）→ Pipeline Builder（配置数据流程与任务管道）→ Workflow Operator（运行与监控数据工作流）→ Platform Engineer（构建平台能力与基础设施）→ Agent Capability Designer（设计 Agent 能力与工程体系）。

数据工程师过去的主要工作是写 SQL/Python/Spark、配置 Connector/ETL、拖拽 DAG/设置调度、看日志/修复失败任务、编写数据文档；而在未来，他们的核心工作将变为五种设计：Context Designer（设计数据与业务上下文，让 Agent 真正理解）、Skill Designer（设计可复用的数据技能，让 Agent 会用会组合）、Policy Designer（设计规则与约束策略，让 Agent 可控可信）、Evaluation Designer（设计评估指标与方法，让 Agent 可衡量可持续）、Agent Engineering Commander（统筹工程体系与交付，放大数据工程能力）。

数据建模、业务抽象、架构设计、数据治理、风险判断、责任意识这六种能力不会消失——它们恰恰是设计 Context、Skill、Policy 的前提。

所以，如代立冬所说，"未来最有价值的数据工程师，不是写最多 Pipeline 的人，而是能够把数据工程能力组织给 Agent 使用的人。"

落地路径从低风险高频开始

在 Harness 落地路径上，代立冬建议从低风险高频任务开始，而非先替代整条链路。原则是先证明它能在边界清晰的任务里稳定交付，再逐步扩大自动执行范围，才是企业真正可接受的上线方式。

适合先进入第一阶段的有四类任务：数据发现、元数据补全和 Schema 理解这类读多写少的任务；SQL 草案生成、规则校验和 DAG 组装这类"先生成、后审查"的任务；集成任务创建、参数编排和环境检查这类可模板化的重复工程；日志诊断、修复建议和重试编排这类可回放、可验证的运维闭环。

不建议第一波直接全自动放权的也有四类任务：生产核心表删除、覆盖、批量改写等不可逆动作；关键指标口径改写和跨域主数据逻辑重构这类高业务责任任务；缺少审批链、缺少回滚路径的 Schema 变更和高成本写入；业务责任边界不清、结果无法自动核验的跨团队复杂流程。

总的来说，Harness 落地整个路径可以分三个阶段：协作式辅助——读元数据、生成草案、给人审，先让系统学会被验证；受控执行——把非核心、可回滚、可校验的任务交给 Harness 执行；治理放权——只有在 Policy、审计和回滚成熟后，才扩大自动权限边界。

结语

数据工程的未来不是无人化，而是"人定义目标，Agent 执行任务，Harness 约束交付"。用公式表达就是：Business Intent + Agent Intelligence + Enterprise Context + Engineering Skill + Policy & Control + Human Review = Trusted Agentic Data Engineering。

"Agent 负责生成，Runtime 负责执行，Harness 负责让结果可信。"这一范式变革的本质，是在模型之外搭建一套能够支撑 Agent 持续执行的运行体系——不再是简单地优化提示词或扩展上下文，而是从工程层面重构数据平台与人的协作方式。而这，或许正是 Agentic AI 时代数据工程平台的未来。