随着大模型与 Agent 技术逐步进入企业数据领域，数据平台的人机交互方式也在发生变化：用户可以先用自然语言描述业务目标，再由 Agent 理解意图、补充上下文、规划任务，并调用平台能力完成执行。
但对于企业级数据平台而言，真正的难点并不是让 AI "会聊天"，而是如何让 AI 在生产环境中安全地执行、可靠地验证，并对整个过程进行审计。
在近期举行的 Cisco Webex 与 Apache DolphinScheduler 社区分享中，李庆旺围绕"基于 Apache DolphinScheduler 的企业级 Data Agent 实践"，介绍了企业数据平台从调度底座向自然语言数据入口演进的路径。
视频回放：https://weixin.qq.com/sph/AXRT6qo0en
讲师介绍
李庆旺：Cisco Webex 大数据平台开发工程师、Apache DolphinScheduler Committer。
整场分享主要围绕四个部分展开：从调度平台到数据入口、Agent 平台定位与架构、治理执行与验证闭环，以及能力扩展与落地准备。
一、从调度平台到数据入口
1. 从 DolphinScheduler 二次开发开始
Apache DolphinScheduler 功能强大，但在企业落地时，仍需要结合内部业务和治理要求进行适配。通过平台化二次开发，可以将其通用调度能力进一步封装为企业数据平台，为不同团队提供统一的生产入口。
这一过程首先解决的是企业内部不同数据团队使用方式不统一的问题。
在统一接入层面，可以围绕 Project / Namespace、租户、权限以及资源组 等能力，为不同团队建立统一的生产入口。
在任务层面，则可以进一步支持 SQL、Spark、Flink 等计算引擎和 ETL 等任务形态，同时对自定义任务和参数建立统一规范。
进入生产之后，还需要解决发布治理问题，包括环境、版本、依赖，以及审批、调度和补数等生产流程。
与此同时，平台还需要具备完整的运维能力，包括任务状态、日志、告警，以及重跑、诊断和审计。
经过上述平台化建设，DolphinScheduler 的角色进一步延伸：它成为 SQL、Spark、Flink、ETL 等生产任务的统一编排与运行底座。
2. 平台共享之后，新的瓶颈出现了
当调度能力完成平台化共享后，新的瓶颈往往不再位于调度本身，而是出现在任务开发、上线和运维等前后环节。
一次生产任务真正落地，需要经过发现、开发、上线和排障等多个环节，而这些环节往往仍然高度依赖专家。
首先是发现难。
企业的数据资产可能分散在不同的表、Topic 和数据系统中，Owner 和数据口径也可能分散在不同团队。用户知道自己想要什么数据，却未必知道应该使用哪张表、哪个 Topic，或者应该找谁确认。
其次是开发难。
SQL、代码和配置往往具有较高的专业门槛，需要数据开发人员或平台专家参与。对于不了解底层技术的业务用户而言，从一个业务需求转化为可运行的数据任务，本身就是一道门槛。
然后是上线难。
一个任务能否进入生产，不只是"代码能不能运行"的问题，还涉及环境、权限、参数以及潜在风险。用户需要判断这些因素，而这些判断同样依赖平台和领域专家。
最后是排障难。
出现问题之后，往往需要跨越日志、指标、源端和目标端寻找证据。问题定位不再只是查看某一个任务的运行状态，而是需要结合多个系统的信息进行分析。
因此，平台越开放，专家支持反而越容易成为新的瓶颈：用户知道业务目标，却仍然需要依赖专家完成数据发现、开发、上线和运维。
这也成为 Data Agent 介入企业数据平台的重要切入点。
二、Agent 平台定位与架构
如果说传统数据平台解决的是"如何执行数据任务"，那么 Data Agent 要解决的则是"用户如何以更自然的方式使用数据平台"。
Data Agent 的核心可以归纳为三个动作：
理解业务意图、在治理边界内执行，并用可追溯证据验证结果。
1. Agent 平台：治理型 AI 操作层
企业级 Data Agent 并不是简单地给数据平台增加一个聊天窗口，而是构建在生产治理体系之上的 AI 交互与操作层。
其核心定位可以概括为：
自然语言数据操作 + 生产级治理。
具体来看，平台需要同时具备四个方面的能力。
第一是 Intent-driven（意图驱动）。
用户不再需要首先学习具体 API 或平台操作流程，而是直接描述目标。Agent 根据用户的目标规划执行步骤，并选择相应工具完成任务。
第二是 Governed（受治理约束）。
AI 所做的每一个生产动作，都需要受到身份、权限、风险和审批等约束。Agent 可以进行规划，但不能绕过企业已有的治理边界。
第三是 Auditable（全程可审计）。
一次 Agent 操作不应该只留下最终结果，还需要记录会话、工具调用、决策、审批以及最终产物，从而形成完整的操作留痕。
第四是 Verifiable（结果可验证）。
任务不能因为 Agent 生成了 SQL 或配置就直接视为成功。发布前需要进行验证，运行之后还需要结合日志和数据证据对最终结果进行确认。
因此，Data Agent 的核心原则非常明确：AI 可以负责规划，但所有生产动作都必须经过统一的治理与验证层（AI Harness）。
2. 自助式 Data Agent：六类工作场景的变化
在这样的定位下，Data Agent 并不是只解决"写 SQL"这一件事情，而是覆盖数据工作中的多个环节。
在流水线开发方面，过去用户需要手写代码、SQL 和配置；Agent 则可以让用户直接用自然语言描述需求。
在故障排查方面，过去需要人工搜索日志和指标；Agent 可以自动收集相关证据并辅助诊断。
在平台操作方面，过去主要依赖专家操作 UI 或 API；Agent 则转向意图驱动的受控执行。
在数据发现方面，过去需要分别搜索作业、表和 Owner；Agent 可以通过自然语言检索元数据。
在代码审查方面，过去代码评审所需的上下文往往分散在不同地方；Agent 可以结合代码 Diff、沙箱、风险和审计信息提供辅助。
在知识复用方面，过去专家需要反复回答相同的问题并提供支持；Agent 可以将这些经验进一步沉淀为领域知识和可复用的 Agent 能力。
因此，变化并不是简单地用 AI 替代人工操作，而是从过去的"手工构建、搜索、评审和支持"，逐渐转向有治理约束的 AI 协作。
3. 从一句问题到一条生产闭环
从用户视角来看，Data Agent 的目标是通过一个统一入口覆盖完整的数据工作流程。
用户可以首先询问：
"这个作业做什么？输入、过滤、聚合和输出是什么？"
Agent 对应的是发现与理解。
进一步，用户可以提出：
"从 Kafka 读取数据，生成 ETL 处理流程，并配置为每日运行的工作流。"
这进入开发与发布阶段。
当任务出现异常时，用户可以直接询问：
"昨晚延迟突然升高，帮我定位原因并给出修复建议。"
这对应监控与排障。
在数据分析场景中，用户还可以要求：
"发现可信表，分析指标，并生成可解释的仪表板（Dashboard）。"
这对应分析与可视化。
同时，Agent 还可以帮助检查作业的资源使用情况，并判断资源配置是否过度。
也就是说，一个统一入口最终可以覆盖：
Data Engineering · Data Discovery · DataOps · Insight。
4. 总体架构：企业级 AI Harness
要让上述能力真正进入企业生产环境，仅有 Agent 本身还不够，还需要一个完整的企业级 AI Harness。
整个架构可以分为几个层次。
最上层是交互入口，面向用户提供 Web、CLI 和 MCP Client 等方式，并可接入 Codex、Claude 等 AI 客户端。
下面是 Agent 编排层，负责意图理解、任务规划、上下文发现、工具编排以及证据总结。
再往下是整个架构的关键------AI Harness。
这一层负责身份与权限、沙箱验证、风险策略、审批、幂等，以及审计和 Trace。它并不直接替代 Agent，而是为 Agent 的生产动作提供治理边界。
再下面是工具与执行层，包括 Discovery、SQL / Spark / Flink / ETL、DS Workflow 和 Observability。
底层是企业生产系统，包括 Kafka、Catalog、Lakehouse、OLAP 和 Compute 等。
其中，Apache DolphinScheduler 继续承担编排、调度与运行能力。
与此同时，平台状态与审计存储还需要记录 Session、Approval、Sandbox Result、Artifact 和 Trace 等信息。
因此，这套架构并不是让 Agent 直接调用生产系统，而是在 Agent 和生产系统之间设置治理与验证层。
5. Agent Platform：构建领域 Agent 生态
在统一平台底座之上，还可以进一步形成领域 Agent 生态。
其中包括负责 Flink SQL、Spark、ETL 和 Workflow 的数据工程 Agent ；负责审批编排、策略判断和风险阻断的审批策略 Agent ；负责本地语法、Kafka 样例和远程沙箱验证的沙箱验证 Agent。其中，高风险场景仍保留人工审批环节。
此外，还有负责状态、日志、Checkpoint 以及源端/目标端证据的工作流观测 Agent ，负责元数据、Owner、资源、血缘的发现与血缘 Agent，以及负责 Session、Approval、Trace 和失败证据的平台支撑 Agent。
这些 Agent 并不是各自建立一套独立的治理体系，而是共享同一个底座：
MCP 入口、Identity、Sandbox、Policy、Approval、Audit、Trace、Idempotency。
这也是企业级 Agent 与单点 AI 应用之间的重要区别：领域能力可以不断增加，但治理能力应该尽可能统一。
三、治理执行与验证闭环
如果说第二部分解决的是"Data Agent 应该是什么"，那么第三部分解决的就是"Data Agent 如何安全地执行"。这一部分概括为三个关键词：
统一治理模型，三条执行路径；风险分级审批与前置验证；上线后以运行和数据证据闭环。
1. 治理执行模型：统一治理模型，三条路径
一个完整的 Agent 请求，可以被拆分成六个步骤。
第一步是用户意图：用户通过自然语言提出业务请求。
第二步是Agent 计划：Agent 根据请求生成步骤、SQL 或配置。
第三步是上下文发现：进一步获取元数据、Owner、历史等信息。
第四步是Harness 检查：检查身份、沙箱、风险，并识别所需的审批方式。
第五步是治理执行：通过受控封装层（Wrapper）调用 API。
第六步是审计与结果：记录执行证据，并向用户返回最终结论。
在这个基础上，平台进一步将执行分成三条路径。
Read Path：读路径
读路径主要用于发现、状态、日志和元数据等信息。它不修改生产状态，并在记录审计信息后返回结果。
Change Path：变更路径
变更操作需要经过更严格的控制。它的典型流程是沙箱 → 风险策略 → 自动 / 人工 / 阻断 → 批准后幂等执行。
也就是说，真正影响生产状态的操作不能因为 Agent 生成了一个正确的调用参数，就直接执行。
Observe Path：观测路径
观测路径则负责在任务发布之后，或者用户主动询问时，收集运行、源端、目标端以及日志等证据。
因此最终形成一个清晰的原则：每个请求都有路径，每个高风险动作都有闸门，每个结果都可审计。
2. 风险分级审批：自动、人工与阻断
企业生产环境中的操作不宜采用单一的审批方式，可以按风险划分为三类：
对于低风险操作，如果用户对目标资源具有操作权限、沙箱验证已经通过，并且用户已经确认意图，就可以自动批准并进入治理执行。
对于高风险或高影响操作，例如操作他人或共享资源、修改共享集群，或者 Owner 边界并不明确，则需要暂停并触发人工确认。
还有一类情况需要直接阻断，例如身份无效、语法或数据验证失败、企图未经验证直接发布生产，或操作可能造成危险的大范围影响。
这种设计的重点并不是为所有操作统一增加人工审批，而是根据风险匹配相应的处置机制和执行路径。
低风险操作可以保持效率，高风险操作获得人工控制，而明显不安全的操作则直接停止。
3. 前置验证：把错误挡在发布之前
传统的数据任务流程可能演变为创建 → 发布 → 发现错误 → 生产事故。
问题在于，很多错误只有进入生产环境之后才会暴露。Agent 驱动的流程则试图将验证前移。
首先是 Plan，生成任务计划。
然后进入 Local Sandbox，进行语法和逻辑验证。
之后可以进一步进入 Remote Sample，利用 Kafka 样例或者集群沙箱进行验证。
接着进入 Result Analysis，对 Schema 和业务风险进行分析。
最后才进入 Create & Release，完成安全发布。
这里的核心并不是依靠某一个单独的验证环节，而是结合本地执行、真实样例数据、远程沙箱和结构化结果分析，尽可能把错误和风险挡在生产发布之前。
4. 上线后验证：从提交到结果证实
即使一个任务已经通过前置验证并成功发布，也不意味着整个流程已经结束。
真正的生产闭环还需要从任务创建一直追踪到最终业务结果。
完整流程包括创建 / 发布 → 检查运行状态 → 观察日志 → 诊断源 / 目标 → 验证业务结果 → 反馈结论。
验证过程中需要关注的证据包括运行状态，如 Running、Failed；近期日志和错误信息；Kafka 消费情况；以及目标表是否完成写入。
因此，Data Agent 最终返回给用户的不应该只是"任务已经提交"或者"API 调用成功"，而应该尽可能回答：
任务到底有没有正常运行，数据有没有真正流动，目标端有没有产生预期结果。
这使得 Agent 的验证从"调用成功"进一步走向"结果证实"。
四、能力扩展与落地准备
当治理、执行和验证形成统一底座之后，Data Agent 的能力就不必局限在某一个场景，而可以持续向不同数据领域扩展。
这一阶段的核心思路是，领域 Agent 可持续扩展，复用同一套治理与审计底座，从专家能力走向平台能力。
1. 平台扩展：每个领域都可以成为 Agent
首先可以构建预测运维 Agent，用于提前识别故障风险，给出资源调整建议，并在策略约束下执行修复。
在数据发现方面，可以构建通用发现 Agent，跨作业、Topic、表、Owner、血缘以及质量信号进行检索。
在数据开发方面，可以构建流水线生成 Agent，支持从文档生成流水线、从 Schema 生成工作流，并实现跨引擎转换。
在数据分析方面，可以构建业务洞察 Agent，负责发现可信数据，生成查询、图表和解释。
在数据治理方面，可以构建数据质量 Agent，识别 Schema 漂移、分布异常和迟到数据，并辅助完善治理标签。
此外，还可以构建成本优化 Agent，分析资源使用情况，并推荐运行时、并行度以及资源保留策略。
这些能力虽然属于不同领域，但并不意味着每增加一个 Agent 就需要重新建设一套安全机制。
整个体系的核心目标（North Star）是：
领域能力不断扩展，生产安全仍由统一的平台 Harness 提供保障。
2. 业务价值：把专家经验扩展为平台能力
从企业实际价值来看，这套架构主要体现在四个方面。
首先是效率。通过自然语言和 Agent，可以更快创建流水线，同时减少大量手工平台操作。
其次是质量。通过前置验证，让问题尽可能在生产之前暴露，从而提升工作流可靠性。
第三是治理。AI 的每一个动作都绑定身份，策略决策也能够实现全程审计。
第四是规模。领域 Agent 可以复用，从而减少企业对专家重复性支持工作的依赖。
最终，数据平台的形态也会随之发生变化：
当前是 UI / API 驱动的专家平台，未来则可能走向 AI 原生的 Agent 平台（AI-Native Agent Platform）。
这里的关键并不是单纯增加一个 AI 对话入口，而是通过受治理、可复用、理解生产语义的 Agent，把原本依赖专家个人经验的能力沉淀并复用到平台中。
总结：从调度平台到自然语言数据入口
回到整场分享的核心，可以看到，Data Agent 并不是要取代 Apache DolphinScheduler，而是在 DolphinScheduler 已有的生产编排能力之上，改变用户进入和使用数据平台的方式。
首先，调度底座不变。Apache DolphinScheduler 继续承担工作流编排、任务运行、监控和运维等核心能力。
其次，入口发生变化。用户不再需要从具体的 UI、API 或任务配置开始，而是可以从描述业务目标开始，由 Agent 衔接后续的数据发现、开发、发布和排障流程。
更重要的是，限制与治理机制为安全执行提供保障。Intent-driven、Governed、Auditable、Verifiable 四个原则共同约束生产动作，让 Agent 的能力始终处于企业治理边界之内。
因此，企业级 Data Agent 真正需要解决的问题，并不是"AI 能不能完成一次数据操作"，而是能否让这次操作在真实生产环境中有权限、有边界、有验证、有证据，并能够持续运行。
正如本次分享最后总结的那句话：
Data Agent 的价值，不是"会聊天"，而是让正确的数据工作安全、持续、可验证地运行。
这也意味着，随着 Data Agent 不断深入企业数据平台，Apache DolphinScheduler 的核心编排与运行能力仍然是整个体系的重要基础。在其之上构建的 AI Harness，则进一步连接自然语言交互、领域 Agent、治理策略、审批、沙箱、审计和结果验证，推动数据平台从传统的专家驱动平台 逐步走向AI 原生的 Agent 平台。